上月时, 我递交了一个PR, 自觉写得蛮不错。然而, CI当中增添了一个AI步骤, 瞬间扫描出3个SQL注入风险点来。那时, 我的脸一下子全变绿了。说实在的, 关于AI进行代码审查这件事, 在2024年的时候, 我还认为那只是个噱头。到了2026年, 我却已然离不开它了。并非是由于它能够取代人工, 而是在于它能够在人最容易出现疏漏的那些地方——像是安全漏洞、空指针、资源泄露这些方面——达成近乎零遗漏的状况。至关重要的认知是, AI代码审查并非单纯意味着让AI去查看代码是否存有问题, 它有着更为复杂的要求, 要区分不同维度, 赋予特定角色, 设置相应约束条件, 并且需像精准地给一位审查专家分配任务那般精确。为什么帮我这段代码是最烂的提示词我曾进行过尝试, 向AI给予了一个包含200行的文件, 并提供如下提示词: 整整一句, 即“this code and find ”, 仅此而已。它返回了6条建议, 其中3条是之于命名规范的, 原因是变量名不够语义化了另外2条是关于注释的, 给出的建议是需要添加注释, 还有1条是关于类型标注的。有这样一个问题, 代码存在竞态条件, 也就是race状态, 在多线程的场景当中, 数据会出现混乱的情况。先是, AI没发现, 并非由于其自身没具备发现之能力, 而是缘我并未告知它需着重关注并发安全, 于是乎, 它默认选择了最为轻松的途径, 也就是挑选一些表面性问题充作数量。四步审查法每个维度独立提示词要将代码审查划分成为四个维度, 每一个维度都配备一个单独的提示词, 然后依照顺序进行审查。这里的顺序是极为关键的——首先要审查安全方面, 接着是逻辑方面, 再之后是性能方面, 最后才是可读性方面。第一步安全检查你是一名资深安全工程师。请审查以下代码的安全漏洞重点关注 1. SQL注入 / NoSQL注入 2. XSS跨站脚本 3. 认证/授权漏洞权限绕过 4. 敏感信息泄露密钥、密码、token硬编码 5. 输入验证缺失 6. 反序列化风险 对每个发现的问题用以下格式输出 - [严重程度高/中/低] - 问题所在行号 - 问题描述 - 修复建议给出具体代码 - 如果没有安全问题回答未发现安全问题而不是硬凑。 代码 [粘贴代码]第二步逻辑审查你是一名资深后端开发。请审查以下代码的逻辑正确性重点关注 1. 边界条件处理空值、零值、空列表 2. 条件分支是否覆盖所有情况 3. 循环退出条件是否正确 4. 并发/异步场景下的竞态条件 5. 异常处理是否完善 6. 数据一致性事务、回滚 格式同上。 代码 [粘贴代码]第三步性能分析主要的要点在于: N加上一的查询, 并非必需的循环嵌套, 大量对象不断地频繁创建, 缓存出现缺失的状况, IO产生阻塞的情况。第四步可读性评估命名, 函数长度, 嵌套深度, 注释质量。这一步, 人工智能而言, 做得最为出色, 然而, 也是最不具备重要性的——自行斟酌修改即可。实测对比普通提示词 vs 四步法我用一个200行的电商下单接口做了对比测试方法发现问题数高危问题误报 this code6个0个1个四步审查法14个3个SQL注入权限绕过竞态条件0个差异主要展示于高危事项方面。一般提示词识别出来的尽是命名、注释这类“安全”问题, 这些AI随意识别都能找出一大批, 然而真正关键的漏洞一个都未曾发觉。说的更加直接明白一些, 并非是AI没有能力, 而是你所给出的提示词, 没有使得它进入到那种“审查模式”。进阶技巧用多个模型交叉审查这个玩法, 是我最近才发现的, 它是这样的, 用两个不同的模型, 去审查同一段代码, 然后取并集。上个月, 有一段支付回调代码, 从中发现了逻辑漏洞, 也就是重复支付没做幂等处理, GPT发现了安全漏洞, 具体是回调签名验证不完整, 两个模型各自发觉了对方未曾留意到的问题。成本是翻倍了但一次多花几分钱总比线上事故强。建议搭配组合为, 4主导逻辑审查, 同时GPT - 4o主导安全审查。存在一个情况是, 在中文业务代码的注释理解方面, 其表现比这两者都更为出色, 所以针对中文项目而言, 可以考虑采取三模型交叉的方式。依据2026年官方给出的数据, 其内部所具备的代码审查功能, 在针对安全漏洞进行检测时, 准确率已然达到了92%。然而说实话, 这种审查更加侧重于“实时代码给出提示”, 与专门开展的深度审查之间, 确实还是存在着一定差距的。什么时候AI审查不够用在AI代码审查里, 当下最强的领域是, 安全模式匹配, 空指针检测, 资源泄露, 注入漏洞。这些全都是“有明确对错”的问题。它没办法做好的是, 业务逻辑方面的合理性判断, 架构设计的好坏状况, 还有和用户体验紧紧相关的代码质量表现。并且, 有关这些方面的情况, 始终还是得要依靠人去进行裁决判断的。一个用以进行判断的简单标准是, 要是问题能够借助和静态分析工具予以发现, 那么AI在很大可能上同样能够发现。要是问题需要通过“理解业务上下文”才能够做出判断, 当前AI的能力就在这方面差出了一大截。常见问题AI代码审查能替代人工Code 吗完全不能替代, AI 在安全漏洞、带有 SQL 注入、XSS 这类模式化问题方面检测率极高90% , 可是在业务逻辑错误、架构设计问题、用户体验缺陷这些地方仍旧赶不上有经验的开发者。最佳实践是 AI 先全面扫描一遍, 然后由人工对重点部分进行复核。用什么AI模型做代码审查最好到2026年进行的实际测试来看, 4在代码逻辑方面分析的呈现当中是最强态势, GPT - 4o在安全漏洞检测领域微微具备优于其他的情况, 在对于中文注释理解这一方面是有着一定优势情况存在的。给出的建议是采用两个模型相互交叉审查 , 也就是利用一方进行逻辑审查另一方利用GPT进行安全审查, 如此这般所达成的覆盖面是最为广泛状态。AI代码审查提示词最关键的是什么最为关键之处在于, 要进行分维度审查, 不能笼统地提及“this code”, 而是要分别从安全、性能、可读性、边界条件这四个维度, 逐个进行审查。对于每个维度, 给出独立的提示词, 其效果相较于一个大杂烩式的提示词, 要好得多。AI审查出的问题需要全改吗并非需要, AI存在的问题在于“宁愿多进行申报而非有所遗漏申报”, 会存在一定程度的假阳性情况。我们的具体做法涵盖: 对于全部高危问题展开核实工作然后进行修复, 针对中危问题在予以评估以后才做出决定, 面对低危问题像是命名方面的建议等情况会经过选择才进行采纳行为, 不要毫无头绪地全部进行改动。诚实地讲, AI代码审查这般技能一经熟练运用之后, 你将会发觉自己异常“依赖”, 类似于常年习惯使用它后, 会深切感知到再也难以回归到手写代码的状态。若你认为此内容具备效用, 那就请将其转发给你的技术负责人吧。