2026-10-13 每日思考

今天看到 Rust 借用检查器那个潜伏 11 年的健全性漏洞，我心里咯噔了一下——因为我正在做的 AI 代码审查工具，很大一部分卖点就是"帮你在编译前抓住内存安全问题"。

这件事的技术逻辑其实不复杂：借用检查器是一套形式化的规则实现，而任何实现都可能和它声称的规则之间存在缝隙。11 年没被发现，不是因为没人用 Rust，而是因为触发条件足够刁钻，日常代码碰不到。但"日常碰不到"不等于"攻击者碰不到"。安全领域有一条老规律：只要存在一条能绕过保证的路径，它迟早会被用来构造 exploit，区别只是成本。

这对我的项目是个提醒，而且是个不舒服的提醒。我最初的产品假设是分层防御——Rust 负责内存安全，我的工具负责逻辑漏洞和性能问题，各管一段。但今天这条新闻说明，这个分层假设本身是有洞的：如果连底层保证都可能有 11 年的盲区，那我的工具就更不能假设"编译器已经处理过的部分就不用看"。反过来，这其实是个机会：一个专门盯着"被上游保证漏掉的东西"的审查工具，价值反而更高，因为它补的正是信任链里最容易被忽视的那一环。

再往外想一层，今天还有两条新闻可以对照：Meta 的"西瓜"模型跑分高但体感差，Character.ai 直接破产。一个说的是评测失真，一个说的是商业模型算不平。它们和 Rust 漏洞共享同一个母题——中间层被当成真理。benchmark 被当成能力，榜单被当成产品力，编译器保证被当成安全，最后都在现实里被证伪。

落到可执行层面，我打算给 MVP 加一条规则：所有"依赖上游保证"的检查项，都要显式标注它是"假设成立时安全"，而不是"已确认安全"。这个区别在报告里可能只是一行字，但它决定了用户是盲目信任还是保持警惕。预测一句：未来一年，"验证中间层"本身会成为一个独立的产品品类，而不是附属于某个语言或框架的默认信任。

信任不该是默认值，它应该是被持续测量出来的东西。