跑了兩週 Agent QA Pipeline — 真實數字、踩到的坑、重來我會怎麼做
這是 QA Pipeline 系列的最後一篇。前五篇分別講了 pipeline 結構、spec-driven、learned-patterns、launchd、Linear queue。那些是「怎麼做」。這一篇是「兩週跑下來真的值嗎、哪裡該重做」。
先講一件事：系列規劃時我本來想等 30 天累積再寫 retrospective、後來決定兩週也夠了。兩週是一個足夠小的觀察窗、能看到真實訊號；但又太小、看不到大型 regression。所以這篇算是第一次 retrospective，過一個月我會再寫一次 update。
兩週完整數字
從 pipeline 的 reports 跟 Linear 撈出來的真實數字：
Pipeline 本身
| 指標 | 數字 |
|---|---|
| 總 shift 次數 | 16（期望 28、因為 MacBook 有幾天沒插電沒跑） |
| 成功完成的 shift | 15 |
| 成功率 | 93.8% |
| 典型 shift 時長（median） | 37 分鐘 |
| 最短 / 最長 shift | 19 / 66 分鐘 |
Agent 產出
| 指標 | 數字 |
|---|---|
| 追蹤到的 bug 數（排除 meta） | 53 |
| 已關閉 | 46（77%） |
| Merged qa-bot PRs | 17 |
| 有掛 fix PR 的 issue | 40（平均 1 PR 關 2.4 張 issue） |
| 平均 turnaround（created → closed） | 2.9 天 |
| 中位數 turnaround | 2 天 |
知識累積
| 指標 | 數字 |
|---|---|
| Learned patterns | 9 條 |
Graduated 到 .claude/skills | 4 條（44%） |
| Pattern 自動套用次數 | 22 |
Bug 類別分布
| 類別 | 數量 | 佔比 |
|---|---|---|
| coverage-gap（spec 有、test 沒覆蓋） | 27 | 51% |
| code-bug（source 不符 spec） | 12 | 23% |
| test-bug（test 不符 spec） | 6 | 11% |
| needs-spec-review（spec 本身不清楚） | 5 | 9% |
| flaky（行為對但不穩） | 3 | 6% |
coverage-gap 過半是兩週數據最顯眼的信號。這不是「系統原本有很多 bug 沒被發現」— 是「spec 有、人類沒時間寫對應 test」。這一塊是 agent 最能 scale 的地方：產 test 是重複性勞動、人類不想做、agent 做得開心。
做對的三件事
1. Spec 放進 git、spec-driven 三方比對
〈#2 Spec-driven 是 SSOT〉 已經講透。實際數字佐證：5 個 needs-spec-review case 裡、沒有一個是 agent 自己誤判 spec 寫錯。
這個比例很誠實 — 代表當 agent 說「我不確定 spec 要什麼」時，通常 spec 真的需要人類釐清。而且那 5 個人工 review 完、回頭修 spec、其他 48 個 bug 不再互相染色。spec-as-SSOT 架構的 selling point 就是這個。
2. Learned-patterns graduation（而不是 auto-pruning）
〈#3 讓 Agent 教 Agent〉 已經講透。關鍵是命名：
- 原本叫 auto-pruning → 暗示丟掉、而我不想丟
- 改叫 graduation → 升級成更穩定的 context（
.claude/skills/*.md）
兩週 9 條 pattern、4 條畢業（44%）、共被自動套用 22 次。如果沒有這一層、至少 13 個「fix 一個 file 還有 sibling bug 沒掃到」的 case 會變成下個 sprint 的 hidden regression。
3. qa-fixer 跟 qa-reviewer 分離
最重要的架構決策。同一個 agent 不能自己改 code 又自己 review，LLM 有很強的 self-validation bias。
Reviewer 拿到 fixer 的 PR 時完全看不到 fixer 的 thought trace、只看 diff + spec + test — 等同於一個獨立 senior engineer 進來 review。
兩週實際案例：qa-fixer 修完 AUT-60（login progressive delay）後覺得修得很漂亮、自信滿滿。reviewer 看完發現 fixer 用的 fastForward(N-1) 檢查不可靠、要求重做。fixer 第二輪（rounds: 2）改用 loading-state 檢查才過。
如果是同一個 agent、這個 bug 會直接進 main。分離不是 nice-to-have、是 safety property。
做錯的三件事
1. 一開始 prompt 給太多
第一版的 qa-planner.md 被我塞到幾百行。我以為越多 context agent 越聰明。錯。
超過某個長度後、agent 開始挑重點讀、而且挑錯重點。具體症狀：planner 會忽略我特別強調「不要做 X」的段落、然後做了 X。
重寫後 planner prompt 剪到不到 200 行（目前 170 行），把細節拆到 reference files（agent 需要時才 Read）、成功率反而上升。更省 token、跑更快、判斷更準。
教訓：prompt 設計要跟 software design 一樣遵守 single-responsibility。agent 的 working memory 比你想的窄。
2. 沒從 Day 1 開 monitoring
前兩週我完全不知道 pipeline 的細節失敗在哪裡。每天早上看 Slack 只知道「成功」或「失敗」、但不知道哪個 agent、哪個 step 花最久、哪個 tool call 失敗。
後來加的監控層：
- 每個 agent 的 start/end timestamp（寫進
health.json） health.json記最後 3 次 shift 的 summary- Sentry（agent call 失敗、API rate limit、超時）
建議：Day 1 就開監控、不要等「pipeline 穩了再來做」。不穩才更需要監控。這一點我跟你講過、相信我、你重來一次還是會犯。
3. Learned-patterns 沒做 graduation criteria 之前、planner 會越跑越慢
初版 .learned-patterns.json 沒有 graduation 機制。patterns 一直累積、planner 每次 session 開場都要對每一條 pattern 跑一次 grep — patterns 越累積、session 前段的重複工作比例越高。
後來補上 graduation criteria（applied_count ≥ 3 且 fix 沒被 revert → 畢業到 skills）後、熱區 patterns 保持在個位數、planner 開場時間穩定了。
教訓：任何「持續累積」的 agent memory 都要配套一個「退出機制」。沒有退出、memory 只會膨脹成 cruft。
重來會怎麼做
如果回到 2026-03、第一天開始這個系統：
- 先做 monitoring、後做 agent。倒著做、day 1 就有
.health.json跟 Slack。 - Prompt 從 ~200 行起步、證明再擴。不要一開始寫 800 行。
- Graduation criteria 從 day 1 定義。就算只是「applied_count ≥ 3 就畢業」這麼簡單。
.env.test從 day 1 權限 600。還好兩週內沒漏 credential、但這是運氣。- Spec 寫法範例放在 planner prompt 裡。我當時 assume spec 作者會寫得夠結構化、結果頭三週 needs-spec-review 比例異常高、根因是 spec 格式不一致。
- Linear label 從一開始全部定義好（
qa-bot、needs-human-review、module:*、dora:*）。後補 label 要手動回溯、很痛。
接下來：抽成 OSS claude-qa-pipeline
這套東西在原本的 repo 裡跑得好、但綁死在特定 repo 結構、特定 Linear team、特定 spec 路徑約定上。
要抽出來讓別人能用、得拆成：
- Core（pipeline orchestrator、agent 契約、learned-patterns schema）— repo-agnostic
- Adapter: queue（Linear、GitHub Issues、Jira）— 可替換
- Adapter: scheduler（launchd、cron、GitHub Actions）— 可替換
- Spec format（怎麼寫 spec、planner 怎麼讀）— 最大的抽象挑戰
雛形已經在 ~/Project/claude-qa-pipeline。下一個 milestone 是把 Linear adapter 抽出來、做一個 GitHub Issues adapter 來驗證介面設計沒綁死。
終局：agent 不是取代 QA、是取代「每天重複的 triage 勞動」
整個系列的最後一句話：
這 17 個 merged PR 大多是「如果不會被這個 pipeline 抓到、我自己可能半年內都不會主動排去修」的那種 bug。
不是大 bug、不是 showstopper。是 edge case、是 401 沒處理、是 i18n 漏字、是某個 input state 沒 reset、是 E2E 偶爾閃爆。這些 bug 每個都不痛、加起來卻讓整個產品體驗像還沒打磨好的 demo。
這個層級的 polish 人類 engineer 心知肚明該做、但永遠排不上優先序。一旦 agent 能自動做 — 跑了兩週、產品 feel 就從「可用」變成「順手」。這是 Jira 看不到、PM 看不到、只有 engineer 自己 use product 時才感覺得到的差別。
QA agent 的真正價值不是取代 engineer 判斷、是把 engineer 永遠沒時間做的那些小 polish 自動化。
如果你也想跑一套
claude-qa-pipeline 還沒 release、但骨架在 ~/Project/claude-qa-pipeline。如果你是：
- 在做 multi-agent 系統、想看 graduation / feedback loop 怎麼實作
- 有自己的 spec-driven 開發流程、想加上 agent 層
- Linear 重度使用者、想把 API 當成 agent queue
Twitter @waiting7777 找我、或者 GitHub follow waiting7777 等 claude-qa-pipeline 開放 beta。前 5 個 beta tester 我會 1:1 幫忙接入。
這系列的其他文章
Waiting7777
WoW Arena 冠軍轉前端，用電競 meta 思維拆解技術趨勢。
相關文章
AI Agents開發者工具+1Orca 七個月拿下 10 萬顆星：我拆了它的 GitHub 數據，看到 agent 開發真正的瓶頸
一個由 agent 寫出來、拿來管 agent 的開源 IDE。19,000 個 commit、979 次 release 背後，最值得看的數字是 2,525 個放了一個月還沒人處理的 PR。
2026年10月20日 · Waiting7777 · 7 分鐘閱讀
繼續閱讀 →自動化測試開發者工具你的 100% Coverage 是假的 — 用 test-audit 抓出沒被真正測到的分支
AI 寫的 code 跑出漂亮的覆蓋率數字，但 error path 根本沒人測過，這工具專門抓這個。
2026年10月20日 · Waiting7777 · 3 分鐘閱讀
繼續閱讀 →AI Agents自動化測試+1我用 15 個 Claude Code Agent 跑了一條自動 QA Pipeline — 兩週 17 個 merged PR
這不是 proof of concept，是跑在 macOS launchd 上的真實系統：每天兩班、spec-driven、自己開 Linear issue、自己發 PR、自己從過去的 fix 裡學新的 pattern。
2026年10月20日 · Waiting7777 · 5 分鐘閱讀
繼續閱讀 →這篇文章對你有幫助嗎？
每週一篇 — 技術趨勢背後的商業邏輯
AI 產業在變什麼、工程師該注意什麼——拆清楚寄到你的信箱。