SpecFlow，讓 Agent 開發變成可控流程

概述

最近這一年，我開始大量使用 AI（目前主要用 Claude Code）來寫程式碼。

老實說，現在我幾乎已經不太親自下去寫 code 了。

在工作上的 task 通常都比較小：

• 下 prompt
• 看結果
• 確認有沒有符合預期

但當我開始做 side project（從 0 到 1） 的時候，事情就完全不一樣了。

你會需要：

• 訂 spec
• 做 UI 設計
• 設計資料結構
• 測試功能
• Review 成千上萬行 code

問題是：

人類的 review 速度，根本追不上 AI 的產出速度

於是我開始思考一件事：

有沒有可能讓 AI 不只是寫 code，而是「幫我完成整個開發流程」？

開發發想

一開始在做 side project 時，我也試過一些 spec-driven 工具，例如：

• openspec
• get-shit-done

但都會遇到一個狀況就是：

手動的東西實在太多了

每個開發階段都要驗證 AI 的產出，get-shit-done 光是一個 phase 我就需要手動給指令 3 次，我根本不想做這些，結果最後是好的就好了，但我又不能不驗證，怎麼辦呢？

好像可以請另外一個 agent 來幫我 QA 測 e2e 跟瀏覽器交互的狀況，並在測出問題時可以回報給開發 agent 處理。

有個大概輪廓了，於是就開始設計開發流程。

核心問題：為什麼需要流程化？

在深入設計之前，先釐清一下為什麼單純用 AI 寫 code 不夠，需要一套完整的流程：

問題一：Context 消耗

AI 的 context window 是有限的。當你在同一個對話中又要討論需求、又要寫 code、又要 debug，context 很快就會被塞滿。分工的好處是每個 agent 只需要關注自己的那一塊，context 使用效率大幅提升。

問題二：品質無法保證

一個 agent 從頭做到尾，很容易「自己覺得寫好了」但其實有 bug。當你有獨立的 QA agent，它不會看到開發過程的假設，而是直接從使用者的角度測試，更容易抓到問題。

問題三：追蹤困難

當專案越來越大，你根本不記得上次做到哪裡、哪些功能已完成、哪些還有問題。把一切記錄在 GitHub 上（issue、PR、comment），就有了完整的軌跡可以追溯。

問題四：平行化受限

一個 agent 一次只能做一件事。但如果有良好的分工，多個 agent 可以同時處理不同的 task，開發速度直接翻倍。

設計

在最初期我覺得至少要有這些角色：

• PM：用來跟我確認要開發什麼專案，大致的方向是如何
• UI Designer：設計產品的設計語言，讓後續前端開發的產出視覺上保持一致性
• Tech Lead：負責規劃產品開發，要把太大的 task 切成多個 sub task，分散下去做
• Engineer：就碼農
• QA：負責驗證 engineer 的產出是否有符合預期

參考 openspec 的做法，我選擇把 spec 存在 repo 中，讓所有 agent 以 GitHub 作為協作中心：

• spec → 定義要做的事情
• issue → 任務分配
• comment → agent 溝通
• PR → 結果驗證

流程大致如下：

1. PM 定義需求 → 撰寫 spec
2. Tech Lead 拆解 feature → 建立 issue
3. Engineer 根據 issue 開發
4. QA 同步設計測試項目
5. Engineer 完成後 → QA 開始測試
6. QA 發現問題 → 開 bug issue
7. Engineer 修復

為什麼用 GitHub？

除了 workflow 清楚之外，還有幾個額外好處：

• 可以透過 API 做可視化管理
• 可以串接 auto review（例如 OpenAI Codex 類型工具）
• 所有紀錄都是 persistent，可追蹤
• 整體的可靠性變高

每個角色的具體職責

PM Agent

PM 的工作其實很單純，就是跟我（人類）對話，把我的想法具體化成 spec 文件。它會問我一系列問題：

• 這個產品要解決什麼問題？
• 目標使用者是誰？
• 有哪些必備功能？哪些是 nice to have？
• 有沒有參考的產品？

問完之後，它會產出一份結構化的 spec，存在 repo 的 docs/spec/ 目錄下。

Tech Lead Agent

Tech Lead 拿到 spec 後，會做幾件事：

