Ruddy Lee 分享空間

前言

這是前面三篇文章的總結，我從來沒有這麼做過，把一篇超過20000字的文章切分成三篇來登載。這是第一次嘗試，結果是按耐不住心情，一口氣就刊登出來了。現在想再回頭也難了，就把觀念在這裡做個總結。

目的是為了在 Product Backlog Item 進入開發前，先增加 Hypothesis backlog，讓 PBI 和 「項目的假設成果」一起進入 Sprint 的開發過程，SP後便能務實的對照開發的意義和價值。三篇文章如下:

• 為什麼「累加功能」是產品開發中最昂貴的錯誤
• 為什麼 PO 不能只當功能管理者
• Hypothesis Backlog：PO 真正的 Backlog

敏捷也需要改善，變得更敏捷一些

在很長一段時間裡，產品開發的進步，被理解為「做得更快、更穩、更有效率」。Scrum 之初；我們學會了如何拆需求、排序 Backlog、跑 Sprint，也學會如何用工具與流程，把不確定性包裝成可控的進度。然而，

當 AI 開始大幅降低「做出東西」的成本時，一個原本被掩蓋的問題，反而被放大了出來：

如果做一個功能幾乎不再昂貴，
那麼真正昂貴的，究竟是什麼？

答案並不新，卻愈來愈清楚；是錯誤的承諾，也就是品質。

---

保守型的開發方式，一定會挑選累積型的開發方式，讓進度緩緩向前，大家的心情也會穩定許多。但到了AI 時代，開發成本與時間已經縮短到幾天內的時間了，似乎弄清楚方向會比迅速累積功能要重要許多。所以，未來的產品開發，所謂真正的專業，是指知道什麼不要累加，避免多作無益的開發行為。

---

功能導向的極限：我們太早承諾了解法

功能導向的產品開發，有一個隱而未說的前提：
問題已經被正確理解，剩下的只是把解法做好。

於是，需求被快速翻譯成功能，功能被拆解成 PBI，PBI 被穩定地交付。從外表看，一切井然有序，彷彿風險正在被逐步消化。最後專案開發完畢，上市後；卻是對產品市場沒有太大幫助，一種可有可無的現象，不免讓人懷疑當初的決策是不是太草率了，投入了開發能量卻走錯了方向。

但實際上，風險只是被延後了。這正如《韓非子》所言：

「不知其本，而事其末，雖巧必困。」

當我們忙於管理功能這個「末」，卻沒有治理假設這個「本」，
再精巧的流程，也只是在錯誤方向上愈走愈深。

【註釋 1】功能導向（Feature-driven）並非錯誤方法，而是適用於問題高度確定的情境；在高度不確定的環境中，卻容易掩蓋認知風險。

---

敏捷與精實真正要解決的，其實不是速度

敏捷（Agile）與精實（Lean）經常被解讀為「更快交付」的方法，但這種理解其實過於表層。

它們真正試圖處理的，是一個更根本的問題：

• 當需求本身不穩定時，我們是否還假裝它是穩定的？

敏捷引入短迭代與回饋，精實強調消除浪費與縮短學習迴路，兩者的交集，其實都指向同一件事，讓學習發生得更早(一種 fail fast learn fast的精神)。

問題在於，當這些方法被簡化為流程與儀式時，「學習」往往退居其次，功能交付再次成為唯一可被衡量的成果。

【註釋 2】團隊已經在實踐敏捷開發了，卻對市場產品沒有太大幫助，為甚麼?

這也是為何許多團隊「看起來很敏捷」，卻仍然在做錯的產品。

---

假設驅動：從「做什麼」轉向「相信什麼」

所謂「假設驅動」，並不是多寫幾條假設，而是承認一件事：

真正需要被管理的，不是功能數量，而是尚未被驗證的相信。

在假設驅動開發（Hypothesis-Driven Development, HDD）的視角下，每一個產品決策，背後都隱含著一個或多個假設；關於使用者、關於價值、關於可行性、關於成長。

差別只在於：
這些假設，是被清楚說出來、排序、驗證，還是被默默藏在功能背後，等結果揭曉。

《中庸》有一句話，恰好點出假設驅動的精神：

「凡事豫則立，不豫則廢。」

這裡的「豫」，不是過度規劃，而是對未知有所預備。

【註釋 3】假設驅動（Hypothesis Governance）就是fail fast learn fast

強調的不是「避免犯錯」，而是「避免在關鍵假設尚未被驗證前，做出不可逆的承諾」。

---

為什麼 AI 讓假設驅動成為必然，而不是選項？

• AI Agent 的出現，讓產品開發進入一個新的階段：
  嘗試的成本趨近於零，但承諾的後果依然真實。

當 AI 能快速生成原型、方案與分析時，組織面臨的風險不再是「做不到」，而是「做太多、太快、太早」。

如果沒有假設驅動：

• Backlog 會快速膨脹
• 功能會不斷累加
• 但真正被驗證的理解，卻沒有同步增加

結果就是一種新的錯覺：產出暴增，學習停滯。

這也是為什麼，在 AI 時代，產品開發的下一步，不是「更強的執行力」，而是更清楚的節制力。

【註釋 4】AI 擅長擴張「可能性空間」，但無法替代「是否值得承諾」的價值判斷。

從「功能導向」到「假設驅動」，意味著角色與結構的轉變

當假設成為治理對象，產品角色的責任也必須隨之調整。

Product Owner（PO）不再只是功能管理者，而是：

• 假設的承擔者
• 學習的守門人
• 承諾邊界的決策者

Backlog 的重心，也從「待完成事項」，轉向「待驗證的理解」。
功能不再是起點，而是某個假設被驗證後的結果。

這並不是否定 Scrum 或既有流程，而是讓它們回到最適合的位置，在理解之後，穩定交付。

【註釋 5】這正是 Hypothesis Backlog 被視為「PO 真正的 Backlog」的原因。

---

結語：下一步，不是更快，而是更清楚

產品開發的下一步，並不是再多一套工具或流程，而是一個更成熟的轉向：

從管理功能，轉向治理不確定性。

當我們開始問「這個功能是否值得被做」，而不只是「能不能被做得更好」，
產品開發才真正跨過了一個世代的門檻。

《易經》說：「知止而後有定。」

在一個什麼都做得到的時代，知道什麼該先停下來驗證，或許才是最稀缺、也最昂貴的能力。

• 一個極為重要的工具，教你什麼功能該作 :

這張 Hypothesis Prioritization Canvas，可以作為這個系列文章的假設思維的判斷工具：

它不是幫你決定「要做什麼功能」，而是幫你決定「哪些假設值得被承諾」。

• 這張圖用兩個維度幫助 PO 與團隊做關鍵取捨：
  縱軸是價值高低，橫軸是風險高低。

• 右上角（高價值 × 高風險｜Testing）
  這裡是最值得投入探索資源的地方。假設一旦成立，回報巨大，但不確定性也最高，因此應優先設計實驗、快速學習，而不是急著全面開發。
• 左上角（高價值 × 低風險｜Ship & Measure）
  這些假設多半已被部分驗證，重點不在探索，而在快速交付、上線後量測與追蹤成效。
• 左下角（低價值 × 低風險｜Don’t test, usually don’t build）
  常被誤解為「不重要」，其實屬於必要但不具差異化的項目（如上桌門票）。不需大量驗證，但在必要時仍得完成。
• 右下角（低價值 × 高風險｜Discard）
  這些是假設治理中最關鍵的「放棄區」。高風險卻低回報，繼續投入只會消耗組織耐心，應果斷捨棄。

總結：

這張圖提醒我們，產品開發的成熟，不在於做了多少功能，而在於是否把有限資源，用在最值得被驗證、被承諾的假設上，這才是產品真正的品質。

---

註釋與延伸說明

1. 功能導向（Feature-driven Development）：以功能交付為主要進度與價值衡量方式的開發模式。
2. 敏捷與精實的誤用：當方法被簡化為儀式與流程，而忽略其背後的學習目的。
3. 假設驅動（Hypothesis Governance）：一種將未驗證假設視為核心風險來源的管理觀點。
4. AI Agent 的角色限制：AI 可協助生成與分析，但無法承擔價值與責任判斷。
5. PO 的角色轉變：從需求翻譯者，轉為理解與承諾的責任人。

在前兩篇文章中，我們已經拆解了兩個常被忽略、卻彼此高度相關的問題：
第一，為什麼「累加功能」其實是產品開發中最昂貴的錯誤；
第二，為什麼 PO 不能只當功能管理者，而必須承擔「理解是否正確」的責任。

如果這兩個觀點成立，那麼接下來自然會出現一個關鍵問題：

• 如果 PO 不該只管理功能，
• 那麼 PO 到底應該管理什麼？

答案，正是 Hypothesis Backlog（假設待辦清單）。

---

為什麼「功能 Backlog」不足以支撐學習？

在多數 Scrum 團隊中，Backlog 被視為產品管理的核心工具。
但我們必須誠實面對一件事：傳統 Product Backlog 只擅長管理「要做什麼」，卻幾乎無法管理「我們相信什麼」。

一個典型的 PBI，通常描述的是：

• 功能行為
• 使用情境
• 驗收條件

但它極少明確指出：

• 這個功能背後的假設是什麼
• 若結果不如預期，代表哪個理解是錯的

於是，Backlog 看起來井然有序，實際上卻隱含大量「未被命名的不確定性」。

這就像《韓非子》所說的那句話：「不知其本，而事其末，雖巧必困。」

當我們只管理功能這個「末」，卻不管理假設這個「本」，團隊遲早會在看似順利的交付中，發現新增功能對產品的影響可有可無，陷入一種方向性的困境。

---

Hypothesis Backlog 的本質：把「相信什麼」變成可管理的對象

Hypothesis Backlog 的核心精神，不是多一個清單，而是改變管理的單位。

在這個結構中：

• 功能，不再是起點
• 假設，才是起點

