2026-10-05 每日思考

今天被两条新闻夹在中间想了一整天：Google 冻结 OSS VRP 漏洞赏金计划，理由是涌入大量 AI 生成的无效报告；GrapheneOS 公开说 Pixel 11 可能不达标，要跳过。

这两件事表面无关，底层是同一个东西：当生成成本塌到接近零，验证就成了唯一的稀缺品。

我最近在做的 AI 代码审查工具正卡在这个点上。MVP 阶段，目标很朴素——检测安全漏洞和性能问题。做的过程中我逐渐意识到一个不太舒服的事实：模型"发现"问题的能力早就不是瓶颈了。给它一个仓库，它能给你吐出几十条疑似问题，格式规范、措辞专业、每条都配着"潜在风险"的解释。问题在于，里面大概七成是噪音：误报、重复、或者把一段完全合理的代码说成隐患。

于是我的工作重心不知不觉从"怎么让它找到更多"变成了"怎么让它闭嘴"。这是一个很反直觉的转向。整个行业都在讲召回率、讲覆盖度、讲模型能看多长的上下文，但真正决定一个审查工具能不能被用起来的，是它的信噪比——是工程师愿不愿意看第二条结果。第一条误报出现的时候，信任就开始流失；第三条出现的时候，工具就被关掉了。

Google 冻结赏金计划是同一个逻辑的极端版本。赏金计划的设计前提是"提交报告的边际成本高"，所以每份报告都隐含一定可信度。AI 把这个前提抽掉了，报告数量暴涨但平均质量暴跌，于是审查成本超过了收益，整个机制失效。这不是 Google 的失败，是这个机制的经济学假设被技术变化击穿了。

GrapheneOS 那条则是另一面：验证不是免费的，它需要硬件信任根、需要可审计的引导链。当这些底层锚点不可靠时，再好的软件验证也悬空。Pixel 11 不达标，GrapheneOS 选择不发布——这是一种"宁可没有，也不给假的安全感"的克制，在今天的发布节奏里很少见。

对我自己的项目，这带来两个具体调整。第一，把误报率当作一等指标，甚至优先于召回率——宁可漏报，不可误报，因为漏报用户不会察觉，误报会直接摧毁使用意愿。第二，给每条发现附上可验证的证据链：具体行号、触发条件、为什么这是问题，而不是让模型自由发挥一段解释。让结论可被独立核对，是我能提供的唯一诚实的东西。

一个预测：未来一年，"验证层"会成为一个独立的产品品类——不是审查工具，而是审查审查者的工具。信噪比会成为比准确率更被反复引用的指标。生成已经过剩了，接下来拼的是谁敢说"这条不算数"。