Fable 5 讓 Claude Code 更像真同事

我拆這篇測評，整理出一套把 Fable 5 用進 coding 和 agent 工作流的可複製模板。

我用 Claude Code 這類工具已經有一陣子了。說實話，前面幾代模型都挺能聊，甚至挺會認錯，但總有種別扭感。你把任務交給它，它先說「好」，再說「明白」，然後開始繞圈子。代碼寫得像是知道答案，真到要跑、要合併、要進主幹的時候，又開始露怯。最煩的是那種「看起來很努力」的假動作，像是在配合你，而不是在解決問題。

所以我看到這篇中文測評時，第一反應不是「又一篇 SOTA 通稿」，而是想看看它到底是不是把那種別扭感往前推了一步。原文來自知乎專欄《實測「神話」級模型 Fable 5：強者世界裡的最強者 | AI 上新》，作者是極客公園。它講得很直白：Anthropic 放出來的 Fable 5 不是完全裸奔的 Mythos 級模型，而是套了一層安全分類器，危險問題會回退到更保守的 Opus 4.8。這個設定位子很有意思，因為它把「能力」和「可公開使用」硬拆開了。

我先把結論放前面：這篇文章真正值得我抄的，不是「Fable 5 很強」這種廢話，而是它看模型的方式。它不是只盯著 benchmark 分數，而是盯著模型到底把什麼能力放在第一位、它能不能在真實工程裡被接受、以及它會不會把外部 harness 逼薄。這個視角對我們做 agent、做 coding workflow、做內部評測，都比單純看榜單有用得多。

先看廠商把什麼放第一位，別被榜單順序騙了

「看模型發布有哪些能力更新了，其實有個很取巧的辦法：看廠商把哪個指標放在第一位。」

這句我很認同。廠商不是隨便排順序的，誰都知道首頁最上面的那個數字最能打人。原文裡，Fable 5 開頭放的是 SWE-bench Pro 和 FrontierCode，前者是 coding，後者是 agent。這個順序本身就已經說明問題了：Anthropic 想讓你記住的，不是它會不會寫幾段花活，而是它能不能把複雜任務真的做完。

翻譯一下就是：別把 benchmark 當成一個平面分數表，要把它當成產品策略說明書。SWE-bench Pro 這種題，更多是在測模型是否「聽話」、是否能按題意補丁式修代碼；而 FrontierCode 測的是更接近真實工程的東西，代碼能不能被接受、能不能進主幹、能不能通過項目自己的規範和審查。後者明顯更接近我們日常碰到的髒活累活。

我自己也踩過這個坑。以前我會拿一堆「解題題」去測模型，問它寫個函數、補個 bug、改個腳本，覺得挺準。後來真把它丟到一個有歷史包袱的倉庫裡，問題就來了。它不是不會寫，而是不理解上下文，不知道哪裡能動、哪裡不能動，不知道改完之後誰會炸。那一刻我才明白，單點能力和工程能力根本不是一回事。

怎麼用這個思路？我建議你以後評估模型時，先問三個問題：

• 這個模型最想讓我記住的能力是什麼？
• 這個能力是「答題」還是「交付」？
• 它的分數是在實驗室裡好看，還是能進真實倉庫？

如果你在做產品選型，這個順序比「誰高了 2 分」重要得多。尤其是你要做 coding assistant、內部自動化、代碼遷移、測試修復，這種場景裡，能不能進主幹比能不能把題做對更值錢。

FrontierCode 這種題，才像真工程，不像考試

文章裡最打動我的，其實是 FrontierCode 這個基準。它不是讓模型做一套「標準答案題」，而是從真實開源項目裡抽任務，要求結果能被接受、能被合併。原文提到，任務來自 Celery、Mattermost 這些項目，而且專業開發者會花四十多個小時打磨一道題。這個信息很關鍵，因為它說明題目本身就帶著工程世界的摩擦。

也就是說：模型不只要「會寫」，還要「寫得像能活下去」。真實項目裡，正確答案往往不是唯一答案，甚至不是最優雅答案，而是那個能過 review、能符合 repo 習慣、能不把別的模塊帶崩的答案。這個差別太大了。你在 LeetCode 上的滿分，到了真實倉庫裡可能連 PR 都開不出來。