每一個項目，描述的不是「要做什麼」，而是：

• 我們目前相信什麼？
• 這個相信值不值得被驗證？
• 若它是錯的，後果有多嚴重？

因此，在 Hypothesis Backlog 裡，「完成」的定義不再是「做完」，
而是 被驗證、被否定，或被修正。這一點，與傳統待辦事項的邏輯截然不同。

【註釋】Hypothesis Backlog 的概念，可追溯至 Lean Startup、Lean Enterprise 對「未驗證假設」的風險管理觀點，但並非單一框架或工具的專利。

---

PO 為何必須擁有 Hypothesis Backlog？

在假設驅動開發（HDD）中，PO 的核心責任是「承擔假設」，而非「保證功能交付」。

而 Hypothesis Backlog，正是讓這個責任得以落地的結構。

它幫 PO 做了三件關鍵的事：

第一，把策略層的模糊信念，轉化為可被討論、排序的對象。
第二，讓團隊在動手之前，就知道「這一次的工作，是為了驗證什麼」。
第三，讓學習不再是事後解讀，而是事前就被期待的產出。

Hypothesis Backlog 不是新增計畫，而是先承認不知道(做假設)，並為這個不知道預留位置。

---

Hypothesis Backlog 與 PBI 的正確關係

一個常見誤解是：
「既然有 Hypothesis Backlog，那是不是就不需要 PBI 了？」恰恰相反。

PBI 並沒有消失，而是角色改變了。

在這個結構中：

• Hypothesis Backlog 管理的是「學習的優先順序」
• PBI 則是某一條假設之下，用來設計與執行實驗的「工具」

換句話說：

• 不是「想做功能 → 寫 PBI」，
• 而是「想驗證假設 → 設計實驗 → 產生 PBI」。

這也正是為什麼，在沒有驗證目標之前，PBI 不該被排進 Sprint。
否則，Scrum 只會成為一台高速運轉、卻方向未明的機器。

---

為什麼 Hypothesis Backlog 在 AI 時代更關鍵？

AI 的出現，徹底改變了產品開發的「經濟結構」。今天的問題，不再是「想不出東西做」，而是「什麼都做得出來」。在這樣的環境下，假設不再稀缺，判斷才是稀缺資源。

如果沒有 Hypothesis Backlog：

• 團隊會不斷把 AI 生成的想法轉成功能
• Backlog 會快速膨脹
• 但真正被驗證的理解，卻沒有同步累積

結果就是：產出暴增，學習停滯。

Hypothesis Backlog 的角色，正是用來「治理假設洪流」，不是阻止嘗試，而是幫助組織判斷：哪些嘗試值得發生。

---

結語：Backlog 的真正價值，不在於「列出要做的事」

Backlog 之所以重要，從來不是因為它能排事情，而是因為它能反映組織真正重視什麼。

如果 Backlog 裡只有功能，那麼組織真正重視的，就只是交付。

但如果 Backlog 裡有假設，那代表組織願意為「理解是否正確」負責。

知道什麼該先驗證，知道什麼不該急著做，這才是 Hypothesis Backlog 作為「PO 真正 Backlog」的意義所在。

---

註釋與延伸閱讀

1. Hypothesis-Driven Development（HDD）：一種以可被證偽的假設作為開發起點的產品與系統開發思維。

2. Lean Enterprise：強調企業風險往往來自尚未被驗證的假設，而非執行效率。
3. PO（Product Owner）：在此脈絡下，PO 是假設與學習的責任承擔者，而非單純的需求翻譯者。

在上一篇文章中，我們談到「累加功能」為何會成為產品開發中最昂貴的錯誤。真正的問題，並不在於工程能力或交付速度，而在於：我們往往在還沒真正理解問題之前，就過早承諾了解法。
而這個錯誤，最容易在一個角色身上集中發生，就是Product Owner(PO)。

如果說假設驅動開發（Hypothesis-Driven Development, HDD）是在處理「我們是否做對的事」，那麼 PO 的角色，就不可能只停留在「功能是否被完成」。

---

功能管理，其實是最低風險的錯位

在多數 Scrum 團隊中，PO 的實際工作內容往往被壓縮成三件事：
蒐集需求、寫 PBI、排序 Backlog。
久而久之，PO 被默認為「功能管理者」，負責確保功能被定義、被排序、被交付的角色。

這樣的分工乍看合理，甚至安全。因為只要功能準時交付，PO 就「完成了責任」。但問題在於：

功能完成，並不等於問題被解決。

當 PO 只管理功能時，真正被忽略的，其實是那個更根本的問題:

我們為什麼相信，這個功能值得被做？

功能管理，看似中立，實際上卻是一種責任轉移：
把「是否正確」的風險，悄悄交給了未被明說的假設。

---

PO 真正擁有的，不是 Backlog，而是理解

在 HDD 的視角下，PO 的責任並不是把策略翻譯成功能，而是把策略轉譯成可被證偽的主張。

換句話說，PO 真正擁有的不是 PBI，而是「理解是否正確」這件事。

PBI 只是暫時的載體，是實驗的一種形式；
但假設，才是那個一旦錯誤，會讓整個方向偏離的核心。

這也解釋了為什麼在 HDD 流程中，假設會先進入 Hypothesis Backlog，而不是直接變成 Sprint 待辦事項。
因為在被驗證之前，它們不該被當成「理所當然要做的事」。

---

只管功能，等於把學習責任外包

當 PO 只扮演功能管理者，會出現一個結構性後果：
學習變成沒有人負責的事情。

工程師負責實作，設計師負責體驗，數據團隊負責報表；
但「這些結果代表什麼？是否改變我們的理解？」卻沒有明確的責任歸屬。

HDD 之所以要求每一次驗證都必須導向 Persevere / Pivot / Stop 的決策，正是為了避免這種學習真空。
而這個決策責任，正是 PO 不能外包、也不能模糊處理的地方。

---

假設優先排序畫布: 本質上是一種「節制工具」，是PO用來排列優先順序的依據，用來防止團隊把寶貴的探索能量，浪費在不該花力氣的地方。

這張圖稱為假設優先排序畫布(Hypothesis Prioritization Canvas)，它的目的不是幫團隊「想更多點子」，而是在假設已經很多的情況下，幫助團隊決定：哪一些值得被驗證、哪一些可以直接做、哪一些應該果斷放棄。在假設驅動開發（HDD）與精實產品思維中，真正稀缺的從來不是創意，而是時間、注意力與學習頻寬。畫布的兩條軸線：橫軸是「風險高低」，縱軸是「感知價值高低」。這裡的風險，不只是技術風險，也包含市場風險、使用者行為的不確定性；而價值，指的是一旦成立，對使用者與商業是否真的有實質影響。

---

在 AI 時代，PO 的角色反而更嚴苛

AI 讓生成程式碼、原型與實驗的成本大幅下降，這並沒有讓 PO 的工作變簡單，反而讓角色變得更困難。

因為當「什麼都能試」的時候，真正稀缺的，不是點子，而是判斷哪些值得試。

如果 PO 仍然只扮演功能管理者，那麼 AI 只會加速累加錯誤；
但如果 PO 能站在假設治理的位置，AI 才會成為放大學習速度的工具，而不是風險倍增器。

---

結語：PO 不是交付的終點，而是理解的守門人

PO 不能只當功能管理者，並不是因為功能不重要，而是因為功能永遠只是手段，而不是目的。

在不確定性成為常態的時代，真正成熟的產品角色，不是確保「東西被做出來」，而是確保：

我們每一次投入，都在逼近更正確的理解，而不是更深的承諾。

如果說 Scrum 幫助團隊穩定交付，
那麼 HDD 所要求的 PO，則是那個確保我們值得交付的人。

---

註釋

這張圖叫做 Hypothesis Prioritization Canvas（假設優先排序畫布），它的目的不是幫團隊「想更多點子」，而是在假設已經很多的情況下，幫助團隊決定：哪一些值得被驗證、哪一些可以直接做、哪一些應該果斷放棄。在假設驅動開發（HDD）與精實產品思維中，真正稀缺的從來不是創意，而是時間、注意力與學習頻寬；這張圖的存在，本質上是一種「節制工具」一種減法思維，用來防止團隊把寶貴的探索能量，浪費在不該花力氣的地方。畫布的兩條軸線很關鍵：橫軸是「風險高低」，縱軸是「感知價值高低」。這裡的風險，不只是技術風險，也包含市場風險、使用者行為的不確定性；而價值，指的是一旦成立，對使用者與商業是否真的有實質影響。說明如下:

1️⃣ 從右上角開始看（高價值 × 高風險，標示為 Test），這一區是整張圖的「心臟地帶」。這些假設一旦成立，可能帶來巨大回報，但同時也最不確定，因此最值得投入實驗、學習與探索資源。HDD 真正存在的理由，就在這一格：如果團隊不主動設計實驗去驗證這些假設，最後往往會在產品成型、資源投入已深時，才發現方向錯誤。

2️⃣ 左上角（高價值 × 低風險，Ship & Measure）則代表那些團隊已有高度信心的假設，這時不需要再花太多發現性研究，而是應該快速交付、上線後量測結果即可；換言之，學習已經發生在過去，現在重點是執行與追蹤。

3️⃣ 右下角（低價值 × 高風險，Discard）則是最容易被情緒或政治因素拖住的一區，但畫布明確提醒：這些假設既風險高、回報又低，繼續投入只會消耗組織耐心，應該果斷丟棄。

4️⃣ 左下角（低價值 × 低風險，Don’t test, usually don’t build），它常被誤解為「完全不重要」，但圖中其實點出一個現實：有些功能雖然無法帶來差異化，卻是「上桌門票」（table stakes），例如付款系統或基本合規機制，它們不需要大量假設驗證，但在必要時仍得完成。

當AI 讓生成假設與方案變得極快，結果往往不是「沒想法」，而是「什麼都想做」；而這張畫布正是用來”治理假設洪流” 的工具。

