# 工作流：测试驱动的智能体开发

> 先写失败测试、再提交测试、再让智能体实现并让它不得修改测试，最后由独立会话评审，用可执行的检查替代人盯人，适合需求明确的功能。

## 适用场景

需求清晰、输入输出能写成例子的功能，比如校验函数、计费规则、格式转换、接口行为。这类任务最适合「先写测试」：测试就是验收标准，智能体可以自己运行、自己迭代，不需要你每步盯着。

官方最佳实践的第一条就是给智能体一个可以验证自己工作的办法。没有这个办法，「看起来写完了」就是它唯一的判断依据，你会成为那个验证回路。

## 模板

四步，每步一个新提示词：

```text
# 第 1 步：只写测试
根据下面的需求，为【模块或函数】编写测试。现在只写测试，不要写任何实现代码，
也不要创建被测函数的占位实现以外的东西。
需求与示例：
- 【例子 1：输入 → 期望输出】
- 【例子 2：边界情况】
- 【例子 3：错误情况，期望抛出什么】
要求：沿用项目现有测试风格；用例名描述行为；覆盖正常、边界、异常三类。
写完后运行测试，确认它们因为「功能尚未实现」而失败（而不是因为测试本身有错），贴出输出。

# 第 2 步：你检查并提交测试
（你自己读一遍测试，修改不合理的断言，然后提交，提交信息以 test: 开头。）

# 第 3 步：实现
现在实现功能，让上面的测试全部通过。规则：
- 不允许修改、删除、跳过或放宽任何测试。如果你认为某个测试本身有问题，停下来告诉我。
- 先做最简单能通过的实现，再整理代码；每次改动后运行测试。
- 全部通过后，再运行完整的测试套件、Lint 和类型检查，贴出真实输出。

# 第 4 步：独立评审
（新开会话或交给子智能体。）请对照需求评审这次实现：测试是否真的覆盖了每一条需求；
实现里有没有测试没覆盖到的分支；有没有为了通过测试而写死特殊值。
只报告影响正确性或需求的问题，给出证据。
```

## 怎么用 / 怎么改

1. **第 1 步的失败很重要。** 如果测试一开始就是绿的，说明它没有测到新行为。必须让它因为正确的原因失败。
2. **你要读测试。** 测试是规格，智能体写的断言可能和你的意图不同。这是整个流程里人最该花时间的地方。
3. **把检查变成关卡。** 想让智能体在测试没通过时不能收工，有几种方式：在同一条提示词里写「运行测试并持续修复直到通过」；用 `/goal` 设置完成条件，由独立的评估器每轮复核；或者配置 Stop hook，在它想结束时运行你的检查脚本，失败就阻止结束。
4. **分工写测试与实现。** 官方还提到一种做法：一个会话写测试，另一个会话写代码去通过它们，让两边互相制衡。
5. **UI 与脚本类任务。** 没法写单元测试时，用其他可执行的检查代替：构建退出码、对照样例的脚本、浏览器截图和设计稿对比。

## 常见问题或注意事项

- **智能体改了测试让自己通过。** 第 3 步明确写禁止，并在合并前单独查看测试文件的 diff。更保险的做法是在 PreToolUse hook 里拦截对测试目录的编辑，退出码 2 表示阻止并把原因反馈给智能体。
- **实现靠写死答案通过。** 例子太少会鼓励这种作弊。补充不同数据的用例，或者要求测试里用随机化或表驱动输入。
- **Stop hook 可能反复阻止。** 官方对连续阻止的次数有上限，用于兜底；检查脚本本身要稳定、快速，别在里面跑很久的全量测试。
- **评审仍然需要。** 测试全绿只说明满足你写下的例子。独立评审关注的是例子之外的缺口。
- **别用在探索性任务上。** 需求不明确时，先用提问或计划模式把问题想清楚，再写测试。