原文還提到一個 Stripe 的案例：在一個 5000 萬行 Ruby 代碼庫裡，Fable 5 用一天完成了原本要一個團隊幹兩個多月的遷移。這個說法我不會替它背書成絕對事實，但它至少表達了一個方向：模型正在從「幫你寫代碼」變成「幫你搬家」。這兩個動作的難度不是一個量級。

我自己做過代碼遷移，最痛的從來不是語法轉換，而是邊角料：老接口、歷史註釋、隱式約定、測試夾具、奇怪的命名、沒人敢刪的兼容分支。你讓模型只寫新代碼，它往往還行；你讓它在舊代碼上動刀，它就開始犯糊塗。FrontierCode 這種基準的價值就在這兒，它逼模型面對真實工程的髒和亂。

如果你想把這個思路用到自己的團隊裡，我建議你把評測題改成這三類：

• 單文件修復：看它能不能補一個明確 bug。
• 跨文件改動：看它能不能理解依賴關係。
• 真實倉庫 PR：看它能不能接受 review 約束。

這三層一層比一層接近真實價值。只測第一層，容易高估模型；只看榜單，不看 PR，基本等於自我安慰。

拍照直接解題，比轉 LaTeX 更像真實使用

我很喜歡原文在數學題上的測法。作者故意沒走那種「先把 PDF 轉 LaTeX，再餵給模型」的老路，而是直接拍照截圖丟進去，讓模型自己讀圖解題。這個選擇很對，因為現實裡沒人會為了問一道題先花半小時做格式清洗。那不是 AI 輔助，那是給 AI 打工。

原文裡說，Fable 5 能直接看懂高考數學卷裡的幾何圖、輔助線，然後一題一題解下去，最後拿到 150 滿分。這裡我不打算把這個結果神化，但我要承認，這種「直接看圖並推理」的體驗，確實比單純文本問答更接近我們未來會用到的方式。

翻譯一下就是：多模態能力真正有價值的地方，不是「它能看圖」，而是「它能少一步」。少一步就意味著少一個人工轉換層，少一個出錯點，少一個讓人放棄的門檻。很多模型看起來都能處理圖片，但一旦你真的把原始截圖、白板照、票據、UI 截圖扔進去，馬上就露餡。不是它不聰明，是它沒把輸入世界當成真實世界。

我以前做內部知識庫問答時，最煩的就是用戶總要上傳亂七八糟的截圖。傳統做法是 OCR、清洗、再總結，鏈條長得離譜。最後你得到一個看起來很「工程化」的流程，但用戶體驗爛透了。Fable 5 這類模型給我的啟發是，別急著把輸入格式標準化到過頭，先看看模型能不能直接吃原始材料。

如果你要落地，可以這麼做：

• 保留原圖輸入，不要默認轉文字。
• 讓模型先解釋它看到了什麼，再開始推理。
• 把「讀圖正確率」和「最終答案正確率」分開記。

這樣你才能知道問題出在感知層，還是出在推理層。很多團隊把這倆混在一起，最後根本不知道模型到底差在哪。

Agent 真正的分水嶺，不是會不會調工具，而是會不會自己收尾

原文裡對 Fable 5 的 Agent 體感描述得很到位：以前的模型像聰明實習生，要你拆好任務，一步一步餵；它更像一個能自己拆任務、自己調子代理、自己驗證結果、自己處理異常的人。這個比喻雖然有點誇張，但方向是對的。Agent 的核心不是「能不能調用工具」，而是「能不能把一件事從頭做到尾」。

也就是說：真正有價值的不是某一次工具調用，而是長鏈路執行能力。模型要能記住目標、分解任務、在中間卡住時自救、發現失敗後改策略、最後把結果收回來。這裡面任何一個環節掉鏈子，用戶就得重新接管。只要你得接管，那它就還沒從「演示」進入「工作」。

文章引用了 Ethan Mollick 和 Simon Willison 的體驗，這兩個人都不是來湊熱鬧的。Mollick 讓模型自主構建等時線地圖，涉及多個子代理、上千條交通數據、連續十個小時；Willison 則說挑戰在於找到它做不成的任務。這個方向和我自己的體感一致：模型越強，你越少需要盯著它每一步，但你越需要給它一個清楚的邊界。

我自己也遇到過類似情況。以前模型一旦中間出錯，我就得人工插手修正。到了更強的模型，問題變成了另一種：它未必一開始就錯，但它會自己繞開一些你本來希望它處理的細節，最後交給你一個「差不多」的結果。這個時候，最重要的不是再加提示詞，而是加驗收標準。