它迫使團隊在每一條假設上，先做價值與風險的判斷，再決定行動型態，而不是一律丟進 Backlog 變成待辦事項。用《孫子兵法》的一句話來說，它體現的是「不戰而屈人之兵」的精神，在寫程式、做實驗之前，先用結構化思考淘汰不值得嘗試的方向。

最終，這張圖的意義不在於分類本身，而在於它幫助團隊形成一個共識：不是所有假設都值得被驗證，而真正的專業，體現在知道哪些「不做」。

從這張圖示開始，看見我們習以為常的盲點

在敏捷與產品開發領域，有一張經典圖示常被引用：
上半部，是「輪子 → 兩個輪子 → 半台車 → 汽車」；
下半部，則是「滑板 → 腳踏車 → 機車 → 汽車」。

多數人第一次看到這張圖，直覺會以為它在談 開發速度或 MVP，但這其實是一個誤會。這張圖真正要指出的，不是「哪一條路比較快」，而是一個更根本的問題：

• 在產品尚未完成之前，使用者能不能真的使用到？
• 而開發團隊，能不能在過程中從使用者得到回饋，真的學到東西？

❌ 上半部的「累加功能」路徑，在工程邏輯上無可挑剔：把系統拆解成零件，逐步完成，最終組合成完整產品。這種做法看起來穩健、可控制，也符合多數組織對「降低風險」的直覺理解。

✅ 但問題在於，在這條路徑的絕大多數時間裡，使用者其實什麼都用不了。輪子不能移動，半台車也無法載人；在產品真正完成之前，所有的進度，都只存在於內部報告與專案文件中，而不在真實世界裡。

---

傳統開發為何偏好累加？因為它看起來最安全

「累加功能」並不是錯誤思維，而是一種歷史上極為合理的選擇。

在需求高度確定、變更成本極高的年代 (例如大型企業系統、政府專案、硬體導向開發)，最可怕的風險不是「做錯」，而是「中途改變」。因此，完整規劃、需求凍結、階段性交付，成為一種保守卻有效的風險管理方式。

這套做法背後，其實隱含了一個關鍵前提：

• 只要一開始想得夠清楚，後面就只剩執行問題。

❌ 問題是，在高度不確定的市場與使用情境下，這個前提本身，往往從未被驗證。

---

敏捷真正想對抗的，不是慢，而是 假確定性(False Certainty)

敏捷的出現，並不是因為大家突然想「快一點」，而是因為越來越多團隊發現：需求本身並不穩定，卻被迫假裝一切都已經確定。

Scrum、XP、看板所強調的短迭代、可交付成果與持續回饋，本意是為了降低這種「假確定性」。然而，在實務中，敏捷常被誤用為單純的節奏管理工具，Sprint 跑得很順，Backlog 排得很滿，但每一次迭代，交付的仍然只是「無法獨立使用的半成品」。

換句話說，速度變快了，但真正的學習卻沒有提前。

當敏捷只剩下形式，而沒有觸及「我們是否正在做對的事?」這個問題時，它就只是把傳統開發切成小塊，而不是降低真正的風險。

---

累加功能真正昂貴的，是延後了學習

再回到那張圖的下半部。

滑板、腳踏車、機車，看似是不同產品，實際上卻是在反覆驗證同一個核心假設： 使用者是否需要一種可自行掌控、有效移動的方式。

每一個階段，都能被真正使用；每一次交付，都能帶來真實回饋。差別只在於成本、風險與規模，而不是「能不能學到東西」。

這正是「累加功能」最昂貴的地方，它把學習延後到承諾之後。

當你花了半年完成一套功能齊全的系統，卻在上線後才發現使用者根本不在乎，那不是技術失敗，而是認知失敗。

---

Lean 與假設驅動開發：把學習拉回開發核心

精實 (Lean) 與假設驅動開發 (Hypothesis-Driven Development, HDD)，正是為了解決這個問題而被引入產品與軟體開發。

在 Lean 的觀點裡，真正的浪費不是「寫錯程式」，而是：

在尚未被驗證的假設上，投入大量不可逆的承諾。

HDD 要求團隊先說清楚「我們相信什麼」，再設計最小、最便宜的方式去驗證，最後才決定是否將其轉化為正式功能。這不是讓開發變慢，而是避免把速度用在錯的方向上。

在 AI 大幅降低實作與原型成本的今天，這一點反而更重要。因為「做出半台車」變得前所未有地容易，也意味著「在錯誤假設上加速」變得前所未有地危險。

---

結語：真正的專業，是知道什麼不要累加

「累加功能」之所以昂貴，並不是因為它不理性，而是因為它過度相信自己一開始就理解了問題。

在不確定性成為常態的世界裡，真正成熟的開發方式，不是一次把系統做到位，而是：

在每一次投入之前，先確認自己正在驗證什麼。

那張看似簡單的圖示之所以歷久彌新，正因為它提醒我們一件極不直覺、卻極其重要的事：

不要交付不完整的解法，而要交付完整但簡化的價值。

這正是敏捷之後，Lean 與假設驅動開發(HDD) 試圖帶回產品開發核心的真正精神。

---

註解說明（供延伸閱讀）

1. Henrik Kniberg 圖示：常見於其敏捷與產品開發演講與文章，用以對比「功能累加」與「假設驗證」兩種不同的學習路徑。
2. 假確定性（False Certainty）：指在高度不確定環境下，仍以確定性規劃與指標假裝風險已被消除。
3. Lean 與 TPS：Lean 思想源自 Toyota Production System（TPS），核心在於縮短回饋迴路、以學習驅動改善。
4. Hypothesis-Driven Development：由精實創業與產品管理領域系統化提出，強調以可被證偽的假設作為開發起點。
5. AI 與開發成本：AI 並未消除不確定性，只是降低了實作成本，反而放大了錯誤決策的影響。

從寫程式到理解世界：為何我們必須退後一步？

( 2025 WebConf 15分鐘的閃電Show，題目: 軟體工程不只是寫程式)

簡報檔在這裡，

前言

在軟體工程領域，我們最常犯的錯，就是「只看見眼前 AI 所產出來的程式碼，卻忽略了系統演化的方向」。

1950年，阿蘭·圖靈 Alan Turing 曾預言，到20世紀末，『 廣大受過教育的人的看法會發生很大的改變，那時談論機器思考將不再受到反駁 』。

當時這個預言，會想信的人一定少之又少，今天呢 …

---

我們在進行專案規劃時，難免會做出一些「 假設 」這是不可避免的，然而假設就是對未來的一種猜測( 預言 )，一種以終為始的預言。你說會猜錯嗎?! 當然會錯! 但是敏捷開發告訴我們要持續修正，錯了! 並不可怕，知道錯了還不去修正才可怕。專案開發就應該運用「 小增量、多迭代時時尋求回饋的態度」來適應變化，自然就能夠克服變化進而達成目標。

這裡；我們藉由瑞典敏捷專家亨立克.克里貝尼(Henrik Kniberg，瑞典人 註 1. ) 的一篇文章 Are developers needed in the age of AI? 對AI 與開發者之間的關係，做為假設的開始。

---

一、AI 與工程師之間的五階段演化：從工具到夥伴

Henrik 認為AI 能力每提升一個階段，就會重新定義工程師的角色。
這五階段並不是幻想，而是我們正在經歷的變化，2年過去了，現在看起來依然實用。

• 工具階段（Tool Phase）

人們把 AI 當作是升級版的 IDE 或 搜尋引擎 Stack Overflow，它補充程式碼、解 bug、產測試。
此時；工程師仍然是主角。

• 助理階段（Assistant Phase）

AI 開始懂上下文，能提供 API 設計建議、邏輯提醒、風險分析。
主體程式碼仍是你寫，但它提供你片段的功能及 協助你「思考」。

此時，AI 對程式碼的修改開始擁有許可權能進行提交和 PR，並審查 PR。人們釋放一些權限給它，然後懷疑、觀望它能做得多好。

• 合作者階段（Collaborator Phase）

AI 不只是協助你，還幫助整個團隊。它可以審 PR、整理文件、預測 bug、拆解需求。像是團隊中的一位中階工程師，默默協助所有人。

此時；使用 AI 的人將學會如何越來越信任它，它也將變得更加先進，並將更多地瞭解您的產品和上下文( Prompt 工程大演進)。

• 導師階段（Mentor Phase）

一旦 AI 能看懂架構、流程、模式，它會反過來幫你成長。你從它的輸出「學到更好的寫法、理解更深的概念」。
這個時期，工程師開始從「執行者」變成「學習者」。

但AI 有時需要監督，因為它會提出沒有意義的愚蠢解答，因此人類需要審查程式並進行更正。但可以預期不久人工智慧將比人類更快地完成所有與開發相關的工作，並且品質相同甚至更好。

• 夥伴階段（Partner Phase）

AI 將負責編寫所有程式碼。它將與請求者和其他利益相關者直接討論設計，但實際編碼完全由 AI 完成。

未來十年，AI 可能具備自主決策能力、主動創新能力。
甚至「沒有原始碼」(在動態記憶中執行)、或「沒有傳統開發團隊」的架構都可能成真。

但這不代表工程師會消失。相反的：

AI 寫程式，人類定義世界。

工程師將負責的是價值判斷、方向制定、風險治理、架構邊界、系統演化。這些都是 AI 無法單獨完成的。

---

---

二、提示工程五階段：從術到心法，走向 Conceptual Engineering

AI 演化的不只是它在團隊裡的位置，還包含它與我們互動的方式。

來談一下提示工程的五階段演進：

1. Magic Prompt

2022 年在LLM 開始之初，它像神燈一樣用說的就能達成我們的心願，就像唸「咒語一般」，提示詞往往只能靠技巧、靠格式、靠直覺，輸入後就只能期待有好的產出，它像鏡子一般直覺反應出我們的思考，效果十分的不穩定，也不太能夠複製。這一點是這個時期，它唯一的缺點，我們一直相信 scaling law 能夠解決這個問題。

