Ruddy Lee 分享空間

AI 時代的敏捷不再只是開發流程，而是一個持續修正的學習系統。

在AI時代，傳統的「敏捷開發」（Agile Development）已經不足以應對快速變化的環境。 因為AI不再只是輔助工具，而是你的「第二大腦」。 如果你只把AI當成「寫code的助手」，你會一直處於追趕狀態，持續的焦慮會一直陪伴著你； 但如果你把整個開發流程轉型成一個持續學習的系統，你就能在AI時代取得領先。

這個系統概念稱為「AI敏捷」，它的核心有三件事：

1. 適應開發節奏
2. 與 AI 共智（Co-Intelligence）
3. 採用假設思維(Hypothesis Thinking)

掌握這三點，你不需要重讀大量AI論文，也不需要等待公司導入新框架，就能立刻在當前專案、當前行程式碼中適應AI時代。

---

一、開發節奏：把「一天」當成最小學習單位

傳統敏捷以「Sprint」（衝刺，通常1-4週）作為節奏單位，AI敏捷則改以「一天」為最小節奏單位。

原因很簡單：AI模型與工具的迭代速度已達小時級甚至分鐘級。 你今天早上用的Prompt，下午可能就顯得過時；今天下午學到的模式，明天早上可能已被新模型超越。

工程師可以參考執行的具體做法：

• 每天固定30分鐘「AI Pair Programming Time」（AI配對程式設計時間）： 開一個新分支，把昨天的程式碼交給AI重構，然後你親自Review它的每一個決定。 重點不是讓AI寫完就結束，而是透過Review來學習它的思考邏輯。 因為 Vibe coding 所產出的程式碼一定要足夠的了解才能放行，避免黑盒。
• 每天下午4點進行「今日假設驗證」： 選出今天最重要的假設（例如：「這個API若採用RAG(註1.)會比fine-tune(註2,)快3倍」），立刻實測並記錄結果。 失敗沒關係，關鍵是把失敗數據轉化為下次Prompt的養分。
• 每週五下午做「節奏復盤」： 比較本週 AI產出的程式碼與最終合併版本的diff，問自己： 「AI哪裡幫我省時間？哪裡反而讓我多花時間？」 把心得寫進個人「AI Prompt Library」（Prompt資料庫），然後傳入Skills中。

相信；持續一個月，你的開發速度會從線性成長轉為指數成長，因為你的節奏已與AI同步。

---

二、與AI共智：從「使用AI」升級到「與AI形成共智關係」

許多工程師還停留在「讓Copilot補function」或「問Claude怎麼優化」的階段。 Ethan Mollick（沃頓商學院教授，《Co-Intelligence: Living and Working with AI》作者）提出：真正的共智（Co-Intelligence）是把AI視為「有缺陷但極具潛力的合作夥伴」，並用四項原則系統性地互動。

Ethan Mollick的四原則（實戰版）：

1. 永遠邀請AI上桌（Always Invite AI to the Table） 不管任務大小、難易，都先把AI拉進來參與。 即使這次沒幫助、甚至搞砸，也是在持續探測「AI目前的邊界」。 實踐方式：
   • 每天第一件事：把待辦清單丟給AI，讓它拆解、估時、提風險。
   • 寫code前：先問「如果你是這個功能的資深維護工程師，你會怎麼設計？」
   • 連debug log、寫commit message、review PR都讓AI參與。 一個月後，AI會從「偶爾工具」變成你思考流程的預設的一部分。
2. 做在迴圈裡的那個人（Be the Human in the Loop） AI會產生幻覺（hallucination,註3）、偷懶或誤解上下文，你必須永遠保持「最終負責人」角色。 但這不是單純檢查，而是「與AI共同學習」的過程。 實踐方式：
   • AI給完code後，用Prompt問：「找出這段code的所有潛在bug、效能地雷、安全漏洞，並評分嚴重度。」然後親自驗證。
   • AI出錯時，不要只修正，要問：「你為什麼這樣判斷？下次怎麼避免？」把答案加入專案記憶庫。
   • 架構選擇、trade-off等關鍵決策由你拍板，AI只負責提供選項與論證。
   • 這是你看見全貌的最好方式。
