Cursor 最大的风险，不是“写不出来”，而是“写得像对，但你没法证明它真的对”。
这就是为什么测试要前置。不是因为测试更学院派，而是因为它给 AI 任务加上了可验证边界。
建议先一起看 Vitest 与 Jest 对比、Cursor 最小回归集、Cursor 代码生成回归测试 和 单元测试最佳实践。
先给结论：先写测试目标，AI 才知道什么叫完成
如果没有测试或断言，AI 只能靠“看起来合理”生成实现；而工程任务里，真正需要的是：
$$ 可运行输出 + 可验证边界 + 可回归行为 $$
测试的作用，就是把“可验证边界”补上。
一、为什么先写断言，比先写实现更适合 AI 协作
你让 Cursor 直接写实现，通常会出现两类问题：
- 主路径能跑，但边界条件没覆盖
- 代码结构复杂，却没有真正满足业务规则
如果先写断言，AI 会更容易围绕：
- 输入是什么
- 输出应该是什么
- 什么情况算失败
来组织实现，而不是自由发挥。
二、最小可执行工作流
第 1 步：先定义 3 到 5 条核心断言
例如一个价格计算函数，不要一上来让 Cursor 写代码，而是先写：
- 正常输入返回正确金额
- 折扣为空时按默认逻辑处理
- 非法输入抛出可识别错误
第 2 步：让 Cursor 先补测试，再审测试
先让它输出测试草稿，而不是实现草稿。因为测试比实现更容易被人类快速检查。
第 3 步：在测试固定后，再生成实现
这一步的优势是实现已经有了边界，不容易继续发散。
第 4 步：补最小回归集
除了核心断言，还要加 1 到 2 条典型失败样本，防止“只对 happy path 生效”。
三、什么样的测试最适合约束 Cursor
最有价值的不是数量最多的测试，而是覆盖关键边界的测试。
建议优先写：
| 测试类型 | 价值 |
|---|---|
| 正常路径 | 确认主功能成立 |
| 空值 / 缺失值 | 防止输入不完整时崩溃 |
| 非法输入 | 保证错误处理可预期 |
| 关键业务边界 | 防止核心规则被误解 |
这也是为什么“最小测试集”经常比“先铺很多测试文件”更实用。
四、提示词应该怎么写
一个适合测试驱动的提示词，建议包含：
- 功能目标
- 测试框架
- 先输出测试、后输出实现
- 禁止绕过断言
- 生成后必须说明覆盖了哪些边界
例如：
使用 Vitest，先生成该函数的最小测试集，覆盖正常输入、空值、非法输入和关键业务边界；测试通过后再生成实现，不要引入额外依赖。
五、最常见的失败方式：让 AI 自己决定“测什么”
如果你不先定义边界，Cursor 很可能写出“语法正确但业务不关键”的测试。
例如它会测试：
- 返回类型是不是对象
- 函数能否被调用
却漏掉真正关键的：
- 折扣规则是否正确
- 状态切换是否一致
- 错误文案是否可识别
所以测试驱动不是把测试外包给 AI，而是把业务边界先交给 AI。
一个失败案例：测试很多，但依然没拦住回归
常见情况是：
- 生成了很多测试
- 但全是表层 happy path
- 一旦输入为空、顺序变化或状态异常，仍然出错
这类问题的根因不是测试数量不够，而是测试没有覆盖真正决定业务正确性的边界。
Cursor + 单元测试检查清单
- 是否先定义了 3 到 5 条核心业务断言
- 是否先审测试再审实现
- 是否覆盖正常、空值、非法输入和关键边界
- 是否禁止 AI 为了通过测试而篡改需求边界
- 是否保留最小回归集作为后续改动门禁
- 是否能把测试失败映射回具体业务规则