2. Prompt Patterning 依模式產出提示

開始有 CoT、ReAct等等模板，官方也會自動提供。但有了模式，仍找不到本質。

3. Prompt as Code

提示開始變成工程化的產物：
工程方法的思維被加了近來，必須有版本控制(GIT)、有測試、有審查(code review)、有回歸檢查。
這是提示工程的正式成年禮時期，有不少書本在描述這個過程。

4. SDD：Story + Demo + Structure 出現

這是目前最重要的階段，一堆公司開始採用 SBE(實例化需求)來撰寫需求，一下子，BDD 行為驅動開發成了當紅炸子雞。
大家終於看懂了AI的本質是 pattern learner，不是 rule follower，因此完美的 prompt 是不存在的。我們很難寫出讓 AI 能夠完整依據的規則，相反的，應該用範例的方式讓AI 由範例中自己提煉出規則才是王道。
因此我們需要：

• 用故事建語境，
• 用示例建立模式，
• 用結構給它推理骨架。

透過有故事有範例有結構化的上下文，如此 AI 才能形成穩定的理解能力。

5. Conceptual Engineering

我們都知道 : 概念才是王道。

未來的 AI 開發，不是寫 prompt，而是設計 AI 的「概念空間」。

• 什麼是問題？
• 世界的規則是什麼？
• 任務語意如何建立？
• 推理架構如何遷移？
• 使用者意圖如何壓縮成概念？

這其實就是邁向 AGI 的必要條件。
AGI 不是大模型所堆出來的，而是 能理解概念 並跨任務遷移推理的能力。而誰在做這件事？ 答案是: 工程師。

---

三、工具心態 vs 夥伴心態：不讓 AI 替你思考，而是放大你的思考

這張圖在說明，你不只是用 AI 寫程式，而是用 AI 讓自己升級。

❌ 你把 AI 當成工具的心態

把 AI 當成自動完成或偷懶工具。
問題是：它會讓你變得愈來愈淺顯。

✅ 當成夥伴心態的心態

讓 AI 幫助你：

• 理解更深
• 學得更快
• 看得更遠

AI 是你的「另一個大腦」，不是替代品，而是增幅器，讓AI 協助你學習成長。

---

四、軟技能 × 硬技能 × 濕技能：工程師價值的三角模型

硬技能（Hard Skills）

一般指向那些可量化、可驗證、可部署、可維護的技能。

例如: 語言、框架、工具、雲端、CI/CD。

• 進階的特點是一步一腳印、靠操練與經驗累積。
• AI 可取代率最高（60–80%），因為規則清晰、可示範、可模仿。
• 隨時間推進，純硬技能的價值邊際快速下降。

軟技能（Soft Skills）

一般指向那些有人味，如: 領導統御、團隊信任感與共識的技能。

例如: 協作、需求釐清、架構討論、跨部門溝通、問題 framing。

• 這些能力不像硬技能可透過靠單一教材學會，而是靠情境反覆磨練，靠經驗學會的。
• AI 可取代率降低（20–40%），因為軟技能牽涉「情境、語境、利害、協商」，AI 雖能模擬，但難以完全取代。

濕技能（Wet Skills）——AI 時代最核心的技能組

濕技能不是高階軟技能，而是：軟技能 × 系統演化 × 情境推理 × 方法論的內化

例如：識人、洞察團隊文化、敘事能力、戰略性決策、系統性思維、故事化溝通。

• 此類能力源於人的「心智模型、價值觀 與 判斷力」。
• AI 可取代率最低（5–15%），因為涉及人的直覺、信任、責任、倫理與組織動能。

它包括：

• 敏捷開發
• DevOps
• 架構取捨
• 需求發掘
• 風險判斷
• Spec-Driven Development / SDD
• DevEx（開發者體驗）
• Living Documentation
• AIOps
• Systems Thinking（系統思維）

濕技能是工程師真正的競爭力來源。它們無法被 AI 取代，也不會被工具簡化。濕技能讓工程師從「寫程式的人」，成為「設計系統、協作、治理的人」。

整體曲線意味著：
越往後，技能越難透過 AI 量產；人的影響力反而越強。

軟技能與濕技能之間，看似只是一小段時間差，但其實象徵工程師成長的分水嶺。它決定一位工程師是成為「高效個人工作者」，還是晉升為「團隊的技術舵手」。

• 從「操作訊息」到「解讀人心」的跨越。能夠讀懂利益關係人背後的盤算，又能守住組織文化又能透過敘事描述出正確的解答。
• 從「會把事情做對」到「知道什麼事值得做」。軟技能讓工程師把手上的事做好；濕技能則能讓工程師選對事情做、並讓更多人一起做。
• 從「能被替代的協作者」到「無法被替代的價值製造者」。硬、軟技能都可能部分由 AI 協助完成，但濕技能是一種被「信任的技藝」：當團隊信任你、主管信任你、客戶信你、後輩願意被你帶，這些信任一旦建立，就是個人的專屬能力，一種無形的權利。

間隙象徵著：工程師從功能 → 到角色 → 到影響力的飛躍。

---

Developer Growth Loop：工程師的自我進化路徑

>> 我們應該有的視角：

AI 越強大，我們越不能讓它替我們思考，而是用它來放大我們的思考。

工程師的成長曲線不再只是學語言、學框架 或做 Side Project。未來的成長來自三件事：

1. 硬技能落地（把事情做對）
2. 軟技能提升（讓價值能被看見）
3. 濕技能深化（讓系統能持續演化）

再加入：

• 深度思考
• 強化學習
• 結構化思維
• Conceptual Engineering
• 系統理解

工程師就能在 AI 時代，不但不會被替代，還能被放大。

五、什麼是 Conceptual Engineering？為什麼它是 AI 時代工程師的下一個核心能力？

當我們談「Conceptual Engineering 概念工程」時，我們其實在談一個工程師很少真正正視它、卻又一直在做的事：「 定義問題、建構概念、設計推理，使系統能理解並正確運作。」這個我們熟悉的流程，過去這件事被語焉不詳地分散在下面這些領域中，工程師完全靠經驗在工作：

• 架構設計
• 需求訪談
• 產品討論
• 技術規格
• 文件撰寫

但在 AI 時代，這項能力被徹底推到舞台中央。

因為；
AI 會寫程式，但不會定義概念；
AI 會模仿推理，但不會創造推理架構；
AI 會完成任務，但不會知道任務的本質。

這些事情，全部落回工程師身上。還記得AI製作的魚缸嗎，魚兒經常優游的穿過邊界，這種不可思議的錯誤，代表 AI 在繪圖時根本不知道邊界為何物，一切都只是演算法。

這使得 AI 在程式生成上能「做得像」，但在複雜領域上仍「不知道自己在做什麼」。

因此，工程師必須做一件事：把概念設計成 AI 能理解、能套用、能泛化的形式。 這就是「概念工程 Conceptual Engineering」。

>> 概念工程做的不是程式，而是「推理空間」(註 5.)

傳統軟體工程設計的是：模組、API、流程、架構、需求。

而概念工程所設計的是更前面的東西：

例如: 任務的本質是什麼？、哪些概念是關鍵？、推理需要哪些關係？、有哪些隱含規則需要顯化？、AI 如何知道此任務的成功條件？

一旦這些基本的概念正確了，AI 才能正確推理；如果概念不清，AI 再強也會胡亂生成。讓概念變成知識的主體輸入給AI，而不是規格化的 SDD。雖然 SDD（Story + Demo + Structure）是目前最有效的作法，因為它能讓 AI 從示例中捕捉模式，自己去產生規則。

但 SDD 無法解決許多問題，例如: 任務定義錯，示例愈多愈錯、未顯化的概念仍無法泛化、若範例無法涵蓋複雜情境，AI 就無法遷移、隱含的潛規則 AI 永遠也補不出來。

也就是說：SDD 是讓 AI 學推理；概念工程則是讓 AI 學「什麼是值得的推理」。

>> 你可能懷疑，為什麼在 AI 時代，Conceptual Engineering 會成為工程師（尤其是 AI 工程師）的下一個核心能力？

因為 AI 時代最大的挑戰已經從「算力」與「資料」轉移到「我們到底要讓機器優化什麼？」; 而這個問題的本質就是 概念工程。

---

結語： 工程師不是寫程式的人，而是理解世界的人

從 Kniberg 的 AI 五階段，到提示工程的五階段，再到濕技能的掘起，我們看到同一個問題，那就是 AI 會寫程式，但 AI 不會理解世界，但工程師會。

未來工程師的價值，不是寫更多程式，而是：

• 能夠看見全貌
• 定義建構問題
• 建立概念
• 設計推理
• 協作與對齊
• 引導 AI，而不是被 AI 引導

這是 AI 奪不走的，也是工程師未來職涯最值得追尋的道路。

你可能會問: 走到後來為何是概念呢? 概念工程是不是太抽象了呢?

其實不用擔心，教育界早就先走上這條路上了(還記得一度讓家長們覺得荒唐無比的建構式教學嗎? 其實它就是概念為本的教學，想要改革，難上加難，立意雖好，卻往往歸咎於實施方法 …)，以 概念為本(Concept Base) 的學習方式，目的在取代傳統教學以目標為本的教學方式，未來的考試目的在測量學生想對了嗎? 思考的方向是否正確，而不是只給出正確的答案。(註3.)

在概念工程的前提下，我們在提示的下達中；依然運用結構化的語法與AI溝通，但內容卻是注重在推理。

未來的工程師，要學會設計讓程式碼能夠自我學習的系統，就好比AI能夠自我學習一般，建立自學習的生態系統( learning Ecosystem )。

【 技術應該用來探索未來 】

AI 之於工程師的真正意義，不只是提升效率，而是重新揭示技術存在的初衷：技術應該被用來探索未來。

