AI智能体写静态检查器，最强也只及格一半

一、任务升级：从“修一个Bug”到“造一台探测器”

在静态分析工具的体系里，检查器（Checker）是负责识别某一类特定缺陷模式的核心组件：有的专门盯着空指针解引用，有的专注内存或资源泄漏，有的负责捕获越界访问。检查器的质量，直接决定了一个静态分析产品的专业程度。

但写检查器长期以来是少数专家的工作。要交付一个“既能抓住真实问题、又不会疯狂报错”的检查器，作者至少要跨过三道门槛：

• 程序分析基础：理解抽象语法树（AST）、控制流图（CFG）、数据流分析、指针分析等基础设施，清楚模式匹配与语义分析的边界在哪里；
• 对目标缺陷的领域理解：同一类缺陷在不同语言、不同框架、不同编码习惯下形态各异，检查器必须覆盖这些变体；
• 精度与召回的工程平衡：报得太多，开发者会直接关掉规则；报得太少，工具就失去存在价值。

近年来，随着AI智能体（Agent，即能自主调用工具、读写代码、运行程序的智能系统）能力快速提升，一个自然的问题被提出：能不能让智能体代替专家完成检查器开发？

二、一场专为检查器设计的“考试”

国内多所高校与研究机构合作开展了一项系统评测：构建一个专门考察智能体编写检查器能力的基准，把“写检查器”从一句口号变成可量化、可复现的任务。其基本思路是：

1. 从真实工程中提炼典型缺陷模式，作为检查器需要捕获的“靶子”；
2. 为每个模式准备正样本（含缺陷代码）与负样本（易混淆但实际无害的代码）；
3. 让智能体在真实仓库环境中自主分析、编写并调试检查器；
4. 以其在正负样本全集上的检出情况与误报情况综合评分。

评测覆盖了21种模型与工具组合，每项任务独立重复三轮以排除随机性。结果并不乐观：

• 平均通过率仅32.30%；
• 表现最好的组合也只有45.33%。

换句话说，即便采用当前最强的智能体配置，十个检查器编写任务里仍有超过五个无法达标。这组数字为“AI能否自主开发静态分析能力”这一问题，给出了一个冷静的量化回答。

三、为什么老基准测不出新能力

在解释这个低分之前，先要回答一个前置问题：业界已有大量评测智能体编程能力的基准，为什么还要专门造一个新考场？

主流的代码智能评测大多遵循同一套范式：给智能体一个真实缺陷报告和对应代码仓库，让它生成补丁，再用人类编写的测试用例验证补丁是否正确。这套流程评估“修Bug”很有效，但与“写检查器”存在本质错位。

一个类比可以让差异一目了然：家里马桶堵了，水管工拿管钳把堵塞物掏出来，这是修复，对应代码场景就是打补丁——一次性、针对具体实例。但如果你想要的是一套能持续预警“马桶将来会不会堵”的监测系统，水管工就必须理解堵塞的成因机理，设计通用的传感与报警机制，还要确保马桶正常使用时系统不误报。前者是点状修补，后者是可复用的诊断能力。

如果把补丁式评测照搬到检查器任务上，智能体有很强的动机走捷径：

# 反面示例：面向评测样例的"补丁式"写法（示意）
if 函数名 == "handle_request" and 出现行号 == 42:
    上报("疑似空指针解引用")

这样的实现能在单个用例上得满分，却对任何其他代码失去作用——它记住的是“这道题的答案”，而不是“这类题的解法”。缺乏防走捷径设计的基准，会把这种记忆能力误判为程序分析能力。这正是专门基准存在的价值：用足够多样的正负样本，逼着被测系统展示真正的模式抽象能力。

四、检查器难在哪：三个被低估的门槛

结合上述结果，可以把智能体写检查器的难点归纳为三层。

1. 模式抽象，而非实例记忆

