Anthropic 技術人員 Thariq Shihipar（負責 Claude Code）在 AI Engineer World Fair 做了一場名為「A Field Guide to Fable」的主題演講，把「該怎麼跟 Fable 這種新型模型協作」拆成四個面向講完，影片已上 YouTube

Anthropic 技術人員 Thariq Shihipar（負責 Claude Code）在 AI Engineer World Fair 做了一場名為「A Field Guide to Fable」的主題演講，把「該怎麼跟 Fable 這種新型模型協作」拆成四個面向講完，影片已上 YouTube。 演講一開場，他先講對 Fable 的感受：這是 Anthropic 少數會讓你記住的模型，跟 Sonnet 3.5 New、Opus 4、Opus 4.5 同一個層級。他用一個比喻形容它——「地圖正在展開」：就像玩 RPG 剛結束新手教學、終於走到開放世界的起點，可做的事情多到令人興奮，但也有點畏懼和困惑。所以他把平常寫成一系列部落格文章的心得，趁 Fable 發表這天在台上一次講完（他自己形容是「快速通關」），整理成四個部分：解放 Claude、找出你的未知數、處理失落感、保持不講理。 Field Guide to Fable — Thariq Shihipar, Anthropic 一、解放 Claude（unhobbling）：限制模型的其實是我們 Thariq Shihipar 的核心前提是：模型是「長出來」的，不是「設計出來」的。團隊不會一覺醒來就決定要在 SWE-bench 上拿 99 分，而是餵資料、回饋、算力，小心翼翼把它培育出來，過程有點有機、邊用邊摸索。這也意味著，真正框住模型的是我們——我們給它的 harness、我們下 prompt 的方式，其實是「我們對 Claude 理解程度」的函數。所謂解放（unhobble），就是問：我們能不能更了解 Claude、進而釋放它的潛力？而 Fable 還很早期，還有很多潛力等著被解鎖。 他用一個反直覺的例子說明「能力懸崖」（capability overhang）：幾週前一則瘋傳的推文問「為什麼大型語言模型說不出哪些寶可夢的名字結尾是 AW？」——一千多隻寶可夢裡，只有 Croconaw 和 Dreadnought 兩隻。你問一般聊天模型，它答不出來，儘管它明明知道每一隻的名字；但你問 Claude Code，它就答得出來，因為它會去抓每一隻寶可夢的資料、寫一段程式碼篩選出結尾為 AW 的名字。這就是能力懸崖：Claude 變聰明的方式是「尖峰式」的，給它程式碼執行工具，它就能跨過原本跨不過的坎。 他再舉聊天模型的演進為例：早期大家天真地以為，解決程式問題就是把上下文視窗撐得夠大，好把整個程式庫貼進去（那會是上億 token 的視窗）；結果證明相反——只要給模型「手臂」，例如 bash 工具和跟環境互動的能力，它就能自己建立、搜尋自己的上下文。這正是催生 Claude Code 的洞見。 接著他談近期幾個「模型變了、需求也跟著變」的訊號： 系統 prompt 大幅瘦身：他們最近把 Claude Code 約 80% 的系統 prompt 拿掉。Sonnet 3.5 New 時代的最佳實踐是「短系統 prompt＋少量工具＋大量範例」；隨模型變聰明，一度變成塞滿範例和工具的長 prompt；但這類新模型反而想要更少、更精簡——因為範例會限制它，它其實比你給的範例更有想像力。所以現在是給它「上下文」而非「限制」，盡量避免「不要做這個」這類、以前非寫不可的禁令。 主動且多人協作的新一代 Agent：相對於 Claude Code 得由你下 prompt 才動工，新模型能主動醒來、以多人協作的方式自己去做事——他認為這是解鎖下一代 Agent 的關鍵。 「詢問使用者問題」工具（Ask User Question）：這是他剛進 Claude Code 時參與的功能。Opus 4 幾乎叫不動這個工具，要很費力調校；到 Opus 4.5 他試著要它針對規格問自己 40 個問題，結果它真的開始「訪談」他；到 Opus 4.8 和 Fable，它已經能做出一份完整 HTML 報告、把問題嵌在裡面，成為跟 Claude 互動的全新方式。 從 Markdown 到 HTML 報告：Markdown 一開始是很好的輸出格式，在 plan mode 下讓你看懂 Claude 打算做什麼；現在 Claude 能為你產出深入的 HTML 報告。 他強調，這一切「更接近生物學而非物理學」——很經驗性、很有機，規則我們還沒摸透，但背後確實有科學，關鍵是建立直覺。他推薦 Anthropic 一篇他最愛的研究〈大型語言模型的生物學〉，鼓勵大家去讀。 二、找出你的未知數：地圖不等於疆域 Thariq Shihipar 說，跟 Fable 合作時你也得「解放自己」。他常想的一句話是「地圖不等於疆域」：你腦中的計畫、prompt、規格是地圖，真實的程式庫、現實世界和 Claude 得繞過的限制才是疆域。每當 Claude 在疆域裡撞到地圖上沒有的東西，他稱之為「未知數」——一個你還沒指定的決策點。Fable 是頭幾個讓他覺得「非把未知數釐清不可」的模型，因為它會跑過太大的區域，撞到的未知數也特別多。 他用「已知的已知／已知的未知／未知的已知／未知的未知」這個矩陣來思考，並示範怎麼用 Fable 反過來幫自己找出未知數： 盲點檢查：例如「我要接一個全新的 auth provider，但完全不懂，你在這個程式庫裡幫我做盲點檢查、找出未知的未知、幫我寫更好的 prompt。」Claude 會去翻驗證模組，指出哪裡是常見的棘手死胡同，還能去搜 git diff 或 Slack。這招用途很廣，也能拿來學新領域——他最近做影片剪輯的調色就用它。 腦力激盪與原型：用來挖出「未知的已知」，尤其是設計這種「看到才知道喜不喜歡」的東西。他會直說「我沒有視覺品味，幫我做一個 HTML 頁面、擺四種截然不同的設計」，好讓自己有東西可以反應。 訪談：有了初步想法後，請 Claude 反過來訪談他，並多給它一些關於自己、工作和目前進度的背景，還會提醒它「優先問那些會改變架構的問題」。 參考資料：給 Claude 地圖最好的方式，就是再給它一張地圖。與其寫規格，不如丟一段「代表我想做的東西」的程式碼（哪怕是別的系統或語言），讓它讀懂、據此起步。做 React 元件時，他就會拿一份 HTML 模型當作參考地圖傳進去。 實作筆記與測驗：遇到未知狀況就請 Fable 記下來，方便你回頭看偏差發生在哪、為什麼；最後再讓它針對「剛剛發生了什麼」測驗你，確保你真的跟得上、在開 PR 或合併時說得清楚這份工作。他說「保持同步」是跟 Fable 協作最重要的一環。 三、處理失落感：唯一的出路是穿過去 Thariq Shihipar 坦言，第一次用 Fable 時，他同時感到巨大的獲得感與失落感。LLM 出現前的寫程式，回想起來像身處異國：他以前經營過一家約 30 人的 YC 新創，總被迫做取捨——App 跑快一點，還是花一兩個月做新功能原型，只能二選一，非常難。幾週前他回頭看那個舊程式庫，發現當年想做卻做不到的事，現在幾個小時就能搞定；他說「你怎麼能不笑出來，但老實說，又怎麼能不哭呢？」 矛盾在於，他是真的熱愛親手寫程式、享受在腦中把整個程式庫轉一遍的感覺；但他也記得為除錯熬夜、為跑不動的功能苦戰幾週、沉浸在失敗裡的日子——他參與過的大多數專案都失敗、多數新創都倒了。寫程式本來就很難，即使他享受那些高峰，也已經回不去了。他的反思是：唯一的出路就是穿過去。Agentic 程式開發還有很多要學，Fable 也是；但只要夠努力、保持在迴圈裡、持續解放模型，就能走到、而且收穫更多。 四、保持不講理：讓取捨不再是預設 Thariq Shihipar 說，他最愛 Anthropic 的一點，是相信「取捨並非絕對必要」。在上一家公司他很習慣「講理」：列一份優先清單，然後在兩件事之間做取捨、當成這一季的重點，聽起來很合理。但如果你把它全做了呢？如果你逼現實把取捨的結果攤給你看呢？他對未來的決心就是「變得沒那麼講理」——因為 Claude 和 Fable 的算術，真的改變了你對取捨的看法。過去在腦中隱性做的取捨，例如「好、快、便宜」三選一，現在可以三個都要。 他認為想做更有野心的工作，最好的方式就是重新構思、把自己變得更有野心；而證明 Agent 真的有用的唯一方法，就是比以往任何時候都更快地完成人生中最好的作品。他舉例：這份簡報是他前一晚用 Fable 花大約四小時做出來的，做得很快、過程也很享受。全世界都在看著 AI 工程師，等著證明 AI 不是一時流行，而是真能讓人更有效率、省下時間——他今年的決心是更有效率，但工時更短，把更多時間留給真正在乎的人。 最後他點出一個容易被忽略的重點：開發變容易了，但創造價值依然很難。AI 工程師常常太在意開發的過程和自己的設定，可是重點是創造價值，而那需要一次又一次的嘗試才找得到真正有價值的東西——但那確實是目標。他以三句話收尾：去探索、讓它成真，還有——變得沒那麼講理。原文：https://easyvibecoding…