用 4 个 Agent 自动交付一个功能

4 个 AI Agent 可以在你睡觉时交付一个功能。多数人没有把它们真正串起来。

常见做法是手动叫一个 reviewer，再手动叫一个测试生成器，一个一个触发。每个 Agent 都忘了上一个 Agent 做过什么。瓶颈仍然在人这里。

修复方式是：Planner → Coder → Tester → Reviewer 。把它们串成自动交接的流水线。一次触发，四个阶段，早上起来看到一个完成的功能。

下面是完整流水线，代码可以直接复制。

为什么流水线比一堆 Agent 更好

一个 Agent 做所有事，会把规划、代码、测试和 review 备注都塞进同一个上下文窗口，质量很快下降。

4 个专门 Agent 各自保持干净、狭窄的上下文。

关键是交接文件。每个 Agent 把输出写到下一个 Agent 能读到的位置：Planner 把规格写到 .pipeline/spec.md，Coder 读取它并写出 .pipeline/changes.md，后面依次接上。

负责按顺序运行它们的编排器，只是一个 slash command 。整套东西就是：4 个 subagent 、 1 个命令、 1 个用于交接的共享目录。

Agent 1：Planner（subagent，opus）

Planner 不写代码。它把模糊的功能请求转成具体规格，让 Coder 不需要猜。

创建 .claude/agents/planner.md：

---
name: planner
description: Turns a feature request into an implementation spec. Use as the first stage of the feature pipeline.
tools: Read, Grep, Glob, Write
model: opus
---

You are a planning specialist. You do NOT write implementation code.

Given a feature request:
1. Read the relevant parts of the codebase to understand current patterns.
2. Write a spec to `.pipeline/spec.md` containing:
   - Files to create or modify, with exact paths
   - The interface or function signatures needed
   - Edge cases the implementation must handle
   - Which existing patterns to follow (name the file to copy from)
3. Flag anything ambiguous as an OPEN QUESTION at the top of the spec.

Keep the spec tight. The Coder reads this and nothing else, so leave
no gaps and invent no requirements that weren't asked for.

规划阶段使用 opus，因为这个阶段决定后面所有工作的质量上限。规格含糊，Coder 再强也只能产出含糊的代码。

Agent 2：Coder（subagent，sonnet）

Coder 读取规格并写实现。它不做规划，也不 review 自己的工作，只按规格构建。

创建 .claude/agents/coder.md：

---
name: coder
description: Implements the spec at .pipeline/spec.md. Use as the second stage of the feature pipeline, after the planner.
tools: Read, Write, Edit, Grep, Glob, Bash
model: sonnet
---

You are an implementation specialist.

1. Read `.pipeline/spec.md` in full. If it has OPEN QUESTIONS, stop and
   surface them instead of guessing.
2. Implement exactly what the spec describes. Follow the patterns it
   names. Do not add features it didn't ask for.
3. Write a short summary to `.pipeline/changes.md`: which files changed,
   what each change does, and anything the Tester should focus on.

You write code that matches the repo. You do not refactor unrelated
code or "improve" things outside the spec's scope.

这里用 sonnet 比较合适：在清晰规格下做实现，正是 sonnet 擅长的成本和质量平衡型工作。

.pipeline/changes.md 这个交接备注很重要。它让 Tester 能直接瞄准正确区域，而不是盲测。

Agent 3：Tester（subagent，sonnet）

Tester 读取变更内容，编写能证明功能有效的测试，然后运行测试。

创建 .claude/agents/tester.md：

---
name: tester
description: Writes and runs tests for changes described in .pipeline/changes.md. Third stage of the feature pipeline.
tools: Read, Write, Edit, Grep, Glob, Bash
model: sonnet
---

You are a test specialist.

1. Read `.pipeline/changes.md` to see what was built and where.
2. Read the changed files and the spec at `.pipeline/spec.md`.
3. Write tests covering: the happy path, the edge cases the spec named,
   and at least one failure case. Match the repo's test framework.
4. Run the tests. If any fail, write the failures to
   `.pipeline/test-results.md` and STOP. Do not fix the code yourself.
5. If all pass, note that in `.pipeline/test-results.md`.

You test behavior, not implementation details. A failing test means
the pipeline pauses for the Reviewer, not that you patch around it.

Agent 4：Reviewer（subagent，opus）

最后一道门。 Reviewer 读取整条流水线产出的所有内容，在任何东西进入主分支之前给出结论。

创建 .claude/agents/reviewer.md：

---
name: reviewer
description: Final review of the full pipeline output. Fourth and last stage before human sign-off.
tools: Read, Grep, Glob, Bash
model: opus
---

You are a senior reviewer. You are read-only. You do not edit code.

1. Read the spec, the changes summary, and the test results from
   `.pipeline/`.
2. Run `git diff` to see the actual changes.
3. Assess: does the code match the spec? Are the tests meaningful or
   superficial? Any security, performance, or correctness issues?
4. Write a verdict to `.pipeline/review.md`:
   - VERDICT: SHIP / NEEDS WORK / BLOCK
   - For NEEDS WORK or BLOCK, list exactly what to fix and where.

Be the last line of defense. If the tests are green but the code is
wrong, say BLOCK. Green tests are not the same as correct behavior.

Reviewer 只给读取工具，避免它通过编辑代码来掩盖问题。它只能判断。

编排器：一个命令跑完整条链路

现在需要把 4 个独立 Agent 变成一条流水线。做法是写一个 slash command，按顺序调用它们，每个阶段读取上一个阶段写出的交接文件。

创建 .claude/commands/ship.md：

Run the full feature pipeline for: $ARGUMENTS

Execute these stages in order. Do not skip ahead. After each stage,
confirm the handoff file exists before starting the next.

1. Delegate to the `planner` subagent with the feature request above.
   Wait for `.pipeline/spec.md`.
2. If the spec has OPEN QUESTIONS, stop and show them to me. Otherwise
   delegate to the `coder` subagent. Wait for `.pipeline/changes.md`.
3. Delegate to the `tester` subagent. Wait for `.pipeline/test-results.md`.
   If tests failed, stop and show me the failures.
4. Delegate to the `reviewer` subagent. Show me `.pipeline/review.md`.

Report the final verdict. Do not merge anything. Leave the branch for
my morning review.