前幾天讀到 Anthropic 的 Thariq 寫了一篇 A Field Guide to Fable: Finding Your Unknowns，談怎麼用好 Fable 5 這個目前號稱最強的 coding agent 模型。文章寫得很扎實，框架也漂亮——但讀完之後我腦子裡一直轉的，反而是他沒有講到的那些事。
先講前提：這篇討論的東西，不是一般的 AI 使用建議。Thariq 的方法論，以及我接下來要聊的，都建立在一個特定前提上——你用的是 Fable 5 這個等級的新世代模型。什麼等級？能力夠強、主動性夠高、會在你沒給指示的地方自行判斷並完成工作。如果你用的模型還需要你手把手拆解每個步驟，那你面對的是另一組問題，不在這裡的討論範圍。
OK，那我們開始。
三十秒讀懂他的框架
Thariq 的核心隱喻是「地圖 vs 領土」——你的提示詞是地圖，實際的 codebase 和約束條件是領土，兩者之間的落差就是你的 unknowns（未知之處）。
他把 unknowns 拆成經典的四象限：
- Known Knowns（知道已知）：你寫進提示詞的東西
- Known Unknowns（知道未知）：你知道自己還沒想清楚的部分
- Unknown Knowns（不明已知）：你覺得太理所當然而不會寫下來，但看到就知道對不對的東西
- Unknown Unknowns（不明未知）：你根本沒想到的坑
然後圍繞這四個象限，他設計了一套三階段工法：
實作前，用 盲點排除（blind spot pass）讓 Claude 幫你挖盲點、腦力激盪（brainstorm）做原型探索、訪談（interview）讓 Claude 反問你、找 參考原始碼、擬定 實作計劃（implementation plan）。實作中，開一個 implementation-notes.md 記錄 agent 偏離計畫的決策。實作後，打包成 pitch 文件加速 review，讓 Claude 出題考你確認你真的理解改了什麼。
核心主張很明確：Fable 5 的工作品質瓶頸，不在模型能力，在你釐清 unknowns 的能力。
這個主張本身我同意。但問題在於，他從這個主張推導出來的對策，有幾個結構性的盲點。
你不在場的那個瞬間
先聊一個根本性的變化。
傳統開發——不管有沒有用 AI——人類是執行者。你在寫程式碼的過程中親自撞上未知：「啊，這個 API 沒有我以為的那個參數」「啊，這兩個 state 會互相打架」。你痛苦，但你不會「不知道發生了什麼」，因為你就在現場，探索（discovery）和 實作（implementation）是同一個動作。
新模型改變了這件事。
當 AI 在執行過程中撞上未知，它不會停下來困惑（人類工程師會），它會用自己的 最佳猜測策略（best guess）直接跨過去。你交給它一個任務，它還你一個看起來完整、能跑、邏輯自洽的成品。問題是——它在過程中碰到的那些分岔路口，它替你做的那些選擇，你完全不知道。
你不在那個判斷瞬間裡。
所以 Thariq 才要搞那麼多前置探索流程（discovery）——blind spot pass、interview、prototype，全部都是在 agent 開始跑之前先把問題逼出來。這些動作的本質不是傳統意義的「前期規劃」，而是在補償一件事：一旦 agent 開始跑，你就不在 決策迴圈（decision loop）裡了。
換句話說，他做這些前置工作的真正原因，不是怕 AI 做不到，是怕它做到了但不是你要的，而你還看不出差異。
盲點悖論：誰來發現你不知道的事？
好，那我們來看他的核心對策——盲點排除（blind spot pass）。
概念很直覺：你告訴 Claude 你要做什麼、你知道什麼、你的經驗背景，然後請它幫你找出你的「不明未知」（unknown unknowns）。聽起來很合理對吧？
但這裡有個結構性的矛盾：能被你找到的，就已經不是盲點了。
盲點排除 能做到的，充其量是把 不明未知 轉換成 已知未知——把「你不知道自己不知道的」變成「你知道自己不知道的」。但這個轉換能成功的前提是什麼？是你對那個 領域範圍 已經有足夠的既有認知，讓 Claude 有東西可以「照出來」。
打個比方：一個資深後端工程師要做 auth 模組，他做 盲點排除 的時候，Claude 提醒他「這個 codebase 的 session 管理有個特殊的 middleware chain」——這對他有用，因為他知道什麼是 middleware chain，只是不知道這個 codebase 的特殊做法。這是「忘了考慮」，不是真正的盲點。
但同一個工程師如果要去寫 shader（渲染器）？做 color grading（調色處理）、？他的「不明未知」跟初學者一樣多。盲點排除 能挖出什麼？Claude 不知道他不知道什麼，他也不知道自己不知道什麼——兩個視野的交集不等於全貌。
所以這套方法論真正適用的，不是「資深的人」，是「在自己熟悉領域裡工作的人」。資深不資深不是關鍵，你對那塊 領域 有沒有足夠的認知底盤才是。
對於真正面對 不明未知 的使用者——進入陌生領域的開發者、剛開始學 AI 協作的人——這套方法論提供的，是一種結構完整但實質空轉的安全感：你做了 盲點排除，你覺得自己準備好了，但真正會炸的東西根本沒出現在那次 pass 裡。
（說到底，如果「做一次 盲點排除 就能找到所有盲點」這件事成立的話，那軟體開發大概就不會有 bug 這種東西了吧……）
失敗模式的質變：從做不出來，到不知道哪裡不對
這就帶出了一個更深層的問題——AI 失敗的方式，已經跟以前完全不一樣了。
用舊模型的時候，失敗是顯性的。你少給一個條件，它就卡住、報錯、生出一個半成品。你一看就知道「這裡壞了，我得補東西」。痛苦，但安全——因為壞掉的東西不會被誤認為完成品。
新模型呢？你少給一個條件，它用自己的判斷補上去。交給你一個看起來完整、能跑、邏輯自洽的成品。
但那個「補上去的判斷」是不是你要的？你不一定看得出來——特別是在你不熟的領域。
風險的性質變了。以前的風險是「做不出來」，現在的風險是「做出來了，但你不知道哪裡不對」。
而且這個風險特別陰險的地方在於——它不會立刻爆開。你的功能上線了、client 驗收了、KPI 達標了。一切看起來都好好的。風險藏在「下一次需求變更」或「第一次出意外」的時候：AI 在過程中替你做了三十個你從未同意過的小決策，每個單獨看都合理，但你從來沒有檢視過這個決策組合。等到某個環節出問題，你回頭找，根本不知道是哪個假設偏掉的。
Thariq 的方法論，本質上就是在處理這個新型風險。但如同前面說的——能用這套方法有效防禦的人，恰好是那些「本來就看得出哪裡不對」的人。看不出來的人，做了 盲點排除 也還是看不出來。
數學考卷與 KPI 的陷阱
我後來想到一個比喻，可能可以幫大家更直覺地理解這個問題。
這就像數學考試。過去你寫不出正確答案的時候，老師至少可以看到你的運算過程，根據過程給予適當的分數——你的思路是對的，只是計算出錯，還是可以拿部分分數。
現在呢？AI 幫你寫的答案都是對的。但過程呢？如果老師不去檢查計算過程的話，要怎麼評分就出現了一個很尷尬的狀況。
更深一層想：一個學生用錯誤的過程碰巧得到正確答案，老師只看答案就給滿分。這個學生下一題換個數字就會爆掉——而且師生雙方都不知道為什麼。
對應到現在的開發現場就是：AI 用了一組你不知道的假設做出能跑的成品，你驗收通過。三個月後需求一變，那些隱藏的假設開始崩，而你完全無法 debug，因為你從來沒理解過那個「運算過程」。
這件事放大到組織層面更可怕。
當 AI 讓「不理解過程但產出正確結果」變成預設狀態——注意，不是例外，是預設——結果導向的評價體系就從根部失效了。不是有人在作弊，不是有人走捷徑，是整個結構預設「能交出成果＝有能力」，而 AI 讓這個等式徹底斷裂了。你正常使用工具，KPI 就達標了。但整個組織可能正在累積一堆沒有人真正理解的產出。
以前 KPI 造假是個人道德問題，管理層可以靠稽核去抓。但現在這個問題是結構性的——沒有人在造假，系統本身就會產出這個結果。
工具沒有消失，裡面裝的東西要換掉
聊到這裡，很多人可能會想：那以前大家花那麼多時間建立的 Sub-Agent 架構、Skill 定義、精心設計的 prompt template，是不是都白費了？
不是白費。但裡面裝的東西，方向要整個翻轉。
以前我們寫一個 Skill 的內容是什麼？「第一步呼叫這個 API，第二步解析 response，第三步格式化輸出。」它本質上是一份操作手冊，補的是 AI「不知道怎麼做」的缺口。
但當模型已經強到自己會做了，這種操作手冊式的 Skill 不只是多餘——它可能變成反效果。你寫了一堆 SOP 限制 AI 的行為路徑，但它本來可以找到更好的路，你的 SOP 反而把它鎖死在你認知範圍內的解法。
現在同一個 Skill 該寫的是什麼？「這個專案的命名慣例長這樣、錯誤處理的哲學是 快速失敗（fail fast）不是 retry（重試）、前端的互動風格偏保守，不要搞花俏動畫。」它變成一份決策指南，定義的不是「怎麼做」，而是「AI 自己判斷的時候該往哪邊靠」。
Sub-Agent 的拆法也是一樣。以前拆 agent 是因為一個模型吃不下整個任務，所以你幫它分工。現在模型的能力不是問題，但你還是可能需要拆——理由不同了：這幾個決策領域的判斷標準根本不同，混在一起會讓 AI 的優先序互相打架。
所以工具的外殼沒變，但內容物要從 how（怎麼做）轉向 what matters（在意什麼）。從教 AI 做事，變成告訴 AI 你在意什麼。
這個轉向聽起來簡單，但實際操作起來比寫 SOP 難太多了——因為「你在意什麼」這個問題，很多時候你自己也沒想清楚。（又回到那個盲點悖論了是吧……）
真正需要的不是更好的 SOP，是判斷力
把上面這些串起來看，Thariq 的方法論做了一件很有價值的事：它提醒大家，面對能力極強的新模型，你的工作方式需要根本性地改變。不是給更詳細的指令，而是在對的地方設下對的邊界。
但他給的是攔截的操作手冊——blind spot pass（盲點排除）、interview（訪談）、quiz（提問）、implementation notes（實作筆記）。他沒有處理的是：你怎麼知道該在哪裡攔？
什麼決策是「AI 你自己決定就好」的？什麼是「這個你得問我」的？同一個技術分岔點——用 輪詢（polling）還是 websocket——對不同的專案、不同的人、不同的優先序，重要性完全不同。
這個判斷力沒有 SOP 可以速成。它來自你對自己要什麼的清晰程度，來自你對那個領域的認知深度，來自你跟 AI 協作夠久之後累積出的直覺——什麼時候該放手讓它跑，什麼時候該介入。
模型變強不是讓你退後的理由。恰好相反——你需要往前站，只是站的位置不一樣了。以前你站在「寫程式碼」的位置，現在你站在「守決策品質」的位置。
而對某些人來說，後者其實更難。因為寫程式碼有對錯，守決策品質沒有標準答案。
被迫升職：從工程師到管理者
其實換個角度想，這整件事就像一次強制升職。
以前用舊模型，你是資深工程師帶一個能力不足的 初階新人。你得幫它拆任務、寫詳細指令、檢查每一步的產出。累，但你勝任——因為用的還是工程師的能力：把定義好的問題解決掉。
現在用新模型，你的角色變了。你變成管理者，帶一個能力極強但不懂你要什麼的新人。他什麼都做得到，效率比你高，涉獵比你廣——但你不說清楚方向，他就自己決定往哪走。你需要的不再是「怎麼做」的知識，是「要做什麼」和「做到什麼程度算好」的判斷。
而且這次的「升職」不是公司決定的，不是你主動爭取的——是模型的能力進步直接把你推上去的。你沒有選擇要不要當管理者，模型一更新，你就是了。
這基本上就是彼得原理的 AI 版。
職場上我們都看過這種情形：一個技術能力很強的工程師被拔擢成主管，然後發現自己不勝任。不是他變笨了，是這個位置需要的能力跟他擅長的能力根本是兩套東西。工程師的核心能力是「給我規格，我實現出來」；管理者的核心能力是「定義問題本身——什麼該做、什麼不該做、優先序怎麼排、品質標準在哪裡」。
現在每一個使用新模型的開發者，都在經歷這個轉換。而且跟職場不同的是——職場裡你可以選擇不升職，繼續當資深工程師好好寫程式碼。但 AI 模型的進化不給你這個選項。它直接改變了「使用 AI 寫程式」這件事的本質，你要嘛學會用管理者的方式跟它協作，要嘛就得接受它替你做的每一個你看不到的決策。
Thariq 的方法論，翻譯成這個框架的話，其實就是一本「新手管理者速成手冊」——教你做 一對一訪談（one-on-one, interview）、設訂目標與關鍵結果（OKR, implementation plan）、做 回顧（retrospective, quiz）。對於本來就有管理思維的人，這些工具拿起來就能用。但對於一直靠技術能力吃飯、從來沒有練過「定義方向」這塊肌肉的人……
嗯，速成手冊救不了肌肉量不足的問題。
進步，還是複雜度搬家？
我不是要否定 Fable 5 或任何新模型帶來的進步。能力的提升是實實在在的，很多以前做不到的事情現在可以做到了。
但在慶祝之前，值得想清楚一件事：
模型能力進步了，使用者的負擔從「實作」轉移到了「定義意圖」。聽起來很美好——從動手做事，升級到定義方向。
但「定義意圖」其實比「寫程式碼」更難。程式碼有編譯器、有測試、有 CI 會擋你。意圖呢？沒有任何機制會告訴你「你定義的方向是錯的」——直到三個月後爆掉。
你省下的力氣，有沒有被另一種更隱蔽的成本悄悄接走？
對非技術者來說，大概不需要想這些。AI 幫你補完空白、交出成品，你開心用就好——這確實是解放。
但對技術者，對企業，對任何需要為成品負責的人來說——新模型不是讓你輕鬆的。它只是把複雜度從一個你看得到的地方，搬到了一個你看不到的地方。
而 Thariq 的方法論，與其說是一套完整的解決方案，不如說是一聲來得正是時候的警鈴：你以為 AI 越強你就可以越退後？不，你得往前站——而且你得比以前更清楚自己到底要什麼。
（至於怎麼變得更清楚自己要什麼……嗯，那大概是另一篇文章的事了。）
