提示词：为现有代码补测试

适用场景

一段已经在跑的代码没有测试，你想在重构或加功能之前先把它「钉住」。智能体写测试很快，但常见的失败方式有三种：测试风格和项目不一致；只覆盖顺利路径；写出来的测试永远通过，改坏代码也不红。

这份提示词让它先学项目已有的测试写法，再有针对性地补，最后用「故意改坏代码」来验证测试的价值。

模板

目标：为【文件或函数路径】补充单元测试。不要修改被测代码；如果你认为被测代码有 bug，
先停下来告诉我，不要自己改。

步骤：
1. 读取被测代码，列出它的所有分支、边界和异常路径。
2. 阅读项目里 2 到 3 个现有的测试文件，总结：测试框架、文件命名和位置、
   夹具与 mock 的用法、断言风格。新测试必须与它们一致。
3. 运行现有测试（只跑相关文件），记录基线结果，并说明当前覆盖了哪些、没覆盖哪些。
4. 给出准备补充的用例清单，按三类分组，等我确认后再写：
   - 边界：空值、零、最大最小、重复、顺序、时区和编码。
   - 异常：非法输入、依赖失败、超时、权限不足。
   - 回归：已知出过问题的场景（见下面「已知问题」）。
5. 我确认后实现用例。要求：
   - 用例名描述行为，例如 `返回空列表当用户没有订单`，不要叫 test1。
   - 每个用例只验证一件事；断言要具体，不要只断言「不抛异常」。
   - 尽量使用真实对象，只在访问网络、时间、随机数、外部服务时才用 mock。
   - 不依赖用例执行顺序，不共享可变状态。
6. 运行新增测试和相关的全部测试，贴出真实输出。
7. 变异检查：挑 3 处关键逻辑，临时把代码改坏（例如把 > 改成 >=、删除一条校验），
   确认至少有一个新测试因此失败；每次检查后立刻还原。最后用 git diff 证明被测代码没有任何改动。

已知问题（可选）：【出过哪些 bug，或需要特别保护的行为】

怎么用 / 怎么改

• 在支持 @ 引用的工具里，用 @路径 把被测文件和一个有代表性的现有测试文件直接带进对话，比让它自己搜索更快更准。
• 想先看清缺口，可以把第 4 步之后的内容暂时删掉，只做「找出没有测试覆盖的函数和分支」。这也是官方常见工作流的第一步。
• 项目已有覆盖率工具时，在第 3 步补一句「用 【覆盖率命令】 获取覆盖率，并只关注与业务相关的未覆盖行」。
• 前端组件测试可以追加「用用户视角的查询方式（按角色、文本）断言，不要依赖内部实现细节」。

常见问题或注意事项

• 测试为了通过而照抄实现。 比如把被测函数的算法在测试里再写一遍。要求用手算的期望值或固定样例做断言。
• mock 太多，测的是 mock。 看到一半以上代码都在搭 mock，说明被测单元耦合重，应该去补集成测试，或者先做小的重构。
• 运行很慢。 开发期间只跑相关文件，最后再跑全量。可以把这点写进项目的 CLAUDE.md。
• 变异检查必须还原。 每次故意改坏之后立即恢复，最后检查 diff，这一步很容易被智能体遗漏。
• 不要追求 100% 覆盖率。 有价值的是覆盖了关键分支和失败路径，凑数的测试只会增加维护成本。