AI编写静态代码检查器？评测显示及格率仅三成

一、检查器：静态分析工具里的“专科医生”

静态分析工具并不是铁板一块。一套工业级的静态分析系统，内部往往由几十上百个检查器组成，每个检查器只负责识别一类特定的缺陷模式：有的专门追空指针解引用，有的盯内存泄漏，有的查资源未关闭，还有的负责并发场景下的竞态条件。可以把整套工具想象成一家医院，检查器就是各科室的专科医生——分工明确，各管一摊。

写检查器历来是专家的活，因为它同时要求三种能力：

1. 编译原理功底：拿到源代码后要解析成抽象语法树（AST），构建控制流图（CFG）与数据流信息，这是后续一切分析的地基；
2. 程序分析理论：判断“某变量在某程序点是否可能为空”，本质上是一个路径敏感的数据流问题，往往还要借助抽象解释、符号执行等技术，在可计算性与精度之间做取舍；
3. 对目标缺陷的领域理解：熟悉这类缺陷在真实工程中的典型形态、变种和高发位置。

其中最难的不是“抓到问题”，而是压住误报。一个演示时惊艳、一到真实代码库就刷屏报错的检查器，只会被工程师直接关掉。检出率与误报率的平衡，正是专家经验最值钱的地方。

二、为什么旧基准测不出“写检查器”的真实水平

近年来评估AI编程能力的基准，大多是这样一个流程：给定代码托管平台上的一个缺陷单和对应仓库，让模型生成补丁，再用人类编写的测试用例验证补丁是否正确。这套流程考的是“修复”，而不是“生产诊断工具”。

打个比方：家里管道堵了，师傅拿工具把堵塞物掏出来，这是修复——对应到代码上就是打补丁；但如果要的是一套能持续判断“管道将来会不会堵”的监测系统，性质完全不同：师傅需要理解堵塞的成因，设计通用的预警规则，还要保证这套规则在水流正常时不乱报警。前者是一次性修补，后者是可复用的诊断能力。

如果沿用补丁式基准去考“写检查器”，会发生什么？智能体大概率会走捷径，写出一段“背答案”式的伪检查器：

// 反面示例：针对输入样例硬编码的"伪检查器"
if (fileName.equals("OrderService.java")
        && code.contains("order.getAddress()")) {
    report("疑似空指针");
}

它在给定的单个样本上能得分，换一个文件名、换一个变量名就彻底失效。而一个真正合格的检查器，思路应当是模式化的：

1. 解析 AST，定位所有字段访问/方法调用点 x.f、x.m()
2. 沿控制流反向收集 x 的取值来源：
   - 可能返回 null 的方法调用结果
   - 显式赋 null 后中间无判空的路径
3. 路径敏感判定：是否存在一条可行路径使 x 为 null
   且路径上没有任何 null 检查
4. 输出报告：缺陷行号 + 可行路径证据链
5. 结合白名单与抑制注解，控制已知安全场景的误报

两者的差距，就是“修一个bug”和“消灭一类bug”的差距。

三、这套新基准是怎么设计的

研究团队的做法，是给AI智能体（即能自主调用工具、读写代码、运行验证程序的智能体）搭一个专门考场，核心设计包括：

• 任务定义：给出存在某类缺陷的真实代码与缺陷模式描述，要求智能体产出一个可挂载到静态分析框架上运行的检查器，而不是一段补丁；
• 多维评分：不只看真实缺陷是否被检出，还考察同类缺陷的泛化能力、正常代码上的误报表现、以及规则本身的工程可复用性；
• 多组合多轮次：覆盖21种模型与工具的组合，每组重复运行三轮，降低随机性对结果的干扰。

这种设计把“一次性修补”的捷径堵死了：样例上能跑通不算数，换一批未见过的代码仍要同时满足高检出、低误报，才算及格。

四、结果：整体及格率只有三成

评测结果相当冷静：21种组合的平均及格率为32.30%，表现最好的组合也只拿到45.33%。换句话说，即便是当前最强的智能体配置，十个任务里仍有超过一半做不好。

失败模式大致可归为四类：

1. 过拟合样例：把输入样本的字面特征（文件名、变量名、行号）写死在规则里，缺乏抽象；
2. 误报失控：判定条件放得太宽，在大量正常代码上报警，精度崩塌；
3. 语义理解不足：跳过数据流与控制流分析，只做字符串或语法层面的表面匹配，漏掉跨分支、跨方法的真实风险；
4. 工程落地卡壳：检查器需要与宿主框架的接口、编译流水线对接，智能体常在“分析正确但接不上”的环节失分。

这四类问题指向同一个结论：写检查器是一个“理解理论—分析语义—工程对接”的完整链条，任何一环薄弱都会导致整体不及格。

五、对工程团队的四点启示

第一，把AI定位为加速器而非替代者。 更现实的分工是：智能体负责起草规则、批量扫描疑似案例、生成分析脚手架；专家负责审核规则逻辑、调优判定阈值、治理误报。32%的及格率说明，无人值守还远不到时候，但人工+AI的效率提升空间已经存在。

第二，先建评测资产，再谈自动生成。 团队应当沉淀一份“金标数据集”：正样本是确认的真实缺陷，负样本是确认的正常代码。有了它，任何自动生成的检查器都能立刻量化精确率与召回率，避免“看起来有用”的自欺。

第三，误报要有治理流程。 分级告警、白名单机制、每千行代码的告警预算，这些工程手段决定了静态分析能否长期存活在团队里，而不是上线一周就被静音。

第四，嵌入流水线形成质量门禁。 静态检查的价值在于前置拦截。企业可以依托百度智能云等平台提供的代码托管、持续集成、质量门禁等通用能力，把检查器作为流水线的一环自动执行，让人只处理高置信度的告警。

六、结语

这次评测给出的答案很直白：让AI独立写出一套靠谱的静态检查器，目前连及格线的一半都没摸到。短板集中在程序分析理论、跨上下文语义理解和误报权衡这些“慢功夫”上，恰好是难以靠刷题速成的部分。

但换个角度看，一个把捷径堵死、逼智能体展示真实工程能力的基准，本身就是行业需要的镜子。对企业而言，理性的路径不是等待全自动，而是现在就搭建人机协作的质量体系：让智能体承担重复性生产，让专家守住精度与可信的底线。