실전: 7개의 Agent를 사용하여 Vibe Coding을 전문가급 개발 프로세스로 업그레이드하는 방법을 단계별로 알려드립니다

作者 @sairahul1 拆解了從「Vibe Coding」升級到「軟體工廠」的工作流革命：把單一 AI 對話拆成 7 個專責代理人：研究員、故事撰寫者、規格撰寫者、後端建造者、前端建造者、測試驗證者、實作驗證員，每個只擁有單一職責、乾淨的上下文與嚴格邊界。（前情提要：串聯萬物的 MCP 加上 Web3，能成下一波 AI 百倍敘事嗎？）（背景補充：最強投資大師幫你打工！集結巴菲特、蒙格、Cathie Wood…19 個 AI Agent 幫你分析市場）我以為我在用 AI 寫程式。實際上，我只是打字打得比較快而已。這篇要說的就是兩者的差異——以及徹底改變一切的「7 代理人系統」。把這篇存下來。它會幫你省下好幾個月。那個看起來很有產能、其實沒有的循環: → 要 Claude 幫你做一個功能 → 它生出程式碼 → 某個地方壞了 → 把錯誤訊息貼回去 → 它修補 → 又壞了另一個地方 → 再問一次第 1 天:這像魔法。第 30 天:你花在監督 AI 的時間,比過去自己寫程式還多。同樣的邏輯出現在三個不同的地方。Claude 忘了你兩週前訂下的慣例。新功能弄壞舊功能。測試不是缺少就是寫得很淺。你某天醒來才意識到:不是 AI 在失敗,是你的工作流在失敗。問題的本質是結構性的。當你在 Claude Code 裡輸入「幫我做這個功能」,你其實是在要求一個 AI 對話同時扮演: → 產品分析師 → 架構師 → 後端工程師 → 前端工程師 → 測試工程師 → 程式碼審查員全部一次到位。在同一個一團亂的對話裡。計畫裡錯的假設,會變成錯的資料庫模型。錯的資料庫模型,會變成錯的 API。錯的 API,會變成錯的 UI。等你發現時,錯誤已經擴散到處都是。這就是所謂的 vibe coding(憑感覺寫程式)。它有一道很硬的天花板。真正改變一切的關鍵: 真正的工程團隊,不會在一個大型對話裡工作。不同的人擁有不同的工作: → 有人釐清使用者問題 → 有人思考架構 → 有人寫 API → 有人寫 UI → 有人思考邊界情況 → 有人做審查當你把所有這些塌縮成一個 AI 對話,錯誤就會悄悄地累加。修正之道,是把工作拆給專門化的代理人。每一個代理人會得到: → 一個聚焦的工作 → 自己乾淨的上下文視窗 → 只擁有它真正需要的工具 → 對它「不可碰觸的範圍」有嚴格規則結果:一座軟體工廠。一個開發者 + 七個聚焦的代理人 = 一支協調的團隊。以下就是讓這件事運作的七個代理人。開發者用 AI 時最大的錯誤是什麼? 把「要程式碼」當成第一步。 AI 接受 prompt,做出猜測去填補空白,然後開始生成。糟糕的設計就是在這時偷偷溜進來。研究員修正這件事。它唯一的工作:檢視程式碼庫並解釋現況——在一行程式被寫下來之前。它做什麼: - 標出相關檔案與它們的角色 - 記錄既有需要遵循的模式 - 找出已經建過的類似功能 - 標示風險(時區、多租戶、重試邏輯) - 列出哪些測試會需要更新它不能做什麼: - 編輯檔案(只有讀取權限) - 執行任何會改變狀態的指令 - 做假設——它應該改成發問工具: Read、Grep、Glob,僅此而已。規則: 每一次,在動工之前都要先探索。研究員永遠先跑。大部分功能失敗,並不是因為程式碼錯了。而是因為問題從來沒有被清楚定義。故事撰寫者把粗略的功能構想,變成一個真正的使用者故事——在任何技術決策被做出之前。輸入: - 你的粗略功能描述 - 研究員的調查結果產出: - 一個使用者故事:「作為 [角色],我想要 [行為],這樣 [結果]。」 - 驗收標準:可以被測試直接驗證的敘述。Happy path、失敗路徑、商業規則。 - 邊界情況:邊界、重試、多租戶顧慮。 - 不在範圍內:什麼是明確「不會做」的。 - 未解問題:它真心不知道的東西——絕不亂猜。它不能做什麼: - 發明商業規則 - 寫任何程式碼或技術設計 - 在有東西真心不清楚時繼續推進工具: Read,僅此而已。規則: 你要讀過這份故事並核准,才會發生下一件事。這是讓下游一切都不出錯的關鍵——人類審核點 1。故事核准之後,規格撰寫者把它變成一份技術簡報。這份簡報就是每個建造代理人會遵循的藍圖。輸入: - 你核准過的使用者故事 - 研究員的調查結果 - 你專案的 CLAUDE.md 規則產出: - 資料模型變動(欄位、型別、遷移) - 背景流程 / 處理流程 - API 變動(端點、request/response 格式) - 前端變動(元件、頁面、hooks) - 需要的測試(成功、失敗、邊界) - 風險與未解問題 - 每一個會被改動的檔案它不能做什麼: - 編輯任何檔案 - 發明新的基礎設施——而是要明確指出 - 跳過租戶隔離或時區考量 - 留下沒有答案的問題工具: Read、Grep、Glob,僅此而已。規則: 這份簡報是人類審核點 2。你讀過、核准,才會有任何一個檔案被動。如果你看見「把 ID 存在記憶體裡」——那就是紅旗。現在抓出來。不要等到 10 個檔案被改完。現在才開始建造。後端建造者實作功能的「後端那一半」——而且只負責後端那一半。輸入: - 核准的技術簡報 - 研究員的調查結果 - 你專案的 CLAUDE.md 它建造: - API 路由 - Services 與商業邏輯 - 資料庫存取與遷移 - 背景任務 - 它所寫東西的單元測試它不能做什麼: - 碰任何 React 元件、頁面或 client-side hooks(那是代理人 5 的工作) - 在沒有指示下發明新依賴 - 修改範圍外的檔案 - 沒跑 typecheck、lint 與測試套件就停下完成後,它會回傳一份摘要:每個新增或編輯的檔案、每個被重用的既有 helper 或模式、任何「如果有 CLAUDE.md 規則會更好」的觀察。工具: Read、Edit、Write、Bash——只限後端資料夾。重點就在分離本身。後端建造者永遠不可能不小心弄壞前端。前端建造者實作 UI 那一半——只負責 UI 那一半。它會先讀後端建造者的摘要。這很重要。它會依照後端產出的樣子去使用 API。它不會發明新的端點。如果 API 的形狀對 UI 而言是錯的,它會把不符回報出來——而不是自己打補丁。輸入: - 核准的技術簡報 - 研究員的調查結果 - 後端建造者的摘要(API 合約) 它建造: - React 元件與頁面 - Client-side hooks 與狀態 - Loading 與 error 狀態 - 它所寫東西的元件與單元測試它不能做什麼: - 碰 services、API 路由、workers 或遷移(那是代理人 4 的工作) - 發明端點或回應格式 - 在沒有指示下加依賴 - 沒跑 typecheck、lint 與測試套件就停下工具: Read、Edit、Write、Bash——只限前端資料夾。兩個建造者。兩個乾淨的上下文視窗。零機率一個會弄壞另一個的工作。兩個建造者都幫自己寫了單元測試。那不夠。測試驗證者只做一件事:證明這個功能真的做了使用者故事說它要做的事。它寫的是「驗收測試」(acceptance tests),不是單元測試。驗收測試從外部測試功能——就像一個真實使用者會去體驗它的方式。輸入: - 核准的使用者故事(包含所有驗收標準) - 核准的技術簡報 - 兩個建造者的摘要產出: - 一份覆蓋每個驗收標準的驗收測試檔 - 一份報告:哪些通過、哪些失敗、哪些無法乾淨覆蓋它不能做什麼: - 修改任何後端或前端程式碼 - 為無法測試的標準發明繞道方案 - 把實際沒覆蓋到的標準標為已覆蓋如果一個測試失敗:這個功能就不滿足故事。它會回報「哪一條標準失敗了」。它不會去修補程式碼。修補會被丟回正確的建造者那邊。工具: Read、Edit、Write(僅測試檔)、Bash。規則:在驗收測試通過之前,你還沒有這個功能。這是那個會抓出大家漏掉的東西的代理人。驗證員會把目前的實作,對照核准的故事與簡報,回報落差。它從不修任何東西。它只說真話。每一次它會跑的檢查: - 故事的驗收標準有沒有還沒實作的 - 沒有測試覆蓋的失敗路徑 - 安全議題:缺漏的權限檢查、租戶隔離漏洞、log 裡的密鑰、原始錯誤外洩到 client - 範圍外被改動的檔案 - 與 CLAUDE.md 或既有程式碼不一致的模式 - 應該重用既有 helper 卻被寫成重複邏輯的地方 - 簡報中被悄悄跳過的時區或多租戶考量輸出永遠按嚴重度分組: - Critical — 合併前必修 - Important — 合併前應修 - Minor — 偏意見,審查者自己決定每一個發現都會附上檔案路徑與行號。如果沒有問題,它就直接說沒問題。它不會為了顯得認真而發明問題。工具: Read、Grep、Glob,僅此而已。這個代理人,是讓整座工廠值得信任的原因。自評的成績單沒有價值。一個只看「磁碟上有什麼」、不看「怎麼被寫出來」的驗證員,才是誠實的。完整流程——一個 prompt 啟動一切: 你打開 Claude Code,輸入: 「幫我做『超過 7 天未付的發票提醒』功能。」接下來你不需要再多打任何字,它會這樣發生: 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 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 規則裡。專家知識,以代理人的形式被共享。不被困在「誰有空」這件事裡。 - 安裝 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 分鐘搞定,可以避免大型災難。 - 跑一個真實的功能走完整條鏈。挑一個小的。觀察它在哪裡卡住。加規則。工廠會自己調整。總時間:2–3 小時。跑個幾個功能。3–4 個之後,工廠就認識你的程式碼庫了。你會花更少時間監督,更多時間決定「接下來要做什麼」。 - 研究員(Researcher) — 在任何東西被造之前先掃過程式碼(只讀) - 故事撰寫者(Story Writer) — 把構想變成使用者故事與驗收標準(只讀) - 規格撰寫者(Spec Writer) — 把故事變成技術簡報(只讀) - 後端建造者(Backend Builder) — 建造 API、services、jobs、單元測試(只限後端資料夾) - 前端建造者(Frontend Builder) — 建造元件、頁面、hooks、UI 測試(只限前端資料夾) - 測試驗證者(Test Verifier) — 對使用者故事寫驗收測試(只限測試檔) - 驗證員(Validator) — 拿實作對照故事與簡報、回報落差(只讀) 3 個人類審核點: → 核准故事 → 核准簡報 → 核准 PR 其他都自己跑。大部分用 Claude Code 的開發者還在 vibe coding。Prompt → 生成 → 補丁 → 祈禱。那不算錯。但那有天花板。工廠不是把你從流程裡踢出去。它是把你從「不需要你判斷」的部分裡踢出去。你會留在那些「你的判斷真正重要」的環節裡: 這是對的問題嗎?這是對的設計嗎?這個可以安全上線嗎? 中間的所有事情,代理人負責。這就是「把 AI 當成更快的鍵盤」和「把 AI 當成一支協調團隊」的差別。原文作者：@sairahul1