我請 Claude Code 幫自己的開發流程跑了 7 輪實驗：一段優化 SpecFlow 的心得

起點

上個月我做了 SpecFlow 的第一版 —— 一套讓 AI 自己跑開發流程的多 Agent 系統。spec → 技術規劃 → 5 個 agent 平行（backend / frontend / pipeline / QA / 設計）→ 測試 → 驗證，全部以 GitHub issue / PR 為協作中心。

做完之後我一直在修修改改：這個 prompt 太囉嗦砍一點、那個 agent 偶爾忘記做某步補一條規則、token 好像有點吃多再瘦一下……都是憑感覺。改了一陣子之後我突然停下來想：

我到底有沒有真的讓它變好？還是只是「感覺」變好？

我從來沒有認真 review 過這個流程的效益數據。沒有 baseline、沒有對照、沒有量過一次完整跑下來花多少 token、產出幾個能用的 PR。全憑直覺在調一個我看不到內部狀態的黑盒子。

於是我做了一個決定：請 Claude Code 幫我寫一份 benchmark 實驗，然後連續跑它，用數據來驅動優化。 結果一跑就是 7 輪，過程比我想的更像在做分散式系統的可靠度工程，而不是「調 prompt」。這篇是這段路程的心得。

怎麼量：把「感覺」換成可重複的實驗

我請 Claude Code 設計的實驗很簡單：每一輪都建一個全新的「請假系統 MVP」demo repo（6 個 feature、約 90 條 acceptance criteria），讓完整的 SpecFlow 流程從頭跑到尾，然後量三個數字：

1. 總 token —— 跑完整套花多少
2. agent 自己開出幾個 PR —— 有沒有真的交付
3. 幾個 PR 真的 merge 進 main —— 端到端有沒有完成

每輪結束就看哪裡掛了、翻 log 找根因、改一個東西、再跑一輪。有了這個 loop，「優化」第一次變成一件有憑有據的事，而不是猜。

一路上的反直覺發現

一、我先做的瘦身，幾乎沒省到 token

我第一步先把 7 個 agent 的常駐 prompt 大瘦身 —— 長範例、重複 JSON、樣板全搬到「按需載入」的檔案，規則改精簡。行數砍 79%、估算 token 砍 64.7%，自我感覺良好。

結果 benchmark 打臉：總 token 從第一輪 541K 到第二輪 498K，之後就卡住。為什麼瘦這麼多卻沒省？

• prompt cache 把多數收益吃掉了：系統 prompt 大多是快取命中，只收約 1 成費用。
• 真正的成本在 output 和工具 I/O：每次寫檔、讀檔、跑指令的內容都進對話歷史，全價計費，量遠大於那點 prompt。

這是第一個體悟：該看的不是「每次跑多少 token」，是「每個真實交付物多少 token」。 第一輪跑完 0 個 PR，token 等於白燒；到後面變成約 248K 換一個 merged PR。同樣預算，從「什麼都沒產出」變成「功能寫完還 merge 了」。

二、agent 在「正要交付」的那一刻被砍掉

第一輪結果讓我傻眼：4 個實作 agent 把 code 都寫好了，一個 PR 都沒開、一個都沒 merge。

翻 agent 的執行 log（grep stop_reason）才看懂：每個都在「正準備 commit / 開 PR」那一刻被 harness 的 sub-agent 上限切斷 —— 大約 60-65 次工具呼叫、或 10 分鐘。它們把預算全花在「做事」，還沒走到「交付」就被切了。

更意外的是：agent 設定檔裡的 maxTurns 根本不是 hard limit，log 顯示每個實際跑的回合都超過自己設的上限。真正的天花板在 harness 端 —— 我原本想「把 maxTurns 調高」的修法假設，直接被數據推翻。

三、解法不是給更多預算，是「先交付再雕琢」

既然天花板砍不動，那就反轉順序。我請 Claude Code 加了一條叫 deliver-first 的規則：

agent 認領任務後，第一件事就是開分支 → 空 commit → push → 開 draft PR，然後才開始寫 code。

