AI 可以很快列出很多测试点，但如果这些点不对应真实风险，最后只是增加维护负担。补测试的正确起点是：这次改动最可能破坏什么、用户最不能接受什么、出了问题怎样尽快发现。
先列风险，再写用例
风险可以来自输入为空、权限不同、数据重复、网络中断、旧数据兼容和异常回滚。每条风险对应至少一个可复现的场景，写清输入、期望结果和不应发生的副作用。
| 风险 | 示例测试 | 验收点 |
|---|---|---|
| 权限 | 不同角色访问同一操作 | 无权限不能绕过限制 |
| 重复提交 | 连续触发同一请求 | 不会产生重复记录 |
| 异常输入 | 空值、极值、格式错误 | 给出可理解错误且系统稳定 |
让 AI 辅助但不替代判断
- 先给出变更说明、已有规则和风险清单。
- 让 AI 提出遗漏场景和测试数据草案。
- 由开发者确认优先级和可测试性，再写入测试。
- 变更后运行相关测试与关键用户路径的回归检查。
修复问题时，先复现再验证的原则可参考 Bug 修复正确流程。
测试失败是信息，不是噪声
失败要记录它暴露的是需求不清、实现错误还是测试假设过时。这样 AI 提出的测试场景才会逐步变得更贴近真实风险，而不是一味堆数量。