對每天忙碌於工作的工程師而言，那些日常的技術累積，本質上都是在為未來搭橋鋪路。

(一)、技術不是只為了完成今天的任務，AI 時代提醒我們的是： 技術不是為了把事情做完，而是為了讓更大的事情變得可能。

(二)、探索未來不是離開現在，而是讓現在有更深的意義，對工程師來說，最務實的未來探索，是在今天的工作裡，做一點超出需求、一點高於交付的思考。

(三)、AI 時代更顯這句話的重量 – 技術應該用來探索未來

AI 會加速所有 routine 的事。

因此工程師的價值，愈來愈不在於「做多少」，而在於「往哪裡走」。也就是，技術的價值不是讓你跑得更快，而是讓你走向值得走的方向。

四、對忙碌的工程師而言的真正意義

當你願意用技術去好奇、去預想、去試驗，而不是只拿來解壓、交差、救火，那一刻，你就已經在探索未來。

對工程師而言，這不是額外的任務，而是一種視野。

---

註 1. Henrik Kniberg 提出的 AI 未來五個階段

註 2. PARA 系統

什麼是 PARA？  作家: 提亞戈．佛特 (Teago Forte)在他的書裡頭所發明的一種有組織的整理方式《打造第二大腦 : 多一個數位大腦，資訊超載時代的高效能知識管理術》，我一直受用到今天。

• – 有明確死線的東西 → 全部丟 P（Projects）
• – 這輩子都要持續負責的事 → 全部丟 A（Areas）
• – 哪天可能會用到的冷知識、興趣 → 全部丟 R（Resources）
• – 做完、放棄、不想鳥了的 → 全部丟 Archives（封存）

記住：每份檔案永遠只有這4個家，不會流浪！

書裡有一段話引發我很深的思考:

你要把今天學習到的知識打包放到你未來會經過的路徑上。

這句話所說的正是 “概念" ，知識應該包含你如何學習到的，在怎樣的情境下學會的，打包起來正是"概念"，而人們對於未來的決策，正是依靠這些個概念。

註3. 一種「概念為本」的學習方式

概念為本(Concept Base) 的學習方式，目的在取代傳統教學以目標為本的教學方式。強調教學應以給予學生擁有思考的概念，比實作以達成任務的教學更重要。參考: 《邁向概念為本的課程與教學：如何整合內容與歷程》

作者:  琳恩.艾瑞克森(Lynn Erickson) 與 絡薏絲.蘭寧(Loris A. Lanning) 概念為本的基本理念依據是: 知識性結構 與 歷程性結構。

有興趣者，請參考: 概念驅動：AI 時代開發者體驗的遷移與修練

註 4. 概念工程

Conceptual Engineering（概念工程）是一種哲學方法論，近年迅速成為應用哲學、認知科學與人工智慧領域中最熱門的跨領域工具。簡單來說，它就是：

「有系統地檢視、診斷、修補或徹底重設計我們所使用的概念（concepts），讓這些概念在特定目的下更好地運作。」

傳統哲學問「真理是什麼（what is justice? what is knowledge?），而概念工程問的是：「我們現在用的『正義』、『知識』、『公平』這些概念，到底好不好用？有沒有bug？要不要升級或換掉？」

著名哲學家如Cappelen、Plunkett、Chalmers、Sally Haslanger、Kevin Scharp 等人都把概念工程當作當代哲學的核心實踐。它不只是「澄清概念」，而是像工程師一樣把概念當成可以被改良、替換、重新編程的工具。

一個經典的例子：

婚姻：2010年代前「婚姻」概念在許多國家不包含同性伴侶，經過概念工程（法律與社會運動），現在大多數民主國家的「婚姻」概念已經被升級到性別中立版。

註 5. 推理空間 ( The Space of Reasons )

「推理空間」是一個在哲學，特別是 邏輯學 和 知識論 (Epistemology) 中使用的術語，它源於哲學家 Wilfrid Sellars 的著作。

• 定義：它指的是所有具備理由、證據、邏輯關係的信念、陳述、判斷和推論所構成的網狀結構或領域。
• 在這個空間中，一個信念或行動是合理的 (justified)，是因為我們可以為其提供理由 (reasons)。
• 功能：推理空間是我們進行判斷、論證、獲得知識和合理行動的框架。

在這裡；我們使用的概念構成了這個推理空間的「坐標軸」或 結構的樑柱。

• 例如，「知識」這個概念決定了在什麼條件下我們能合理地聲稱我們知道某事。如果我們改變「知識」的定義（即進行概念工程），那麼在 推理空間中，哪些陳述是「合理的」或「可證成的」也會隨之改變。
• 類比：如果概念是 棋盤上的規則，那麼推理空間就是 所有可能的、合法的棋局。

工程師如何為「概念工程」做準備?

為了與 AI 有效協作，工程師必須深化軟技能（濕技能），特別是在以下三個方面：

• 1. 提示工程 (Prompt Engineering)
• 2. 架構模式掌握 (Pattern Proficiency) ，當 AI 負責生成實現細節時，工程師必須負責設計高層級的藍圖。
• 3. 驗證與測試 (Verification & Testing)

工程師必須能夠從單純的「編程人員 (Coder)」升級為「AI 協作系統的架構師與引導者」。

從「用AI」到「與AI共學」的工程師思維革命

---

一、我們一直都誤會了「技術」

多數工程師都以為「技術」的價值在於速度與自動化。
撰寫更快的程式、部署更快的架構、讓開發更自動。
但教育心理學家 David H. Jonassen 在 2000 年出版的《Learning to Solve Problems with Technology》（《學會用技術解決問題》，註 1.）中提醒我們：

“Technology should be used to think with, not just to work with.”
技術應該被用來「思考」，而不只是「操作」。

這句話在 AI 時代顯得格外讓人震撼。

也對應了黃仁勳先生所說的: 『不要把 AI 當成拐杖，而要把它當成放大你思考的工具。 』

因為我們已經太習慣讓 AI 幫我們「完成」任務：寫程式、改 bug、翻譯、生成報告……
但 Jonassen 的觀點揭示了一個更深層的問題：
你用技術，只是為了少做點事？還是為了讓自己思考得更清晰？

這也是許多工程師在使用 ChatGPT、GROK、Copilot、Claude 時感到矛盾的原因。

AI 很強，但它強到讓人「不再需要思考」；
於是我們變快了，卻也更容易停在「表層操作」的水平。

真正的成長，應該是學會「透過 AI 來思考」，而不是「依賴 AI 來產出」。

---

二、AI 不是工具，而是思考的共創者

當你和 AI 對話時，其實正在進行一場「思維鏡像」 (註3.)。
AI 不只是回答你的問題，它也在反映出你問題表達的深度與結構。

假如你給出的 prompt 模糊、缺乏邏輯、沒有上下文，AI 生成的結果往往同樣零散。
但若你的描述具備層次、有明確邏輯鏈、清楚目標，AI 的輸出也會呈現出你思維的清晰度。

這就像 Jonassen 所說的「技術是心智的延伸（Mindtools）」。
AI 是一面鏡子，幫你看見自己的思考。
你越會提問，它越能激發你新的洞見；
你越會結構化表達，它越能生成有價值的知識。

AI 不會自動讓你聰明，但它能讓你更快看見自己哪裡還不夠聰明。

---

三、從解題者到問題設計者：Prompt 是新的思維語言

AI 時代最重要的語言，不是 Python，也不是 C++，
而是「問題語言（Problem Language）」。

Prompt 不是魔法咒語，而是一種「結構化思維」的展現。
好的 prompt 往往隱含三個層次的思考：

1. 目的層（Why）：我想要達成什麼目標？
2. 邏輯層（How）：AI 需要按照什麼步驟或限制進行？
3. 評估層（What if / How to verify）：我要如何判斷結果是否正確？

寫得好程式的工程師很多，但真正能夠清楚「描述問題」的工程師卻很少。

提示工程其實是一種「問題架構設計」。
你越能明確定義目標與限制，AI 的生成就越接近你的認知模式。

因此，AI 時代的學習關鍵不在於學更多語言，
而在於學會讓 AI 聽得懂「你的思考」。

---

四、AI 是心智的共振器：讓你看見自己的思考

在 Jonassen 的理論中，有一個核心觀點叫「反思迭代（Reflective Iteration）」。
意思是：學習不是一次完成的動作，而是一連串的修正與再理解。

AI 正好成為這個反思過程的「觸發器」。
當 AI 給出一個答案，而你意識到「這不是我想要的」時，
你會開始重新審視自己：
是不是我定義錯了？假設錯了？還是我理解不夠深？

這一刻，其實就是「學習正在發生」的時刻。

AI 的價值常常不在於正確答案，而在於幫助你看見自己思考的盲點。
每一輪錯誤的生成，其實都是一個「外化的反思機會」。

Jonassen 認為學習的核心是「主動生成理解（Generative Understanding）」(註 2.)，這是一種「創造性思維的過程」；透過主動參與、反思與重構，讓知識真正內化。

---

五、工程師的新素養：從結構化思維到生成式理解

AI 時代的工程師，最重要的兩項素養是：

結構化思維（Structured Thinking） × 生成式理解（Generative Understanding）

這兩者分別代表「讓 AI 懂你」與「讓你懂自己」。

---

（1）結構化思維：讓 AI 聽得懂你的邏輯

結構化思維，是一種把複雜問題拆成可理解架構的能力。
在軟體開發中，這體現為：

• 能把需求轉化為模組與資料流；
• 能畫出系統邏輯圖，明確界定輸入與輸出；
• 能以層級化的 prompt 讓 AI 理解任務邏輯。

舉例來說，一個結構化的 prompt 會長這樣：

目標：我想重構一段 Python 程式，使其可讀性更高。

限制條件：

• 不改變原功能；
• 優先使用 Pythonic 寫法；
• 請提供重構前後的差異比較表。

回應格式：表格 + 簡要說明。

