AI 让写代码变快了，但这也带来一个新问题：错误代码产生得更快了。

所以 AI 编程里，测试不是可选项，而是护栏。

如果你只让 AI 写功能，不让 AI 补测试，短期看很快，长期看会越来越不敢改。

为什么 AI 编程更需要测试

人写代码会犯错，AI 也会犯错。

AI 常见的问题包括：

• 只覆盖正常流程。
• 漏掉权限判断。
• 对业务规则理解错。
• 写出看起来合理但实际跑不通的代码。
• 为了通过当前场景破坏旧逻辑。
• 没有考虑空数据、重复提交、异常输入。

测试的作用不是证明 AI 很强，而是限制 AI 的错误影响范围。

第一步：先让 AI 列测试矩阵

不要直接说：

帮我写测试。

更好的提示词是：

请先阅读这个功能和相关代码，不要写测试代码。
先输出测试矩阵，包含：
1. 场景名称
2. 输入条件
3. 操作步骤
4. 期望结果
5. 覆盖的风险

测试矩阵比测试代码更重要。

因为它能先暴露：我们到底要验证什么。

一个好的测试矩阵长什么样

以登录功能为例，至少应该覆盖：

• 正确账号密码登录成功。
• 密码错误时提示失败。
• 用户不存在时提示失败。
• 表单为空时不能提交。
• 多次失败是否有限制。
• 登录成功后是否跳转。
• 未登录访问受保护页面是否被拦截。
• 已登录用户访问登录页如何处理。
• token 过期后是否退出。

如果 AI 只列了“登录成功”和“登录失败”，说明它还没有进入测试思维。

你可以追问：

请补充边界场景和安全相关场景。
重点考虑空输入、重复提交、权限不足、token 过期和异常响应。

第二步：让 AI 使用项目现有测试框架

测试不是独立存在的，它必须融入项目。

提示词：

请基于上面的测试矩阵补充测试。
要求：
1. 使用项目已有测试框架
2. 参考已有测试文件的写法
3. 不引入新测试库
4. 测试名称描述业务行为
5. 只测试公开行为，不测试私有实现细节

“参考已有测试文件”这句话很关键。

否则 AI 很可能凭空使用 Jest、Vitest、pytest、JUnit 中的某一种，而不是你的项目正在用的方式。

第三步：让 AI 跑测试并解释失败

如果你的 AI 编程工具能执行命令，就让它跑测试。

如果不能，你自己运行，然后把完整日志贴回去。

提示词：

下面是测试失败日志。
请分析：
1. 失败的是哪个用例
2. 失败原因是什么
3. 是测试写错了，还是业务代码有问题
4. 最小修复方案是什么
先不要直接修改代码。

这里最重要的是第三点。

测试失败不一定说明代码错，也可能是测试误解了需求。

AI 很容易为了让测试通过而改业务代码，所以你要让它先判断。

第四步：让 AI 做测试审查

测试通过以后，不代表测试质量好。

继续问：

请审查这些测试。
重点检查：
1. 是否只覆盖 happy path
2. 是否遗漏边界条件
3. 是否过度依赖实现细节
4. 是否存在脆弱测试
5. 是否有重复或无意义断言

这一步经常能发现：

• 测试只是检查函数被调用，没有检查结果。
• mock 太多，反而失去了验证价值。
• 测试名称和断言不一致。
• 只测成功，不测失败。
• 对时间、随机数、网络请求处理不稳定。

测试类型怎么选

不要什么都上端到端测试。

可以按风险选择：

单元测试：适合纯函数、数据转换、权限判断、金额计算、状态机。

接口测试：适合登录、下单、支付回调、数据增删改查。

组件测试：适合表单校验、交互状态、条件渲染。

端到端测试：适合核心业务链路，比如注册登录、下单支付、创建项目。

手工验收清单：适合样式、兼容性、权限配置、第三方平台回调。

AI 可以帮你判断：

对于这个功能，请推荐测试策略。
说明哪些用单元测试，哪些用接口测试，哪些只需要手工验收。
不要为了测试而过度测试。

一个完整测试提示词模板

这是本次功能说明和相关代码：
<粘贴需求或文件说明>

请帮我设计测试。

流程：
1. 先输出测试矩阵，不要写代码
2. 覆盖正常流程、边界值、异常输入、权限和重复提交
3. 标注每个测试覆盖的业务风险
4. 根据项目现有测试框架生成测试代码
5. 输出运行命令
6. 审查测试是否遗漏关键场景

约束：
- 不引入新测试库
- 不测试私有实现细节
- 测试名称必须描述业务行为
- 如果需求不明确，先列问题

最后

AI 编程真正可持续的前提，是你有办法验证它。

没有测试，AI 写得越快，你越不敢改。

有测试，AI 才能从“代码生成器”变成“可协作的工程助手”。

下一篇我会写上线部署。因为本地跑通只是第一步，真正交付还要过构建、配置、数据库、日志和回滚这一关。