写测试提示词：先找行为，再写用例

这页适合已经能看懂一点代码的人。写测试前，先让 AI 找行为，不要直接堆测试代码。

先别做什么

• 不要为了覆盖率让 AI 乱写测试。
• 不要先改业务代码再猜测试。
• 不要新引入测试框架，除非项目本来没有测试方案。
• 不要让 AI 一次性补全整个项目测试。

可复制提示词

请先阅读相关代码，不要直接写测试。

我要为这个功能补测试：{功能名称或文件路径}

请先告诉我：
1. 当前功能的输入是什么
2. 当前功能的输出或可观察行为是什么
3. 哪些边界情况值得测试
4. 项目现有测试文件在哪里
5. 项目现有测试风格是什么
6. 应该新增测试还是修改现有测试
7. 最小测试用例列表

等我确认测试用例后，再写测试代码。

确认后再发：

可以写测试。请遵守：
1. 优先沿用项目现有测试框架
2. 只覆盖刚才确认的最小用例
3. 不改业务逻辑，除非测试暴露了明确 bug
4. 写完后告诉我如何运行这一组测试

成功标志

• 测试能对应真实输入、输出或页面行为。
• 测试数量少但能覆盖关键边界。
• AI 没有为了测试大改业务代码。
• 运行命令明确。

常见错误

• 测试目标太模糊：例如“给项目补测试”。
• 没有先看现有测试风格。
• AI 新增了不必要的测试依赖。

下一步

测试写完后，用 代码审查提示词 让 AI 检查是否影响无关功能。

来源与日期

• 来源：作者实战模板。
• 分享日期：2026-06-16。
• 复测日期：2026-06-16。