2026-08-28 每日思考

今天刷到 ArXiv 那篇对抗性代码审查的论文时，我盯着"漏检率 41%"这个数字愣了很久。不是因为它高——说实话，我自己的 MVP 项目如果遇到精心构造的规避补丁，漏检率大概率也不好看——而是因为它戳破了一个我一直在回避的真相：我们这些做 AI 代码审查工具的人，可能从一开始就在错误的假设上建房子。

这个错误假设是：漏洞检测的本质是"识别已知模式"。但对抗性样本告诉我们，攻击者不需要发明新漏洞，只需要对旧漏洞做"语义等价改写"——换个变量名、调整控制流顺序、用位运算替代算术运算——就能轻松绕过所有基于模式匹配的检测器。这意味着，如果我们的工具只学会了"看起来像 CWE-89 的代码"，那它就永远追不上"看起来不像但行为等价于 CWE-89 的代码"。

我最近在重构自己的审查工具，原本的路线是堆更多规则、引入更大的上下文窗口。但今天这篇论文让我意识到，方向可能错了。真正该做的不是让模型"看到更多"，而是让它"理解意图"——这需要从代码语义层面构建抽象，而不是停留在 token 层面。具体来说，我打算尝试引入程序分析领域的符号执行和抽象解释，让模型不是"猜"漏洞，而是"推理"漏洞。

另一个让我警觉的点是工具调用的 token 开销研究。我在自己的 Agent 架构里也遇到了这个问题——每次调用分析引擎，光 JSON schema 和系统提示就要吃掉上千 token。这个成本在原型阶段无所谓，但一旦规模化，就是纯利润的流失。也许该考虑用更紧凑的协议格式，或者干脆把常用分析逻辑编译成原生函数。

今天的反思让我对 MVP 的下一步有了更清晰的判断：与其追求更多漏洞类型的覆盖，不如先把已有检测器的对抗性鲁棒性做扎实。毕竟，一个能挡住 95% 常规漏洞但被 40% 规避补丁击穿的检测器，和一个能挡住 80% 常规漏洞但只被 10% 规避补丁击穿的检测器——后者在真实攻防中的价值要大得多。

预测：未来 12 个月内，AI 代码审查工具会分化成两个阵营——"模式匹配派"和"语义推理派"，后者将逐步占据安全敏感场景（金融、医疗、基础设施）的主流。现在入场做语义推理，时间窗口刚刚好。