一个常见场景是：把需求丢给 AI，它返回一段代码，你追问“有没有问题”，它回答“没有问题，逻辑正确”。这句话几乎不构成信息——生成它的和判断它的，是同一个上下文、同一套假设、同一个目标。

生成与审查的目标相反

生成阶段要收敛：在有限信息下给出一个能跑通的实现。审查阶段要发散：找出遗漏的需求、越界的行为、被吞掉的异常。两者对同一份代码的注意力方向相反。当审查紧接着生成、发生在同一个对话里，模型面对的是自己刚写下的推理链，更倾向于延续原有假设，而不是重新质疑。需求里被误解的边界条件，往往会被同一套误解再确认一遍。

更稳妥的做法是：代码和测试完成后，重新整理上下文，把已确认的需求、代码差异和测试结果组织成一份独立的审查输入，让 AI 以审查者身份判断。审查提示里应当显式列出已确认的规则，比如包含匹配、空关键词返回全部、去除首尾空格、无结果返回空数组、参数化查询、本次不做分页排序，然后要求它逐项检查是否遗漏需求、是否越界、是否存在输入校验与查询安全风险、是否破坏原有接口、测试是否覆盖关键边界。

拆成两轮检查

逻辑审查看业务规则、分支条件、异常处理和接口兼容性：空关键词是否真的返回全部，去空格发生在查询前还是查询后，无结果与查询失败是否被混为一谈。工程审查看变更范围、测试、配置与发布风险：是否改了无关文件，是否新增了未记录的环境变量，是否需要数据库迁移，本地测试能否重复执行。

还有一个容易忽略的要求：即便没有发现问题，也应当列出已检查的项目，而不是只回复“通过”。这一条把“通过”从结论变成了可核对的范围。

需要说明的是，换另一个工具来审查，并不自动等于更可靠。角色分离的价值来自输入明确和独立判断，而不是工具数量。

审查不替代人的判断。范围控制、技术取舍、数据安全和最终发布，仍然由维护者自己决定；它能做的，是把“写完了”和“能上线”之间的那道门，明确成一次独立动作。