實戰：手把手教你用 7 個 Agent 將 Vibe Coding 升級為專家級開發流程

作者 @sairahul1 拆解了從「Vibe Coding」升級到「軟體工廠」的工作流革命：把單一 AI 對話拆成 7 個專責代理人：研究員、故事撰寫者、規格撰寫者、後端建造者、前端建造者、測試驗證者、實作驗證員，每個只擁有單一職責、乾淨的上下文與嚴格邊界。
（前情提要：串聯萬物的 MCP 加上 Web3，能成下一波 AI 百倍敘事嗎？）
（背景補充：最強投資大師幫你打工！集結巴菲特、蒙格、Cathie Wood…19 個 AI Agent 幫你分析市場）

本文目錄

Toggle

沒有人在談的那個問題
轉折:從 Vibe Coding 到軟體工廠
七個代理人
- 代理人 1:程式碼庫研究員(Codebase Researcher)
- 代理人 2:故事撰寫者(Story Writer)
- 代理人 3:規格撰寫者(Spec Writer)
- 代理人 4:後端建造者(Backend Builder)
- 代理人 5:前端建造者(Frontend Builder)
- 代理人 6:測試驗證者(Test Verifier)
- 代理人 7:實作驗證員(Implementation Validator)
整條鏈是怎麼跑的
基礎:代理人能運作之前,你需要這個
- CLAUDE.md ── 存活於每個對話的記憶
- 上下文漂移 ── 那個無聲的殺手
結果:真正改變的是什麼
- 工廠之前:
- 工廠之後:
- 真正的轉變:
這個週末就做出你自己的版本
- 8 步設置清單:
七個代理人 ── 快速參考

我以為我在用 AI 寫程式。實際上，我只是打字打得比較快而已。

這篇要說的就是兩者的差異——以及徹底改變一切的「7 代理人系統」。

把這篇存下來。它會幫你省下好幾個月。

沒有人在談的那個問題

那個看起來很有產能、其實沒有的循環:

→ 要 Claude 幫你做一個功能 → 它生出程式碼 → 某個地方壞了 → 把錯誤訊息貼回去 → 它修補 → 又壞了另一個地方 → 再問一次

第 1 天:這像魔法。

第 30 天:你花在監督 AI 的時間,比過去自己寫程式還多。

同樣的邏輯出現在三個不同的地方。Claude 忘了你兩週前訂下的慣例。新功能弄壞舊功能。測試不是缺少就是寫得很淺。

你某天醒來才意識到:不是 AI 在失敗,是你的工作流在失敗。

問題的本質是結構性的。

當你在 Claude Code 裡輸入「幫我做這個功能」,你其實是在要求一個 AI 對話同時扮演:

→ 產品分析師 → 架構師 → 後端工程師 → 前端工程師 → 測試工程師 → 程式碼審查員

全部一次到位。在同一個一團亂的對話裡。

計畫裡錯的假設,會變成錯的資料庫模型。錯的資料庫模型,會變成錯的 API。錯的 API,會變成錯的 UI。

等你發現時,錯誤已經擴散到處都是。

這就是所謂的 vibe coding(憑感覺寫程式)。

它有一道很硬的天花板。

轉折:從 Vibe Coding 到軟體工廠

真正改變一切的關鍵:

真正的工程團隊,不會在一個大型對話裡工作。

不同的人擁有不同的工作:

→ 有人釐清使用者問題 → 有人思考架構 → 有人寫 API → 有人寫 UI → 有人思考邊界情況 → 有人做審查

當你把所有這些塌縮成一個 AI 對話,錯誤就會悄悄地累加。

修正之道,是把工作拆給專門化的代理人。

每一個代理人會得到:

→ 一個聚焦的工作 → 自己乾淨的上下文視窗 → 只擁有它真正需要的工具 → 對它「不可碰觸的範圍」有嚴格規則

結果:一座軟體工廠。

一個開發者 + 七個聚焦的代理人 = 一支協調的團隊。

以下就是讓這件事運作的七個代理人。

七個代理人

代理人 1:程式碼庫研究員(Codebase Researcher)

開發者用 AI 時最大的錯誤是什麼?