3. 把AI當人對待，但先告訴它它是什麼樣的人（Treat AI Like a Person, But Tell It What Kind of Person It Is） 給AI明確的「角色 + 個性 + 專業背景」，它的輸出品質會大幅提升，因為它會模仿該角色的思考模式。 實踐方式（可直接複製的Prompt模板）：
   • 「你現在是Meta Scale Infrastructure團隊的Distinguished Engineer(註4)，專長distributed system與高可用性，請用SRE⁵最高標準幫我設計這個cache失效策略。」
   • 「你是一位極度偏執的安全工程師，曾在Google負責過身份驗證系統，請審核這段JWT實作的所有潛在漏洞。」
   • 「你是我最討厭拖拉、愛找碴的前同事，請挑剔這段refactor後的code，找出任何可能讓未來維護者罵娘的地方。」 越具體、越有「人格」，AI越能給出高價值洞見。
4. 假設這個AI是你用過最爛的AI（Assume This Is the Worst AI You Will Ever Use） 今天最好的模型，明天就會被超越。永遠用「這只是起點」的態度，避免過度依賴，也避免因一次失敗就放棄。 實踐方式：
   • 用完AI後問自己：「如果明天模型強10倍，我現在的Prompt會不會浪費？」
   • Prompt寫得「未來相容」：多用邏輯鏈（Chain of Thought）、Few-shot範例、多要求自我檢驗。
   • AI表現很差時，視為「數據點」而非挫折，記錄下來迭代Prompt Library。

四原則如何串聯成完整共智流程？

邀請上桌 → 定義角色 → 保持人類在迴圈 → 以最爛AI心態持續迭代。 當你內化這些原則，AI就從「外掛」變成你思考的延伸。在顧問的組織裡，他表現的效果都非常的好，只是這個成果只記在工程師身上，沒人認為是推廣者的功勞。

三、採用假設思維：把開發變成科學實驗

AI時代最大的陷阱是「看起來很完美」的幻覺。 AI產出的code永遠漂亮，但不一定正確，但實際上有方法可以應對它，哪便是假設思維。

假設思維的四步驟（工程師必備心法）：

1. 明確假設 寫code前先說出口：「我假設用這個Prompt + GPT-4o能在30分鐘內完成這個功能，且bug率低於5%。」
2. 快速驗證 每寫一個小模塊就立刻驗證（unit test + AI自檢Prompt）。
3. 紀錄偏差 AI輸出與預期有差距時記錄：「AI誤判邊界條件X，因為Prompt沒提到Y。」這是下次Prompt升級的原料。
4. 迭代假設 把偏差紀錄變成新Prompt的開頭：「根據上次失敗教訓，這次請先…」

把每一次的開發作業都霸它當成在座科學實驗，將AI活生生的從黑盒子變成可控制變因的實驗室。

---

結語：AI敏捷不是方法論，是生存技能

讓我們從「害怕被AI取代」的工程師，轉而成為另一種「與AI共智」的成功人士。前者把AI當工具，後者把AI當學習系統。入門門檻極低，你今天就可以開始：

• 開一個新分支
• 設定 30分鐘AI Pair Time
• 寫下今天第一個「開發假設」(註7.)

持續一個月後，你會發現： 寫code不再是「工作」，而是「與AI一起進化」的日常。

這就是AI敏捷的本質，不是讓你更快寫code，而是讓你更快成為AI時代的工程師。

現在，開始你的第一天實驗吧。 你的AI夥伴已經在等你。

---

註釋

1. RAG（Retrieval-Augmented Generation，檢索增強生成）：一種讓大型語言模型在生成回答前，先從外部知識庫檢索相關文件，再結合檢索內容生成答案的技術，能大幅降低幻覺並提高準確性。 ↩
2. fine-tune（微調）：對預訓練的大型語言模型進行針對特定任務或資料集的進一步訓練，使其在該領域表現更好，但需要較多計算資源與資料。 ↩
3. hallucination（幻覺）：AI生成看似合理但實際錯誤或虛構的內容，常見於大型語言模型。 ↩
4. Distinguished Engineer：科技公司（如Meta、Google）的高階技術職稱，通常代表在某領域有極高專業成就、能影響公司技術方向的資深工程師。 ↩
5. SRE（Site Reliability Engineering，網站可靠性工程）：Google首創的一種軟體工程與運維結合的實務，強調透過軟體工程方法來達成系統的高可用性與可靠性。 ↩
6. 假設思維(Hypothesis Thinking) : 請參考敏捷的假設思維、談假設思維之下的開發者體驗
7. 如何做假設， 四個基本元素:

當遇到不確定性的問題，要做的第一件事其實很簡單: 先冷靜下來，停一下。別急著做決策，也別依據過去的習慣辦事，別馬上Google一堆答案或問ChatGPT「該怎麼辦」。Maggie Jackson 在她的書《Uncertain》裡提出了一個超實用的四步心法，叫 「S.H.I.P. 迷霧法則」，就像在霧裡開船的指南針，幫你: 先穩住、看清楚後再小步的前進：

• S – Stillness（先停下來） 腦袋嗡嗡叫的時候，先深呼吸，把船錨丟下去。別急著做決定，讓自己靜一靜，讓那團霧慢慢散開一點。很多時候，停下來才是最有力的行動。
• H – Humility（承認自己不知道） 老實說一句：「我現在真的搞不清楚。」承認有空白、不知道的部分，反而讓你輕鬆一點。不用硬裝懂，也不用急著把所有答案塞滿腦袋。
• I – Inquiry（帶著好奇去問） 這時候才打開手電筒，開始問：「到底是哪裡讓我這麼不安？」「有沒有我沒注意到的線索？」「別人怎麼看這件事？」用好奇心取代恐懼，去照亮霧裡的細節。
• P – Productive Struggle（用力划，但划得有意義） 接下來會覺得累、會卡住、會很掙扎，但這是好的掙扎。就像健身時肌肉在酸痛一樣，這股阻力正在幫你變強。堅持下去，你會慢慢找到方向，也變得更能扛事。

先停下來 → 承認自己不知道 → 然後帶著好奇去問 → 克服困難掙扎的去實踐

---

在當今的 AI 時代，我們正站在一場前所未有的科技變革浪潮之中。人工智慧不僅重塑了工作的方式、產業的結構與日常生活的節奏，也帶來一種深層而普遍的「不可預測性」。生成式 AI 的爆發、模型能力的指數級成長，使未來看似充滿可能，卻同時籠罩在層層迷霧之中。失業風險、倫理爭議、隱私外洩，以及社會結構可能發生的劇烈變動，讓人們在期待與焦慮之間來回擺盪。（註1.）

---

• 在生存層面：人們擔心自己的工作被AI所取代，擔心將會失業恐懼。
• 成長層面：學習不再是為了向上爬，而變成了為了「不掉隊」的生存掙扎。學習與轉型的無力感。
• 自我認同層面：價值感與存在焦慮。人們害怕自己從「創造者」降級為「作業員」，害怕原本定義我們是「誰」的技能，變得一文不值。
• 人生的宏觀層面：人生與社會的不確定。對社會結構、金錢流向與教育體系的信任感正在瓦解。

這張圖雖然充滿了焦慮，但也反映了一個事實：我們正在經歷一場「意義的轉型」。

---

不確定性，已成為結構性問題

在這樣的時代背景下，不確定性不再只是個人的心理狀態，而是一種結構性的現象。對被取代的恐懼、對未來的不安、對意義流失的疑問，並非來自單一事件，而是來自一個高速變動、難以預測的系統。

那麼，問題不再只是「如何消除不確定」，而是：我們該如何在不確定中行動，而不迷失方向？

從恐懼到智慧：Maggie Jackson 的不確定觀

Maggie Jackson 在《意料之內》中提出一個關鍵觀點：不確定性並非認知的缺陷，而是一種心智的鞭策（mental spur）。正因為我們無法依賴既有答案，才被迫跳脫慣性，進入更高層次的思考與判斷。（註3.）

她結合神經科學與心理學研究指出，不確定能促進創造力、培養韌性，並深化人際理解。在 AI 時代，這一點尤為明顯，當知識迅速過期、職涯路徑變得難以預測，不確定已成為常態。

世界經濟論壇（WEF）預估，到 2030 年，AI 可能取代約 8,500 萬個工作，但同時也創造約 9,700 萬個新機會。這並非單純的樂觀或悲觀，而是顯示：轉換本身，才是最大的風險與挑戰。（註4.）

---

告別知識就是力量，迎接「知識的轉化」才是力量。

---

