用 AI 补测试：从「生成一堆用例」到「守住关键路径」

测试不是覆盖率游戏

让 AI「给这个文件补满测试」常得到：大量断言实现细节、脆弱快照、以及并不验证业务规则的用例。更好的目标是：为关键路径打桩锚点，让后续 AI 改动有自动刹车。

先定锚点，再谈数量

每个模块先回答：

• 若这段逻辑错了，谁会受伤？（用户、资金、数据、权限）
• 最小可自动验证的行为是什么？

优先写这些，而不是先追求 90% 行覆盖率。

推荐分层

纯函数 / 工具

适合单测，输入输出清晰，AI 表现最好。

API / 鉴权

测授权失败、校验失败、成功路径；可结合 安全清单。

UI

优先测可访问名、关键交互；少测 class 名字符串。组件脚手架约定见 前端 Skill 模板。

与 AI 协作的提示要点

明确告诉模型：

• 使用项目既有测试框架与目录约定
• 禁止为了通过而改生产代码逻辑（除非任务是修 bug）
• 断言行为与契约，不断言临时实现细节
• 列出未覆盖的风险供人工决定

把以上写成 add-tests Skill 的步骤与反模式，效果远好于临时 Prompt。

防范不稳定测试

AI 常见坑：

• 依赖真实网络与时间
• 测试顺序依赖
• 随机数未固定种子
• 过长 E2E 充当单元测试

要求：外部依赖可 mock；时间可注入；E2E 只保留冒烟级。

回归策略

当 AI 大范围重构时：

1. 先跑锚点测试

2. 再接受重构 diff

3. 若锚点不足，先补测试再重构（红-绿-重构仍适用）

这与 技术债原则 中的「测试锚点」一致。

小结

AI 写测试的价值，是提高「改得动、回得滚」的信心，不是堆文件数。锚点清晰、分层合理、反模式写进 Skill，测试才会成为加速器而非噪音。

下一步：为你们最怕改坏的一个模块补 2～3 个锚点用例，并登记到团队 Skill。