把「要程式碼」當成第一步。

AI 接受 prompt,做出猜測去填補空白,然後開始生成。糟糕的設計就是在這時偷偷溜進來。

研究員修正這件事。

它唯一的工作:檢視程式碼庫並解釋現況——在一行程式被寫下來之前。

它做什麼:

標出相關檔案與它們的角色
記錄既有需要遵循的模式
找出已經建過的類似功能
標示風險(時區、多租戶、重試邏輯)
列出哪些測試會需要更新

它不能做什麼:

編輯檔案(只有讀取權限)
執行任何會改變狀態的指令
做假設——它應該改成發問

工具: Read、Grep、Glob,僅此而已。

規則: 每一次,在動工之前都要先探索。

研究員永遠先跑。

代理人 2:故事撰寫者(Story Writer)

大部分功能失敗,並不是因為程式碼錯了。

而是因為問題從來沒有被清楚定義。

故事撰寫者把粗略的功能構想,變成一個真正的使用者故事——在任何技術決策被做出之前。

輸入:

你的粗略功能描述
研究員的調查結果

產出:

一個使用者故事:「作為 [角色],我想要 [行為],這樣 [結果]。」
驗收標準:可以被測試直接驗證的敘述。Happy path、失敗路徑、商業規則。
邊界情況:邊界、重試、多租戶顧慮。
不在範圍內:什麼是明確「不會做」的。
未解問題:它真心不知道的東西——絕不亂猜。

它不能做什麼:

發明商業規則
寫任何程式碼或技術設計
在有東西真心不清楚時繼續推進

工具: Read,僅此而已。

規則: 你要讀過這份故事並核准,才會發生下一件事。

這是讓下游一切都不出錯的關鍵——人類審核點 1。

代理人 3:規格撰寫者(Spec Writer)

故事核准之後,規格撰寫者把它變成一份技術簡報。

這份簡報就是每個建造代理人會遵循的藍圖。

輸入:

你核准過的使用者故事
研究員的調查結果
你專案的 CLAUDE.md 規則

產出:

資料模型變動(欄位、型別、遷移)
背景流程 / 處理流程
API 變動(端點、request/response 格式)
前端變動(元件、頁面、hooks)
需要的測試(成功、失敗、邊界)
風險與未解問題
每一個會被改動的檔案

它不能做什麼:

編輯任何檔案
發明新的基礎設施——而是要明確指出
跳過租戶隔離或時區考量
留下沒有答案的問題

工具: Read、Grep、Glob,僅此而已。

規則: 這份簡報是人類審核點 2。

你讀過、核准,才會有任何一個檔案被動。

如果你看見「把 ID 存在記憶體裡」——那就是紅旗。

現在抓出來。不要等到 10 個檔案被改完。

代理人 4:後端建造者(Backend Builder)

現在才開始建造。

後端建造者實作功能的「後端那一半」——而且只負責後端那一半。

輸入:

核准的技術簡報
研究員的調查結果
你專案的 CLAUDE.md

它建造:

API 路由
Services 與商業邏輯
資料庫存取與遷移
背景任務
它所寫東西的單元測試

它不能做什麼:

碰任何 React 元件、頁面或 client-side hooks(那是代理人 5 的工作)
在沒有指示下發明新依賴
修改範圍外的檔案
沒跑 typecheck、lint 與測試套件就停下

完成後,它會回傳一份摘要:每個新增或編輯的檔案、每個被重用的既有 helper 或模式、任何「如果有 CLAUDE.md 規則會更好」的觀察。

工具: Read、Edit、Write、Bash——只限後端資料夾。

重點就在分離本身。

後端建造者永遠不可能不小心弄壞前端。

代理人 5:前端建造者(Frontend Builder)

前端建造者實作 UI 那一半——只負責 UI 那一半。

它會先讀後端建造者的摘要。

這很重要。

它會依照後端產出的樣子去使用 API。它不會發明新的端點。

如果 API 的形狀對 UI 而言是錯的,它會把不符回報出來——而不是自己打補丁。

輸入:

核准的技術簡報
研究員的調查結果
後端建造者的摘要(API 合約)

