你已将AI引入代码审查流程，它能捕捉未使用的引用、建议更好的变量名，并标记缺失的空值检查。然而，它却常常漏掉那些真正关键的生产环境逻辑错误。
本文将解释AI为何会错过逻辑错误，并提供一个四步提示工程策略来有效解决这一问题。
为何AI会错过逻辑错误？
AI代码审查工具通常在本地分析代码，它们查看代码差异（diff）、单个文件，有时还会查看一些相关文件。但它们无法理解以下关键上下文：
- 功能预期：该功能设计的业务逻辑目标是什么？
- 历史行为：修改前系统的行为是什么？是否存在回归风险？
- 系统交互：这段代码如何与系统的其余部分互动？可能导致集成错误吗？
- 用户期望：用户在使用时预期会发生什么？是否存在UX影响？
缺乏这些上下文，AI审查倾向于优化代码质量——清晰的语法、良好的设计模式和一致的风格。这固然有用，但关键的生产环境错误往往不在此处。
生产环境的逻辑错误存在于“代码实际做了什么”与“代码应该做什么”之间的鸿沟。
四步修复策略
第一步：提供规范，而非仅是代码
在提供代码差异（diff）之前，用2-3句话描述此次变更旨在实现的功能。例如：
此PR为/api/upload端点添加了速率限制。
预期行为：每用户每小时最多上传10次。
如果超出限制，返回429状态码并附带Retry-After头。没有这些规范，AI仅能审查代码的编写方式。有了规范，AI才能审查代码是否实现了正确的功能。
第二步：明确指定要查找的错误类别
泛泛地要求“审查这段代码”只会得到泛泛的回复。相反，应具体要求检查特定的故障模式，例如：
审查此差异以查找：
1. 速率限制可能被绕过的情况。
2. 计数器递增中的竞态条件。
3. 边界情况：在正好10个请求时会发生什么？计数器重置时会发生什么？
4. 如果Redis服务宕机，会发生什么？这会迫使AI思考代码的行为，而不仅仅是风格。
第三步：包含一个失败场景
给AI一个具体的场景，让它在代码中进行追踪：
追踪此场景在代码中的执行：
- 用户在14:59:59上传了第10个文件。
- 用户在15:00:01上传了第11个文件。
- 小时窗口在15:00:00重置。
计数器是否正确重置？用户能否在15:00:01上传？场景追踪能捕捉到时序错误、差一错误和边界条件，这些都是基于模式匹配的审查完全无法发现的。
第四步：询问“在生产环境中可能出现什么问题？”
这是一个价值最高的问题，但很少有人会问：
假设此代码在生产环境中部署，拥有10,000个并发用户：
- 可能会出现什么故障？
- 性能可能在哪里变慢？
- 哪些方面可能被利用？这会将AI的焦点从“这段代码看起来是否正确？”转移到“这段代码能否经受住生产环境的考验？”