Jackson 進一步警告，現代社會過度追求「確定性」，習慣用數據、演算法與快速決策來壓制不確定。但在 AI 黑箱盛行的情境下，這反而可能放大偏誤、掩蓋風險。（註5.）

她主張，我們需要的是「在不確定中行動的能力」，而非假裝不確定不存在。為此，她提出了 S.H.I.P. 法則，作為在迷霧中航行的行動指南：（註7.）

• Stillness：在不確定來臨時，暫停衝動反應，避免被資訊洪水牽著走
• Humility：承認知識有限，為學習與修正保留空間
• Inquiry：以好奇心主動探詢未知，而非被動等待答案
• Productive Struggle：將掙扎視為成長的必要張力，而非失敗

SHIP 法則提供的是導航心態，但僅有心態仍不足以解決長期所承受的壓力。

結構思維：讓思考不在壓力下崩塌

如果不確定是原料，那我們需要一種能承重的結構。

J.E. Gordon 在《結構：為何物體不會崩塌》中，從工程學角度提供極為務實的視角。他指出，結構的韌性來自對基本原則的理解——張力、壓力、材料強度與斷裂點，而非追求完美計算。（註15.）

好的結構會加入「安全係數」，不是假設一切順利，而是預留餘裕應對未知。這一思維在軟體工程與 DevOps 中已有對應實踐，如錯誤預算、冗餘設計與混沌工程。（註11.）

將 Jackson 與 Gordon 的觀點結合，我們可以這樣理解：

不確定是外部負荷，結構思維是內部支撐。

• 將結構思維應用於 AI 不確定性的四個步驟
• 識別不確定（映射外部負荷）
• 分解問題（檢視材料強度）
• 在不完整資訊下迭代前進（可調式結構）
• 在團隊與社會層面建立韌性結構

限制與未來

結構思維並非萬靈丹。過度結構化可能壓抑創造力；忽略人類情感，也可能造成脆性失敗。理想狀態不是選邊站，而是在結構與開放之間維持張力。

在代理式 AI 興起的未來，不確定只會更頻繁。我們需要的，將是一種「可承壓、可調整、可學習」的適應性思維。

結語

在面對 AI 時代的不確定性時，我們其實同時卡在兩個層次：
一個是內在的，為什麼我會焦慮、遲疑、害怕做錯決定？
另一個是現實的，在資訊不完整、變化又這麼快的情況下，我到底該怎麼行動，才不會一腳踩空？

也正是在這兩個層次上，Maggie Jackson 與 J.E. Gordon 的兩本書，形成了一個意外卻高度互補的對話。

《意料之內》不是一本教你「如何做出正確決策」的書。相反地，它試圖回答一個更根本的問題：當世界本來就不確定時，我們是否錯把不確定當成失敗？
Jackson 告訴我們，不確定並非理性不足的象徵，而是一種迫使心智升級的狀態。當舊答案失效、路徑模糊時，人類反而更可能產生創造力、韌性與真正的理解。這本書像是一位冷靜的嚮導，幫助我們在焦慮中重新站穩，而不是急著找答案。

而《結構：為何物體不會崩塌》則從完全不同的角度切入。Gordon 關心的不是感受，而是在不可預測的外力下，什麼樣的結構能撐得住。他用橋樑、飛機、建築的例子反覆提醒我們：真正可靠的結構，從來不是假設一切順利，而是預先承認「一定會有超出預期的狀況發生」。

放在 AI 時代來看，這本書給的是一種極為務實的提醒：不要等到資訊完備才行動，而是要建立能在不確定中「彎而不斷」的思考與決策結構。

如果說 Maggie Jackson 幫助我們重新理解「不確定是什麼」，那麼 J.E. Gordon 則教會我們：當不確定來臨時，該如何設計一個不會輕易崩塌的行動方式。
這也正是為什麼，這兩本書特別適合在 AI 時代一起閱讀。

AI 時代的不確定，不只是威脅，而是一種邀請。借 Maggie Jackson 的智慧，我們學會不逃避不確定；用 J.E. Gordon 的結構思維，我們學會在其中前行。

迷霧不會消失，但我們可以學會航行。

---

註解

註解1：不確定性的三層面: 技術、經濟、社會。

註解2：這二本書都是針對AI時代不確定性所給人的衝擊著作。