它建造:

React 元件與頁面
Client-side hooks 與狀態
Loading 與 error 狀態
它所寫東西的元件與單元測試

它不能做什麼:

碰 services、API 路由、workers 或遷移(那是代理人 4 的工作)
發明端點或回應格式
在沒有指示下加依賴
沒跑 typecheck、lint 與測試套件就停下

工具: Read、Edit、Write、Bash——只限前端資料夾。

兩個建造者。兩個乾淨的上下文視窗。零機率一個會弄壞另一個的工作。

代理人 6:測試驗證者(Test Verifier)

兩個建造者都幫自己寫了單元測試。

那不夠。

測試驗證者只做一件事:證明這個功能真的做了使用者故事說它要做的事。

它寫的是「驗收測試」(acceptance tests),不是單元測試。

驗收測試從外部測試功能——就像一個真實使用者會去體驗它的方式。

輸入:

核准的使用者故事(包含所有驗收標準)
核准的技術簡報
兩個建造者的摘要

產出:

一份覆蓋每個驗收標準的驗收測試檔
一份報告:哪些通過、哪些失敗、哪些無法乾淨覆蓋

它不能做什麼:

修改任何後端或前端程式碼
為無法測試的標準發明繞道方案
把實際沒覆蓋到的標準標為已覆蓋

如果一個測試失敗:這個功能就不滿足故事。

它會回報「哪一條標準失敗了」。它不會去修補程式碼。

修補會被丟回正確的建造者那邊。

工具: Read、Edit、Write(僅測試檔)、Bash。

規則:在驗收測試通過之前,你還沒有這個功能。

代理人 7:實作驗證員(Implementation Validator)

這是那個會抓出大家漏掉的東西的代理人。

驗證員會把目前的實作,對照核准的故事與簡報,回報落差。

它從不修任何東西。它只說真話。

每一次它會跑的檢查:

故事的驗收標準有沒有還沒實作的
沒有測試覆蓋的失敗路徑
安全議題:缺漏的權限檢查、租戶隔離漏洞、log 裡的密鑰、原始錯誤外洩到 client
範圍外被改動的檔案
與 CLAUDE.md 或既有程式碼不一致的模式
應該重用既有 helper 卻被寫成重複邏輯的地方
簡報中被悄悄跳過的時區或多租戶考量

輸出永遠按嚴重度分組:

Critical — 合併前必修
Important — 合併前應修
Minor — 偏意見,審查者自己決定

每一個發現都會附上檔案路徑與行號。

如果沒有問題,它就直接說沒問題。它不會為了顯得認真而發明問題。

工具: Read、Grep、Glob,僅此而已。

這個代理人,是讓整座工廠值得信任的原因。

自評的成績單沒有價值。一個只看「磁碟上有什麼」、不看「怎麼被寫出來」的驗證員,才是誠實的。

整條鏈是怎麼跑的

完整流程——一個 prompt 啟動一切:

你打開 Claude Code,輸入:

接下來你不需要再多打任何字,它會這樣發生:

Step 1 → 研究員把你的發票、付款與 email 程式碼掃過一輪。回傳相關檔案、既有模式與風險。

Step 2 → 故事撰寫者產出使用者故事與驗收標準。

⏸ 暫停:你閱讀並核准故事。

Step 3 → 規格撰寫者把核准的故事變成技術簡報。

⏸ 暫停:你閱讀並核准簡報。(就在這裡抓出「把 ID 存在記憶體裡」的錯誤。)

Step 4 → 後端建造者實作 service、API 路由、BullMQ 任務與單元測試。回傳:檔案變動、重用模式、全部測試綠燈。

Step 5 → 前端建造者讀後端的 API 摘要,做出 admin UI 區塊與提醒按鈕,寫元件測試。全綠。

Step 6 → 測試驗證者為六條驗收標準寫驗收測試。回報:7 條通過,1 條失敗——手動觸發沒有檢查租戶擁有權。

Step 7 → 驗證員抓到了。以 Critical 等級回報,附檔案路徑與行號。

→ 回到後端建造者。修好。8 條驗收測試全綠。驗證員再跑一次。乾淨。

