一人開發怎麼用AI團隊？Claude Code分工與上版審查

一個人開發網站，我的做法是把 Claude Code 組成一支 AI 團隊。我當 CEO 定方向，主對話當工程總監拆任務、派工，底下 6 個代理各管一段工作。每個任務都走「提案、批准、執行、回報」；提案沒批准不寫程式，上正式站每一批都要我明說。

這篇記錄豪享生活這套 AI 協作開發流程怎麼分工、怎麼運作，以及上版前審查擋下與沒擋下的問題。網站本身的技術架構，寫在個人網站怎麼架。

一個人開發，為什麼要用團隊的方式和 AI 合作？

因為寫程式的和檢查程式的，不能是同一個。只用一個對話從需求做到上版，寫的人自己審自己，盲點也會一樣。

我把工作拆成角色以後，得到三個好處：

• 範圍變小：每個代理只拿到自己那一段需要的規則與資料，交出固定格式的成果。
• 寫和審分開：審查員只寫報告、不改程式，找到的問題不會被自己的修法蓋過去。
• 可以平行：契約簽核後，前端和後端同時做；跨 repo 的改動，各 repo 同時審。

我自己只留兩件事：決定要做什麼，以及決定能不能上線；「怎麼做」交給團隊。

2026 年 4 月初，我把團隊的設定獨立成一個 repo，角色、流程與 skill 都寫成檔案、用 git 管版本。每個產品都照同一套規則做。

Claude Code 的 AI 團隊怎麼分工？

團隊分成三層：我是 CEO，主對話是工程總監，底下是 6 個代理。工程總監負責拆任務與派工，不自己把所有事做完。

AI 團隊的三層分工：我定方向，總監拆任務，代理各做一段

AI 團隊的角色與分工

要做判斷的角色用 Opus，照規格動手的角色用 Sonnet。

一個任務怎麼跑？提案、批准、執行、回報

我給方向，工程總監拆成任務，每個任務都照同一個循環走：

1. 提案：工程總監說明要做什麼、為什麼做、打算怎麼做。
2. 批准：我看過提案，同意才動工；不同意就退回重寫。
3. 執行：工程總監派工給對應的代理，代理交件後先驗收。
4. 回報：做了什麼、驗了什麼、還有什麼沒做，一次講清楚。

每個任務的循環：兩道閘門都要我明說才能過

小修改走比較短的 6 步流程，新功能、新產品才走 10 步的大流程。

哪兩道閘門一定要我點頭？

第一道是「提案沒批准，不寫程式」；第二道是「上正式站，每一批都要我明說」。這兩道是硬閘門，沒有例外。

第一道閘門擋在動工前。 AI 寫程式很快，方向錯了，也會很快寫出一大批。在提案階段改方向，只要改幾行字；程式寫完再改，就要整批重來。

第二道閘門擋在上線前。 正式站有真實的使用者與資料，「代理覺得沒問題」不等於我同意上線。所以每一批上正式站，都要我在對話裡明說同意。

授權也不延續。我說過「影片都可以上傳」，不代表同意排程公開；上次同意上正式站，也不代表這次可以。

文章也照同一條規則：一律先發草稿，先發到本機給我看，我回「發佈」才上正式站。

大功能怎麼做？10 步與契約先行

新功能照 10 個步驟走，每一步有固定的負責角色：

1. 需求：PM 寫需求文件，彙整動工前要問我的問題。
2. 畫面設計：先定好使用流程與畫面。
3. 架構與契約：架構師做系統設計，寫出 API 契約與資料表。
4. 後端：契約簽核之後，後端照契約實作 API 與單元測試。
5. 前端：同樣等契約簽核才動工，照契約和設計做畫面。
6. 審查：審查員審正確性，並做資安檢查。
7. QA：跑整合測試，實際操作關鍵情境。
8. 文件：更新說明文件。
9. 上版：過上版前審查，等我同意。
10. 驗收：PM 站在使用者的角度驗收。

契約先行的意思是：API 長什麼樣，先寫成契約、簽核，前端與後端才動工。契約定了，前後端可以同時做，接起來時不會才發現欄位對不上。

做到一半卡住時，代理開一張問題卡，分三級處理：

• L1：代理自己能解決，解完繼續做。
• L2：設計有問題，退回架構師改契約或設計。
• L3：需求有問題，退回 PM 重新釐清。

代理說做完了，怎麼驗收？

代理說「做完了」，不等於做完了。所以交件要過三層檢查：檔案在不在、內容是不是實質的成果、必查清單有沒有逐項過。

QA 也一樣，要實際跑過關鍵情境，並留下跑過的證據。只回一句「測試應該會過」，不算驗收。

新產品另外有一份上線手冊。2026 年 9 月底豪享算命上線後，我把那次的流程整理成手冊，附上踩雷表；之後的新產品照同一套骨架上線。

