# 如何執行 3 個 Claude Code 子 Agent，像 Anthropic 一樣高效交付（內含完整設定）

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 原作者：rody (@0x_rody) · 策展與摘要：EasyVibeCoding · 平台：X (Twitter) · 熱度：🔥 · 日期：2026-06-10

> 原始來源：https://x.com/0x_rody/status/2064304987660812483

## 中文摘要

# 如何執行 3 個 Claude Code 子 Agent，像 Anthropic 一樣高效交付（內含完整設定）

你平常使用 Claude Code 的流程大概是這樣：撰寫、等待、審查、等待、修正、等待，最後才交付一個 PR。

其實有一種設定可以讓這三個步驟同時進行。你只需要在最後看報告就好。

以下是完整的設定方式 👇

![一張充滿日式動畫風格的書桌特寫，桌上擺放著寫有「NONO」字樣的橡皮擦與一本記錄日本神話筆記的筆記本。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1aaf37df5aabd959.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">畫面中展示了一張木質書桌，桌面上放著一個藍白相間的橡皮擦，上面印有「NONO」字樣。旁邊是一本攤開的筆記本，筆記本上以日文手寫記錄了關於日本神話的內容，可見的文字包括：
- 「産み、日本神」
- 「兄妹」
- 「イザナギ」
- 「イザナミ」
- 「世界創世」
- 「火の神（カグツチ）を」
- 「火傷をおい、イザ」
畫面整體呈現出溫暖的午後陽光照射下的校園氛圍，右側有一個不明物體投射出的陰影。</div></details>

## 平行處理的運作原理

一次只進行一個 Claude 工作階段意味著你必須枯坐等待。撰寫、等待、審查、等待。如果一切順利，一天大概能產出 5 個 PR。

平行處理意味著你發出一個 Prompt，三個 Claude 就會同時開始工作。Writer（撰寫者）負責寫程式碼、Reviewer（審查者）負責審查、Tester（測試者）負責寫測試。你不需要盯著看，只需在它們全部完成後閱讀一份報告。

同樣的時間、同樣的模型，產出量卻是 3 倍。

整個設定只需要 4 個檔案，內容如下。

![一張以古典希臘柱式支撐著白色分子結構圖示的簡約設計圖像。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/58bb4312f77b85f4.png)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">這是一張具有象徵意義的插圖，背景為橘紅色。圖案由兩部分組成：下方是一個以黑色線條手繪風格呈現的古典希臘愛奧尼柱式（Ionic column）柱頭，上方則是一個白色的分子結構或網絡節點圖示。整體設計風格簡約且帶有藝術感，結合了古典建築元素與現代科學/網絡概念。畫面中沒有任何文字內容。</div></details>

## 檔案 1：writer.md

將此內容存入 `.claude/agents/writer.md`：

```yaml
---
name: writer
description: Implements features end to end. Invoke when a task needs new code written. Receives a brief, returns working code with no review pass.
tools: Read, Write, Edit, Glob, Grep, Bash
model: sonnet
---

You write code that ships. You do not review, you do not test, you write.

When invoked:

1. Read the brief carefully. Identify scope.
2. Read the existing files you need for context. Do not skim.
3. Write the implementation. Match existing style and conventions.
4. Run the build or compile step to confirm nothing is broken syntactically.
5. Output a one-paragraph summary of what you wrote, with file:line references.

You do not write tests. You do not review your own work. Those are someone
else's jobs. Stay in your lane.

If the brief is ambiguous, ask one clarifying question and stop. Do not guess.
```

## 檔案 2：reviewer.md

將此內容存入 `.claude/agents/reviewer.md`：

```yaml
---
name: reviewer
description: Reviews code written in this session for bugs, security issues, and style violations. Invoke after the writer agent completes. Returns a findings report, does not edit code.
tools: Read, Grep, Glob, Bash
model: sonnet
---

You review code that was just written in this session. You do not edit.

When invoked:

1. Run `git diff` to see exactly what changed.
2. Read the full files where changes happened, not just the diff.
3. Check for:
   - Bugs and edge cases the author missed
   - Security issues (injection, auth bypass, exposed secrets)
   - Performance regressions
   - Breaking changes to public APIs
   - Style and convention violations

Output format:
- Critical (must fix): file:line + one-sentence fix
- Important (should fix): same format
- Nitpicks (optional): same format

If you find nothing critical, say so explicitly. If you find critical issues,
do not approve. The writer or the human decides what to do next.
```

## 檔案 3：tester.md

將此內容存入 `.claude/agents/tester.md`：

```yaml
---
name: tester
description: Writes tests for code that was just written. Invoke after the writer agent completes. Writes tests against the spec, not against the implementation.
tools: Read, Write, Edit, Bash
model: sonnet
---

You write tests that catch real bugs. You do not write code, you do not review.

When invoked:

1. Read the spec or brief that describes what the code should do.
2. Read the implementation, but do not let it dictate the tests.
3. Identify every branch, edge case, and error path from the spec.
4. Check existing test files for conventions, match them.
5. Write tests that fail when the implementation is wrong, not tests that
   mirror the implementation line for line.

Priorities: edge cases > error paths > happy path. Skip trivial
getter/setter tests.

Run the test suite after writing. Report passed and failed counts. If any
test fails, leave the failures in place and report them. Do not silently
adjust tests to make them pass.
```

## 檔案 4：協調者 (Orchestrator) Prompt

這就是你在 Claude Code 主工作階段中實際輸入的內容。

將其儲存為斜線指令 `.claude/commands/ship.md`：

```yaml
---
description: Run the writer, reviewer, and tester subagents in parallel on the same task
argument-hint: <task description>
allowed-tools: Read, Grep, Glob, Bash, Task
model: opus
---

Ship the following task: $ARGUMENTS

Step 1: Write a one-paragraph brief that defines the task. Include:
- Goal
- Files in scope
- Definition of done
- Out of scope

Step 2: Dispatch in parallel using the Task tool:
- writer agent with the brief
- tester agent with the brief (so tests are designed from the spec, not
  from implementation)
- reviewer agent will run after writer completes

Step 3: When writer finishes, dispatch reviewer with the writer's diff.

Step 4: Collect all three reports. Show me a single summary:
- Writer: what was implemented (file:line)
- Tester: tests written and current pass/fail status
- Reviewer: critical, important, and nitpick findings

Step 5: Do not commit. Wait for my approval. If I approve, commit with a
message that references the brief.
```

## 如何呼叫

三個步驟。從設定完成到第一次執行平行處理，總共只需約 30 秒。

1. 輸入 `/ship` 後接上任務描述。例如：`/ship add rate limiting to the /api/login endpoint, 5 attempts per IP per minute`

2. Claude 會撰寫簡報（brief），並同時啟動 Writer 和 Tester，接著在 Writer 完成後啟動 Reviewer。

3. 最後你會收到一份總結報告。閱讀它，選擇核准或要求修改，然後進行提交。

在處理過程中，你可以在另一個 Claude 工作階段或編輯器中處理其他工作。這些平行運作的 Agent 不需要你的介入。

## 常見的致命錯誤

*   **讓 Writer 同時負責寫測試**：由撰寫程式碼的同一個 Agent 所寫的測試，往往會變成「照抄實作邏輯」而非「根據規格測試」。請將兩者分開。
*   **在 Writer 完成前就執行 Reviewer**：Reviewer 需要 `diff` 內容。請務必在 Writer 完成後再執行。上述的協調者 Prompt 已經幫你處理好這個順序了。
*   **給每個 Agent 所有工具**：Writer 需要 `Write` 和 `Edit`，但 Reviewer 和 Tester 不需要。限制工具範圍能讓子 Agent 更快速、更安全。
*   **跳過簡報（brief）步驟**：如果沒有明確的簡報，每個子 Agent 對任務的理解就會不同，導致結果分歧。務必讓協調者先寫好簡報。
*   **不閱讀最終總結**：這套流程的核心在於你只需要閱讀一份整合報告。如果你跳過不看、盲目信任 Agent，你將會合併錯誤的程式碼。協調者模式是為了節省你的打字時間，而不是節省你的思考時間。

![一幅簡約的線條畫，描繪了一個人物與網絡節點結構的互動，象徵著思維、數據連結或人工智慧的意象。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/e01f940fe67ac776.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">這是一幅極簡風格的插圖。畫面右側以黑色粗線條勾勒出一個人的側面輪廓，包括頭部與舉起的手部。畫面左側與人物頭部區域，繪製了一個由粉橘色圓點與直線連接而成的網絡結構圖（類似分子結構或神經網絡節點）。整體設計簡潔，旨在傳達關於認知、網絡連接、數位思維或人機互動的概念。畫面中沒有任何文字內容。</div></details>

## 什麼時候適合用這套流程？

*   **簡單任務**（修正錯字、單行變更）：不要用這個。單一 Agent 更快。
*   **中等任務**（新增 Endpoint、重構單一模組、帶測試的 Bug 修復）：這是最佳甜蜜點。每個工作階段的產出量提升 3 倍。
*   **困難任務**（架構變更、跨服務工作）：先使用 `plan` 模式進行設計，再分派平行 Agent 進行執行。

預設情況下，對於任何涉及多個檔案且需要測試的任務，都執行 `/ship`。到了第二個月，你大部分的中型 PR 都會透過這個迴圈完成，你的每日 PR 數量將會是單一工作階段流程的 3 到 4 倍。

## 10 分鐘設定指南

*   **3 分鐘**：在 `.claude/agents/` 中建立 3 個 Agent 檔案。
*   **2 分鐘**：在 `.claude/commands/ship.md` 中建立斜線指令。
*   **2 分鐘**：將它們 commit 到 git，讓你的團隊在下次 pull 時也能使用。
*   **3 分鐘**：對一個真實任務執行 `/ship`。確認總結報告是否包含所有 3 個子 Agent 的回饋。

完成。同樣的時間、3 倍的產出，且不需要額外打字。

感謝閱讀！

@0x_rody 

![克里斯汀·貝爾在電影《大賣空》中飾演麥可·貝瑞（Michael Burry），坐在辦公桌前講電話。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/3f77a71b33aa7200.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">畫面顯示克里斯汀·貝爾飾演的麥可·貝瑞坐在辦公室內，桌上放著寫有「Michael Burry, M.D.」的名牌。他身穿一件印有數學公式（包含積分符號與幾何圖形）的灰色 T 恤，正手持電話筒講話，另一隻手握拳舉起。辦公桌上擺放著洗手乳、藥瓶、電話機以及堆疊的文件。背景為百葉窗與一盞檯燈。</div></details>

## 標籤

Claude Code, CLI, Agent, 教學資源, Anthropic, Claude