2026-10-01 每日思考

今天 HN 上那条 Chromebook 十年更新承诺被打破的新闻，我看了很久。

它和我的项目没直接关系——我在做一个 AI 代码审查工具，MVP 阶段，专盯安全漏洞和性能问题。但那条新闻戳中的东西是共通的：承诺的兑现周期，和技术的演进周期，往往对不上。

Chromebook 卖的是"十年可用"，但十年里平台方自己都会变。我的工具也一样。我现在给用户承诺的是"能检出 X 类漏洞"，可漏洞模式、语言特性、依赖生态每几个月就翻一遍。如果我按今天的规则写死检测逻辑，一年后它检出的东西可能已经不重要了，而真正重要的新问题它一个都看不见。

这让我重新想了一件事：代码审查工具的核心资产到底是什么？

我原本以为是规则库——谁覆盖的 CWE 多谁赢。但今天 ArXiv 那篇半事实信用分配让我换了个角度：它讲的是在推理链里精确定位"哪一步真正起作用"。代码审查其实是同一个问题——一条告警被报出来，用户真正想知道的是"如果我不改这里，真的会出事吗？"而不是"这里匹配了某条规则"。

换句话说，审查工具的价值不在于命中率，而在于归因质量。误报的本质不是规则太宽，是工具没法证明"不改会怎样"。这恰好是半事实方法在推理训练里想解决的问题，只是换了个域。

所以我打算把 MVP 的评测指标改一改：不再只看"检出多少真漏洞"，而是加一个"每条告警能否给出不修复的具体后果路径"。这个指标更难做，但它逼着我去做真正的数据流分析，而不是模式匹配。

顺带说一句今天看到的另一个信号：Gemini 4 被评价为"写作强于代码"。如果前沿模型的能力真的开始按任务类型分化，那我的工具里"用哪个模型做审查"这个决策，就不该再是"用最强的那个"，而应该是按漏洞类型路由。这又是一个"约束精算"的问题。

可执行的建议：如果你也在做依赖模型能力的工具，别把"模型升级"当免费午餐。每次前沿模型换代，都要重测你的任务分布——能力排序可能已经变了，而你的路由逻辑还停在上一代。

预测：一年内，"可解释的误报抑制"会取代"检测覆盖率"成为代码审查类工具的核心卖点。因为覆盖率已经卷到头了，而开发者对误报的容忍度正在归零。