這樣的表達方式，不只是「問 AI 問題」，而是讓 AI 加入你的思維結構。

當你的思考有結構，AI 才能「對齊」你的邏輯。
如果思考是模糊的，AI 只會放大混亂。

---

（2）生成式理解：與 AI 一起深化思考

當 AI 能理解你的結構，它也會回饋新的視角。
它可能幫你重構邏輯、指出盲點、甚至生成更好的抽象。

這個過程不是被動學習，而是一種「共思（Co-thinking）」：
你與 AI 在對話中不斷修正、重組與再創造。

這就形成了「生成式理解循環（Generative Understanding Loop）」：

1. 主動參與（Active Engagement）： 主動設計問題與上下文；
2. 意義建構（Meaning Construction）： 生成概念圖或邏輯鏈；
3. 反思迭代（Reflective Iteration）： 透過 AI 回饋修正思維；
4. 創造產出（Creative Production）： 將理解外化成作品或程式。

這個循環讓工程師從「輸入-輸出」模式，進化為「思考-反思-再創造」的模式。

AI 不只是回答者，而是思考的催化劑。

---

（3）兩種素養的協奏：結構 × 生成

素養面向	核心能力	實踐方式	目標成果
結構化思維	條理化問題、明確上下文	畫出邏輯圖、拆解任務、設計層級化 prompt	讓 AI 產出 「對的方向」
生成式理解	與 AI 共思、反思、重構	多輪對話、比對版本、驗證概念	讓自己學得「更深一層」

>> 結構化思維讓 AI 聽懂你；生成式理解讓你聽懂自己。

當兩者交織，就形成一種新型學習力；「可被AI放大的思考力」。

這是未來工程師的核心競爭力。

---

六、程式只是結果，思維才是起點

AI 會寫程式，但它不會「為什麼」寫這樣的程式 (也就是真正了解需求的意義)，而這正是人類的價值所在。

未來的開發流程會越來越自動化，但能定義問題、拆解邏輯、設計結構的人，仍然是整個系統的靈魂。

程式只是思維的外顯結果。
如果思考沒有結構，再多的 AI 也只是混亂的放大器。

所以，工程師的任務不再只是「學會使用 AI」，
而是「學會與 AI 一起學習」。

你不需要比 AI 更快，你需要比別人更懂得如何透過 AI 理解世界。

---

小結: 學會「與AI一起解題」，而不是「靠AI交作業」

AI 不會讓你變聰明，但它能放大你思考的清晰度。

真正的學習，不是把問題交給 AI 解，而是透過 AI 看見自己是如何解題的。

Jonassen 在書中說： “Learning is not the product of teaching. Learning is the product of thinking.”
學習不是教出來的，而是思考出來的。

在 AI 時代，我們要延伸這句話：「學習，不只是思考的結果，而是與 AI 一起生成理解的過程。」

這，就是《學會用技術解決問題》在 AI 世代的全新意義。
技術不再只是工具，它是思維的延伸；
AI 不再是程式員的助手，而是工程師心智的共學者。

---

註釋:

1. David H. Jonassen（戴維．強納森） 的主要著作與出版資訊

Learning to Solve Problems with Technology: A Constructivist Perspective

• 出版年份： 2000（第2版 2006）
• 出版社： Pearson / Merrill Prentice Hall
• 概要：
  這是 Jonassen 最具代表性的著作之一。
  他主張「技術應作為思考的心智工具（Mindtools）」，強調學生透過主動建構與反思來學習問題解決，而非被動接受教導。
  書中奠定了之後「生成式理解（Generative Understanding）」與「學習環境設計」的基礎。
• 結構化思考（Structured Thinking） 的典故

「結構化思考（Structured Thinking）」這個詞最早並非來自心理學或教育學，而是出現在 20 世紀中期的管理顧問與系統工程（Systems Engineering）領域。

David H. Jonassen（2000）《Learning to Solve Problems with Technology》他指出「學習的核心是結構化的問題理解」。學習者要能建立「心智模型（mental model）」來組織知識，這正是結構化思考的內在機制。

AI 時代的延伸：結構化思考 × 生成式理解

到了 2020 年代，AI 與生成式模型興起，「結構化思考」再度成為人機協作的核心能力。

2. Jonassen 的理論核心

註 3. 在生成式學習理論（Generative Learning Theory）與強調「生成式理解」（Generative Understanding）的框架中，
「思維鏡像」可視為人與AI共同形成理解的中介界面。

AI產出答案，人類不是被動接受，而是透過鏡像思考去檢視：

我與AI的思維模型有何差異？
這個生成結果映照出我理解的空白在哪？

這就像一面能即時反射的智慧鏡，
既映出AI的推論，也映出使用者的概念結構。
當我們與AI協作編程或學習時，
「思維鏡像」能促進我們從被動使用者轉化為主動反思者。

運用 GIRLS 方法，讓理解成為自然的生成循環

---

前言

我一直認為，AI 誕生之初，並未真正做到「因材施教」。 它沒有教會各行各業的人「如何自然地上手與 AI 協作」，造成許多人只是把它當成工具，平白損失了許多在知識與認知上更上一層樓的機會，當然更遑論建立AI時代正確的認知框架。 但對我來說，人類的認知才是核心；我們需要的不是 AI 給出完美程式碼，而是一套內建於腦海的思考流程，讓我們一坐到電腦前，就能自然啟動：

「準備上下文 → 生成程式碼 → 快速測試 → 反思建構 → 循環精進 → 內化理解 → 接受反饋 → 打開黑盒子」

這樣的過程，應該像 遇見心儀的女孩，想進一步交往時的自然流暢才是：

• 一開始，你不會直接說「我愛你」，而是先觀察她的背景、興趣、語氣（ ＝上下文工程）；
• 然後用輕鬆的語氣開口聊天（ ＝vibe coding）；
• 她回應後，你認真傾聽、提問、試探反應（ ＝Inquire & Run）；
• 接著反思對話、調整策略（ ＝Learn）；
• 最終，你們一起創造回憶、建立默契（ ＝Synthesize）。

這就是我理想中的 AI 協作體驗，像人類談戀愛一樣的自然、逐步深入、彼此成就，而不是生硬地「複製貼上程式碼」。

這便是生成式理解（Generative Understanding，註1.）的核心概念，所以整理了一下，便生成了下面的「GIRLS方法」了。

---

解釋:  GIRLS 方法是一個五步循環，結合 vibe coding 的創意與 context engineering 的結構化優勢，讓工程師從快速生成程式碼到系統化學習，逐步掌握複雜的技能，克服陌生程式碼對我們的威脅。

---

理解的節奏 : 孔子對於理解的重視

---

【 GIRLS 方法論 】

1. Generate（生成）：結構化的 Vibe Coding

Generate 是 GIRLS 的起點，工程師透過 vibe coding 快速從 AI 獲取程式碼，但加入 context engineering 以確保輸出品質^[3]。Context engineering 強調在提示前提供全面的「信息環境」，包括專案背景、技術約束、相關文件或歷史對話總結。

• 實踐方式：
  • 上下文準備：明確專案需求，如「專案使用 Django 4.2，資料庫為 PostgreSQL，需 REST API 支援分頁」^[4]。
  • 檢索與整合：使用檢索增強生成（RAG）拉取相關示例程式碼，或加入錯誤日誌、API 文件等^[6]。
  • Vibe 描述：結合上下文，提出直覺化提示，如「[Context: 後端為 Django，需高效查詢] 給我一個有現代 RESTful vibe 的用戶管理 API。」
• 範例：原本簡單的 vibe coding 提示可能是「給我一個用戶 API」，現在變為「[Context: 專案為 SaaS 平台，需 JWT 認證，資料庫 schema 包含 users table] 給我一個有高安全 vibe 的用戶管理 API。」
• 好處：上下文工程可以減少 AI 的幻覺，提升程式碼的立即可用性，節省後續 debug 時間約 30-50%^[6].

這一步對應生成理解的 主動參與，工程師透過精心設計的上下文，積極引導 AI 輸出符合需求的程式碼。

2. Inquire（提問）：拆解與意義建構

收到 AI 生成的程式碼後，工程師常面臨「陌生程式碼」的挑戰。Inquire 階段透過提問，將新程式碼與已有知識聯繫起來，實現生成理解的 意義建構^[7]。

• 實踐方式：
  • 針對程式碼提出結構化問題，如「為什麼這裡使用依賴注入？」「這段程式碼如何處理高 Hit-rate 現象？」
  • 參考上下文問更具體的問題，例如「基於提供的 PostgreSQL schema，這段查詢是否會引發 N+1 問題？」^[8]
  • 自我對話或向 AI 詢問，記錄問題與答案。
• 範例：對於一個 AI 生成的 FastAPI 程式碼，工程師可能問：「這個端點如何與我熟悉的 Flask 路由比較？」「上下文提到的高並發需求，這裡的設計是否足夠？」
• 好處：提問幫助工程師將陌生程式碼轉化為熟悉的知識結構，避免表面理解。

3. Run（運行）：驗證與實際的操做參與

Run 階段要求工程師執行程式碼並進行 debugging，進一步實現 主動參與^[9]。這不僅驗證程式碼的正確性，還讓工程師親手體驗其行為。

• 實踐方式：
  • 運行程式碼，觀察輸出並記錄錯誤。例如，發現 API 在高負載下崩潰。
  • 將錯誤日誌或行為反饋加入上下文，作為下一輪生成的依據^[11]。
  • 嘗試小規模修改，探索程式碼的邏輯邊界。
• 範例：運行一個 AI 生成的購物車 API，發現資料庫連線超時。工程師記錄：「連線池設置不當，需調整上下文要求 connection pooling。」
• 好處：實操讓工程師發現 AI 輸出的局限，培養批判性思維。

4. Learn（學習/反思）：迭代與知識精煉

Learn 階段對應生成理解的 反思與迭代，工程師回顧程式碼的優缺點，更新上下文並精煉理解^[11]。

