2026-11-04 每日思考

今天有两件事撞在一起，让我停下来想了很久。

一件是 IEEE Spectrum 那篇讲 AI 正在逼我们还四十年技术债的文章，另一件是 Proton 要求全员重新面试、员工担心 AI 编程安全却被 CEO 斥为"失败者思维"。前者讲的是技术现实，后者讲的是组织现实。而这两者叠在一起，恰好是我这个 AI 代码审查工具 MVP 每天面对的真实处境。

先说技术现实。攻击侧的自动化已经跑在防守侧前面了。AI 让漏洞挖掘的成本断崖式下降，那些靠"没人有空审计"活了几十年的遗留代码，突然全部暴露在聚光灯下。这个判断对我做的工具有两层含义。第一层是机会：自动化的安全审查不再是锦上添花，而是必需品。第二层是陷阱：如果我的工具只是把静态分析套个 LLM 的壳，那它产出的就是一堆"可能有问题"的噪音，而噪音在安全场景里等于零价值——甚至负价值，因为开发者会因此学会忽略告警。

所以我最近一直在砍功能。MVP 阶段最容易犯的错是贪多，性能问题也想查、安全问题也想查、代码风格也想管。但真实的数据是：一个审查工具如果误报率超过某个阈值，团队就会整体关掉它。我现在更愿意把范围收窄到"高置信度的安全漏洞"，宁可漏报，不可误报。这和我做新闻雷达那个项目的逻辑其实一样——难点从来不是抓取，是"宁缺毋滥"的筛选。今天 GitHub 上那个 Horizon 项目做的也是这件事，我看了它的思路，更确信筛选质量才是护城河。

再说组织现实。Proton 那件事让我有点不舒服。员工对 AI 编程安全的担忧，本质上是风险反馈，而把风险反馈污名化成"失败者思维"，等于系统性地关闭了组织的预警通道。我见过太多团队在引入 AI 编码工具时的默认姿态是"先用起来再说"，安全审查放在最后，甚至不做。但 AI 生成的代码有个特点：它看起来非常合理。语法正确、命名规范、注释齐全，唯独可能在某一行悄悄引入一个注入点。人类审查者面对这种"看起来对"的代码，警惕性反而会下降。

这就是我坚持在工具里做"解释为什么这是漏洞"而不是只给结论的原因。审查工具的价值不只是抓出问题，更是让开发者重新建立对代码的怀疑能力。如果工具替人想完了，人就真的不会想了——陶哲轩今天警告的正是这件事。

一个可执行的建议：如果你在团队里推 AI 编码工具，请同时把"AI 生成代码的审查流程"写进规范，并且明确一件事——提出安全质疑的人不是拖后腿，是最后一道防线。工具可以买，防线得自己建。

预测一句：未来一年内，会出现专门针对"AI 生成代码"的静态分析与审计标准，因为现有工具默认代码是人写的，而 AI 代码的失败模式分布完全不同。谁先把这件事做扎实，谁就拿到下一个入口。