📍 真實場景
小型軟體外包接案的後端工程師小陳
每天用付費大模型（API）幫客戶寫程式、修 bug，月底帳單讓他心驚
😖 卡住的地方：頂級模型很準但很貴；便宜的小模型或自己電腦跑的開源模型常常寫錯，改來改去更花時間
💡 讀完你會知道一種「不換模型、只換用法」的做法，以及怎麼用 3 個步驟親手驗證它是否真的有效
⚡ 一句話講清楚
這則消息來自一篇名為 GVS5H 的研究（程式碼公開在 GitHub）。研究者發現：與其花大錢買更大的模型，不如讓「同一個模型」開出好幾個全新的分身，讓它們像小組分工一樣合作。做法叫「帳本式零樣本自我編排」，聽起來很繞，其實很直觀：分身們共用一個資料夾，裡面放三樣東西——計畫（要拆成哪幾題）、筆記（目前學到什麼）、目前的解答。每個分身讀完資料夾就接著做，不用從頭想。這個方法不需要重新訓練模型（training-free，意思是不用再花算力去「教」模型），所以零樣本事先不給範例、也不特別教，模型直接上場做題就能用。
成績怎麼樣？研究者在 LiveCodeBench（一套會定期出新題的程式題庫，用來避免模型「背過答案」）最新的 100 道高難度題目上測試。結果是：Qwen3.8 Flash Next 用這個方法拿到 93.0% 的 pass@1，高於 Fable 5 單獨作答的 90.4%，而成本只有 9%。pass@1模型只出一次答案、一次就答對的比例 是這類評測最嚴格的指標之一。更驚人的是可以放在自己電腦跑的開源模型 Qwen3.8-27B，成績從 66.8% 升到 92.4%。研究者的分析認為，進步主要來自兩件事：把大題目拆成小題，以及把進度寫在檔案裡不遺忘。
但要注意三個但書。第一，這個方法不是對每個模型都有效，論文自己寫明有些模型成績沒變、甚至變差。第二，測試只涵蓋寫程式題，不代表寫文章、做客服也一樣。第三，原文提到 Opus 5 是用較早版本的框架、單次作答、透過 OpenRouter 這個中轉服務跑的，並不是跟其他模型在完全相同的條件下比，所以和它的比較要保守看待。這些數字是作者自己的實驗，建議當成「值得驗證的線索」，而不是已經定案的結論。這個做法的核心是 編排（orchestration）由一個「管理者」程式負責拆題、派工、收結果，像專案經理一樣，而不是把模型變聰明。
🏃 快速上手三步（今天就能做）
1
先看懂專案、備好環境打開 GitHub 專案 slee-persis/GVS5H，先讀 README 與 NOTICE.md（程式碼是 MIT 授權，論文與資料是 CC BY 4.0，題庫與範本各有自己的授權）。確認電腦已安裝 uv（Python 的套件與環境管理工具），並準備好你想測試的模型的 API key，例如 OPENAI_API_KEY；其他模型用 anthropic:、dashscope:、openrouter: 開頭，各有自己的 *_API_KEY。注意：API key 只放在環境變數，不要寫進程式碼或上傳到 GitHub。
▼
2
用小規模先試跑，控制花費進入 codebase/v2-current 資料夾，設好 API key 與 MULTIAGENT_MODEL（例如 openai:模型名稱），執行 run_bench.py。官方範例是 --lcb 100（跑 100 題）、--parallel 8（同時 8 路），但完整跑可能花不少錢，建議先把 100 改成 10 左右、parallel 調低，確認流程跑得通再放大。同時留意 ESCALATION_CLOUD_TIMEOUT 官方範例是 7200 秒（2 小時），表示單題可能跑很久。Windows 使用者要注意：官方範例是 Linux／Mac 的 export 寫法，在 PowerShell 要改用 $env:變數名 = "值" 設定。
▼
3
對照基準線，用成績判斷值不值得同一批題目分別跑 --engine multiagent（多分身管理者）和 --engine single（一次呼叫的基準線），比較終端機最後印出的 pass@1 分數，結果存在 runs/results.json，每題工作檔在 runs/ws/ 可以打開看分身們的計畫與筆記。判斷標準：若多分身版明顯更準，再算「花費 ÷ 答對題數」，確認真的比直接用貴模型划算；若沒進步，就如論文所說，你的模型可能屬於「不適用」的那一類，別硬套。
🧠 工程思維透鏡（資深工程師看到的是什麼）
🔭 成本只有 9%，但「多個分身 + 反覆讀寫檔案」真的比較省嗎？
論文宣稱的是在同一批 LiveCodeBench 題目上，Qwen3.8 Flash Next 的總成本約為 Fable 5 的 9%，因為小模型單價低很多，即使呼叫次數變多仍划算。但這個比例取決於供應商定價、單題要拆幾輪、以及 token 上限（範例設到 128000）。自己導入時要實測，並注意延遲：多輪串接會讓單題等待時間變長，不適合需要即時回應的場景。
🔭 92.4% 是在公開題庫上量的，換到真實的公司專案還成立嗎？
LiveCodeBench 是題目明確、有自動測試可判對錯的競賽型題目，這正好讓「拆題＋反覆驗證」發揮；但真實專案常有需求模糊、多檔案相依、沒有現成測試的情況，分身們共用檔案也可能把錯誤的筆記一路傳下去。再加上論文本身承認有模型沒進步甚至退步，所以應該先在自己的任務和模型上做小規模驗證，不要直接把分數當保證。另外，Opus 5 的比較條件不同（較早版本框架、單次通過 OpenRouter），也讓『追上頂級』的說法需要打折看。