• 實踐方式：
  • 反思問題，如「這段程式碼的性能瓶頸在哪？」「是否有更簡潔的實現方式？」
  • 更新上下文，例如「上次生成忽略了錯誤處理，需加入 try-catch 要求。」
  • 記錄心得，確保知識內化。例如，寫下：「這次迭代讓我理解了 middleware 在 FastAPI 中的作用。」
• 範例：發現 API 缺乏安全性，於是更新上下文：「[Context: 需遵循 OWASP 標準] 優化這段程式碼的安全性。」^[12]
• 好處：反思與上下文迭代讓工程師的知識結構從零散變為系統化。

5. Synthesize（創造）：生成最終產出

Synthesize 是 GIRLS 的最終階段，工程師基於內化知識，生成屬於自己的 創造性產出，如改進的程式碼、系統架構或完整應用^[14]。

• 實踐方式：
  • 基於前四步的學習，改進程式碼或擴展功能。例如，將單一 API 升級為帶負載均衡的微服務。
  • 產出不僅是程式碼，還包括更新後的上下文文件，供未來參考。
• 範例：從 AI 生成的簡單用戶 API 出發，工程師最終產出一個包含認證、權限管理和日誌的完整後端模組，並記錄上下文（如「最終版本支援 1000 QPS」）。
• 好處：創造性產出體現工程師的理解深度，進階到系統構建思維。

---

GIRLS 方法的好處:

• 易記與親和：GIRLS（Generate, Inquire, Run, Learn, Synthesize）是一個朗朗上口的縮寫，帶有輕鬆的「vibe」，與 vibe coding 的創意精神契合，特別適合學習者或團隊推廣^[14]。
• 上下文強化：透過 context engineering，Generate 階段從模糊的 vibe coding 升級為結構化生成，減少後續修正成本。
• 批判性思維：Inquire 和 Learn 階段確保工程師保持主動思考，避免將 AI 視為黑箱。
• 全面學習：GIRLS 涵蓋生成理解的四大特徵，幫助工程師從程式碼內化到系統設計的進階。

---

要有效應用 GIRLS 方法，工程師可以從以下方式開始：

• 小專案試驗：選擇一個不熟悉的技術領域（如以生成式理解為原則產出Girls 方法 GraphQL），用 GIRLS 流程學習。例如，Generate 一個簡單查詢 API，逐步迭代到支援複雜查詢。
• 上下文模板：建立標準化的上下文模板（如專案背景 + 技術約束 + 示例程式碼），加速 Generate 階段^[16]。
• 記錄工具：使用筆記工具（如 Notion 或 Obsidian）記錄 GIRLS 各階段的問題、錯誤和反思，追踪學習進展。
• 團隊推廣：在團隊中介紹 GIRLS，製作簡單圖表（如五步循環圖），鼓勵全員採用。

範例：應用 GIRLS 構建一個微服務

假設工程師想開發一個認證微服務：

1. Generate：「[Context: Node.js + Express，PostgreSQL 資料庫，需 JWT 認證，效能 < 100ms] 給我一個有高安全 vibe 的認證 API。」
2. Inquire：「為什麼這裡用 bcrypt 而不是其他Hash算法？」^[17]
3. Run：運行程式碼，發現 token 過期處理不當，記錄錯誤日誌。
4. Learn：反思並更新上下文：「[Context: 需 token 刷新邏輯] 優化 token 管理。」
5. Synthesize：產出一個完整認證模組，支援刷新 token 和多用戶角色。

---

• GIRLS  = 「生成、提問、運行、學習、創造」

---

小結

千萬不要把AI當成工具來使用，那樣你只會在意他能提升你多少效能，要與AI 進行協作，才能從中獲得最大的效益(參考: AI不是工具，而是夥伴：讓工程師打開更高層次的思考力)。

這裡提供與 AI 協作的工程方法 GIRLS 它是一個結構化且富創意的框架，讓工程師在與 AI 的協作中，從 vibe coding 的快速生成開始，透過上下文工程提升程式碼品質，再經由提問、運行、反思和創造，內化陌生程式碼並進階到系統構建思考。一切都以學習、理解為主。在 2025 年的技術浪潮中，GIRLS 方法將幫助工程師從 AI 的「使用者」轉為「協作者」，真正掌握知識並創造價值。請從下一個專案開始，請試試 GIRLS方法，記錄你的上下文演進與學習心得，體驗它如何改變你的技術旅程！

---

注釋

1. 生成式理解：Generative Understanding教育理論中的一種學習框架，強調學習者透過主動參與、意義建構、反思迭代和創造性產出來建構知識，特別適用於技術學習。參考自(1) 維特洛克(Wittrock)的生成學習理論: 提出生成學習（generative learning），強調學習的本質是學習者的認知結構與環境中接受的資訊相互作用並主動建構意義的過程。及 (2)《走出唯一真理觀》是陳嘉映先生的佳作。 參考自: 生成學習理論：「知識不是輸入腦中的，而是被學習者生成出來的。」因此，有效的教學與AI輔助學習，應設計能促使學習者：(1) 主動參與；(2) 建構意義；(3) 反思與修正；(4) 產生新的創造性輸出。由美國教育心理學家 Merlin C. Wittrock 所提出。傳承自生成式學習的「生成式理解」(GU)，參考自Jonassen (1996) 在內部章節標題中使用 GU 指代 Generative Understanding。
2. Context Engineering：超越傳統 prompt engineering，透過動態管理上下文（如專案背景、文件、歷史對話）提升 AI 輸出品質，常見於 2025 年的 AI 應用。
3. Vibe Coding：一種基於直覺或模糊描述的程式碼生成方式，鼓勵創意但可能因缺乏上下文而產生不精準輸出，最好能夠需結合 context engineering。
4. 專案需求示例：上下文應包含具體技術棧（如 Django 4.2）、資料庫 schema（如 PostgreSQL users Table）及 限制約束（如響應時間 < 100ms），以確保 AI 理解專案環境。
5. 檢索增強生成（RAG）：AI 技術，透過檢索外部知識庫（如內部程式碼庫或公開文件）增強生成內容的相關性，常用於上下文工程。
6. Debug 時間減少：研究顯示，結構化上下文可將後續 debug 時間縮減 30-50%，因 AI 輸出更貼合需求，減少無效迭代。
7. 意義建構：生成理解的核心特徵之一，指學習者將新信息與現有知識聯繫，形成個人化理解，例如比較新舊框架的異同。
8. N+1 問題：資料庫查詢中的常見性能問題，指多次小查詢導致效率低下。提問時參考上下文（如 schema）可精準發現此類問題。
9. 主動參與：生成理解強調學習者主動操作而非被動接受，運行程式碼與 debug 是典型實操方式。
10. 錯誤日誌作為上下文：將運行中的錯誤(如 stack trace)加入下輪提示，可讓 AI 生成更精確的修正建議。
11. 反思與迭代：生成理解的關鍵階段，透過反思程式碼行為（如性能、安全性）並迭代上下文，逐步精煉知識結構。
12. OWASP 標準：開放 Web 應用安全項目，提供網頁應用安全的最佳實踐，如防範 SQL 注入或 XSS 攻擊，常用於 API 安全優化。
13. 創造性產出：生成理解的最終目標，產出反映學習者理解的成果，如改進的程式碼或系統設計，超越簡單複製 AI 輸出。
14. GIRLS 命名：GIRLS 縮寫（Generate, Inquire, Run, Learn, Synthesize）設計為易記且具親和力，靈感來自 vibe coding 的輕鬆氛圍。
15. 批判性思維：Inquire 和 Learn 階段要求工程師質疑 AI 輸出（如「這個設計是否最佳？」），避免盲目接受。
16. 上下文模板：標準化的上下文結構（如背景 + 約束 + 示例）可重複使用，降低 context engineering 的前期成本。
17. Bcrypt：一種安全hash算法，用於密碼加密。提問其選擇原因（如計算成本高，防暴力破解）有助於理解認證邏輯。
18. 名稱接受度：GIRLS 的輕鬆命名適合學習者，但在企業環境可搭配縮寫解釋（如「生成、提問、運行、學習、創造」）提升專業性。
19. RAG 與文件檢索：進階上下文工程可使用 RAG 或向量資料庫（如 Pinecone）動態檢索相關程式碼或文件，提升生成品質。
20. 避免過度依賴：過分依賴 AI 可能削弱工程師的獨立思考，GIRLS 的提問與反思階段確保主動學習。
21. 有關"理解的節奏" 說明:

《關雎的節奏：理解，是一場生成的關係》
孔子曾說，《詩》可以興，可以觀，可以群，可以怨。
他最推崇的，是那首開篇的〈關雎〉。
關關雎鳩，在河之洲，窈窕淑女，君子好逑。
很多人以為這只是愛情詩，
但孔子看到的，是學習與理解的節奏。
那不是一見鍾情，而是一場循序漸進的生成。
「關關」兩字，是起音，也是引子；像工程師啟動對話前的第一個提示。
要讓 AI 理解你，先讓上下文流動起來，營造理解的氛圍，而不是直接命令。
>>這是 Generate — 生成的藝術。
接著，「窈窕淑女，君子好逑」。
不是衝上去追，而是觀察、提問。
孔子說，詩可以觀人之志。
工程師也該學會觀 AI 的邏輯，
問得深一點，問得準一點。 >>這是 Inquire — 提問的智慧。

—
再來，「參差荇菜，左右流之」。
學習不止於觀想，要親手去試。
運行程式碼、看錯誤日誌、觀察行為。
理解，不是想出來的，是做出來的。
>>這是 Run — 行動的證明。

—
「寤寐求之，求之不得，寤寐思服。」
這是反思與迭代的階段。
理解 AI，也是在理解自己。
一次錯誤、一段修正，
都讓思維更貼近真實。
>>這是 Learn — 反思的深度。

