一个开源项目维护者凌晨三点合并了一个陌生人的群智漏洞补丁。代码跑通了，群智漏洞测试通过了，群智漏洞他没多想。群智漏洞三天后，群智漏洞全球四万台服务器开始对外发送垃圾邮件。群智漏洞那个补丁里藏了一行几乎看不见的群智漏洞字符——不是恶意代码，而是群智漏洞一个逻辑漏洞，被另一个人发现了，群智漏洞又被第三个人写成了利用脚本。群智漏洞三个人从没同时在同一个聊天窗口里出现过。群智漏洞

这就是群智漏洞群智漏洞。它不是群智漏洞某个人写的bug，也不是群智漏洞某个团队疏忽的产物。它是群智漏洞无数人各自做"正确的事"之后，系统自己长出来的一道裂缝。

我去年参与过一个开源地图项目。社区里有个老哥负责审核道路数据，他有一套自己的判断标准：凡是用户提交的弯道曲率超过某个阈值，他就打回。理由很充分——太弯的路八成是画错了。结果三个月后，有人发现某山区所有的盘山公路都被删了。那些路确实弯，弯得离谱，但它们真实存在。审核者没有恶意，提交者没有恶意，写曲率算法的人也没有恶意。三个善意叠加，制造了一个空洞。

漏洞的可怕之处不在于它被触发，而在于它被触发之前，所有人都在为自己的那部分鼓掌。

安全研究者有个说法叫"攻击面"。群智系统里，攻击面不是代码行数，而是人与人之间交接的缝隙。你写了一个函数，我调用它，他封装了一层。每一层都合理，每一层都信任下一层。信任链越长，末端的微小偏差被放大的倍数就越大。一个参数默认值写错了，经过五层封装，可能变成一场灾难。没人需要犯错，系统自己会犯错。

更麻烦的是，这种漏洞很难归因。你没法说"这是张三的锅"。张三的代码单独跑没问题，李四的测试单独跑也没问题。问题出在他们之间的那根线上。而那根线，谁也不拥有。

我见过一个更极端的例子。某个去中心化存储网络，节点之间靠信誉分互相选择。信誉分高的节点优先被选中，这很合理。但有人发现，只要长期稳定运行、从不作恶，信誉分就会缓慢上涨。于是有人养了一批"好人节点"，跑了半年，信誉分涨到顶端，然后一次性作恶。系统惩罚了它们，但数据已经丢了。设计者说：我们没想到有人会花半年时间伪装。可群智系统的本质就是，总有人愿意花你没想到的时间。

那怎么办？我没见过完美的解法。但有几个方向值得琢磨。一是缩短信任链，能直接验证的就别经过中间人。二是给"合理行为"设上限，一个人再怎么表现良好，也不能获得无限权限。三是承认群智系统必然有漏洞，把精力放在检测和恢复上，而不是幻想彻底堵住。

最危险的心态是：这么多人看着，不会出事的。恰恰相反，人越多，缝隙越多。每个人都觉得别人会发现问题，结果就是没人发现。这不是愚蠢，这是结构性的盲区。

那个凌晨三点合并补丁的维护者后来在issue里写了一段话，我记到现在。他说：我不怪那个提交补丁的人，也不怪自己。我怪的是我们居然以为，一个几千人参与的项目，靠几个人盯着就能安全。

他说得对。群智漏洞不是bug，是feature。是分布式协作自带的代价。你享受了众人拾柴的火焰，就得接受火星子乱蹦的可能。