⏸ 暫停:你審查並開 PR。

三個人類審核點。其他都自己跑。

基礎:代理人能運作之前,你需要這個

CLAUDE.md ── 存活於每個對話的記憶

每一次你打開 Claude Code,它都是從「零記憶」開始。

CLAUDE.md 修正這件事。

它是 repo 根目錄的一個 Markdown 檔,每個對話開始時都會自動載入。

它是「永久專案事實」的家:

你的技術棧(Next.js App Router、Node.js、Prisma、BullMQ、Resend)
你的指令(npm run dev、npm test、npx prisma migrate dev)
架構規則(「商業邏輯放在 services。API 路由保持薄。」)
不要做的事(「不要加 cron——用 BullMQ。不要把原始付款 payload 寫進 log。」)
深入文件的指標(docs/billing.md、docs/architecture.md)

保持在 100–300 行。

每次 AI 犯了一個讓你驚訝的錯誤,問自己:「如果 CLAUDE.md 裡有一條規則,這次能避免嗎?」

把規則加進去。

幾週後,你的 CLAUDE.md 就會變成「AI 曾經弄錯的所有假設」的記錄——你的對話會明顯變得更好。

上下文漂移 ── 那個無聲的殺手

大部分 Claude Code 對話不會戲劇性地失敗。

它們會漂移。

一個錯的假設進入上下文。模型繼續往上面疊。

你要 Claude 做「訂閱管理」。它設計:User → Subscription。

你後來才想起:訂閱屬於「公司」,不是「使用者」。

如果你只說「不對,訂閱屬於公司」——Claude 會打補丁。

現在你就有了同時飄在四處的 user.subscriptionId 與 company.subscriptionId。

規則:

小錯字?直接 inline 修正。
架構假設錯了?把整個對話丟掉,從頭開始,把對的假設烙進第一個 prompt。

一個有正確心智模型的乾淨對話,永遠勝過一個打了補丁的對話。

結果:真正改變的是什麼

工廠之前:

Vibe coding 循環:prompt → 生成 → 錯誤 → 補丁 → 重複
對話的上下文塞滿雜訊
錯的假設累積成壞掉的功能
一個工程師一次只能做一件事
每個功能都在等對的人有空

工廠之後:

結構化的鏈:研究 → 故事 → 簡報 → 建造 → 驗證 → 確認
每個代理人擁有乾淨的上下文,只裝它需要的東西
錯的假設在「簡報核准」就被抓出——不是 10 個檔案之後
一個工程師可以出一個完整的垂直切片:後端、前端、測試、驗證
團隊最好的知識住在代理人裡——不被困在「某個人」身上

真正的轉變:

付款專家做一個 payments-integration 代理人。從那一刻起,團隊每一個工程師都能出帶帳務的功能。不必等待,不必交接。

前端 lead 的元件模式,住在 frontend-builder 代理人裡。DevOps 工程師的 CI 檢查,住在 hook 裡。QA lead 的邊界情況,住在 test-verifier 規則裡。

專家知識,以代理人的形式被共享。不被困在「誰有空」這件事裡。

這個週末就做出你自己的版本

8 步設置清單:

安裝 Claude Code → code.claude.com
建立資料夾結構:
- .claude/agents/
- .claude/skills/feature-factory/
- .claude/skills/build-with-tests/
- .claude/hooks/
寫你的 CLAUDE.md(100–300 行:技術棧、指令、架構規則、不要做的清單)
用 Claude Code 的 /agents 指令建立 7 個代理人。描述每個代理人的角色。Claude 寫檔案。你審查並 commit。
建立 feature-factory orchestrator skill。叫 Claude 幫你寫——它會讀你 7 個 agent 檔並接好整條鏈。
建立 build-with-tests skill。描述你的團隊怎麼建造:對齊既有模式、邊寫程式邊寫測試、最後跑 typecheck。
加一個 pre-commit hook。擋住把 .env、.key、.pem 或 secrets.json 提交進去。5 分鐘搞定,可以避免大型災難。
跑一個真實的功能走完整條鏈。挑一個小的。觀察它在哪裡卡住。加規則。工廠會自己調整。