1. 評估技術可行性
2. 決定技術棧（或使用已有的）
3. 將 feature 拆解成獨立的 task
4. 評估每個 task 之間的依賴關係
5. 建立 GitHub Issue，並標記 priority 和 dependency

拆 task 的粒度很重要——太大的話一個 agent 做不完或做歪了不好修；太小的話管理成本又太高。目前我的經驗是一個 task 大約對應「一個 PR 能完成的量」比較剛好。

QA Agent

QA 比較特別，它需要：

1. 根據 spec 設計測試案例
2. 用 Playwright 撰寫 e2e 測試
3. 在 Engineer 提交 PR 後自動執行測試
4. 測試失敗時，開一個 bug issue 並附上失敗截圖和 log
5. Bug 修復後重新驗證

實作細節

Agent 之間怎麼溝通？

所有溝通都透過 GitHub：

Engineer 完成開發 → 開 PR → 在 PR description 寫上對應的 issue 編號
                          → QA agent 收到通知
                          → QA 拉下 branch，跑測試
                          → 測試通過 → approve PR
                          → 測試失敗 → 在 PR comment 附上 log，開 bug issue

這樣做的好處是所有溝通都有紀錄，而且不需要額外的溝通基礎設施（不需要 message queue 或 webhook server）。

觸發機制

目前的觸發方式比較簡單：

• PM 和 Tech Lead 是人工觸發（因為需要人類 review spec）
• Engineer 是收到 issue assign 後自動啟動
• QA 是偵測到新 PR 後自動啟動

未來希望能做到更自動化，例如 PM 生成 spec 後自動觸發 Tech Lead 開始拆 task。

錯誤處理

Agent 不是萬能的，它們也會犯錯。常見的問題：

• Engineer 做歪了：偏離 spec 的實作 → QA 測試會抓到
• Task 拆太大：Engineer 做到一半 context 爆了 → Tech Lead 需要重新拆
• QA 測試寫錯了：false positive/negative → 需要人工介入 review 測試本身

目前的做法是設定一個「最大重試次數」，如果同一個 bug issue 被 reopen 超過 3 次，就會通知人類介入。

使用心得

後來用這套開發了幾個專案的感想：

我需要手動介入的部分真的變少了

他會分派 agent 去平行的幫我處理任務，而這帶來了另一個好處：主要的 context 不會消耗，個別 agent 的 context 獨立。

不過需要搭配 Claude Code 新出的 auto mode 或是把 permission 全開，不然還是要常常手動按 yes 是也滿麻煩的。

實際數據

用 SpecFlow 開發一個中型 side project（前後端 + 資料庫）的體驗：

• 傳統方式（我自己下 prompt + review）：大約 3-4 個週末
• SpecFlow 方式：大約 1-1.5 個週末 + 零碎時間 review PR

時間省了大約 60%，而且品質反而更穩定，因為 QA agent 會抓到我自己 review 時可能漏掉的 bug。

目前的限制

1. 初始設定成本高：第一次建立整套流程需要花不少時間 tune 每個 agent 的 prompt
2. Debug 比較困難：當 agent 之間的溝通出問題，要追蹤是哪個環節出錯比較麻煩
3. 某些任務不適合：高度需要創意或需要深度 domain knowledge 的任務，agent 表現不如人類直接操作
4. 成本考量：多個 agent 同時跑，API 費用會比較高

未來方向

目前 SpecFlow 還在 early stage，幾個想改進的方向：

• 部署自動化：現在部署 infra 還需要手動處理，希望可以用簡單交互的方式完成它
• 更好的監控介面：目前要看 agent 的狀態只能去 GitHub 看 issue 和 PR，希望有一個 dashboard
• 學習機制：讓 agent 能從過去的錯誤中學習，減少重複犯錯
• 支援更多 agent 類型：例如 Security Reviewer、Performance Tester 等

給想嘗試的人的建議

如果你也想試試看多 agent 協作開發：

1. 從小規模開始：先用兩個 agent（Engineer + QA）跑通流程，再慢慢加角色
2. Spec 一定要寫清楚：agent 不會通靈，spec 越模糊，產出越離譜
3. 建立 feedback loop：讓 QA 的結果能回饋到 Engineer，形成閉環
4. 接受不完美：agent 會犯錯，重點是建立能「自動修正」的機制，而不是追求零錯誤

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