一个合格的检查器要覆盖目标缺陷的所有常见变体：显式判空与隐式判空、不同写法的资源释放、跨函数传播的空值……评测样本与训练数据之间的分布差异，会立刻暴露智能体究竟是“理解了模式”，还是“背下了样例”。32%的平均分在很大程度上说明，多数组合仍停留在后者。

2. 误报控制是硬约束

检查器的价值模型与补丁完全不同。补丁错了，测试会立刻失败，反馈即时；检查器的误报却要等到真实使用中才暴露，而每一次误报都在消耗开发者对工具的信任。智能体在编写时往往倾向于“宁可多报”，缺乏对误报率的主动度量与抑制策略，这是低分的另一个重要来源。

3. 长链路的自主验证

写检查器不是一次性生成代码，而是一个“实现—编译—在样本上运行—分析漏报误报—迭代修正”的闭环。这要求智能体具备搭建运行环境、执行程序、解读输出并据此修改策略的能力。任何一个环节掉链子，最终交付物就是不可用的。这类长程工程任务，恰恰是当前智能体的能力短板。

五、合格的检查器长什么样：一个示意

下面用伪代码展示一个“资源未释放”检查器的合理骨架，帮助理解“模式级”实现与“实例级”实现的差别：

# 伪代码：检测"资源获取后未释放"模式的检查器骨架
def check_resource_leak(func):
    acquired = find_resource_acquisitions(func)      # 定位所有资源获取点
    for acq in acquired:
        var = acq.target
        release_sites = find_release_calls(func, var)  # 数据流追踪释放位置
        for path in enumerate_paths(acq, func.exit):   # 路径敏感遍历
            if not path.passes_through(release_sites):
                report(path.site,
                       "变量 {} 在提前返回或异常路径上可能未释放".format(var))

关键在于：它分析的是语义与路径，而不是某几行具体代码。对照第三节的反面示例，可以看出两者在泛化能力上的量级差异——这也解释了为什么“在测试用例上跑通”远不等于“检查器可用”。

六、这组数字对工程团队意味着什么

32.30%与45.33%不应被读成“AI没用”，而应被读成一条清晰的边界线：

• 代码生成能力 ≠ 程序分析能力。模型可以熟练写出语法正确、风格良好的代码，但把领域知识组织成严谨的分析逻辑，是另一种更稀缺的能力；
• 智能体的自主验证能力是当前瓶颈。任务失败往往不是“写不出代码”，而是“写完后无法有效发现并修正自己的错误”；
• AI生成的检查规则不能直接上生产。在经过系统性验证之前，其检出结论只能作为线索，不能作为结论。

对计划引入AI辅助静态分析的团队，以下做法值得参考：

1. 把AI产出当初稿：让智能体完成遍历逻辑、样板代码等重复性工作，判定条件与阈值由工程师复核；
2. 建立内部回归集：沉淀本团队历史上真实的缺陷代码与易混淆的无害代码，任何新规则必须先通过回归集才准许启用；
3. 持续度量误报率：将检查器接入持续集成流水线，跟踪开发者对告警的处理反馈，把误报率作为规则优化或下线的依据；
4. 渐进接入：无论是自建环境还是基于百度智能云等云平台的代码托管、流水线等通用研发能力，都可以先在非阻断场景（如定期扫描、报告输出）中观察规则质量，再逐步升级为合并阻断。

七、结语

这项评测的最大贡献，或许不是那个刺眼的32%，而是它把“让AI写检查器”从一个模糊的愿景，变成了一道有明确评分标准、有可复现结果的考题。考题的存在，本身就在推动进步：它告诉研究者，泛化与误报控制是必须翻越的两座山；也提醒使用者，在静态分析这种“精度即生命”的领域，人与智能体的合理分工仍是当前最务实的答案。随着智能体验证与自我修正能力的演进，这条及格线会不断被推高；而在那一天到来之前，“AI起草、人类裁决”依然是最可靠的协作范式。