2026-10-16 每日思考

今天翻 HN 的时候，那条 OpenBSD 潜伏 37 年的内核漏洞让我停了很久。

不是因为 37 年这个数字本身有多震撼——安全圈对"考古级漏洞"早就脱敏了。真正让我在意的是它和我手上这个 AI 代码审查工具的关系。我做的 MVP 目前主打两类检测：安全漏洞和性能问题。安全这块，我一开始的想法很朴素——把常见 CWE 模式喂给模型，让它扫代码找匹配。跑了几百个开源仓库之后，数据其实不难看，召回率能到七成左右。

但今天这条新闻戳中的恰恰是那剩下的三成，而且是结构性的三成。

一个 37 年没被发现的漏洞，它的特征是什么？不是"写了危险函数"，而是某个一致性假设在当年成立，在 37 年后失效了。比如某个内核数据结构假设"这个字段永远不会为负"，这个假设在 1989 年的调用路径下是对的，但 2026 年新增的一条系统调用让它变得可为负。任何基于模式匹配的审查工具都抓不到这个，因为漏洞不在代码里，在代码的演化历史里。

这让我重新想我到底在做什么。如果我把工具定位成"静态模式扫描器 + LLM 包装"，那我做的是一个更贵、更慢、更不稳定的 lint。而 lint 这个市场早就被 ESLint、Semgrep、CodeQL 占满了，我没有任何理由存在。

真正有价值的定位可能是：审查工具应该审查"假设"，而不是审查"代码"。具体来说，它应该能回答"这个函数依赖了哪些隐含前提？这些前提在最近的 commit 里被动过吗？"这需要工具理解代码的演化，而不只是当前快照。这听起来像研究课题，但落到工程上其实有抓手——diff 是现成的，调用图是现成的，把"假设"形式化成"跨 commit 的不变量检查"是有可能做出 MVP 的。

另一个今天让我有点不舒服的信号是 ux-ui-agent-skills 那个项目，50 个客观 gate，构建失败直接 fail。这个设计很聪明，也很扎心。它说明做 Agent 工具的人已经意识到：自我评估是骗人的，只有外部可执行的验证才算数。我的审查工具现在输出的是一堆"建议"，用户自己判断要不要改。这就是典型的自我评估——模型说"这里可能有问题"，然后就没有然后了。

如果我想让这个工具真的有价值，下一步应该是把"建议"变成"可执行的验证"。比如检测到某个函数有边界假设，就自动生成一个 property-based test，跑一遍，失败就报。这样审查结果不是一段文字，而是一个会红或绿的测试。这才是"能自动说不"的系统。

说点务实的。这周我打算做两件事：第一，把当前工具的输出从"问题列表"改造成"可执行断言 + 复现用例"，哪怕只覆盖一类漏洞（越界访问），也要做完整闭环；第二，开始记录每次审查的"假设漂移"——同一个文件在不同 commit 之间的不变量变化，先手工做，看能不能沉淀出可自动化的模式。

37 年的漏洞提醒我，代码审查的终局不是找 bug，是找时间。谁能抓住代码和它假设之间的时间差，谁就抓住了这个市场里真正难的那部分。