4家AI审代码全翻车，1个支付漏洞逃过所有"电子眼"

去年Q3，某金融科技团队把核心支付模块丢给4家主流AI代码审查工具扫描，结果触目惊心——一个可导致资金重复扣款的逻辑漏洞，4个Agent全部漏检。这不是压力测试，是真实生产事故的前传。

测试者用了一个经典陷阱：并发场景下的竞态条件（Race Condition，多线程/进程同时读写同一数据导致的时序混乱）。支付回调接口里，状态校验和余额扣减之间留了0.3秒的窗口期，高并发时同一笔订单能被触发两次。人类老炮一眼能嗅出的味道，AI们集体失明。

测试设计：故意埋雷，看谁能排

被测代码是一个简化版支付服务，约800行Go语言。测试者植入三类漏洞：SQL注入（入门级）、硬编码密钥（中级）、以及那个竞态条件（高级）。前两类属于"教科书案例"，后一类是真实世界里搞垮过Stripe早期系统的同款。

4个Agent配置如下：GitHub Copilot Chat（微软）、Amazon CodeWhisperer（现Q Developer）、Cursor内置审查、以及开源的CodeRabbit。全部开启最高敏感度，提示词明确告知"这是金融支付代码，请重点检查资金安全和并发问题"。

结果分布很戏剧性。SQL注入：4/4检出，平均响应时间12秒。硬编码密钥：3/4检出，CodeRabbit漏了那串藏在注释里的测试密钥——它把注释当噪音过滤了。竞态条件：0/4。

最讽刺的是Cursor的反馈："未发现并发安全隐患，代码使用了标准的数据库事务机制。" 它把Begin/Commit的存在，误解为对竞态条件的防护。实际上那段事务只包裹了写操作，读校验在事务外。

AI的盲区：看不见"时间"

测试者事后复盘，发现所有Agent的注意力机制有共同盲区。它们解析代码时，把程序看作静态结构图——函数调用、数据流、依赖关系。但竞态条件是动态现象，需要想象"两个请求同时抵达"的时序画面。

GitHub Copilot Chat的回复最具代表性：「代码逻辑清晰，建议补充单元测试覆盖边界情况。」它甚至没提到并发，把问题降级为"测试覆盖率不足"。

Amazon Q Developer走得更远，生成了20行"修复建议"——给扣减操作加了分布式锁。但锁的粒度是用户ID，意味着同一用户的所有支付会被串行化，吞吐量暴跌90%。这是典型的"治好咳嗽切掉肺"，AI没理解业务代价。

测试者用了一个精妙的类比：AI审代码像X光片，能看骨头有没有断，但看不出血液在血管里的流速紊乱。竞态条件是"血流动力学问题"，需要理解系统在时间维度上的行为，而非空间结构。

人类最后的高地？

这个结果并不意外。2023年CMU的一项研究（测试者引用了预印本）显示，现有大模型在检测并发漏洞上的F1分数不足0.4，远低于传统静态分析工具如Infer的0.72。但传统工具误报率极高，每100个告警里97个是噪音，工程师早已麻木。

AI的优势是"说人话"。CodeRabbit虽然漏了竞态条件，但它用中文解释了一段复杂正则的作用，比官方文档还清楚。测试团队最后把它当"代码讲解员"用，而非"安全守门员"。

那个竞态条件最终怎么修的？团队里一个写过三年高并发交易系统的老兵，花了15分钟在代码评审会上画了一张时序图。不是他比AI聪明，是他2019年踩过一模一样的坑——某次大促凌晨三点被叫醒救火，记忆刻进了肌肉。

测试者的结论很克制：AI代码审查目前适合"扫盲"（基础漏洞、风格问题、文档补全），但涉及资金、并发、分布式一致性的关键路径，仍需人类持有否决权。不是信任问题，是能力边界问题。

他在报告结尾留了一个细节：那个漏检的竞态条件，在测试结束后被故意保留了一个版本，埋进 staging 环境跑压力测试。三周后，混沌工程团队用1000并发请求成功触发了重复扣款——AI没拦住的，测试拦住了。

如果AI审查工具明年此时再来一次同样的测试，你认为结果会有不同吗？