地圖不是領土（The map is not the territory）。你腦中的計畫、spec 與 prompt 都是地圖；真實的 code base、團隊慣例、歷史包袱與部署限制，才是領土。
在 AI Engineer 大會的舞台上，Anthropic 技術團隊成員 Thariq Shihipar 帶來一場〈Field Guide to Fable〉。他一開場延續 Claude Code 團隊的傳統——先跟全場自拍——接著直入核心：Fable 來了，而這不只是一次模型升級。
他把 Fable 形容成 RPG 遊戲從「新手教學關卡」進入「開放世界」的那一瞬間。地圖突然展開，任務變多、路線變多、可能性也變多。興奮是一定的，但同時也會有點不知所措。因為當模型不再只是更會回答，而是更會探索、更會提問、更會使用工具、更會在真實環境裡推進任務時，使用者也必須升級自己的工作方式。
我把這場演講整理、翻譯，並加上我自己帶團隊導入 AI coding 的落地觀點，寫成這篇。這也接得上我前陣子談的 從 Prompt 到 Loop Engineering：AI 協作開發的重點，一直在往「系統設計」而不是「單句提示」移動。原始演講連結放在文末。
整場演講可以濃縮成四個主題：解除 Claude 的束縛、找出你的未知、面對開發手感的失落、學會不那麼合理。 以下是我的解讀。
一、解除 Claude 的束縛：模型是養出來的，不是設計出來的
Thariq 開場就丟出一個關鍵觀點：模型是 grown，不是 designed。
意思是，Anthropic 不會某天早上醒來就決定「今天要讓模型在 SWE-bench 拿 99%」。大型語言模型比較像是透過資料、回饋、運算與訓練慢慢長出來的系統。它不是一台我們掌握每個齒輪的機器，更像一種正在被觀察、被理解、被馴化的新型智慧。
這也代表，真正限制模型的，往往不是模型本身，而是我們怎麼把它放進工作流程裡。 我們給它什麼工具、用什麼 prompt、給它多少脈絡、允許它探索到什麼程度、又用什麼方式檢查結果——這些才是天花板。
Thariq 把這件事稱為 unhobbling Claude：解除 Claude 的束縛。這裡的「束縛」不是模型不夠強，而是人類常常用過去的理解，把新模型硬塞進太窄的框架，結果模型明明有更大潛力，卻被我們的用法卡住。
Capability overhang：能力是尖峰式爆發的
他用一個概念解釋這件事：capability overhang（潛在能力尚未釋放）。模型其實已經具備某些能力，但只有搭配特定工具、環境或互動方式時，這些能力才會真的被放出來。
他舉了一個很好玩的例子：問一般聊天模型「哪些寶可夢的英文名字以 AW 結尾？」，它常常答不出來。這不代表它不知道寶可夢，而是這種任務需要完整列表、搜尋、過濾與驗證。但把同樣的問題丟給 Claude Code，它會自己抓取全部寶可夢資料，寫一段程式過濾出結尾是 AW 的，最後找出 Croconaw 和 Drednaw。
這就是「給模型手臂」的差別。
過去我們以為，讓模型讀懂大型 code base 的方法，是把 context window 撐到無限大、整包 code 塞進去。Claude Code 帶來的洞察卻是：與其把所有東西塞給模型，不如給它搜尋、讀檔、執行指令、跑測試、自己建立脈絡的能力。 模型需要的不只是更多記憶體，而是一個工作環境。這正是 Agentic Workflow 最重要的轉折——AI 不再只是坐在聊天框裡等你餵資料，而是能進入環境、探索、理解限制、執行、逐步完成任務。
系統提示詞正在變小：模型要的是脈絡，不是鐵籠
演講中另一個很值得注意的點：Anthropic 最近把 Claude Code 的 system prompt 砍掉了約 80%。
早期模型確實需要落落長的提示詞——列規則、列禁忌、列格式、給一堆範例——因為它們容易偏離目標。但到了 Fable 這一類新模型，情況反過來了：
- 過多範例反而限制模型，因為它的想像力已經超過你給的範例。
- 過多「不要做什麼」反而讓它變笨。
- 過多框架，只會讓它在你畫好的框框裡打轉。
所以現在重要的不是塞更多限制，而是給更好的 context：這個專案在哪個階段？真正的目標是什麼？哪些是現實限制、哪些只是過去留下的慣例、哪些可以被挑戰、哪些絕對不能破壞？對 Fable 來說，prompt 不再是命令清單，而更像一張任務地圖。你不是在遙控一台機器，而是在帶一個很強的協作者進現場。
從 Markdown 到 HTML Report：模型在生成「工作介面」
Thariq 也提到輸出形式的演進。一開始 Markdown 是很好的輸出，乾淨、結構化；後來有了 plan mode，模型會先把要做的事列出來讓你確認方向；到了 Fable，它甚至能直接產出完整的 HTML report，把問題、分析、互動內容嵌在裡面。連「向你提問」這件事都在進化——早期模型連多選題對話框都很難好好呼叫，現在你可以請它一次訪談你四十個問題，甚至把問題做成一份互動報告。
這個變化的意義是：AI 不只是生成文字，而是在生成工作介面。 對開發者來說，這代表一件事——別只把模型當成文字補完器，開始把它當成「臨時工具產生器」。它不只是幫你寫文件，它可以為這一次任務，臨時做一個工具。
二、地圖不是領土：先找出你的未知
當模型變得更會探索，新問題就出現了。
以前模型能力有限，可能還沒走多遠就卡住，你不太會感受到「地圖」和「領土」的落差。但 Fable 這類模型能跑得更遠、跨過更多步驟，也會遇到更多你沒寫清楚的決策點。每當它遇到地圖上沒標示的東西，就是一個 unknown——一個你沒指定、它必須自己判斷的分岔口。
所以 Fable 的瓶頸，往往不再是「模型夠不夠聰明」，而是你能不能找出自己的未知。Thariq 用一個矩陣來整理它：
| 已知（known） | 未知（unknown） | |
|---|---|---|
| 你知道你知道 | known knowns：你通常會寫進 prompt 的——要做什麼功能、輸出什麼格式、修哪個 bug | unknown knowns：你其實知道、但太理所當然而不會寫下來的——畫面風格偏好、命名習慣，那些「看到結果才會說『這不是我要的』」的直覺 |
| 你知道你不知道 | known unknowns：你清楚自己還沒搞懂的——某個 auth provider 怎麼串、某段 legacy 為什麼這樣設計 | unknown unknowns：你完全沒想到、卻可能改變整個架構的東西 |
Fable 厲害的地方，是它不只能處理你交付的任務，還能反過來幫你把地圖補完整。真正好的 Agentic Workflow，不是把 prompt 寫得神乎其技，而是讓模型協助你找出這些未知。
三、六個實戰方法：把未知變成可以討論的東西
這是我認為整場最能直接抄作業的部分。Thariq 分享了他跟 Fable 協作的幾個習慣，我依台灣團隊的場景補上用法。
方法一：Blind Spot Pass（先請它掃盲點）
進入不熟的 code base 或新任務時，不要一開始就叫模型直接實作，先請它做一次盲點掃描：
「我準備在這個 code base 接一個新的 auth provider，但我對這個模組不熟。請先幫我做 blind spot pass，找出相關的 unknown unknowns、容易踩坑的地方，以及哪些資訊會影響後續架構決策。」
它可能會去讀 auth module、翻 Git diff、看文件，甚至在有權限時搜尋 Slack 或 issue 討論，幫你把該注意的地方挖出來。這招像是開工前先派一台探測車進地下管線迷宮，避免你一鏟下去就敲到瓦斯管。台灣團隊最適合用在：接手舊系統、重構前盤點、新人熟悉專案、外包交接、導入新服務、大型 PR 前的風險掃描。
方法二：Brainstorm + Prototype（把說不出的偏好逼出來）
很多需求不是不知道，而是說不出來——尤其是設計、儀表板、流程體驗這類任務，你常常無法一開始就精準描述，但看到幾個版本馬上知道哪個對。所以：
「我沒有視覺品味。請做一個 HTML dashboard，給我四種風格截然不同的設計方向，讓我看完再回饋。」
這招專治 unknown knowns。以前做四個方向太貴，團隊一開始就被迫賭一個方向；現在探索成本大降，不是先開會吵半天，而是先讓模型做出四個靶，再一起射箭。
方法三：讓它訪談你（Interview）
當你大概知道要做什麼、但還沒有完整規格時，反過來讓 Fable 訪談你，而且指定它問問題的方向：
「請訪談我，優先問那些會改變架構設計的問題。先別問 UI 細節，先幫我釐清資料模型、權限邊界、錯誤處理與部署策略。」
這樣它就不會問一堆枝微末節，而會把火力集中在真正影響設計的決策點。這招很適合放進 PRD、ADR、spec 的前置流程，減少做到一半才發現方向錯掉。我在 規格導向的 Agentic Coding 裡談的「先把規格談清楚再開工」，本質上就是這件事。
方法四：References（給它另一張地圖）
Thariq 有一句話很值得記：給 Claude 一張地圖最好的方式之一，就是給它另一張地圖。
你不一定要從零寫完整 spec，可以直接提供一段舊系統的程式碼、另一個語言的實作、一個 HTML mockup、一份過去的 PR、一個競品流程、一份你喜歡的文件格式，然後說：「讀懂這個參考、理解它背後的意圖，再轉換到目前這個系統。」Fable 特別擅長這件事，因為它不是照抄，而是能抽取結構、意圖與限制，再映射到新環境。
這也是我認為 prompt engineering 正在往 reference engineering 移動的原因：真正有價值的，不是把需求寫成一串咒語，而是提供高品質參考，讓模型看見你心中那張地圖長什麼樣子。
方法五：Implementation Notes（要求它記錄偏離點）
Fable 越強，越會在執行過程中自己做判斷——這是優點，也是風險。所以當它遇到 unknown、偏離原計畫、或做了重要取捨時，請它記錄 implementation notes：遇到什麼問題、原計畫哪裡不適用、為什麼改用另一種做法、哪些地方需要人類確認、哪些風險還沒消除、哪些測試跑了、哪些沒跑。
Agentic Workflow 健康的模式不是「讓 AI 自己跑、人類下班」，而是——AI 可以跑很遠，但要沿路留下足跡。 你不必牽著它每一步，但你要追得上它怎麼走。
方法六：Quiz Me（讓它反過來考你）
任務完成後，請 Fable 反過來考你。這聽起來有點怪，但對工程師非常有用，因為 AI 可以幫你寫程式、改架構、補測試、整理 PR，最後要負責的人還是你——你要能向同事說明改了什麼、在 code review 裡回答問題、在出事時知道從哪查起。可以請它問：
- 這次改動的核心設計是什麼？哪個模組風險最高？
- 為什麼這裡選 A 而不是 B？線上出事第一個該查哪裡？
- 測試覆蓋了哪些情境？還有哪些 edge case 沒處理？
這能確保你始終在 loop 裡。AI 可以加速，但不能連你的責任也一起外包掉。這點我在 別把「AI 讓工程師更快」當成理所當然 裡也談過：速度是結果，理解才是責任。
四、面對失落感：當寫程式的手感正在改變
這場演講最動人的部分，是 Thariq 談到自己第一次用 Fable 這類模型時，同時感受到巨大的獲得與失落。
他回憶過去經營一家三十人的 YC 新創，每天都在 trade-off 裡掙扎：要讓 app 變快，就沒時間做新功能；要做新功能，可能要花一兩個月；debug 常常卡好幾週，多數專案最後也不一定成功。寫程式很迷人，但也很殘酷。他說，自己前陣子回到那個 code base，發現當年要花好幾週的事，現在幾小時就能做完——「你怎麼能不笑？但老實說，你又怎麼能不哭？」
很多工程師都懂那種感覺：在腦中旋轉整個 code base、親手敲出每一行邏輯、熬夜追一個 bug、在凌晨終於看到測試通過。那種手感像一種職人記憶，很痛，但也很美。當 Fable 讓過去要幾週的工作幾小時就完成，那種「親手雕刻」的感覺確實開始鬆動。
Thariq 的結論是：The only way out is through——唯一的出口就是穿越它。我們回不去 AI 之前的開發方式了；與其懷念純手工鑄劍的年代，不如在新工具裡建立新的專業感。未來工程師的價值，不再主要來自「我親手寫了多少 code」，而是來自：我能不能定義好問題、設計好流程、判斷 AI 的產出、整合工具與環境、讓系統真的創造價值。
這是一種轉職，不是失業。比較像從鐵匠變成造船師——手裡的槌子少了，但面前的海變大了。
五、學會不那麼合理：不要太早接受取捨
最後，Thariq 談到 Anthropic 文化裡他很喜歡的一句：tradeoffs are not real。
這當然不是說現實沒有取捨，而是提醒我們別太早在腦中替現實投降。過去我們很習慣說：「好、快、便宜只能選兩個」「這季只能做 A 不能做 B」「這個重構沒時間」「這個 prototype 不值得做」。這些判斷在建造成本很高的年代是合理的；但當 Fable 大幅降低了建造、探索、原型、測試與文件整理的成本時，很多原本看似合理的取捨，都該被重新檢查。
他說，我們該做的是 forced reality to show you the tradeoff——不要先在腦中刪掉可能性，而是先往前推，讓現實告訴你真正的限制在哪。
同時他也誠實提醒：building is easier, but generating value is still hard。 AI 讓建造變容易，不代表每個造出來的東西都有價值。現在做 prototype 很快、接 API 很快、整理文件很快，但真正困難的仍然是——這是不是一個值得解的問題？使用者真的需要嗎？它能不能進入真實流程、降低成本或提升體驗？它能不能被維護、被組織採用？如果說過去的難題是「做不做得出來」，未來的難題會更偏向「值不值得做」，以及「做出來後能不能真的被用起來」。這也是我一直強調的——會定義問題、會驗證成果，比會寫 code 更稀缺。
六、給台灣開發者與團隊的六個落地建議
把這場演講收斂成可以明天就開始的動作：
- 先在小專案練 blind spot pass。 別一開始就把整個大型系統丟給 AI 重構；挑一個模組，請它掃盲點、找風險、整理 unknowns。
- 把 prompt 從「限制清單」改成「任務脈絡」。 少寫一點「不要做什麼」，多寫一點「為什麼要做」「現在的限制是什麼」「哪些決策會影響成敗」。
- 多提供 references。 與其寫一大段抽象需求，不如給一個你喜歡的範例、一份舊規格、一個 mockup、一段相似程式碼——給它另一張地圖，它會走得更穩。
- 要求 implementation notes。 任務只要超過一兩步，就請它記錄偏離點、風險、假設與待確認事項，讓 AI coding 從黑盒變成可追蹤的流程。
- 讓模型反過來 quiz you。 每次大型修改後被它考幾題，確認你真的理解這次變更。你可以不親手寫每一行，但不能不知道這些行在做什麼。
- 不要太早接受取捨。 很多你以為「沒時間做」的事，現在可以先做個 prototype 看看。讓現實決定限制，別讓舊習慣先幫你把門關上。
結語：少一點合理，多一點探索
Thariq 用三句話收尾，我覺得也很適合拿來總結 Fable 帶來的變化：
Go explore. Make it real. Be less reasonable.
Fable 不是單純更會聊天的模型，而是把 AI 工作流推向更大的開放世界。它要求我們不只學會寫 prompt，也要學會設計流程、提供脈絡、建立參考、追蹤未知、保持在 loop 裡，並且重新挑戰那些看似合理的取捨。
AI Agent 真正改變的，不只是程式寫得更快，而是逼我們重新思考：當建造成本下降之後，我們到底要拿這種能力去做什麼？
地圖已經展開。接下來，不要只站在新手村門口研究背包欄位——往前走，讓世界告訴你邊界在哪裡。
本文整理、翻譯自 Anthropic 技術團隊成員 Thariq Shihipar 在 AI Engineer 大會的演講〈Field Guide to Fable〉（YouTube），並加入我自己的理解與落地建議。內容以官方原始演講為準。
