「无漏洞、安全的代码现在可以实现了」——这个说法听起来很美，但它恰恰是错的。这是 Eric Raymond 关于 AI 辅助漏洞发现的一番乐观表态下 80 多条回复中的一条。Raymond 认为，人类编写的代码总量是有限的，因此缺陷总量也是有限的；有了「一百万个友好的机器人」帮忙修复，我们就有能力在 AI 层面跑赢攻击者，把软件安全搞定。我完全支持这个方向。问题在于，这被当成了「一场终将结束的捉虫行动」。今天的工具在昨天的代码里挖洞，凭什么认为明天的工具不会在今天我们视为安全的软件里继续挖洞？

对花了几十年为开源辩护的人来说，这是一个有趣的转折。Raymond 让 Linus 定律流行起来：「只要眼睛足够多，所有 bug 都是浅的。」但开源从来不保证有足够多合格的眼睛，说实话，真正愿意去看的人一直很少。AI 终于让更多「眼睛」开始工作——只不过这些眼睛是机器人的。

开源的机会在于我们接下来选择做什么。我坚信今天比以往任何时候都更需要开源：共享代码库让一代代漏洞猎人有个地方贡献修复，而且所有人都能用上。这也是我们集体决定「哪些软件重要、为什么重要」的方式。当再生成一个代码库变得很容易时，这个选择就更重要了。

捉虫不会结束

正如我此前所写，开源代码从来不是天生更安全。它的优势在于：当有人发现问题时，代码和流程足够开放，可以采取行动。

AI 让「发现」这一环变得更有意思。2024 年 11 月，Google 报告称，在已经历数十万小时模糊测试的项目中，用 AI 生成的模糊测试目标又发现了 26 个漏洞。今年 3 月，Mozilla 与 Anthropic 的合作在 Firefox 中发现了 22 个安全漏洞，其中 14 个被评为高危。这些软件已经受过大量审视，但大语言模型仍能挖得更深。这很了不起，但拿它当作「软件漏洞终结」的依据却很古怪。这些发现的教训是：我们的信心跑在了检查能力前面。更好的工具暴露了差距，但百分百没有证明差距已经不存在。

Raymond 的「有限代码」论证绕不开这一点。就算冻结一个代码库、承认缺陷有限，也不代表今天的工具能全部找到，更不代表能证明找到了全部。而且，我们并不会真正冻结生产软件：我们改代码、升级依赖、把系统连到原开发者从未设想过的环境里。那位乐观的评论者也承认，系统间交互和复杂行为中仍会有 bug——这个例外可太大了。对企业来说，它依赖的软件很大一部分正是这些交互。

可读软件只是起点

还有一种相关论调：AI 辅助逆向工程让源码访问变得无关紧要——机器能从二进制里重建可用代码，不就等于一切都开源了吗？并非如此。跑在别人服务器上的软件，未必给你可检查的二进制；看似合理的重建也不等于忠实还原。9 月的一篇研究预印本发现，某些 LLM 反编译出的函数能通过给定测试，却在其他合法输入上表现不同。干净漂亮的代码和原程序不一定是同一回事。

就算逆向工程强得多，反编译器也不会给你项目的测试、设计讨论、构建环境和历史，更不会给你开源许可证。能读实现，不等于有权修改和再分发。这些权利之所以重要，是因为它们让你能对发现的东西做点什么：向上游贡献修复，必要时维护一个分支。专有厂商也能做出色的 AI 审计，共享代码库也不是开源独有。区别在于谁有权参与维护，以及这项工作能否独立于原供应商继续下去。

所以我不认为源码访问可以一笔勾销。更好的机器人眼睛让可用的源码更有价值，但更大的机会一直在于项目本身：由人决定什么值得维护，并分担这项工作。

软件终究要维护

PHP 10 月 21 日的安全版本让这一点无比具体。一位开发者在 2024 年发现了某个底层问题的迹象，其潜在可利用性在原理上已被理解，但当时没有具体攻击路径。修复涉及兼容性、性能和第三方扩展的艰难取舍，专家人力有限、共识流程停滞，工作迟迟推不动。随后 AI 辅助研究展示了问题的完整影响。PHP Foundation 与维护者在受支持版本间协调修复，基金会也承认了资源和决策上的失误。更多机器人眼睛帮助把危险变得具体，但它们没有决定接受哪些兼容性代价，也没有组织发布——是人做的。我们一边大谈把人都自动化出软件开发，一边不断看到为什么需要懂软件、能做决策的人。

我们也该停止那种「AI 让共享代码不再必要」的轻率论调。「我可以用 Claude 构建完美贴合个人需求的软件」听起来不错，直到这些需求包括未来十年维护一个数据库、操作系统或办公套件。很少有企业愿意独自承担这一切，无论智能体多快能产出第一版。

考虑一个智能体修复库中授权漏洞的场景。在共享项目里，这个修复可以变成回归测试、受支持的版本，以及面向所有下游用户的更新。换成一百次私有重写，就有一百个团队得自己判断是否有同样的问题、修复是否站得住。AI 也许让这项工作更便宜，但选择重复一百遍，怎么看都不像进步。

共享代码也有代价：广泛部署的依赖会让缺陷扩散得广，而仓库里的修复在用户安装之前保护不了任何人。这恰恰是支持维护者、认真对待更新的理由，而不是假设公开代码会自己照顾好自己。