指揮 Claude Code 打大型戰：把它當成「CEO + 工程師 + QA」的接力賽，而不是一個全能聊天機器人

你有沒有遇過這種狀況：

• Claude Code 很自信說「完成了 ✅」

• 你一跑測試，紅到像聖誕樹

• 你回頭看才發現：它不是不會寫，而是從一開始就「理解錯」

我對這件事的看法一直很簡單：大型複雜任務不是靠更長的 prompt 解決，而是靠更好的工作流治理。

最近看到一篇實戰文（講怎麼指揮 Claude Code 用少量時間處理大型複雜任務），我覺得方向很對：

把 Claude Code 當成一個「會分身的組織」，你要做的是設計角色與交接，而不是陪它一路腦補。

https://blog.ray-realms.com/command-claude-code-to-conquer-complex-tasks/

我用自己的語氣把重點整理一次，順便補上我覺得更可落地的地方。

## 先講結論：大型任務有三座山，分別要用三種機制壓住

### 1) 上下文管理（context 爆炸）
當任務大到超過模型的舒適區，你塞再多資料進去，它也不會更聰明，只會更分心。

解法不是「放更多」，而是「切更乾淨」。

### 2) 一步錯、步步錯（目標偏移）
大型任務最可怕的是：你讓它跑了 30 分鐘，最後才發現方向歪了。

解法是「每段都可驗證」，不接受一次交付一大包。

### 3) 狀態追蹤與錯誤恢復（交接失真）
多階段、多 agent 會讓上下文彼此分離，但也會帶來新的問題：交接不清楚就會累積技術債。

解法是「標準化交接包」，讓下一棒不用通靈。

## 把 Claude Code 當成「CEO + 分工工程師 + QA」

Ray 的核心做法我很喜歡：讓 Claude Code 擔任 CEO，然後召喚 Sub-Agents（分身）去做不同階段。

這個比喻其實很貼近真實專案：

• CEO 不需要寫每一行 code，但要負責「拆任務、排順序、控風險」

• 工程師不需要懂全局，只要把自己那一段交付好

• QA 不需要討論願景，只要確認「有沒有符合合約」

你在做的不是“找一個更聰明的模型”，而是“設計一間比較不會出事的公司”。

## 1）先解耦：介面先於實作（Interface-first）

大型任務最常見的災難是耦合：

• 後端寫了一套 API

• 前端用另一套方式 call

• 最後兩邊都很努力，但就是接不起來

所以我很認同「預備階段」：

• 先派一個 Agent 定契約（API 文件 / schema / error policy）

• 後續前後端/不同子任務全部照契約施工

這一步的價值是：你把「對齊」提前做完，後面才有資格平行/分工。

定契約不是慢，是把未來的返工提早一次做掉。

## 2）再接力：一次只讓一個人改同一個地方

Ray 提到一個很反直覺但很重要的點：

分身可以很多，但一次只讓一個分身真的動手。

理由很現實：

• 兩個 agent 同時改同一個檔案，衝突/覆蓋是必然

• 大型任務的風險不是「跑得慢」，是「錯得很安靜」

所以比較穩的方式是接力賽：

• 一次只交付一個階段

• 階段完成 → 交接包 + 驗證證據 → 才交棒給下一位

這會讓你的人類監督成本下降，因為你只需要逐段檢查，不用一次看一個混雜的 commit 大包。

## 3）再加 QA：每個階段後都要有「證據」

我非常同意「每個階段都要加 QA Agent」。

但我會把 QA 的任務說得更硬一點：

• 沒有證據，不算完成。

這裡的證據，最好是可機器驗證：

• tests（unit / integration / e2e）

• typecheck / lint / build

• schema validation

我也建議加一條規則：

• 不接受「手動測試說明」當成驗收

不是因為手動測試沒用，而是因為你在做長流程接力賽，手動測試很難被下一棒信任、也很難被重複。

## 我會補一個更可落地的「交接包」模板

很多 multi-agent 流程會失敗，不是因為寫不出來，而是交接時資訊失真。

我會強制每一段產出一份交接包（很短也沒關係）：

• What changed：改了什麼（檔案/模組/介面）

• Why：為什麼這樣改（trade-off / 假設）

• How to verify：怎麼驗證（指令/測試/預期結果）

• Known risks：目前知道的風險與未處理事項

• Next step：下一棒要做什麼（含依賴）

這份交接包，不只讓下一個 agent 少猜，也讓你這個人類更容易接管。

## 一句話的收尾：你要做的不是寫 prompt，而是做治理

「vibe-coding」可以是起點，但大型任務需要的是：

• 合約（contract）

• 脈絡（context）

• 證據（evidence）

• 交接（handoff）

把這四個東西做對，模型不需要完美，你的交付也會變得可靠。

#AI #ClaudeCode #CodingAgents #SDD #ContextEngineering #軟體工程