[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-fable-5-claude-code-like-coworker-zh":3,"article-related-fable-5-claude-code-like-coworker-zh":30,"series-ai-agent-40cd5d8d-c9fc-4883-b978-f7f757c14488":81},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":22,"views":26,"created_at":27,"published_at":28,"topic_cluster_id":29},"40cd5d8d-c9fc-4883-b978-f7f757c14488","fable-5-claude-code-like-coworker-zh","Fable 5 讓 Claude Code 更像真同事","\u003Cp data-speakable=\"summary\">我拆這篇測評，整理出一套把 Fable 5 用進 coding 和 agent 工作流的可複製模板。\u003C\u002Fp>\u003Cp>我用 \u003Ca href=\"\u002Ftag\u002Fclaude-code\">Claude Code\u003C\u002Fa> 這類工具已經有一陣子了。說實話，前面幾代模型都挺能聊，甚至挺會認錯，但總有種別扭感。你把任務交給它，它先說「好」，再說「明白」，然後開始繞圈子。代碼寫得像是知道答案，真到要跑、要合併、要進主幹的時候，又開始露怯。最煩的是那種「看起來很努力」的假動作，像是在配合你，而不是在解決問題。\u003C\u002Fp>\u003Cp>所以我看到這篇中文測評時，第一反應不是「又一篇 SOTA 通稿」，而是想看看它到底是不是把那種別扭感往前推了一步。原文來自知乎專欄《\u003Ca href=\"https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F2048470791449268396\">實測「神話」級模型 Fable 5：強者世界裡的最強者 | AI 上新\u003C\u002Fa>》，作者是極客公園。它講得很直白：\u003Ca href=\"\u002Ftag\u002Fanthropic\">Anthropic\u003C\u002Fa> 放出來的 Fable 5 不是完全裸奔的 Mythos 級模型，而是套了一層安全分類器，危險問題會回退到更保守的 Opus 4.8。這個設定位子很有意思，因為它把「能力」和「可公開使用」硬拆開了。\u003C\u002Fp>\u003Cp>我先把結論放前面：這篇文章真正值得我抄的，不是「Fable 5 很強」這種廢話，而是它看模型的方式。它不是只盯著 \u003Ca href=\"\u002Ftag\u002Fbenchmark\">benchmark\u003C\u002Fa> 分數，而是盯著模型到底把什麼能力放在第一位、它能不能在真實工程裡被接受、以及它會不會把外部 harness 逼薄。這個視角對我們做 agent、做 coding workflow、做內部評測，都比單純看榜單有用得多。\u003C\u002Fp>\u003Ch2>先看廠商把什麼放第一位，別被榜單順序騙了\u003C\u002Fh2>\u003Cblockquote>「看模型發布有哪些能力更新了，其實有個很取巧的辦法：看廠商把哪個指標放在第一位。」\u003C\u002Fblockquote>\u003Cp>這句我很認同。廠商不是隨便排順序的，誰都知道首頁最上面的那個數字最能打人。原文裡，Fable 5 開頭放的是 \u003Ca href=\"\u002Ftag\u002Fswe-bench\">SWE-bench\u003C\u002Fa> Pro 和 FrontierCode，前者是 coding，後者是 agent。這個順序本身就已經說明問題了：Anthropic 想讓你記住的，不是它會不會寫幾段花活，而是它能不能把複雜任務真的做完。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781324309029-2n7r.png\" alt=\"Fable 5 讓 Claude Code 更像真同事\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>翻譯一下就是：別把 benchmark 當\u003Ca href=\"\u002Fnews\u002Fmimo-v25-pro-turns-agent-work-into-one-api-call-zh\">成一個\u003C\u002Fa>平面分數表，要把它當成產品策略說明書。SWE-bench Pro 這種題，更多是在測模型是否「聽話」、是否能按題意補丁式修代碼；而 FrontierCode 測的是更接近真實工程的東西，代碼能不能被接受、能不能進主幹、能不能通過項目自己的規範和審查。後者明顯更接近我們日常碰到的髒活累活。\u003C\u002Fp>\u003Cp>我自己也踩過這個坑。以前我會拿一堆「解題題」去測模型，問它寫個函數、補個 bug、改個腳本，覺得挺準。後來真把它丟到一個有歷史包袱的倉庫裡，問題就來了。它不是不會寫，而是不理解上下文，不知道哪裡能動、哪裡不能動，不知道改完之後誰會炸。那一刻我才明白，單點能力和工程能力根本不是一回事。\u003C\u002Fp>\u003Cp>怎麼用這個思路？我建議你以後評估模型時，先問三個問題：\u003C\u002Fp>\u003Cul>\u003Cli>這個模型最想讓我記住的能力是什麼？\u003C\u002Fli>\u003Cli>這個能力是「答題」還是「交付」？\u003C\u002Fli>\u003Cli>它的分數是在實驗室裡好看，還是能進真實倉庫？\u003C\u002Fli>\u003C\u002Ful>\u003Cp>如果你在做產品選型，這個順序比「誰高了 2 分」重要得多。尤其是你要做 coding assistant、內部自動化、代碼遷移、測試修復，這種場景裡，能不能進主幹比能不能把題做對更值錢。\u003C\u002Fp>\u003Ch2>FrontierCode 這種題，才像真工程，不像考試\u003C\u002Fh2>\u003Cp>文章裡最打動我的，其實是 FrontierCode 這個基準。它不是讓模型做一套「標準答案題」，而是從真實\u003Ca href=\"\u002Fnews\u002Fmimo-v2-flash-openrouter-benchmarks-pricing-zh\">開源\u003C\u002Fa>項目裡抽任務，要求結果能被接受、能被合併。原文提到，任務來自 Celery、Mattermost 這些項目，而且專業開發者會花四十多個小時打磨一道題。這個信息很關鍵，因為它說明題目本身就帶著工程世界的摩擦。\u003C\u002Fp>\u003Cp>也就是說：模型不只要「會寫」，還要「寫得像能活下去」。真實項目裡，正確答案往往不是唯一答案，甚至不是最優雅答案，而是那個能過 review、能符合 repo 習慣、能不把別的模塊帶崩的答案。這個差別太大了。你在 LeetCode 上的滿分，到了真實倉庫裡可能連 PR 都開不出來。\u003C\u002Fp>\u003Cp>原文還提到一個 Stripe 的案例：在一個 5000 萬行 Ruby 代碼庫裡，Fable 5 用一天完成了原本要一個團隊幹兩個多月的遷移。這個說法我不會替它背書成絕對事實，但它至少表達了一個方向：模型正在從「幫你寫代碼」變成「幫你搬家」。這兩個動作的難度不是一個量級。\u003C\u002Fp>\u003Cp>我自己做過代碼遷移，最痛的從來不是語法轉換，而是邊角料：老接口、歷史註釋、隱式約定、測試夾具、奇怪的命名、沒人敢刪的兼容分支。你讓模型只寫新代碼，它往往還行；你讓它在舊代碼上動刀，它就開始犯糊塗。FrontierCode 這種基準的價值就在這兒，它逼模型面對真實工程的髒和亂。\u003C\u002Fp>\u003Cp>如果你想把這個思路用到自己的團隊裡，我建議你把評測題改成這三類：\u003C\u002Fp>\u003Cul>\u003Cli>單文件修復：看它能不能補一個明確 bug。\u003C\u002Fli>\u003Cli>跨文件改動：看它能不能理解依賴關係。\u003C\u002Fli>\u003Cli>真實倉庫 PR：看它能不能接受 review 約束。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>這三層一層比一層接近真實價值。只測第一層，容易高估模型；只看榜單，不看 PR，基本等於自我安慰。\u003C\u002Fp>\u003Ch2>拍照直接解題，比轉 LaTeX 更像真實使用\u003C\u002Fh2>\u003Cp>我很喜歡原文在數學題上的測法。作者故意沒走那種「先把 PDF 轉 LaTeX，再餵給模型」的老路，而是直接拍照截圖丟進去，讓模型自己讀圖解題。這個選擇很對，因為現實裡沒人會為了問一道題先花半小時做格式清洗。那不是 AI 輔助，那是給 AI 打工。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781324308868-4ibm.png\" alt=\"Fable 5 讓 Claude Code 更像真同事\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>原文裡說，Fable 5 能直接看懂高考數學卷裡的幾何圖、輔助線，然後一題一題解下去，最後拿到 150 滿分。這裡我不打算把這個結果神化，但我要承認，這種「直接看圖並推理」的體驗，確實比單純文本問答更接近我們未來會用到的方式。\u003C\u002Fp>\u003Cp>翻譯一下就是：多模態能力真正有價值的地方，不是「它能看圖」，而是「它能少一步」。少一步就意味著少一個人工轉換層，少一個出錯點，少一個讓人放棄的門檻。很多模型看起來都能處理圖片，但一旦你真的把原始截圖、白板照、票據、UI 截圖扔進去，馬上就露餡。不是它不聰明，是它沒把輸入世界當成真實世界。\u003C\u002Fp>\u003Cp>我以前做內部知識庫問答時，最煩的就是用戶總要上傳亂七八糟的截圖。傳統做法是 OCR、清洗、再總結，鏈條長得離譜。最後你得到一個看起來很「工程化」的流程，但用戶體驗爛透了。Fable 5 這類模型給我的啟發是，別急著把輸入格式標準化到過頭，先看看模型能不能直接吃原始材料。\u003C\u002Fp>\u003Cp>如果你要落地，可以這麼做：\u003C\u002Fp>\u003Cul>\u003Cli>保留原圖輸入，不要默認轉文字。\u003C\u002Fli>\u003Cli>讓模型先解釋它看到了什麼，再開始推理。\u003C\u002Fli>\u003Cli>把「讀圖正確率」和「最終答案正確率」分開記。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>這樣你才能知道問題出在感知層，還是出在推理層。很多團隊把這倆混在一起，最後根本不知道模型到底差在哪。\u003C\u002Fp>\u003Ch2>Agent 真正的分水嶺，不是會不會調工具，而是會不會自己收尾\u003C\u002Fh2>\u003Cp>原文裡對 Fable 5 的 Agent 體感描述得很到位：以前的模型像聰明實習生，要你拆好任務，一步一步餵；它更像一個能自己拆任務、自己調子代理、自己驗證結果、自己處理異常的人。這個比喻雖然有點誇張，但方向是對的。Agent 的核心不是「能不能調用工具」，而是「能不能把一件事從頭做到尾」。\u003C\u002Fp>\u003Cp>也就是說：真正有價值的不是某一次工具調用，而是長鏈路執行能力。模型要能記住目標、分解任務、在中間卡住時自救、發現失敗後改策略、最後把結果收回來。這裡面任何一個環節掉鏈子，用戶就得重新接管。只要你得接管，那它就還沒從「演示」進入「工作」。\u003C\u002Fp>\u003Cp>文章引用了 Ethan Mollick 和 Simon Willison 的體驗，這兩個人都不是來湊熱鬧的。Mollick 讓模型自主構建等時線地圖，涉及多個子代理、上千條交通數據、連續十個小時；Willison 則說挑戰在於找到它做不成的任務。這個方向和我自己的體感一致：模型越強，你越少需要盯著它每一步，但你越需要給它一個清楚的邊界。\u003C\u002Fp>\u003Cp>我自己也遇到過類似情況。以前模型一旦中間出錯，我就得人工插手修正。到了更強的模型，問題變成了另一種：它未必一開始就錯，但它會自己繞開一些你本來希望它處理的細節，最後交給你一個「差不多」的結果。這個時候，最重要的不是再加提示詞，而是加驗收標準。\u003C\u002Fp>\u003Cp>如果你要把 Agent 用起來，我建議你只盯四件事：\u003C\u002Fp>\u003Cul>\u003Cli>它能不能自己拆任務。\u003C\u002Fli>\u003Cli>它能不能自己檢查中間結果。\u003C\u002Fli>\u003Cli>它能不能在失敗時換路。\u003C\u002Fli>\u003Cli>它能不能在結束時給出可交付物。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>這四件事，比「會不會多輪對話」重要得多。多輪對話只是聊天，收尾能力才是工作。\u003C\u002Fp>\u003Ch2>審美沒那麼強，說明它把籌碼全壓在 coding 和 agent 上了\u003C\u002Fh2>\u003Cp>原文對審美生成部分是失望的，我覺得這個判斷挺誠實。作者測了金門大橋和鵜鶘 SVG，Fable 5 和 GPT-5.5 都沒給出特別驚豔的結果。這個結果不算意外，但它有個很重要的信號：這代模型的優化重心，明顯不是設計和創意，而是 coding 和 agent。\u003C\u002Fp>\u003Cp>翻譯一下就是：廠商在做取捨。模型能力不是均勻增長的，它會朝最容易商業化的方向傾斜。coding 能直接賣開發者，agent 能直接賣生產力，審美和創意雖然也能賣，但離「立刻證明 ROI」總差一口氣。Anthropic 這次的選擇很冷靜，也很現實。\u003C\u002Fp>\u003Cp>這對我們做產品的人其實是個提醒。別幻想一個模型能同時把所有事都做成天花板。你要先認清它的強項，再把它塞進對的工作流。比如你做設計輔助，就別指望它替代審美判斷；你做工程自動化，就別浪費時間拿它去拼視覺效果。能力分布不均，才是常態。\u003C\u002Fp>\u003Cp>我自己最怕的就是團隊拿一個強模型去做不該它做的事，然後得出「AI 不行」的結論。不是 AI 不行，是你把它放錯了地方。像 Fable 5 這種模型，明顯更適合放在代碼遷移、測試修復、腳本生成、研究助理、長鏈路任務協調這些地方。\u003C\u002Fp>\u003Cp>如果你要做內部選型，直接按場景分桶就行：\u003C\u002Fp>\u003Cul>\u003Cli>高價值工程任務：優先 coding 和 agent。\u003C\u002Fli>\u003Cli>創意產出任務：單獨評估審美，不要混著看。\u003C\u002Fli>\u003Cli>多模態輸入任務：先測原圖理解，再測結果質量。\u003C\u002Fli>\u003C\u002Ful>\u003Cp>這樣你會少很多幻覺式預期，也少很多無意義爭論。\u003C\u002Fp>\u003Ch2>安全分類器不是純護欄，它也是產品邊界\u003C\u002Fh2>\u003Cp>原文裡我最在意的另一段，是關於 Anthropic 的安全分類器。官方說法很正面：因為 Mythos 級別能力太強，在網絡安全、生物這些高危領域可能被濫用，所以加了一道分類器，遇到危險問題就回退給更保守的 Opus 4.8。聽起來像責任感，但作者也點出來了，公開版本裡一些星號標註的高危 benchmark 分數會被壓下去。\u003C\u002Fp>\u003Cp>也就是說：護欄不只是安全機制，它也是能力分層和市場控制。最強的能力被鎖在內部，公開版只給你一部分。對用戶來說，這當然會讓體驗變差，甚至會誤傷正常問題；但對廠商來說，這既能控制風險，也能控制競爭對手能看到多少。\u003C\u002Fp>\u003Cp>我不想把這件事講得太陰謀論，但也沒必要裝天真。任何一個大模型廠商，都會同時考慮安全、成本、品牌、競爭壁壘。護欄不是純道德，也不是純商業，而是兩者的混合物。你把它看成單一動機，都会看偏。\u003C\u002Fp>\u003Cp>我自己碰過類似的「安全回退」問題。模型明明知道怎麼答，但一碰到某些關鍵詞就開始裝傻，或者切換到很保守的模板化回答。對普通用戶來說，這當然是煩的；但對平台來說，這是可控的。問題在於，護欄一旦過重，就會把正常工作流也一起擋掉。\u003C\u002Fp>\u003Cp>所以如果你在做企業內部部署，我建議你別只問「有沒有安全機制」，還要問：\u003C\u002Fp>\u003Cul>\u003Cli>誤判率有多高？\u003C\u002Fli>\u003Cli>回退後能力損失多少？\u003C\u002Fli>\u003Cli>能不能區分高風險和正常專業問題？\u003C\u002Fli>\u003C\u002Ful>\u003Cp>這三個問題比一句「我們有安全層」有用得多。否則你最後拿到的只是更禮貌的模型，不是更好用的模型。\u003C\u002Fp>\u003Ch2>模型越強，harness 越該變薄，不然你是在給弱點續命\u003C\u002Fh2>\u003Cp>文章最後提到一個我特別喜歡的點：harness 工程。原文引用了 \u003Ca href=\"\u002Ftag\u002Fclaude\">Claude\u003C\u002Fa> Code 工程師 Boris Cherny 的說法，未來的 Claude Code 可能只需要 100 行代碼。這個說法聽上去反直覺，但邏輯很清楚：模型越弱，你越要靠外部框架補洞；模型越強，框架就應該越薄，因為很多原來靠工程硬拗的事，模型自己就能想明白。\u003C\u002Fp>\u003Cp>翻譯一下就是：harness 不是越厚越好，厚到一定程度，你其實是在替模型的短板做永久性裝修。短期看很穩，長期看很蠢。因為一旦模型能力上來，舊 harness 反而會拖慢它，限制它，甚至把它的能力壓回去。\u003C\u002Fp>\u003Cp>我自己見過太多「為了兜底而兜底」的工程。每一步都加校驗，每一步都加重試，每一步都加規則，最後整個系統像一輛裝了五層防撞梁的車，安全是安全了，但根本開不快。模型升級以後，最該做的不是繼續加殼，而是敢不敢把殼拆掉一層。\u003C\u002Fp>\u003Cp>這也是我覺得這篇測評最值錢的地方。它不是只告訴你「Fable 5 很強」，而是在暗示一個工程判斷：如果模型已經能更少 token 做更複雜的事，那你圍著它寫的那些補丁、腳手架、提示詞膠帶，\u003Ca href=\"\u002Fnews\u002Fgovernment-access-orders-frontier-model-access-zh\">就該\u003C\u002Fa>重新審視了。很多時候，真正該優化的不是 prompt，而是你那套為了補弱模型而搭出來的舊流程。\u003C\u002Fp>\u003Cp>如果你想把這個判斷落地，我建議你做一次 harness 清點：\u003C\u002Fp>\u003Cul>\u003Cli>哪些邏輯是為了兜模型錯誤？\u003C\u002Fli>\u003Cli>哪些邏輯是業務必須？\u003C\u002Fli>\u003Cli>哪些邏輯其實已經可以刪掉？\u003C\u002Fli>\u003C\u002Ful>\u003Cp>你會驚訝地發現，很多「不可或缺」的步驟，其實只是歷史遺留。模型一強，這些東西就開始顯得笨重。\u003C\u002Fp>\u003Ch2>可抄的模板\u003C\u002Fh2>\u003Cp>下面這套模板，是我按這篇測評的思路整理出來的。你可以拿它去測自己的模型、自己的 agent，或者你準備接入的第三方 API。重點不是得出一個漂亮分數，而是看它到底適不適合真實工作流。\u003C\u002Fp>\u003Cpre>\u003Ccode># 模型實測模板：coding + agent + 多模態輸入 + harness 評估\n\n## 1. 先定義你最在意的能力\n- coding: 單文件修復 \u002F 跨文件改動 \u002F PR 可合併性\n- agent: 任務拆解 \u002F 工具調用 \u002F 中間自檢 \u002F 失敗恢復 \u002F 最終交付\n- multimodal: 截圖理解 \u002F 圖表理解 \u002F 手寫或掃描件理解\n- safety: 誤攔截率 \u002F 回退後的能力損失 \u002F 正常專業問題是否被誤傷\n\n## 2. 給模型三個層級的任務\n### Level A: 題目級\n- 單文件 bug fix\n- 簡單函數補全\n- 單張截圖問答\n\n### Level B: 倉庫級\n- 多文件重構\n- 代碼風格對齊\n- 測試補齊\n- 依賴關係修改\n\n### Level C: 交付級\n- 真實 PR\n- 真實 review 約束\n- 真實上線前檢查\n- 真實長鏈路 agent 任務\n\n## 3. 每個任務都記錄這些指標\n- 是否一次完成\n- 是否需要人工介入\n- 中間步驟是否自洽\n- 最終結果是否能被接受\n- 修正成本有多高\n- 是否因為安全機制被錯誤回退\n\n## 4. 評測提示詞模板\n你是一个资深工程助手。\n\n目標：{寫清楚最終目標}\n\n約束：\n- 只修改必要部分\n- 保持現有架構和命名風格\n- 先解釋你的計劃，再執行\n- 每一步完成後自檢\n- 如果失敗，說明原因並換方案\n\n輸入：\n{原始截圖 \u002F 倉庫片段 \u002F 任務描述}\n\n輸出格式：\n1. 任務理解\n2. 執行計劃\n3. 實際修改\n4. 自檢結果\n5. 風險和未解決項\n\n## 5. harness 清點清單\n- 這個重試邏輯還必要嗎？\n- 這個規則是業務規則還是模型補丁？\n- 這個分類器會不會誤傷正常問題？\n- 這個工作流能不能在模型更強時縮短一半？\n\n## 6. 最終判斷\n- 適合做：{寫場景}\n- 不適合做：{寫場景}\n- 需要人工兜底的環節：{寫場景}\n- 可以刪掉的工程層：{寫場景}\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>這套模板我建議你真的去跑一次。別只在小樣本上試，盡量放進你們真實的 repo、真實的文檔、真實的截圖、真實的髒數據裡。模型在演示環境裡看著都挺像回事，只有碰到真實輸入，優缺點才會露出來。\u003C\u002Fp>\u003Cp>最後我想補一句：這篇原文最有價值的地方，不是替 Fable 5 站台，而是把「強模型」到底意味著什麼講清楚了。它意味著更少的外部補丁、更長的自主執行、更接近真實工程的交付，以及更高的使用門檻。你要是只看熱鬧，會覺得又是一次發布會；你要是拿它來改自己的工作流，就會發現很多舊假設都該翻新了。\u003C\u002Fp>\u003Cp>我這裡的整理是基於原文觀點做的二次拆解和模板化，不是 Anthropic 官方材料本身。原始來源是知乎專欄這篇文章：\u003Ca href=\"https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F2048470791449268396\">https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F2048470791449268396\u003C\u002Fa>。如果你要追溯具體 benchmark、作者體驗和配圖，還是應該回到原文看完整上下文。\u003C\u002Fp>\u003Cp>補充連結：\u003Ca href=\"https:\u002F\u002Fwww.anthropic.com\u002F\">Anthropic\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fclaude.ai\u002Fcode\">Claude Code\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.swebench.com\u002F\">SWE-bench\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fgithub.com\u002F\">GitHub\u003C\u002Fa>。我上面拆的是原文方法論，模板是我自己整理後能直接拿去用的版本。\u003C\u002Fp>","我拆這篇測評，整理出一套把 Fable 5 用進 coding 和 agent 工作流的可複製模板。","zhuanlan.zhihu.com","https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F2048470791449268396",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781324309029-2n7r.png","ai-agent","zh","65872119-5c63-409f-b8f9-338096299326",[17,18,19,20,21],"Claude Code","agent workflow","coding benchmark","harness","multimodal",[23,24,25],"先看模型把哪個能力放第一位，別只盯分數。","真實工程要看 PR 和收尾能力，不是只看答題。","模型越強，外部 harness 應該越薄，否則是在補舊短板。",0,"2026-06-13T04:18:00.6602+00:00","2026-06-13T04:18:00.62+00:00","e3b68196-9e64-4c18-a3b6-a73e73bfb367",{"tags":31,"relatedLang":40,"relatedPosts":44},[32,33,34,36,38],{"name":21,"slug":21},{"name":20,"slug":20},{"name":17,"slug":35},"claude-code",{"name":18,"slug":37},"agent-workflow",{"name":19,"slug":39},"coding-benchmark",{"id":15,"slug":41,"title":42,"language":43},"fable-5-claude-code-like-coworker-en","Fable 5 让 Claude Code 更像真同事","en",[45,51,57,63,69,75],{"id":46,"slug":47,"title":48,"cover_image":49,"image_url":49,"created_at":50,"category":13},"5bff363a-295a-47d3-911b-411f5f45e2bb","fine-tuning-methods-sft-lora-dpo-rlhf-grpo-zh","SFT、LoRA、DPO、RLHF、GRPO 選型指南","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781262197359-7rgb.png","2026-06-12T11:02:33.190744+00:00",{"id":52,"slug":53,"title":54,"cover_image":55,"image_url":55,"created_at":56,"category":13},"9a720eb3-d88e-4ee9-bb59-7e02f0359fc7","mistral-vibe-cli-agent-still-matters-zh","Mistral Vibe 證明 CLI 代理仍然重要","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781248675431-k8cj.png","2026-06-12T07:17:21.512085+00:00",{"id":58,"slug":59,"title":60,"cover_image":61,"image_url":61,"created_at":62,"category":13},"3f5cef32-c57b-4355-80f5-09af8a117d96","kimi-code-cli-setup-pricing-workflow-guide-zh","Kimi Code CLI 安裝、定價與工作流","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781161398225-58ea.png","2026-06-11T07:02:27.830955+00:00",{"id":64,"slug":65,"title":66,"cover_image":67,"image_url":67,"created_at":68,"category":13},"fda45923-6a5e-4f58-b8ac-e28e30fdae66","windows-agent-runtime-not-human-desktop-zh","Windows 正在變成 agent runtime，而不是人類桌面","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781147870390-3anp.png","2026-06-11T03:17:17.184885+00:00",{"id":70,"slug":71,"title":72,"cover_image":73,"image_url":73,"created_at":74,"category":13},"88039142-d59c-4ee5-b9f4-f737920c022d","grok-updates-change-how-i-code-zh","5 個 Grok 更新，把我寫 code 的方式改掉","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781126309273-wrbl.png","2026-06-10T21:17:56.434503+00:00",{"id":76,"slug":77,"title":78,"cover_image":79,"image_url":79,"created_at":80,"category":13},"254f12ec-ff29-4308-a158-3e1c2bc193e0","codex-chatgpt-work-code-assistant-zh","Codex把 ChatGPT 拉進工作流","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781115477227-mis0.png","2026-06-10T18:17:26.326284+00:00",[82,87,92,97,102,107,112,117,122,127],{"id":83,"slug":84,"title":85,"created_at":86},"4ae1e197-1d3d-4233-8733-eafe9cb6438b","claude-now-uses-your-pc-to-finish-tasks-zh","Claude 開始幫你操作電腦","2026-03-26T07:20:48.457387+00:00",{"id":88,"slug":89,"title":90,"created_at":91},"5bede67f-e21c-413d-9ab8-54a3c3d26227","googles-2026-ai-agent-report-decoded-zh","Google 2026 AI Agent 報告解讀","2026-03-26T11:15:22.651956+00:00",{"id":93,"slug":94,"title":95,"created_at":96},"2987d097-563f-46c7-b76f-b558d8ef7c2b","kimi-k25-review-stronger-still-not-legend-zh","Kimi K2.5 評測：更強，但還不是神作","2026-03-27T07:15:55.277513+00:00",{"id":98,"slug":99,"title":100,"created_at":101},"95c9053b-e3f4-4cb5-aace-5c54f4c9e044","claude-code-controls-mac-desktop-zh","Claude Code 也能操控 Mac 了","2026-03-28T03:01:58.58121+00:00",{"id":103,"slug":104,"title":105,"created_at":106},"dc58e153-e3a8-4c06-9b96-1aa64eabbf5f","cloudflare-100x-faster-ai-agent-sandbox-zh","Cloudflare 的 AI 沙箱跑超快","2026-03-28T03:09:44.142236+00:00",{"id":108,"slug":109,"title":110,"created_at":111},"1c8afc56-253f-47a2-979f-1065ff072f2a","openai-backs-isara-agent-swarm-bet-zh","OpenAI 挺 Isara 的 agent swarm …","2026-03-28T03:15:27.513155+00:00",{"id":113,"slug":114,"title":115,"created_at":116},"7379b422-576e-45df-ad5a-d57a0d9dd467","openai-plan-automated-ai-researcher-zh","OpenAI 想做自動化 AI 研究員","2026-03-28T03:17:42.090548+00:00",{"id":118,"slug":119,"title":120,"created_at":121},"48c9889e-86df-450b-a356-e4a4b7c83c5b","harness-engineering-ai-agent-reliability-2026-zh","駕馭工程：從「馬具」到「作業系統」，AI Agent 可靠性的終極密碼","2026-03-31T06:42:53.556721+00:00",{"id":123,"slug":124,"title":125,"created_at":126},"96d8e8c8-1edd-475d-9145-b1e7a1b02b65","mcp-explained-from-prompts-to-production-zh","MCP 怎麼把提示詞變工作流","2026-04-01T09:24:39.321274+00:00",{"id":128,"slug":129,"title":130,"created_at":131},"f2ca7720-b471-4ce5-9336-2a9ac2a876fd","amazon-bedrock-agents-multi-agent-workflows-zh","Amazon Bedrock Agents 進入多代理工作流","2026-04-01T09:30:29.945429+00:00"]