實戰分享我是怎麼指揮 Claude Code 用少量時間征服大型複雜任務
這篇文章，我會向大家教學我是如何指揮 Claude Code 優雅的處理大型複雜任務
如何用一個提示詞快速搭建出一個上線的電商網站，當然這是我本人的實戰經驗，它並非完美，歡迎大家討論。
這並不是一堂教你用 10 分鐘做出一個工具的課程；
相反地，這是一篇硬核實戰文，專門寫給已經具備 AI 實戰經驗、且不滿足於寫玩具程式的開發者。
開發一個產品前要先做什麼？先寫文件，將你大腦裡抽象的想法沉澱為文字。
這裡的文件有很多種寫法，其中比較著名的就是 SDD（規格驅動開發）。
如果可以的話，我們要將需求寫得盡可能完整。不只是簡單地寫一句「要有註冊功能」就好，而是以寫成類似使用者故事（User Story）的格式，附上具體的驗收標準，並儘可能覆蓋各種情境
當然，由於 SDD 的教學網路上已相當豐富，因此本文不再贅述細節。但我必須強調：文件是專案的靈魂，它是接下來所有 Agent 開發時唯一依循的真理、整個專案的燈塔、一切的指標，接下來的開發都會基於這份文件為基石而做搭建。
有了這份基石，接下來讓我來講講讓優雅的指揮 Claude Code 開發超大型任務。
現在我們面前有幾座大山。
首先第一座大山，就是所謂的「上下文管理」的問題。
目前的 Agent 在面對超過 7 萬 Token 以上的上下文通常都會面臨巨大的精確度崩潰。
在過去，我們必須手動將任務切割成一個一個階段，再分別交由 Agent 去處理。但在現在，這顯然也是一件很耗時耗力的事情。
再來第二座大山，在面對超大型任務的情況下，Agent 很容易一步錯、步步錯。
尤其是你的「目標」與 Claude Code 理解的目標可能有巨大偏差時，最後 Claude Code 開發完的東西可能根本不能用，而講的太細會導致過多時間被浪費。
第三座大山，狀態追蹤與錯誤恢復
為了能開發大型任務，我們必然需要分割成無數的階段讓各自的 Agent 互相處理。要如何確保下一個階段的 Agent 能夠順利承接上一個階段的狀態？Agent 是否能自動發現問題或錯誤，並確保當前的工作成果，能與下一個階段的認知對齊？這將直接決定 Claude Code 在長流程中的準確度。
還記得我們的目標嗎？
只透過一兩次 Prompt 就讓 Claude Code 能完全靠自己做好一件很難的事情，盡可能減少人類的參與。
所以在這次教學當中，我會在最後附上一個 Prompt，讓大家可以直接用一個提示詞就快速做到這件事情。
Claude Code 的分身槌
首先，為了剷除上頭提到的三座大山
我們需要使用 Claude Code 最重要的技能 Sub-Agent
簡單來說，Claude Code 本身具備「召喚自己」的能力，它可以創造出自己的分身。每個分身（Sub-Agents）都擁有獨立的上下文窗口，且彼此互不干擾。
基本上很類似於多啦 A 夢的分身槌，可以創造自己的分身來做不同的工作
善用這個機制，我們只需要設計一個 Agent 他可以自己把大任務切成好幾個小任務，並且自己把任務外包給其他小 SubAgent，這就很大程度的減少的個體的工作負擔
我自己會覺得這很像開設一間公司
一人公司就是會遇到我剛剛提到的問題：「腦力不足」，所以我們需要讓老闆能夠根據情境找適合員工來工作。
現在，請讓我們的 Claude Code 扮演成 CEO，他自己一個人的腦力是不足的，他需要能夠把任務拆解並分送給其他人才行。
我們的第一部分就要能夠讓 CEO 能夠把任務切成好幾個階段，然後將每個階段各派給一個員工做事
- 對與 CEO 來說，他只需要負責切割階段、然後把任務外包給其他人就好，實際怎麼幹的？CEO 不需要知道
- 對於 實際幹活員工 來說，他只要在意他收到的任務並處理好他即可，至於其他階段的事？那是其他人的工作，他不需要知道。
讓我們以底下這張圖為例
首先，第一個做事的是 CEO Agent，他收到的任務是「電商網站開發」。而他的任務只有兩點：
- 將總任務拆解成數個順序合理的子任務
- 將每個階段派遣（派遣）給一個 AI 去執行
在這張圖片中，這個「電商網站開發」被 CEO 拆解成 4 個任務，被個別四個 Agent 處理
但只是單純把任務外包給四個人還不夠，因為我們還要解決兩個棘手問題：『依賴性』與『耦合』。
第一是『依賴性（Dependency）』帶來的順序問題：
一樣還是剛剛的電商的例子，今天假設要開發貨運與金流這兩個系統，但你不可能在用戶還沒付錢時就安排送貨，所以在程式的設計上需要注意開發的先後順序，這當然直接考驗著 CEO 如何安排任務的「先後順序」。
第二則是更麻煩的『耦合（Coupling）』問題：
這在前後端開發中最常見。前端 Agent 開發畫面時，必然需要呼叫後端的 API。 如果 CEO 只是單純切割成『後端開發』與『前端開發』兩個階段，很容易發生一個慘況：後端寫他的 API，前端寫他的 Call 法，結果最後兩邊完全接不起來。
這就是為什麼我強調要有一個 『預備階段』。 針對這種會互相耦合的任務，CEO 必須具備 『介面先於實作』 的概念。我們先派一個 Agent 專門把 API 文件（契約）定下來，後續的前後端 Agent 就全部依照這份文件施工，互不干擾卻能完美對接。」
以剛才的例子來說：
(a) 第 0 階段（預備階段）：專門派遣一個 Agent 撰寫 API 文件。
(b) 第 1 階段（前端開發）：基於第 0 階段定義的 API 文件進行開發。
(c) 第 2 階段（後端開發）：同樣基於第 0 階段設計的 API 進行實作。
在設計階段時要知道哪些階段會互相耦合，並提前在之前先多設計一個階段來做預備，確保之後的工作都可以基於其之上做開發。
透過這種方式，我們確保了介面設計永遠優先於實際撰寫，讓後續階段能有所依據，確保開發流程的順暢。
規劃已經有了，但我們必須確保第 1 階段與第 2 階段的 Agents，是真的有依照第 0 階段 Agents 所定義的 API 文件去做開發。
因此，我強烈建議在每個階段開發完後，額外增加一個檢查階段。具體做法是：
在任何階段開發完成後，CEO 應該多派遣一名「品質檢查員 Agent」進行檢查。
這個檢查階段主要有兩個核心目標：
- 確保執行正確： 確認該階段 Agent 的產出，確實符合 CEO 的任務要求。
- 確保文件對齊： 確認工程師有沒有乖乖照著『第 0 階段』的 API 文件寫，而不是自己發明新規格。
如果 QA 發現產出不合格，會將錯誤報告回報給 CEO，讓 CEO 可以在錯誤雪球越滾越大以前特別指派 Agent 修正，再繼續下一階段。
透過 Claude Code 的 Sub-Agent，我們讓每個人各司其職，在平均分配每個人的任務的情況下，完成了一項大型任務
但這裡有一個反直覺的關鍵：雖然 Sub-Agent 可以同時工作，但我強烈建議一次只讓一個工程師分身工作。
在實際的 AI 開發上，平行處理往往是災難的開始。如果讓兩個分身同時改同一個檔案，很容易產生程式碼衝突或邏輯覆蓋。 為了確保產出的穩定性，我們寧可慢，也要穩。我們採取『接力賽』的形式，一次只派遣一個工程師 Sub-Agent 專注處理一個階段，完成後再交棒給下一位。
最後再複習一下。CEO 的工作到底是什麼？
CEO 的工作就是將一個大型任務拆解成無數個小階段，並確保階段與階段之間不衝突。
如果後面的兩個工作之間可能會有衝突，就必須在這兩個工作前面多加一個「預備階段」來對齊後續階段之間的認知。
讓每個階段只專注在做他該做的事情，且為了確保任務確實完成，每個階段後都應該增加一個「品質檢查員」（Quality Inspector）。
品質檢查員的職責非常明確，就是確保兩件事：
- CEO 的工作有被落實。
- 前面預備階段的文件有被對齊。
基於這樣的邏輯，CEO 只需要專注於切割任務。最後切出來的任務基本上就能順著流程執行，每個階段各自派遣一個 Agent 去開發即可。
還有一個最重要的事情：還記得我們剛剛最早提到的「三座大山」當中的第二座大山嗎？
Agent 很容易一步錯、步步錯，我非常建議大家在做開發以前，先與 AI 同步認知
請他完整讀過你的文件以後，先不要馬上開始開發，你跟他說一句：
「先不要寫程式，請進入『對齊認知』階段，請複述一下你目前對這個專案的完整理解。」
等 Agent 與你的想像同步後再開始工作
恭喜你，現在最大的問題已經不是開發了，而是我要需要理解 Agent 到底做了啥。
但告訴你一個好消息，只要 CEO 在規劃時已經將這些階段切割得很乾淨，順序、耦合問題都處理得很好，我意外發現，我們只需要順著 CEO 的規劃，從第一階段到最後一個階段依序閱讀每個階段的任務，大概就能掌握整個 AI 的開發歷程與流程，並對整個系統有初步的理解。
所以只要前期的 CEO 角色切割得足夠好，其實也對我們人類接管專案很有幫助。
我自己很建議讓每一組 Agent 除了開發工作以外，在開發完成後都應該寫一份 Log（日誌），講述他們之前做了什麼。
這份紀錄除了方便人類理解，也可以作為後續階段 Agent 開發時的依據。
當然，目前也不可能做到 One Shot，但根據上頭的方法可以透過一個提示詞，快速實現一個項目 70~80% 的功能，比過去的開發時程被快上許多。
可以直接貼上的提示詞
最後，讓我撰寫一份完整的提示詞給各位。
提示詞 ->
Ray 貓
另外這篇文章的所有插圖都是用我開發的一個工具製作的
如果今天你想在一分鐘內替一篇文章生成好幾十頁的資訊插圖或簡報
那這個工具也許能幫上你
選取一段文字，選一個好看風格以及想要的圖片
幾秒鐘後，一張好看、邏輯正確的高質感簡報圖就出來
如果對本工具有興趣，幫我填個表單
https://forms.gle/oYszyoFnwwutcVZA7