我以為我在用 AI 寫程式。
實際上我只是打字變快了而已。
以下是這兩者的差異——以及徹底改變一切的 7 個 Agent 系統。
請存好這篇文章。它會幫你省下好幾個月的摸索時間。
沒人談論的真正問題
看似有效率但實際上沒用的循環：
→ 叫 Claude 做一個功能 → 它產生程式碼 → 出錯了 → 貼回錯誤訊息 → 它修補 → 又壞了 → 再問一次
第一天：感覺像魔法。
第 30 天：你花在監督 AI 的時間，比之前自己寫程式還多。
同樣的邏輯在三個不同地方出現。
Claude 忘了你兩週前設立的慣例。
新功能破壞了舊功能。
測試遺漏或膚淺。
你醒來發現：失敗的不是 AI。
是你的工作流程。
真正的問題是結構性的。
當你對 Claude Code 輸入「建立這個功能」時，你等於要求一個 AI 對話同時扮演：
→ 產品分析師 → 架構師 → 後端工程師 → 前端工程師 → 測試工程師 → 程式碼審查員
全部同時進行。
在同一場混亂的對話中。
計畫中的錯誤假設變成錯誤的資料庫模型。
錯誤的資料庫模型變成錯誤的 API。
錯誤的 API 變成錯誤的 UI。
等你發現時，錯誤早已擴散到各處。
這就是所謂的直覺式編碼。
而且它有個難以突破的天花板。
轉變：從直覺式編碼到軟體工廠
真正帶來改變的是什麼：
真正的工程團隊不會只用一場大型對話來工作。
不同的人負責不同的工作：
→ 有人釐清使用者問題 → 有人思考架構 → 有人建構 API → 有人建構 UI → 有人思考邊界案例 → 有人進行審查
當你把這一切都塞進一個 AI 對話中，錯誤就會默默疊加。
解決方法是將工作拆分給專門的 Agent。
每個 Agent 得到：→ 一個專注的任務 → 自己乾淨的上下文視窗 → 只有它真正需要的工具 → 關於它不能碰觸什麼的嚴格規則
結果：一個軟體工廠。
一個開發者 + 七個專注的 Agent = 一個協同合作的團隊。
以下是讓它運作的七個 Agent。
七個 Agent
Agent 1：程式碼庫研究員
開發者用 AI 犯的最大錯誤？
第一動就要求寫程式碼。
AI 接受提示，用猜測填補缺口，然後開始產生。
這時糟糕的設計就悄悄溜進來了。
程式碼庫研究員解決了這個問題。
它唯一的工作是：在寫任何一行程式碼之前，檢查程式碼庫並解釋事情如何運作。
它做什麼：→ 標記相關檔案及其角色 → 記錄要遵循的現有模式 → 找到已建立的類似功能 → 標記風險（時區、多租戶、重試邏輯） → 列出哪些測試需要更新
它不能做什麼：→ 編輯檔案（唯讀權限） → 執行任何會修改狀態的命令 → 做出假設——它會提問
工具：僅限 Read、Grep、Glob。
規則：每次建構前，先探索。
研究員總是第一個執行。
Agent 2：故事撰寫者
大多數功能失敗不是因為程式碼寫錯。
而是因為問題從未被清楚定義。
故事撰寫者在你做任何技術決策之前，把一個粗略的功能點子變成真正的使用者故事。
它收到的輸入：→ 你的粗略功能描述 → 研究員的發現
它產出的內容：
一個使用者故事：「身為一個 [角色]，我想要 [行為]，以便 [成果]。」
驗收標準：測試可以直接驗證的陳述。快樂路徑。失敗路徑。商業規則。
邊界案例：邊界、重試、多租戶考量。
不包含的範圍：明確指出什麼是不被建構的。
未決問題：它真的不知道的事情——絕不猜測。
它不能做什麼：→ 捏造商業規則 → 寫任何程式碼或技術設計 → 在事情真正不清楚時繼續前進
工具：僅限 Read。
規則：你在任何其他事發生之前，閱讀這個故事並批准它。
這是能拯救下游所有環節的人類檢查點。
Agent 3：規格撰寫者
故事一經批准，規格撰寫者就將其轉化為技術簡報。
這是每個建構 Agent 都要遵循的藍圖。
它收到的輸入：→ 你批准的使用者故事 → 研究員的發現 → 你專案的 CLAUDE.md 規則
它產出的內容：
→ 資料模型變更（欄位、型別、遷移） → 背景流程 / 處理流程 → API 變更（端點、請求/回應結構） → 前端變更（元件、頁面、hooks） → 需要的測試（成功、失敗、邊界案例） → 風險與未決問題 → 每個將會變更的檔案
它不能做什麼：→ 編輯任何檔案 → 捏造新的基礎設施——而是明確指出 → 跳過租戶隔離或時區考量 → 留下未回答的問題
工具：僅限 Read、Grep、Glob。
規則：這個簡報是第二個人類檢查點。
你在觸碰任何一個檔案之前閱讀並批准它。
如果你看到「將 ID 儲存在記憶體中」——那就是你的紅旗。
現在就抓住它。不要在改了 10 個檔案之後才發現。
Agent 4：後端建構者
現在建構開始了。
後端建構者實現功能中的後端部分——而且只做後端部分。
它收到的輸入：→ 批准的技術簡報 → 研究員的發現 → 你專案的 CLAUDE.md
它建構的內容：→ API 路由 → 服務與商業邏輯 → 資料庫存取與遷移 → 背景任務 → 它寫的每一段程式碼的單元測試
它不能做什麼：→ 觸碰 React 元件、頁面或用戶端 hooks（那是 Agent 5 的工作） → 未經指示就引入新的依賴項 → 修改約定範圍之外的檔案 → 在沒有執行 typecheck、lint 和測試套件的情況下停止
完成後，它回傳一份摘要：→ 每個新增或編輯的檔案 → 每個重複使用的現有 helper 或模式 → 任何可能有幫助的 CLAUDE.md 規則
工具：Read、Edit、Write、Bash——僅限於後端資料夾。
分離就是重點。
後端建構者永遠不會意外破壞前端。
Agent 5：前端建構者
前端建構者實現 UI 部分——而且只做 UI 部分。
它會先讀取後端建構者的摘要。
這很重要。
它使用 API 的方式就是後端產生的樣子。
它不會自行發明新的端點。
如果 API 結構對 UI 來說不對，它會將這個不匹配作為回饋提出——而不是自己修補。
它收到的輸入：→ 批准的技術簡報 → 研究員的發現 → 後端建構者的摘要（API 契約）
它建構的內容：→ React 元件和頁面 → 用戶端 hooks 和狀態 → 載入中和錯誤狀態 → 它寫的每一段程式碼的元件和單元測試
它不能做什麼：→ 觸碰服務、API 路由、worker 或遷移（那是 Agent 4 的工作） → 自行發明端點或回應結構 → 未經指示就新增依賴項 → 在沒有執行 typecheck、lint 和測試套件的情況下停止
工具：Read、Edit、Write、Bash——僅限於前端資料夾。
兩個 Builder。
兩個乾淨的上下文視窗。
一個破壞另一個工作的機率為零。
Agent 6：測試驗證者
兩個 Builder 都為自己的程式碼寫了單元測試。
但這還不夠。
測試驗證者只做一件事：證明這個功能確實做到了使用者故事所說的事情。
它寫的是驗收測試。
不是單元測試。
是驗收測試。
這些測試從外部測試這個功能——就像真實使用者體驗它的方式。
它收到的輸入：→ 批准的使用者故事（包含所有驗收標準） → 批准的技術簡報 → 兩個 Builder 的摘要
它產出的內容：→ 一個涵蓋每個驗收標準的驗收測試檔案 → 一份報告：哪些標準通過、哪些失敗、哪些無法乾淨地涵蓋
它不能做什麼：→ 修改任何後端或前端程式碼 → 為無法測試的標準發明變通方法 → 在標準實際上沒有被涵蓋時標記為已涵蓋
如果測試失敗：表示功能不符合故事要求。
它會報告具體是哪個標準失敗。
它不會修補程式碼。
那會回到正確的 Builder 那裡。
工具：Read、Edit、Write（僅限測試檔案）、Bash。
規則：在驗收測試通過之前，你都沒有完成一個功能。
Agent 7：實作驗證者
這個 Agent 負責抓住其他所有人都漏掉的東西。
驗證者將當前的實作與已批准的故事和簡報進行比較——並報告差距。
它永遠不做任何修復。
它只是說出實話。
它每次都會執行的檢查：
→ 故事中尚未實作的驗收標準 → 沒有測試覆蓋的失敗路徑 → 安全問題：缺少身份驗證檢查、租戶隔離缺口、記錄中的機密、暴露給用戶端的原始錯誤 → 在約定範圍之外變更的檔案 → 與 CLAUDE.md 或現有程式碼不一致的模式 → 應該重複使用現有 helper 的重複邏輯 → 簡報中提到的時區或多租戶考量被悄悄跳過
輸出總是按嚴重程度分組：
重大 — 合併前必須修復 重要 — 合併前最好修復 次要 — 基於意見，由審查者決定
每個發現都包含檔案路徑和行號。
如果沒有任何問題，它會直接說沒有。
它不會為了顯得徹底而編造問題。
工具：僅限 Read、Grep、Glob。
這個 Agent 就是為什麼工廠值得信賴的原因。
一份自己批改的考卷是沒有價值的。
一個只看磁碟上實際內容——而不是看它是怎麼被寫出來的——的驗證者，才是誠實的。
鏈條如何運作
完整流程——一個提示就啟動一切：
你打開 Claude Code 並輸入：
「為逾期超過 7 天的發票建立催款提醒功能。」
接下來會發生什麼事，你完全不需要再輸入任何東西：
步驟 1 → 研究員 映射你的發票、付款和電子郵件程式碼。回傳相關檔案、現有模式、風險。
步驟 2 → 故事撰寫者 產出使用者故事和驗收標準。
⏸ 暫停：你閱讀並批准故事。
步驟 3 → 規格撰寫者 將批准的故事轉化為技術簡報。
⏸ 暫停：你閱讀並批准簡報。（就在這裡抓住那個「將 ID 儲存在記憶體中」的錯誤。）
步驟 4 → 後端建構者 實作服務、API 路由、BullMQ 任務和單元測試。回傳：變更的檔案、重複使用的模式、所有測試通過。
步驟 5 → 前端建構者 讀取後端建構者的 API 摘要，建立管理 UI 區塊和提醒按鈕，撰寫元件測試。所有測試通過。
步驟 6 → 測試驗證者 為所有六個驗收標準撰寫驗收測試。報告：7 個通過，1 個失敗——手動觸發沒有檢查租戶所有權。
步驟 7 → 驗證者 發現了這個問題。報告為「重大」級別，附帶檔案路徑和行號。
→ 迴圈回到後端建構者。 修復完成。所有 8 個驗收測試通過。驗證者再次執行。乾淨。
⏸ 暫停：你審查並發起 PR。
三個人類檢查點。
其他一切都自動運作。
基礎：在 Agent 運作之前，你需要這個
CLAUDE.md——跨越每次對話的記憶：
每次你打開 Claude Code，它都是從零記憶開始的。
CLAUDE.md 解決了這個問題。
它是一個位於你專案根目錄的 Markdown 檔案，每次對話都會自動載入。
它是存放永久專案事實的地方：
→ 你的技術棧（Next.js App Router、Node.js、Prisma、BullMQ、Resend） → 你的命令（npm run dev、npm test、npx prisma migrate dev） → 架構規則（「商業邏輯放在 services 裡。API routes 保持輕薄。」） → 不該做的事（「不要新增 cron——使用 BullMQ。不要記錄原始付款資料。」） → 指向更深層文件的指標（docs/billing.md、docs/architecture.md）
保持在 100-300 行。
每次 AI 犯了一個讓你驚訝的錯誤時，問自己：CLAUDE.md 裡的一條規則可以防止這個問題嗎？
加入那條規則。
幾週後，你的 CLAUDE.md 就會變成 AI 所有錯誤假設的記錄——你的對話品質也會顯著提升。
上下文漂移——無聲的殺手：
大多數 Claude Code 對話不是戲劇性地失敗。
它們是慢慢漂移。
一個錯誤的假設進入了上下文。
模型在它之上繼續建構。
你叫 Claude 建立訂閱管理功能。
它設計成：User → Subscription。
你記起來：訂閱屬於公司，不屬於使用者。
如果你只說「不對，訂閱屬於公司」——Claude 會修補。
現在你同時有了 user.subscriptionId 和 company.subscriptionId 四處遊蕩。
規則：
→ 小錯字？直接當場修正。 → 錯誤的架構假設？丟掉這個對話，用內建正確假設的第一個提示重新開始。
一個有正確心智模型的乾淨新對話，永遠勝過一個修修補補的對話。
結果：實際改變了什麼
使用工廠之前：
→ 直覺式編碼循環：提示 → 產生 → 錯誤 → 修補 → 重複 → 對話上下文充滿雜訊 → 錯誤假設疊加成壞掉的功能 → 一個工程師一次只能做一件事 → 每個功能都要等對的人有空
使用工廠之後：
→ 結構化鏈條：研究 → 故事 → 簡報 → 建構 → 驗證 → 確認 → 每個 Agent 得到一個乾淨的上下文視窗，只包含它需要的東西 → 錯誤假設在簡報批准階段就被抓住——而不是在改了 10 個檔案之後 → 一個工程師交付一個完整的垂直切片：後端、前端、測試、驗證 → 團隊最好的知識存在於 Agent 中——而不是困在人身上
真正的轉變：
付款專家建立了一個付款整合 Agent。
現在團隊中的每個工程師都可以交付一個觸及帳務的功能。
不用等待。
不用交接。
前端負責人的元件模式存在於前端建構 Agent 中。
DevOps 工程師的 CI 檢查存在於一個 hook 中。
QA 負責人的邊界案例存在於測試驗證者的規則中。
專家知識，以 Agent 的形式共享。
而不是被個人的時間 Availability 所困住。
如何在本週末建立你自己的系統
8 步驟設定檢查清單：
1. 安裝 Claude Code → code.claude.com
2. 建立資料夾結構： → .claude/agents/ → .claude/skills/feature-factory/ → .claude/skills/build-with-tests/ → .claude/hooks/
3. 撰寫你的 CLAUDE.md（100-300 行：技術棧、命令、架構規則、禁止事項清單）
4. 使用 Claude Code 中的 /agents 命令創建 7 個 Agent。描述每個 Agent 的角色。Claude 會寫出檔案。你審查並提交。
5. 創建 feature-factory 編排器技能。叫 Claude 來寫——它會讀取你的 7 個 Agent 檔案並串聯整個鏈條。
6. 創建 build-with-tests 技能。描述你的團隊如何建構：匹配現有模式、程式碼與測試一起寫、最後執行 typecheck。
7. 添加一個 pre-commit hook。阻止包含 .env、.key、.pem 或 secrets.json 檔案的提交。花 5 分鐘。防止災難。
8. 用一個真正的功能跑一遍完整鏈條。選一個小功能。觀察它在哪裡卡住。加入規則。工廠會自我調整。
總時間：2-3 小時。
然後跑幾個功能。
3-4 個功能之後，工廠就熟悉你的程式碼庫了。
你會花更少的時間監督。
更多的時間決定接下來要建構什麼。
7 個 Agent — 快速參考
→ 研究員 — 在建構任何東西之前映射程式碼（僅限 Read） → 故事撰寫者 — 將點子轉化為包含驗收標準的使用者故事（僅限 Read） → 規格撰寫者 — 將故事轉化為技術簡報（僅限 Read） → 後端建構者 — 建構 API、服務、任務、單元測試（僅限後端資料夾） → 前端建構者 — 建構元件、頁面、hooks、UI 測試（僅限前端資料夾） → 測試驗證者 — 根據使用者故事撰寫驗收測試（僅限測試檔案） → 驗證者 — 將實作與故事和簡報進行比較，報告差距（僅限 Read）
3 個人類檢查點： → 批准故事 → 批准簡報 → 批准 PR
其他一切都自動運作。
大多數使用 Claude Code 的開發者仍在直覺式編碼。
提示 → 產生 → 修補 → 祈禱。
這沒有錯。
但它就是個天花板。
工廠不是要把你從流程中移除。
而是要把你從不需要你的部分中移除。
你留在那些你的判斷力至關重要的環節：
這是對的問題嗎？這是對的設計嗎？這個可以安全上線嗎？
Agent 處理中間所有的事情。
這就是把 AI 當作一個更快的鍵盤——
和把 AI 當作一個協同團隊之間的差異。
如果這篇文章對你有幫助：
→ 轉發分享給你的社群 → 追蹤 @sairahul1 獲取更多這類深入解析 → 收藏這篇——你會需要參考這 7 個 Agent 的
我撰寫關於 AI、產品開發，以及在你睡覺時也能運作的系統。