如果你要把 Agent 用起來，我建議你只盯四件事：

• 它能不能自己拆任務。
• 它能不能自己檢查中間結果。
• 它能不能在失敗時換路。
• 它能不能在結束時給出可交付物。

這四件事，比「會不會多輪對話」重要得多。多輪對話只是聊天，收尾能力才是工作。

審美沒那麼強，說明它把籌碼全壓在 coding 和 agent 上了

原文對審美生成部分是失望的，我覺得這個判斷挺誠實。作者測了金門大橋和鵜鶘 SVG，Fable 5 和 GPT-5.5 都沒給出特別驚豔的結果。這個結果不算意外，但它有個很重要的信號：這代模型的優化重心，明顯不是設計和創意，而是 coding 和 agent。

翻譯一下就是：廠商在做取捨。模型能力不是均勻增長的，它會朝最容易商業化的方向傾斜。coding 能直接賣開發者，agent 能直接賣生產力，審美和創意雖然也能賣，但離「立刻證明 ROI」總差一口氣。Anthropic 這次的選擇很冷靜，也很現實。

這對我們做產品的人其實是個提醒。別幻想一個模型能同時把所有事都做成天花板。你要先認清它的強項，再把它塞進對的工作流。比如你做設計輔助，就別指望它替代審美判斷；你做工程自動化，就別浪費時間拿它去拼視覺效果。能力分布不均，才是常態。

我自己最怕的就是團隊拿一個強模型去做不該它做的事，然後得出「AI 不行」的結論。不是 AI 不行，是你把它放錯了地方。像 Fable 5 這種模型，明顯更適合放在代碼遷移、測試修復、腳本生成、研究助理、長鏈路任務協調這些地方。

如果你要做內部選型，直接按場景分桶就行：

• 高價值工程任務：優先 coding 和 agent。
• 創意產出任務：單獨評估審美，不要混著看。
• 多模態輸入任務：先測原圖理解，再測結果質量。

這樣你會少很多幻覺式預期，也少很多無意義爭論。

安全分類器不是純護欄，它也是產品邊界

原文裡我最在意的另一段，是關於 Anthropic 的安全分類器。官方說法很正面：因為 Mythos 級別能力太強，在網絡安全、生物這些高危領域可能被濫用，所以加了一道分類器，遇到危險問題就回退給更保守的 Opus 4.8。聽起來像責任感，但作者也點出來了，公開版本裡一些星號標註的高危 benchmark 分數會被壓下去。

也就是說：護欄不只是安全機制，它也是能力分層和市場控制。最強的能力被鎖在內部，公開版只給你一部分。對用戶來說，這當然會讓體驗變差，甚至會誤傷正常問題；但對廠商來說，這既能控制風險，也能控制競爭對手能看到多少。

我不想把這件事講得太陰謀論，但也沒必要裝天真。任何一個大模型廠商，都會同時考慮安全、成本、品牌、競爭壁壘。護欄不是純道德，也不是純商業，而是兩者的混合物。你把它看成單一動機，都会看偏。

我自己碰過類似的「安全回退」問題。模型明明知道怎麼答，但一碰到某些關鍵詞就開始裝傻，或者切換到很保守的模板化回答。對普通用戶來說，這當然是煩的；但對平台來說，這是可控的。問題在於，護欄一旦過重，就會把正常工作流也一起擋掉。

所以如果你在做企業內部部署，我建議你別只問「有沒有安全機制」，還要問：

• 誤判率有多高？
• 回退後能力損失多少？
• 能不能區分高風險和正常專業問題？

這三個問題比一句「我們有安全層」有用得多。否則你最後拿到的只是更禮貌的模型，不是更好用的模型。

模型越強，harness 越該變薄，不然你是在給弱點續命

文章最後提到一個我特別喜歡的點：harness 工程。原文引用了 Claude Code 工程師 Boris Cherny 的說法，未來的 Claude Code 可能只需要 100 行代碼。這個說法聽上去反直覺，但邏輯很清楚：模型越弱，你越要靠外部框架補洞；模型越強，框架就應該越薄，因為很多原來靠工程硬拗的事，模型自己就能想明白。

翻譯一下就是：harness 不是越厚越好，厚到一定程度，你其實是在替模型的短板做永久性裝修。短期看很穩，長期看很蠢。因為一旦模型能力上來，舊 harness 反而會拖慢它，限制它，甚至把它的能力壓回去。