這樣就算後面撞牆，draft PR 已經在 GitHub 上，下一個 agent 接著推。從「全有或全無」變「至少保底」。PR 落地率立刻從 0/4 跳到 2/4。

四、prompt 的說服力有極限

但只有一半 agent 乖乖照做。翻 log 發現：frontend agent 想「先 npm install 確認能 build」才 commit、QA agent commit 做了卻忘記 push。我試著把 prompt 寫得更兇、更明確，從 50% 拉到 75% 就上不去了。

這是整段路程最關鍵的一課：要 agent 穩定做對一件事，不是寫更強的 prompt，是把流程壓成它「不可能做錯」的單一動作。

最後把那 4 步包成一支 script，agent 跑一行就完成全部，想跳步都沒辦法。可靠度拉到接近 100%。prompt 負責「叫它跑這支」，script 負責「保證每步都做」。

五、幾個其他踩到的坑

• worktree 隔離不夠：4 個 agent 各有獨立 worktree，卻都 cd 到同一個目錄寫檔，還是互相污染。最後改成每個 lane 各 clone 一份才真的乾淨。
• 保險帶比保險閘穩：與其追求 helper 100% 成功，不如加一道「掃描沒開 PR 的分支自動補開」的安全網，偶爾失手也兜得回來。
• 最大的盲點：前 6 輪我都從主控 session 手動跑流程。直到做整體 review 才發現 —— 使用者實際打的那個指令根本沒接上這些修正。我辛苦修的東西，真正用的人完全吃不到。修掉這個，優化才第一次「對使用者可見」。
• agent 有「先搞懂再動作」的本能：收尾時 backend agent 跑去研究 CI 設定、frontend agent 想先驗證 build，結果都在 merge 前撞牆。得明寫「收尾只准跑這支 script，禁止手動查 CI」來對抗它「想做對所以想先弄懂」的傾向。

七輪下來的數據

關鍵數字的變化（第 1 輪 → 第 7 輪）：

• agent 自己開出的 PR：0/4 → 2/4 →（第 5 輪起）4/4，穩定下來
• 真正 merge 進 main 的數量：0 → 0 → 2 → 1
• 總 token：541K → 498K → 約 500K，幾乎沒降
• 執行入口：前 6 輪都是我從主控端手動跑，第 7 輪才走使用者真正會打的那個指令

PR 開創率從 0% 穩定到 100%；端到端 merge 從「一個都沒有」到「跑得起來」；最後一輪是走使用者真正的入口跑通的。token 沒怎麼降，但「每個交付物的成本」實質從無限大變成可量化。

心得

這段路程最大的收穫，不是「修好了 SpecFlow」，是心態的轉變：

我原本把調 AI 流程當成「寫 prompt 的藝術」—— 文字寫得好不好、夠不夠清楚。跑完 7 輪我才認清，這其實是可靠度工程：

• 沒有 benchmark 就沒有優化，只有自我安慰。「感覺變好」不算數，要有對照數據。
• 失敗了就翻 log 找根因（stop_reason、token 分布、撞牆位置），跟 debug 一個分散式系統一模一樣。
• 接受 agent 一定會犯錯，重點是設計「結構性防呆」（單一 script、安全網、絕對序列），而不是寄望它每次都夠聰明。

最有意思的是，這跟我做傳統 backend 可靠度工程的心法完全一樣 —— 只是這次「不可靠的節點」是一個會自由發揮、會「想太多」、會在你看不到的地方被切斷的 LLM agent。你沒辦法叫它保證做對，但你可以把流程設計成「就算它想偷懶、想多做，也只能產出對的結果」。

如果你也在調自己的 AI 工作流，我最想分享的一句話是：先別急著改 prompt，先想辦法量它。 你會很驚訝有多少「我以為的優化」其實沒效果，又有多少真正的問題藏在你從沒看過的 log 裡。

完整 7 輪的 token / PR / merge 數據和每輪根因，我都寫進專案的 BENCHMARK-REPORT.md 和 SKILL-REVIEW.md 了。

專案連結：github.com/gpwork4u/specflow