Anthropic 剛發布了他們有史以來最強大的模型，而基準測試的躍進幾乎是最不值得一提的部分。
Claude Fable 5.1 與其說是一個更好的聊天機器人，不如說是一種新型的操作者。它可以花數小時處理一個問題，在計畫中斷時恢復，協調其他 Agent，檢查自己的輸出，並持續推進，無需每十分鐘就有人來解救它。
數據也證明了這點。根據 Anthropic 發布的評測，Fable 5.1 在自主科學研究方面的表現比 Fable 5 提升了一倍以上，在商業自動化方面從 17.1% 躍升至 31.4%，並在 CursorBench 上達到了 73.4%。在 Anthropic 報告的大多數編碼、自動化、電腦使用和知識工作測試中，它也領先於 Fable 5、Opus 5 和 GPT-5.6 Sol。
https://x.com/claudeai/status/2094848581425377479
開箱即用，它在困難的編碼、長週期工作、研究、規劃、電腦使用以及產出完整的交付成果方面表現出色。但更大的機會在於，當你不再把它當作執行每個任務的人，而是讓它負責管理執行工作的系統時，會發生什麼事。
這就是本課程涵蓋的內容：Fable 5.1 真正與眾不同的地方、如何讓它坐上領導者的位置、如何在它之下建立工作者、如何在提示時不限制它、如何使用目標和循環，以及五種能將差異轉化為實際收益的工作流程。
如果你不在乎終端機、Agent 檔案和編排，只想把一個想法變成一個可運作的應用程式，那正是我們打造 Shipper 的目的。
這個模型真正擅長的是什麼
在介紹方法之前，先認識一下這台機器。以下是讓 Fable 5.1 感覺與之前模型不同的五項能力。
它能在極長的運行中保持連貫性
給它一個需要數小時的工作，它在中途偏離主題的可能性要小得多。
一位早期測試者報告了一次無人值守的 38 小時機器學習運行，期間 Fable 診斷出一個錯誤的早期結果，修正了它，並行啟動了六個實驗，最後帶著發現和下一步行動返回。另一位測試者提到，它會自行記錄，在條件改變時重新設定優先級，並從中斷的地方繼續執行。
100 萬 token 的上下文視窗 有所幫助，但上下文大小並非真正的升級。真正的升級在於，模型可以在該上下文中持續做出有用的決策，而不僅僅是記住資訊的存在。
它尋找根本原因，而不是最快的修補
先前的 Agent 通常會找到第一個能讓錯誤消失的修復方法。Fable 5.1 更願意持續挖掘，直到它理解錯誤存在的原因。
在 Anthropic 的發布測試中，Millennium 給它一個大約在百萬次運行中才會發生一次、且已四年到五年無法解釋的崩潰。Fable 5.1 拆解了一個外部函式庫，將其與核心轉儲連結起來，並將崩潰追溯到實際的錯誤。他們嘗試過的其他所有模型，包括 Fable 5，都未能發現。
這在除錯之外的領域也至關重要。同樣的本能在研究、策略、財務分析和營運中顯現出來：當底層系統錯誤時，不要優化症狀。
它能看見、行動和驗證
Fable 5.1 可以檢查螢幕截圖、圖表、PDF、介面和文件，然後利用所見來引導下一步行動。
這意味著它可以根據參考資料重建介面，讀取埋藏在財務文件中的數據，操作瀏覽器，將其實作與原始設計進行比較，並在聲稱工作完成之前捕捉到視覺問題。
在 Anthropic 的測試中，它的 OSWorld 電腦使用分數高於 Fable 5 和 Opus 5。更重要的是，該模型越來越能夠將視覺作為驗證循環的一部分，而不僅僅是描述你給它的圖像。
它回傳的是成品，而不是關於成品的長篇大論
給它一個文件夾，要求一份投資備忘錄、一份簡報、一個可運作的原型或一份分析報告，它回傳實際產物的可能性要大得多。
早期測試者報告了 Anthropic 迄今為止最好的 PowerPoint 結果，對財務文件的引用回憶更強，更簡潔的合約修訂標記，以及更完整地完成複雜的多部分請求。一位 MongoDB 工程師描述了一次為期三天的原型運行，其中模型研究了現有服務，設計了系統，以無人值守的方式分階段實作，並回傳了視覺化導覽，附有每個階段運作正常的證據。
實際的差異很簡單：你花在將答案轉換為可用工作上的時間減少了。
它生來就是為了領導
Fable 5.1 在決定下一步該做什麼時最有價值。
Claude Code 已經可以為它提供子 Agent、背景會話、Agent 團隊、動態工作流程、目標、循環、瀏覽器、終端機和專案檔案。Fable 擁有足夠的規劃深度和上下文，能夠比早期模型更長時間地將這些部分指向同一個終點線。
這就是為什麼下面的設定有效，也是為什麼課程從讓 Fable 離開工作者席位開始。
駕駛艙：你真正需要的所有控制項
在執行任何其他操作之前，請先更新 Claude Code。根據當前的模型配置文檔，2.1.255 或更高版本會讓 fable 別名解析為 Fable 5.1，並且最近的版本包含了下面會用到的 goal、loop、background-agent 和 effort 控制項。
然後選擇模型和努力程度：
/model fable
/effort high
對於重要工作，High 是合理的預設值。對於更便宜、更快速的處理，可以降到 medium。只有當問題足夠困難，值得更多思考時，才使用 xhigh 或 max。Fable 的自適應思考始終開啟，因此 effort 才是關鍵的控制項。
其餘的控制項很簡單：
/plan 或 Shift+Tab：讓它在修改檔案前進行檢查和規劃
/goal：在會話期間持續工作，直到滿足一個可測試的條件
/loop：在會話保持活躍期間，按排程重新執行提示
/tasks：查看背景工作者在做什麼
/context：查看什麼正在消耗上下文視窗
這就是駕駛艙。
課程的其餘部分是知道何時以及該使用哪個控制項。
重頭戲：讓 Fable 成為領導者，而不是工作者
最大的一個升級是角色轉變。
停止讓 Fable 執行每一個鍵盤任務。讓它定義工作，將其拆分為清晰的任務線，將這些任務線分配給更便宜的 Agent，並判斷回傳的結果。
設定如下：
Fable 制定計畫：
讓它進入計畫模式，在提出變更之前檢查專案。如果請求仍然模糊，使用 Matt Pocock 的
技能集合 來探究這個想法，將對話轉化為規格，並將規格拆分為任務。
Fable 委派獨立的工作：
實作工作交給 Opus 或 Sonnet 子 Agent，每個工作者負責一條有邊界的任務線。如果你已經在使用 Codex，它也可以作為另一個工作者，但它應該遵循相同的檔案邊界和證據規則。
一個獨立的 Agent 進行驗證：
工作者不為自己的作業評分。一個全新的驗證者會閱讀計畫，檢查 diff，執行檢查，然後要么通過該階段，要么附上具體的失敗原因將其退回。
你在檢查點進行引導：
批准計畫，審查重要的權衡取捨，並在最後檢查證據。你不需要觀看每一個指令。
為什麼這樣有效：昂貴的模型將其 token 花費在架構、優先級排序、恢復和判斷上。較便宜的模型則將其花費在有邊界的執行上。
只有當任務線真正獨立時，這種經濟效益才成立。根據 Anthropic 當前的 API 定價，Fable 5.1 每百萬輸入 token 花費 10 美元，每百萬輸出 token 花費 50 美元，而 Opus 5 是它的一半，Sonnet 5 是它的五分之一。Fable 5.1 還將快取讀取成本降至每百萬 token 0.25 美元，這使得具有穩定專案上下文的長時間會話變得更加實用。
不要為了場面而並行化。五個 Agent 編輯同一個檔案會產生五張帳單和一個合併問題。並行化研究、隔離的模組、測試、文檔以及其他可以獨立完成而不需相互等待的任務線。
建立你的工作者
領導者需要一個小團隊，而一個自訂工作者只是一個放在 .claude/agents/ 目錄下的 Markdown 檔案。
從一個實作工作者開始：
name: implementation-worker
description: 從已批准的計畫中實作一個獨立的階段。僅在該階段擁有獨立的檔案時使用。
model: opus
tools: Read, Grep, Glob, Edit, Write, Bash
maxTurns: 25
你只擁有分配給你的階段。
在編輯之前，確定你的任務線中確切的檔案和驗收標準。
不要修改屬於其他工作者的檔案。
實作最小可行的完整解決方案，然後執行相關測試。
回傳：
- 修改的檔案
- 執行的檢查及其真實輸出
- 任何仍然不確定的部分
如果沒有本次運行的證據，不要宣告成功。
然後建立最重要的那個工作者，驗證者：
name: verifier
description: 獨立驗證一個已完成的階段是否符合其計畫和驗收標準。在每個實作階段之後使用。
model: opus
tools: Read, Grep, Glob, Bash
maxTurns: 15
將實作摘要視為不可信的聲明。
閱讀計畫並檢查實際的 diff。親自執行相關測試。
檢查正確性、回歸問題、範圍和每一個驗收標準。
回傳 PASS 或 FAIL。
對於每個失敗，附上證據和所需的最小修正。
永遠不要修改你正在評分的那個實作。
旁觀者清，當局者迷。一個立即被檢查的階段，遠比在四個階段依賴它之後才發現缺陷要便宜得多。
四條規則讓團隊保持快速：
一個工作者，一條任務線，明確的檔案所有權
僅在任務線不相互依賴時才進行並行工作
Fable 保持在領導者席位，而 Opus 或 Sonnet 處理勞動工作
每個完成聲明都會根據檔案、測試或實際結果進行檢查
秘訣 1：不要規定路線
大多數提示建議是為了防止較弱的模型偏離方向而寫的。
冗長的程序、僵化的步驟列表和大量的規則區塊，在模型無法規劃時有所幫助。對於 Fable 5.1，同樣的框架可能會迫使它走上一條比它自己會找到的路徑更糟糕的路徑。
訣竅是對目的地嚴格，對路線寬鬆。
給它四件事：
結果：
工作完成時必須存在什麼
限制條件：
它不能破壞、花費、暴露或改變什麼
原因：
這是為誰做的，結果必須支持什麼決定或工作
證明：
什麼可觀察的證據將被視為完成
最後一部分改變了一切。「讓結帳功能正常運作」會引來一個看似合理的聲明。「在沙盒中完成一次測試購買並顯示產生的訂單行」則給了模型一個它無法用話語繞過的終點線。
不要要求它展示隱藏的思考鏈。要求它提供計畫、重要的決策、證據和仍然存在的不確定性。Fable 的思考始終是開啟的。對你來說重要的是結果是否能經得起檢查。
並且不要一直提醒它預算正在減少。相反地，將邊界放入系統中：限制工作者的回合數，定義允許的花費，並告訴它在達到限制時該怎麼做。
秘訣 2：保持 CLAUDE.md 輕量
CLAUDE.md 在每個 Claude Code 會話開始時被載入。這使它很有用，但也意味著每一行不相關的內容都會增加未來每個任務的負擔。
Anthropic 現在建議將每個檔案保持在 200 行以下。實際上，你的檔案通常可以短得多。
三個部分涵蓋了大多數專案：
這個專案是什麼：
產品、架構和重要的邊界
如何驗證工作：
用於建置、測試、lint 和本地預覽的命令
它經常出錯的地方：
專案特定的慣例和反覆出現的錯誤
僅在特定時候需要的程序屬於技能。僅適用於某些檔案的規則屬於路徑範圍規則。歷史記錄屬於文檔，而不是每個會話的提示的一部分。
今晚打開你的 CLAUDE.md 並挑戰每一行：如果移除它不會導致實際錯誤，就移除它。
通常，更輕量的檔案是更強大的檔案。
秘訣 3：充分利用目標和循環
這是 Fable 不再只是一個對話，而是一個可以在你做其他事情時持續推進的過程的地方。
目標： /goal 為會話提供一個可測試的完成條件。在每個回合之後，一個獨立的小模型會檢查條件是否滿足。如果沒有，Fable 會開始另一個回合，而不是將控制權交還給你。目標在它通過、變得不可能、遇到無法恢復的錯誤或你清除它時結束。
技巧在於寫一個它無法偽造的終點線：
要求可觀察的證明：「所有 auth 測試通過且輸出已附加」比「修復 auth」更強
定義失敗路徑：如果一個真正的障礙使目標無法達成，則報告該障礙和證據，而不是編造進度
限制風險部分：對工作者使用 maxTurns，對付費服務使用花費限制，並圍繞部署或生產數據設定明確的邊界
在每個簡報中保留一條誠實規則：每個進度聲明必須指向在此次運行中產生或檢查過的結果
僅在你樂於讓其無人值守的邊界內，以自動模式運行目標。當簡報錯誤時，一個更聰明的 Agent 具有更大的破壞半徑。
循環： /loop 按間隔重新執行一個提示。使用 /loop 15m check the deployment and investigate any failure 來設定一個固定的節奏，或者省略間隔，讓 Claude 選擇何時再次檢查。
Claude Code 內部的循環是會話範圍的，最終會過期。將它們用於建置、拉取請求、遷移和臨時監控。對於需要在會話或機器關閉後仍然持續的工作，請使用持續性常式或桌面排程任務。
在目標和循環之間，你可以讓 Fable 持續工作，只要工作真正需要，最後會有證據等著你，而不是另一個充滿自信的段落。
如何一次性完成一個真實專案
現在圍繞一個建置來組裝整個系統。
這個例子是一個帶有可運作等待名單的登陸頁面。替換掉專案，同樣的順序仍然適用。
步驟 1，撰寫簡報
發送一條訊息：
我正在為 [受眾] 推出 [產品]。他們需要一個登陸頁面，做出一個明確的承諾並收集
[電子郵件]。建立 一個響應式頁面，帶有一個可儲存註冊資訊的表單。 限制條件：不需要我維護的框架，沒有付費依賴項，在手機上快速載入，並且在我批准之前不部署。 完成意味著頁面可以在本地運行，一封測試電子郵件出現在儲存中，行動版佈局在 390px 下經過驗證，並且結果附有測試輸出和螢幕截圖。 先檢查專案並規劃。只委派獨立的階段。驗證每個完成的階段。
這個簡報給了它一個目的地，而沒有替它設計實作方式。
步驟 2，批准計畫
在它更改任何東西之前，使用 /plan 或 Shift+Tab 進入計畫模式。
如果想法不夠具體，使用 /plugin install mattpocock-skills 安裝 Matt Pocock 的集合，執行 /setup-matt-pocock-skills 一次，然後在將結果轉化為規格之前使用 /grill-with-docs。
閱讀計畫。刪除你不需要的功能。確保每個階段都有一個可觀察的通過條件。然後批准它。
步驟 3，讓團隊工作
Fable 將第一個獨立的階段分配給實作工作者。驗證者檢查實際的 diff 和測試輸出。一個依賴的階段僅在前一個階段通過後才開始。
你可以離開終端機。當你想查看還有什麼在運行時，使用 /tasks。
步驟 4，設定終點線
使用一個指定狀態和證明的目標：
/goal the page runs locally, the form stores a test signup, and the layout works at 390px, proven by the real test output, the stored record, and a current screenshot. If a genuine blocker makes this impossible, stop and report the evidence instead of claiming success.
這個條件更難僅用言語來滿足。
步驟 5，審查結果
回來查看 diff、測試輸出、儲存的註冊資訊和螢幕截圖。
像使用者一樣審查產品，而不是像模型的經理。要求進行你實際可以看到的更改，執行最後一次獨立的驗證，並在證據與簡報相符時發布。
第一次運行會感覺很複雜。
第二次，你會注意到同樣的順序幾乎適用於你一直在推遲的每個專案。
五個能真正創造收益的工作流程
現在將這個設定指向足夠有價值、值得使用這個模型的工作。
以下是 Fable 5.1 可以創造可衡量差異的五個工作流程。
沒人想要的程式碼庫工作： 估計需要三週的遷移、罕見的生產故障、跨八個服務的性能問題。Fable 繪製系統圖，工作者負責隔離的部分，驗證者檢查每個階段，進度與測試掛鉤，而不是樂觀估計。
決策級研究： 輸入一個問題，研究工作者並行地從主要來源收集資訊，一個持懷疑態度的審查者攻擊每個重要聲明，領導者將倖存的資訊轉化為備忘錄。這可以為收購、發布、市場決策或投資論點提供資訊。
業務營運： 給它正確的工具，讓它核對數據、調查異常、準備報告、監控流程或處理營運積壓工作。Fable 5.1 在 Anthropic 的 AutomationBench 上的得分幾乎是 Fable 5 的兩倍，這是該版本中最清晰的實際躍進之一。
參考驅動的產品工作： 給它你想要的體驗的螢幕截圖、實際的素材以及對正在運行的應用程式的存取權限。它可以根據參考資料進行實作，打開結果，比較兩者，並持續到可見的差距消失為止。你提供品味。它提供眼睛、雙手和耐心。
一個能產生複合效益的知識系統： 將它指向你公司中所有值得保存的東西，讓它將分散的文件轉化為一個維護良好、相互連結的真相來源。文案可以從優秀的銷售頁面建立一個，代理商可以從其案例研究中建立一個，SaaS 公司可以從客戶通話、決策、實驗和支持歷史中建立一個。每個未來的 Agent 都會因為有用的上下文已經存在而變得更聰明。
這些中的每一個過去都是一個「總有一天」的專案。
Fable 5.1 讓其中許多變成「本週」的專案，前提是你給系統一個真正的終點線和一個證明它已跨越終點線的方法。
整個設定在一個區塊中
讓 Fable 5.1 作為領導者運行：它負責規劃、委派、審查和決策
使用 Opus 或 Sonnet 進行有邊界的勞動，每個獨立的任務線配備一個工作者
給它結果、限制條件、原因和證明，然後讓它選擇路線
保持 CLAUDE.md 簡短，並將偶爾使用的程序移到技能中
使用目標進行可驗證的完成，使用循環進行排程檢查
透過努力程度、更便宜的工作者、快取上下文和硬性邊界來控制成本
將系統指向能產生複合效益的程式碼庫、研究、營運、產品工作和知識
這個模型是設定中最顯眼的部分，但它並非全部的優勢。
優勢在於，給予一個能力如此強大的模型一個清晰的目標、一個稱職的團隊、接觸現實的管道，以及一個無法將看似合理的答案與完成的工作混淆的機制。