上版前審查看什麼？

每一批改動都要先過上版前審查。審查只讀程式、只寫報告，不改程式也不 commit。重點有五個：

• 自動檢查先過：CI 的檢查腳本沒過，就不進審查。
• 畫面看 6 種組合：有畫面改動，就在電腦、平板、手機上，各看深色與淺色。
• 跨 repo 一起審：一次改到幾個 repo，每個 repo 各派審查員平行審；動到共用的事件格式，再檢查各 repo 的約定一致。
• 嚴重問題要投票：BLOCKER 與 High 等級的問題，要 3 個不同角度的驗證者投票，過半才算成立。
• 碰到個資或登入必做資安：改動碰到使用者資料或登入，一定加做資安檢查。

審查員也會誤判。嚴重問題一成立，整批就要停下來修，所以要多數同意；Medium 等級由一個驗證者確認。這樣可以避免為了誤報改一堆地方。

2026 年 9 月底起，每次審查都留下紀錄，之後遇到類似改動可以回頭查。

審查過了，程式怎麼上線？

審查過了、我也同意後，程式照固定的分支走：

1. dev：平常的開發都在這裡。
2. production：合併進來才會部署到正式站。
3. main：我確認線上沒問題，才合回 main。

這樣 main 一直是「上線驗證過」的版本。正式站出問題時，手上有一個確定沒問題的版本可以對照。

上版流程：審查投票過了、我同意，才合進 production 部署

上版前審查擋下了哪些問題？

審查最常擋下的，是「功能做對了，卻弄壞別的地方」。下面的例子都在上版前修掉。

上版前審查擋下的例子

這些例子都碰到正式資料或權限。我從這裡學到：會改正式資料的程式，要先備份、先試算，而且只跑一次。

審查沒擋下的問題，後來怎麼補？

審查看的是程式碼與設計，有些問題要到正式環境才會出現。下面兩個坑，都是上線後才發現。

跨 repo 約定沒對齊，情境圖默默寫不回去

• 情境：豪享學英文的單字情境圖在本機批次產生，再寫回正式機。
• 問題：API 路徑改版後，另一個 repo 的呼叫端沒有跟著改，情境圖的回寫默默失敗。
• 判斷：兩邊各自看都沒錯，錯在兩個 repo 之間的約定。只看單一 repo 的審查，抓不到這種問題。
• 做法：上版前審查加上跨 repo 檢查，一次改到幾個 repo，就一起審。
• 學到的：契約不只在前後端之間，任何兩支互相呼叫的程式都需要。

審查都過了，夜盤一跑 K 棒併成一根

• 情境：豪享看股票改了即時 K 棒的程式，審查判斷改法沒有問題。
• 問題：上線後夜盤一開始跑，整段時間的報價被併成一根巨大的 K 棒。
• 判斷：審查的判斷是對的。即時資料的行為，要開盤後報價進來才看得到。
• 做法：即時相關的改動，一律在開盤時段實測過，才上版。
• 學到的：讀程式能找出邏輯錯誤，找不出「真實資料長什麼樣」的問題。

第三方 skills 為什麼不直接裝？

• 情境：Claude Code 可以裝別人寫好的 skill，網路上有很多現成的。
• 問題：我審過幾個，有的會自動回傳資料，有的會自動抓最新版，有的把權杖用明文存起來。
• 判斷：skill 會改變代理做事的方式，裝進來等於讓陌生人的規則進入開發流程；會自動更新的，今天審過、明天就可能不一樣。
• 做法：先審查，只萃取有出處的知識，用自己的話寫成自己的 skill，附上來源與授權。
• 學到的：要的是裡面的知識，不是整包程式；授權條款也要一起看。

常見問題

Q1：一個人用 AI 開發，每件事都要分這麼多角色嗎？

不用。小修改走比較短的 6 步流程，新功能、新產品才走 10 步。角色分工最大的價值，是讓寫程式的和審程式的分開。

Q2：AI 代理會自己把程式上到正式站嗎？

不會。程式合併進 production 分支才會部署，而每一批上正式站都要我明說。前一次的同意，不延續到下一批。

Q3：Claude Code 的子代理和 skill 差在哪？

在我的用法裡，子代理是一個角色，有自己的說明、工具與模型，派出去做完一件事再交件。skill 是一份做事規範，例如寫作規範或上版前審查流程，誰要做那件事就先讀那一份。

延伸閱讀

• 部落格開發紀錄：部落格從網址、留言到 9 月大改版的開發經過
• 個人網站怎麼架？Next.js、Go微服務、部署與發文流程：前端、Go 微服務與部署架構
• 豪享生活部落格能做什麼？找文章、讀系列、收藏留言與RSS訂閱：部落格目前有哪些功能