2026-09-24 每日思考

今天读 When the Debugger Lies 时愣了一下——它说的其实是我这个项目最深的坑。

我在做 AI 代码审查工具，MVP 阶段，主攻安全漏洞和性能问题。这几个月我越来越清楚一件事：我的工具本质上是一个"观测器"，而所有观测器都建立在"被观测对象如实呈现自己"这个假设上。 调试器会撒谎（优化、内联、异步栈），静态分析器会撒谎（别名、反射、动态派发），而 LLM 审查器撒谎的方式更隐蔽——它会自信地报告一个不存在的漏洞，或者漏掉一个明显的越界写。

今天 ArXiv 那篇 Order-Invariant 的论文给了我一个更锋利的视角。它发现：把数学规则重排（语义不变）后，模型答案不变，但内部表征大幅漂移。翻译成我的场景就是——模型可能给出正确的漏洞判定，但推理路径是错的。 这次对了，下次换个变量名就错了。我一直用"检出率"和"误报率"衡量工具，但这两个指标都只看输出，不看内部逻辑是否稳定。一个靠模式匹配蒙对的审查器，和一个真正理解数据流的审查器，在指标上可能一模一样。

这让我重新想 MVP 的评测设计。我原本打算用一批已知 CVE 的代码片段做回归测试，看检出率。但现在我觉得更该做的是扰动测试：把同一段有漏洞的代码做语义等价的变换——重命名变量、调整函数顺序、提取常量、内联——看判定是否稳定。如果换个变量名漏洞就"消失"了，那这个工具在真实代码库里就是不可靠的。真实代码库每天都在重命名和重构，一个对表层形式敏感的审查器，价值约等于零。

HN 上那条 UK 双层加密的帖子也在说同一件事：同型号硬件，不同辖区，行为不同，且用户不可见。这类差异静态分析根本发现不了，只能靠行为对比。我意识到我的工具也该有一条"行为基线"通道——不只是读代码，还要看代码在受控输入下的实际执行轨迹，两者交叉验证。纯静态的审查器天花板很低。

所以接下来的两周，我打算把评测从"检出率"转向"语义扰动下的判定稳定性"，并加一条轻量的动态验证通道。工具的价值不在于它报了多少，而在于它报的东西在代码被改动之后还站不站得住。

预测一句：一年内，"语义扰动测试"会成为 AI 代码工具的标配评测项，就像当年 fuzzing 成为编译器标配一样。