AI 写代码时测过的并不等于没漏洁

使用像 Cursor 或者 Claude Code 这样的 AI 编程助手时，一次性输出代码和测试会陷入一个隐蔽的陷阱：生成逻辑和验证逻辑来自同一个提示，导致两个环节共享相同的假设。如果那个假设其实是错的，整个测试体系就变成了一个自我吹嘘的回环，所有测试都过，问题依旧潜伏。

拿密码重置来说，其中一种常见的判断是“Token 有效就允许重置”，但如果没强调“Token 只能用一次”，AI 可能会写出允许重复使用的代码。它也会据此写测试，模拟“输入正确 Token，重置成功”的流程，然后测试通过，开发者以为没问题。然而用户可能在第二次尝试时，原 Token 仍然能重置密码，违背了“单次有效”这条基本要求。

这种问题不局限于密码重置，而且还出现在并发处理、请求顺序等场景。当两个请求几乎同时发来，使用同一个 Token，系统可能会让两个都通过检查，导致逻辑崩坏。即使规范文档写得很清楚，AI 也可能忽略其中的关键细节，特别是在复杂的环境下。

要打破这种假象，以下几点策略或许值得尝试：

1. 先写规范，再写代码

不要试图在一个 Prompt 里让 AI 同时生成实现和测试。先独立撰写一份规范文档，清楚定义每一条行为规范。比如：

> 重置 Token 在首次使用后必须立即失效，之后再次尝试使用应返回 400 或 403。

但这份规范也不能一劳永安。初稿可能会忽略掉并发场景或边界情况，只有在后续验证中才能逐步补充完善。

2. 引入反向思考

在编写测试之前，可以先引导 AI 扮演“破坏者”的角色，思考哪些情况可能会导致程序崩溃或逻辑出错。比如可以这样指示：

你现在是一个极其挑剔的 QA 工程师，请列举出 5 个可能让这个功能在极端条件下出错的场景。

这些场景不应由 AI 自动生成测试，而是应被人工整理为独立的测试用例，确保它们不会被误导。

3. 强调原子操作

对于关键逻辑，尤其是涉及状态修改的操作，应要求 AI 使用原子操作来避免竞态条件。举个例子，在 PostgreSQL 环境下，最好采用这种方式：

UPDATE table_name SET used = true WHERE token = 'xxx' AND used = false;

而不是先查询再更新，后者存在明显的竞态风险。

4. 保持规范文档活跃

规范文档不应被视为最终版本，而是应在开发过程中不断更新完善。流程可以是这样：

• 起草初步规范
• 让 AI 实现代码
• 独立验证发现问题
• 修改规范
• 重新实现

测试的数量增多并不代表覆盖范围更广。如果所有测试都建立在一个错误的前提之上，即使数量再多，也只能“证明”这个错误假设是正确的。只有建立在独立且可靠的逻辑定义之上，验证才有意义。