2026 年 7 月 1 日，Anthropic 技術團隊成員、任職於 Claude Code 團隊的 Thariq Shihipar（X 帳號 @trq212），在舊金山 Moscone West 舉行的 AI Engineer World's Fair 主舞台發表〈Field Guide to Fable〉演講。
這場演講正值 Claude Fable 5 於當天恢復全球存取、而非首次發布，他以一句「Fable is back」開場。他要談的是怎麼跟這一代模型合作，而他真正想講的一句話是：模型表現好不好，往往不只看模型本身。
他一上來就丟出一個例子：一般的聊天模型，未必答得出名字以「aw」結尾的寶可夢有哪些；但把同一個問題交給 Claude Code，它能自己跑程式、抓出完整清單再篩選，找出 Croconaw（藍鋸鱷） 和 Drednaw（暴噬龜）。
這說明差別不一定只來自模型聰不聰明，也可能來自它能不能動手用工具，而這正是他整場演講的核心。
模型是「養成」出來的，不是設計出來的
Shihipar 的第一個提醒是：面對大型語言模型，心態要比較像在研究生物，而不是在讀物理。
他說，模型是「養成」（grown）出來的，不是「設計」（designed）出來的。沒有人先寫好規格、決定它要在某個測驗拿幾分，再照著把它造出來；工程師做的是餵資料、給回饋、投入運算力，讓它自己長大，再一邊用一邊摸清它哪裡強、哪裡意外地笨。它的能力像鋸齒一樣高低不平：有些地方強得驚人，有些地方又笨得意外。
順著這個想法，他丟出一個更反直覺的判斷：真正卡住模型的，常常是我們自己。我們給它的工具環境（也就是 harness）、我們寫的系統提示和規格，反映的其實是「我們對這個模型了解多少」。了解得越淺，它就有越多本事被埋在檯面下。
Shihipar 把「搞懂這些條件、讓模型跑出實力」的做法，稱為 unhobbling（直譯是「解開束縛」）。
前面那個寶可夢的例子，正好對應他說的「潛藏能力落差」（capability overhang）：能力其實早就在那裡，只是少了一個能跑程式的環境把它接出來。換一套工具，模型那些還沒被工具釋放的能力，就可能冒出來。
除了模型本身，harness 也決定它能發揮多少
大家談 AI 進步，習慣盯著參數量和版本號。但 Shihipar 認為，除了模型版本和底層能力，harness 怎麼設計，也會明顯影響模型實際能發揮多少。他舉了幾個橫跨不同版本的例子。
最早在純聊天的年代，工程師要模型寫程式，直覺就是把整個程式庫貼進去，以為上下文視窗夠大就能搞定。真正的轉捩點不是視窗變大，而是給模型「一雙手」：讓它能自己下 bash 指令、自己搜尋、自己拼湊出需要的背景——這就是 Claude Code 的起點。
系統提示（給模型的開場指令）的變化更能說明問題。他回顧，在新版 Claude 3.5 Sonnet 那時，最佳做法是「提示寫短、工具給少、多塞範例」；模型變聰明後，一度流行反過來，提示寫長、工具給多、範例塞好塞滿。
但到了最新一代，又倒回去。模型反而想要更短的提示，因為範例會綁住它的想像力，它其實比你給的範例更有想法。
Shihipar 說，Claude Code 團隊近期把系統提示砍掉了大約八成，原則從「規定它不能做什麼」改成「給它足夠的背景」，少下禁令、多給脈絡。
另一個他一再提到的例子，是讓模型「反過來問你問題」。這個功能在 Opus 4 上只能勉強用，得費力調半天才叫得動；到了 Opus 4.5，當他明確要求「針對這份規格問我 40 個問題」，模型就能一口氣完成一輪像樣的訪談；再到 Opus 4.8 和 Fable 5，它甚至能直接生出一份把問題嵌在裡面的 HTML 報告。
同一個功能跨過好幾個版本，從「勉強叫得動」變成「主動幫你把需求問清楚」，正是工具和模型一起長進的例子。
瓶頸有一部分，移到了人身上：怎麼找出你沒想到的問題
有意思的是，當模型被「解開束縛」之後，Shihipar 說瓶頸並沒有消失，而是有一部分移到了人身上。
他借了一句老話：「地圖不等於實地。」你腦中的計畫、你寫的提示和規格，是地圖；真正的程式庫、現實限制和各種狀況，才是實地。Claude Fable 5 是最早讓他覺得「必須先把未知想清楚」的模型之一，因為它會一口氣跑很大一片範圍，一路撞上很多你地圖上沒畫、根本沒交代過的決策點。於是「對齊地圖和實地、把未知找出來」，反而變成新的瓶頸。
他把「你知道什麼」分成四種：
- 你知道的
- 你不知道的
- 你其實知道但沒特地寫下來（看到就認得）
- 你完全沒想到的
模型剛好能幫你逼近後面那幾種比較難纏的。Shihipar 分享的做法，其實都能直接變成你照著下的指令：
盲點巡查（blind spot pass）：叫模型去看某個模組、或某段程式修改紀錄（Git diff），例如下「請幫這段 diff 做一次盲點巡查，把我可能沒注意到的風險和邊界情況，照嚴重程度列出來，並說明理由」，幫你補上那些根本沒想到的問題。
讓它反過來訪談你：這是他在台上實測過的一招——直接下「針對這份規格問我 40 個問題，優先問那些會改變整體架構的問題」，模型就會反客為主，把你心裡沒說出口的假設一條一條逼出來。
給它一份參考範例當地圖：丟一份別套系統、別種語言的程式碼，甚至一份 HTML 原型給它，請它對照出你這邊漏掉了什麼。
要它寫下 implementation notes：讓它把動工過程中遇到、但你沒交代清楚的決定即時記下來，事後你就能回頭看，問題到底出在哪一步。
請它出題考你：做完一段後，讓模型反過來出題考你；答不出來，就表示你已經脫離狀況、沒跟上它在做什麼。
他特別強調，「留在迴圈裡」、確定拿到的是你真正想要的東西，是跟這一代模型合作最重要的一環；否則你只是按了個按鈕，對做出來的成果卻半句話都說不上來。
東西更好做了，但做出價值還是難
演講後段，Shihipar 講了幾層更值得咀嚼的東西。
第一層是心情。他形容第一次認真用 Fable 5 這種等級的模型，心裡同時又爽又失落。
他以前經營過一家大約三十人的 YC 新創，被各種取捨折磨慣了：要快、還是要多做一個功能，只能選一個；一個月做完、還是兩個月做完，只能挑一個。
但他也老實說，回頭看幾週前還得花好幾週的工作，現在幾個小時就做完，「你怎能不笑，又怎能不哭」，因為他熱愛親手寫程式、在腦子裡把整個架構轉一遍的手感，而那個時代回不去了。
第二層，是他留給全場 AI 工程師的提醒，也是整場最該被記住的一句話：「 東西變好做了，但做出價值還是難（building is easier, but generating value is still hard） 。」
他認為，別太沉迷於把流程和環境弄得漂漂亮亮，那只是「變好做」的部分；真正難的，是找到那件值得做的事，而那通常要試很多次才會浮現。
延伸閱讀：
工程師與PM的價值被AI重寫？Claude Code負責人點名：未來團隊最缺的不是「建造者」，而是這2種人
Claude Code越用越貴？官方揭設定誤區：effort不是拉越滿越好，這樣用才聰明！
資料來源：Thariq Shihipar〈Field Guide to Fable〉演講（AI Engineer World's Fair，2026 年 7 月 1 日）、AI Engineer World's Fair 官方議程、Anthropic：Claude Fable 5 產品頁、Anthropic：Fable 5 恢復上線公告、Anthropic：Claude Fable 5 與 Claude Mythos 5 發布公告、《On the Biology of a Large Language Model》
本文初稿為 AI 編撰，整理．編輯/ 李先泰