—
最後，「悠哉悠哉，輾轉反側。」
那不是痛苦，而是一種生成中的美感。
孔子說：「思無邪」，當學習回歸真誠與創造，
你會發現，程式不只是邏輯，
而是你理解世界的方式。
>>這是 Synthesize — 創造的完成。
—
🌿〈 關雎 〉講的不是情而是理解的節奏，GIRLS 講的是生成理解步驟
當工程師學會以這樣的節奏與 AI 共學，
那不只是生成程式碼，而是讓理解與創造，
在每一次與生成式AI 的對話之間，緩緩誕生。

孔子說《詩》可以興、可以觀、可以群、可以怨。
他最推崇〈關雎〉，因為那是一首關於「如何逐步理解」的詩。
就像我們與 AI 的關係；從陌生到熟悉，是一場生成的對話。

「關關」是聲的引子，先有氛圍，再有內容。
工程師啟動 AI 對話時，也該先準備背景與目標，
讓生成不再是命令，而是共鳴。

理解 AI，也是在理解自己。
每次 debug、每次調整提示，都讓我們更接近真實問題。
這是 學習 的力量。

孔子說：「思無邪。」
當學習回歸到純粹與創造，我們與 AI 的互動，不只是輸入與輸出，
而是一場持續生成的理解。
這正是創意 Synthesize 的境界。

當你把 AI 視為「工具」，你只在意它能幫你節省多少時間；但當你開始把它當作「夥伴」時，你會發現它能陪你走得更遠；幫助你學得更快、理解得更深，看見程式設計背後的概念與邏輯的美 – 一種層次的提升。

---

近年來，AI 幾乎滲入了每個開發者的日常。它能寫程式、除錯、生成測試案例，甚至幫你潤飾文件。許多工程師對它又愛又怕；一方面驚訝於效率的提升，一方面擔心自己的價值被取代。
但如果我們換個角度看：AI 並不是來搶走我們的工作，而是讓我們有機會看見自己思考的邊界。

---

從輸出到共同學習：AI 是鏡子，不是捷徑

多數人把 AI 當作搜尋引擎在使用。輸入問題、得到答案、貼上結果。當然，這樣做很方便，但也容易讓學習停在表面。(達克效應，註1.)
程式能跑不代表你懂。AI 幫你省下時間的同時，也可能讓你的理解越來越淺顯。

真正的突破，是當你願意問 AI：「為什麼這樣寫？」
這一問，AI 就不再只是輸出機器，而成了反思的鏡子。它會帶你回到設計的原點，去理解結構、取捨與假設。
你開始看見那些自己原本沒注意到的邏輯轉折，這正是將「知識內化」的起點。

【註 】心理學上稱這類過程為「鏡像式學習」（mirroring learning）；也就是透過他人（在這裡是 AI）的反饋，來看清自己的思維結構。

---

把 AI 當成産出程式碼的工具是一種陷阱：你將擁有結果，然後卻失去了學習的機會。

就好比；"Vibe Coding 的核心不是「讓 AI 幫我寫」，而是「讓 AI 理解我在建構什麼「概念」"。

---

工具使用者的陷阱

有位工程師曾分享，他用 AI 生成一段 API 整合程式，執行完美。但幾個月後 API 更新，他卻完全不知道該從哪裡修改起。因為那段程式不是他「理解」的結果，而是他「取得」的結果。

這就是把 AI 當工具的陷阱：你擁有結果，卻失去了學習。
工具使用者只問「怎麼做」，卻不問「為什麼」。
而軟體開發的本質從來不是複製程式碼，而是理解問題的本質。

【註】教育學者 Donald Schön 提出「反思實踐」（Reflective Practice）概念，強調專業成長發生在「行動與反思的循環」中，而非單向執行任務。AI 對話正是這種循環的最佳場域。

---

與AI協作：從程式碼共創到概念建構

當你開始與 AI 對話，而非命令它，你會發現它能帶你學得更多。
例如，請 AI 寫一段快取系統，不要只看輸出，而是問：「為什麼選這種策略？」「在資料暴增時會怎麼表現？」

再請它幫你比較不同方案、解釋效能差異、畫出邏輯流程。
這些對話讓你不只是「生成程式」，而是「生成理解」(撰寫 vibe story 就是在透過過程形成概念)。

【註】教育心理學中有個概念叫「生成理解」（Generative Understanding），指透過創造與解釋過程來建構知識。與 AI 對話正是這樣的生成行為——你不再是被動接收，而是主動共構。

AI 生成的每段程式碼，都是一次機會，一次可以學習的素材。
錯了! 也是一種學習。因為你得去理解錯在哪裡、為什麼錯。這讓你與 AI 的互動不再是輸入–輸出的循環，而是連續的思考對話。

---

讓AI成為學習夥伴的三個關鍵習慣

• 第一個習慣，是以概念為中心提問。
  與其說「幫我寫一個排序函式」，不如問：「如果我要在大型資料集下維持穩定性與可擴充性，該怎麼設計排序演算法？」
  這樣的問題會讓 AI 帶出「為什麼」，而非只是「這麼做」。

• 第二個習慣，是建立反饋循環。
  讓 AI 解釋它的選擇，請它檢查並改進自己的輸出。問：「如果要重構，你會從哪裡開始？」「有哪些 trade-off？」
  這些問句會讓 AI 的回答逐步揭露底層原則，也讓你的知識跟著深化。

• 第三個習慣，是故事化學習。
  將每一次與 AI 的互動，記錄成一段小故事：當時的情境、任務、挑戰、結果與學習。這樣的記錄不只是技術筆記，更是一種反思的鏡像。
  久而久之，你不僅在累積程式碼，也在累積思考軌跡。

【註 】這種記錄法與「Living Documentation」理念相似，知識不該只存在靜態文件，而應活在日常對話與持續演化的過程中。

從「生產程式」到「生成理解」

AI 帶來的，不是取代，而是升級。
它迫使我們放下「怎麼做得更快」的焦慮，回到「為什麼這樣做」的思考。

在這個時代，最強的工程師不一定寫最多程式，而是懂得讓AI的演算能力參與了自己的學習過程。
他們透過對話讓抽象變清晰、讓程式變可理解，並在每次生成的過程中重新塑造自己的思維。

AI 時代的進階，不是誰能把提示寫得更精準，而是與 AI 共學、共創、共思。
因為最終，我們要生成的，不只是程式，而是理解。

這麼做了，AI便不會取代工程師，它反而會放大工程師的思考。能被放大的，才是真正屬於你的力量。

小結：讓AI放大你的思考，而非取代你的手

AI 正在改變程式設計的樣貌，但它帶來的真正價值，從來不只是「寫得更快」。
當工程師學會以概念為中心提問、建立反饋循環，並用故事化的方式吸收經驗，AI 就不再只是產生程式的工廠，而是你思考的延伸。

透過這樣的協作，我們逐漸從「生產程式」走向「生成理解」，
從追求速度，轉向追求洞見；
從單向操作，變成雙向學習。

最終，AI 不會取代工程師，它只會放大工程師思考的深度。
而能被放大的，永遠是那些願意學習、願意思考、願意與未來同行的人。

當你願意問 AI：「為什麼這樣寫？」

這一問，AI 就不再只是輸出機器，而成了反思的鏡子。它會帶你回到設計的原點，去理解結構、取捨與假設。

---

延伸閱讀與概念出處

1. 達克效應（Dunning-Kruger effect)

鄧寧-克魯格效應簡稱「達克效應」，有人稱它為井底之蛙現象，是一種認知偏差，描述能力欠缺的人有一種虛幻的自我優越感，錯誤地認為自己 已經會了。

2. Donald A. Schön, The Reflective Practitioner: How Professionals Think in Action (1983) – 學習的迭代循環

這本經典著作提出「反思實踐」（Reflective Practice）概念，指出專業者的成長來自「行動與反思的循環」。與 AI 協作時的對話，其實正是這種實踐的現代延伸；AI 提供即時的鏡像回饋，讓工程師在操作中進行思考與修正。

3. John D. Bransford, Ann L. Brown, and Rodney R. Cocking (Eds.), How People Learn: Brain, Mind, Experience, and School (2000)

本書提出「生成理解」（Generative Understanding）概念：學習者透過創造、解釋與應用新知來建構理解，而非被動接收資訊。與 AI 對話屬於這種生成型學習；每次提問、解釋與修正，都是知識建構的過程。

4. Jean Lave & Etienne Wenger, Situated Learning: Legitimate Peripheral Participation (1991) – 認知協作

強調學習是社會互動中的參與行為，而非個體的內在過程。這觀點可延伸至 AI 協作：工程師與 AI 的對話形成一種「認知共作」（cognitive co-participation），讓學習嵌入實際工作情境中。

5. Dan North, Introducing BDD (2006) – 對話即設計

行為驅動開發（BDD）倡導「對話即設計」，強調透過故事與範例讓團隊共構理解。這理念與文中「Vibe Story」及「故事化學習」不謀而合，皆主張知識應來自具體的語境與交流。

6. Cyrille Martraire, Living Documentation: Continuous Knowledge Sharing by Design (2019) – 活文件

提出「活文件」(Living Documentation) 思想：文件不應是靜態產物，而要與程式與討論共演化。這啟發了工程師如何將與 AI 的協作記錄下來，使知識保持流動與更新。

7. Donald Norman, The Design of Everyday Things (1988)

Norman 提出「可見化思考」（Making Thinking Visible）概念，指出好設計應揭示其邏輯與用途。與 AI 對話時要求其解釋設計選擇，正是讓程式思維變得「可見」，進而強化理解的過程。

8. Harvard Project Zero, Making Thinking Visible: How to Promote Engagement, Understanding, and Independence for All Learners (Ritchhart, Church, & M

延伸 Norman 的觀點，提出一系列讓思考外化的學習方法。AI 互動若能引導工程師「說出自己的思考」，正是將抽象的邏輯變成可觀察的學習素材。