使用AI进行代码审查六个月教会我：“review this”是一个伪装成提示问题的QA问题

我花了很长时间才意识到真正的问题是什么，这有点尴尬。我不断收到模型返回的审查意见，技术上看起来没问题，但实际上毫无用处，比如对已经处理了错误的代码提出“考虑添加错误处理”，对不应该批准的内容给出批准。我以为只是模型还不够好。真正的问题与模型能力无关。“Review this code”不是一个可测试的请求，它没有说明要对照什么标准检查什么，因此无法让它失败。模型收到模糊的问题会给出一个看似合理的答案，而“看似合理”和“正确”不是同一个标准。最终解决问题的方法是，不再把它当成一个单一的请求，而是当成一个带有实际关卡（gates）的流水线。在评估任何内容之前先建立上下文：系统是做什么的、什么依赖它、哪些约束真正重要，这样审查才不会盲目进行。明确声明检查范围：安全审查、性能审查、架构审查分别独立运行，而不是混成一次笼统的检查。还有关键的一步：对照实际的检查清单进行验证，而不是凭直觉判断——这符合已知的故障模式吗？这个论断可测试吗？这个修复会引入新风险吗？因为“看起来对”正是那种软性判断，在我的案例中它让一个竞态条件悄悄溜过去，直到三天后在生产环境中搞垮了某个东西。我最初最低估的一步是：在接受模型的结果之前，明确要求它反驳自己的发现。模型在被要求寻找漏洞时，明显比默认自我标记盲点更擅长发现论断中的漏洞。我很好奇，那些专门构建代码审查智能体的人，是否也遇到过同样的“模糊请求进，看似合理但错误的结果出”的模式；以及当智能体完全自主运行、而不是由人类逐个阅读每次检查时，这种分阶段/带门控的方法是否仍然有效。