我自己見過太多「為了兜底而兜底」的工程。每一步都加校驗，每一步都加重試，每一步都加規則，最後整個系統像一輛裝了五層防撞梁的車，安全是安全了，但根本開不快。模型升級以後，最該做的不是繼續加殼，而是敢不敢把殼拆掉一層。

這也是我覺得這篇測評最值錢的地方。它不是只告訴你「Fable 5 很強」，而是在暗示一個工程判斷：如果模型已經能更少 token 做更複雜的事，那你圍著它寫的那些補丁、腳手架、提示詞膠帶，就該重新審視了。很多時候，真正該優化的不是 prompt，而是你那套為了補弱模型而搭出來的舊流程。

如果你想把這個判斷落地，我建議你做一次 harness 清點：

• 哪些邏輯是為了兜模型錯誤？
• 哪些邏輯是業務必須？
• 哪些邏輯其實已經可以刪掉？

你會驚訝地發現，很多「不可或缺」的步驟，其實只是歷史遺留。模型一強，這些東西就開始顯得笨重。

可抄的模板

下面這套模板，是我按這篇測評的思路整理出來的。你可以拿它去測自己的模型、自己的 agent，或者你準備接入的第三方 API。重點不是得出一個漂亮分數，而是看它到底適不適合真實工作流。

# 模型實測模板：coding + agent + 多模態輸入 + harness 評估

## 1. 先定義你最在意的能力
- coding: 單文件修復 / 跨文件改動 / PR 可合併性
- agent: 任務拆解 / 工具調用 / 中間自檢 / 失敗恢復 / 最終交付
- multimodal: 截圖理解 / 圖表理解 / 手寫或掃描件理解
- safety: 誤攔截率 / 回退後的能力損失 / 正常專業問題是否被誤傷

## 2. 給模型三個層級的任務
### Level A: 題目級
- 單文件 bug fix
- 簡單函數補全
- 單張截圖問答

### Level B: 倉庫級
- 多文件重構
- 代碼風格對齊
- 測試補齊
- 依賴關係修改

### Level C: 交付級
- 真實 PR
- 真實 review 約束
- 真實上線前檢查
- 真實長鏈路 agent 任務

## 3. 每個任務都記錄這些指標
- 是否一次完成
- 是否需要人工介入
- 中間步驟是否自洽
- 最終結果是否能被接受
- 修正成本有多高
- 是否因為安全機制被錯誤回退

## 4. 評測提示詞模板
你是一个资深工程助手。

目標：{寫清楚最終目標}

約束：
- 只修改必要部分
- 保持現有架構和命名風格
- 先解釋你的計劃，再執行
- 每一步完成後自檢
- 如果失敗，說明原因並換方案

輸入：
{原始截圖 / 倉庫片段 / 任務描述}

輸出格式：
1. 任務理解
2. 執行計劃
3. 實際修改
4. 自檢結果
5. 風險和未解決項

## 5. harness 清點清單
- 這個重試邏輯還必要嗎？
- 這個規則是業務規則還是模型補丁？
- 這個分類器會不會誤傷正常問題？
- 這個工作流能不能在模型更強時縮短一半？

## 6. 最終判斷
- 適合做：{寫場景}
- 不適合做：{寫場景}
- 需要人工兜底的環節：{寫場景}
- 可以刪掉的工程層：{寫場景}

這套模板我建議你真的去跑一次。別只在小樣本上試，盡量放進你們真實的 repo、真實的文檔、真實的截圖、真實的髒數據裡。模型在演示環境裡看著都挺像回事，只有碰到真實輸入，優缺點才會露出來。

最後我想補一句：這篇原文最有價值的地方，不是替 Fable 5 站台，而是把「強模型」到底意味著什麼講清楚了。它意味著更少的外部補丁、更長的自主執行、更接近真實工程的交付，以及更高的使用門檻。你要是只看熱鬧，會覺得又是一次發布會；你要是拿它來改自己的工作流，就會發現很多舊假設都該翻新了。

我這裡的整理是基於原文觀點做的二次拆解和模板化，不是 Anthropic 官方材料本身。原始來源是知乎專欄這篇文章：https://zhuanlan.zhihu.com/p/2048470791449268396。如果你要追溯具體 benchmark、作者體驗和配圖，還是應該回到原文看完整上下文。

補充連結：Anthropic、Claude Code、SWE-bench、GitHub。我上面拆的是原文方法論，模板是我自己整理後能直接拿去用的版本。