• Maggie Jackson 提供「心態轉換」: 《意料之內》作者: 瑪吉·傑克遜

意料之內：有限的認知與不確定的環境(Un-certain).

• J.E. Gordon 提供「務實工程視角」: 《結構》 作者：J.E.戈登

《結構：為何物體不會崩塌》(Structures: Or Why Things Don’t Fall Down.)

註解3：Jackson 核心概念「uncertainty as a spur to higher-order thinking」。不要害怕不確定性這種缺陷，而應該視它為一種「智慧與奇蹟」的來源。

不確定性是來自宇宙的定則，只是被AI 放大了。宇宙本來就是個大盲盒，AI 出現後，就像是有人幫你開了『自動連抽』，讓各種不確定性噴發得更快、更猛。

註解4：WEF 數據客觀呈現。「WEF 數據」指的是世界經濟論壇（World Economic Forum, WEF）發布的《Future of Jobs Report》未來工作報告，這是該組織每年更新的重要報告，用來分析全球勞動市場的變遷趨勢，特別聚焦科技（如 AI）、綠色轉型、人口結構變化、地緣經濟等宏觀因素對就業的影響。

註解5：呼應 Jackson 對「certainty-seeking culture」的批判，尤其適用 AI 黑箱問題。

註解6：Jackson 的「modes of uncertainty-in-action」，簡化為「主動探索」。

註解 7:  S.H.I.P 是 Jackson 書中的核心框架，用來強調處理不確定性的步驟式方法，唯務實的處理應用，可以避免只是在做過於抽象的討論。我喜歡稱它為 SHIP迷霧法則，可以讓人更容易記憶。

註解11：DevOps的「安全係數」觀

軟體可以借鑒「安全係數」的精神：從「估算」轉向「管理不確定性」
雖然沒有精確公式，軟體工程（尤其是 DevOps / SRE）已經發展出類似概念，讓系統在不確定中「彎而不斷」。Gordon 的韌性思維這裡超級適用：不追求「完美強度」，而是用可控變形、冗餘來吸收衝擊。

– 錯誤預算（Error Budget）：Google SRE 的經典概念，類似安全係數的「軟體版」。它定義系統可接受的「失效額度」（e.g. 99.9% uptime → 每月允許 43 分鐘 downtime）。超過預算就停發新功能，專注修復。這是對不確定性的「量化保障」——不是絕對安全，而是「可控風險」。
– SLO / SLI（Service Level Objectives / Indicators）：量化「安全邊界」（e.g. P99 latency < 200ms、錯誤率 < 0.1%）。像 Gordon 的安全係數，預留餘裕來應對突發（流量峰值、bug）。

–冗餘與自癒設計：物理結構用多梁支撐，軟體用多 replica、circuit breaker、auto-scaling。AI 中，這對應 multi-model ensemble（多模型投票）、prompt fallback（主 prompt 失效切換備用）。

– 混沌工程（Chaos Engineering）：Netflix 的實踐，刻意注入「不確定性」（隨機關機、延遲注入、prompt 污染），測試系統的「安全係數」。這比物理測試更動態，因為軟體能即時修復。

– 在 AI / Prompt 中的應用：
不確定性更高：模型輸出有隨機性、hallucination 機率、prompt 解釋變異。

借鑒安全係數：留「token 預算餘裕」；用 confidence score 作為「應力計」。

• 避免脆性：不要追求「完美 prompt」（零不確定），而用「韌性 prompt」：加入「如果 confidence 低，請解釋並建議替代」來吸收變異。

註解12：原創整合模型，讓讀者有可操作框架；J.E. Gordon 讓模型更務實化，如加入「材料測試」步驟。

註解13：強調人類優勢；用 J.E. Gordon 的「應力測試」比喻技能評估。

註解14：閉環形結尾，符合結構思維的「前進」精神。

註解15：J.E. Gordon 的「結構」概念可比喻到思維：AI 時代的不確定如「外部負荷」，結構思維則是「內部支撐」，強調務實、非抽象應用。《結構：為何物體不會崩塌》(原文書名:Structures: Or Why Things Don’t Fall Down.

前言

這是前面三篇文章的總結，我從來沒有這麼做過，把一篇超過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協作編程或學習時，
「思維鏡像」能促進我們從被動使用者轉化為主動反思者。