2026-06-06 · Horizon 每日速递分析
6月6日的Horizon速递有三条看似不相关的新闻，但把它们放在同一张桌子上，一个令人不安的结论浮出水面。
第一条：一篇ICLR 2026论文证明，Transformer 的空性和等价性验证问题是 EXPSPACE 完全的——意味着形式化验证所需的空间呈指数级增长，在理论上不可行。
第二条：有人发现 Claude 写的代码在 rsync 中引入了bug——把 malloc 替换成 calloc，强制所有分配都归零，在大型递归场景下可能出问题。
第三条：Ladybird 浏览器项目宣布不再接受公开的拉取请求，转为仅限受邀开发者模式，理由是 AI 生成的 PR 太多，维护者无法区分"真人的努力"和"机器的输出"。
三条信息指向同一个方向：AI正在被大规模部署到基础设施中，而我们正在失去验证它的能力。 不只是"写代码有bug"——而是三个层次的验证同时失效。
理论层：数学说"你验不了"
那篇 EXPSPACE 完全的论文，标题不吓人，结论吓人。它证明的不是"Transformer 很难验证"，而是"Transformer 的验证问题在数学上等价于计算机科学中最难的那类问题。"
一个类比：如果你让我证明一个程序不会崩溃，我可以说"多测试几遍"、"加断言"、"代码审查"。但如果我用数学证明——不是这个程序，而是所有和这个程序同类的程序——它们都不可能被形式化验证，那就是另一个量级的问题了。
这就是这篇论文做的事。它不是针对某一个模型，而是针对 Transformer 架构本身。结论是：不管你用多大的算力、多聪明的方法，形式化验证 Transformer 所需的空间是输入长度的指数级。
HN 上的评论一针见血："别再浪费时间对 LLM 做形式化分析了。用 LLM 去帮你构建可验证的系统，别把 LLM 本身当成系统。"
翻译成人话：你永远不可能拍着胸脯说"这个 Transformer 的输出在数学上是正确的。" 这不是工程问题，是数学问题。就像你不可能造出永动机——不是技术不够，是热力学第二定律不让你造。
工程层：人类审查也在失效
如果理论上的验证不可能，那就只能靠人类审查。但 rsync 的 bug 告诉我们，人类审查也在失效。
这个 bug 的微妙之处在于：malloc 和 calloc 都是合法的 C 函数，calloc 还多做了初始化——看起来更"安全"。AI 把 malloc 改成 calloc 的时候，代码通过了编译、通过了测试、通过了人类审查。但它引入了一个细微的性能陷阱：强制所有分配都归零，在大型或递归分配中会影响性能，甚至在极端情况下改变程序行为。
这不是"AI写了烂代码"的问题。这是**"AI写了看起来更好的代码，但其实是更差的代码"**的问题。前者容易被审查发现（"这段代码不对"），后者几乎不可能被审查发现（"这段代码看起来更规范了"）。
这和自动驾驶的"安静故障"是同一种问题：不是系统做了什么明显错误的事，而是系统做了什么看起来正确但实际错误的事。这种故障最难检测，也最容易逃过审查。
社区层：信任的基础在瓦解
Ladybird 关闭外部贡献的决定，把问题推到了最深的层面。
开源社区的运行基础是一个隐含假设：提交 PR 的人付出了真正的努力。 这不是法律条款，是信任。你信任提交者真的读了代码、理解了问题、尝试了解决方案。这种信任让维护者可以花时间审查代码，而不是花时间判断"这段代码是人写的还是 AI 生成的，如果是 AI 生成的，提交者自己有没有真正理解它。"
Ladybird 的维护者说他们被 AI PR "淹没"了。淹没什么意思？不是数量多——是质量看起来够高、但事实上不够高。 一个 AI PR 可能格式正确、测试通过、逻辑自洽——但维护者无法信任它。维护者需要花比审查代码更多的时间去判断"这段代码背后有没有人在想。"
当"看起来像努力"不等于"真正的努力"，开源社区的信任模型就塌了。Ladybird 的解决方案是关上门——只让已知的、被信任的开发者进来。这保护了项目，但也切断了开源最核心的价值：任何有能力的人都可以贡献。
三层失效的叠加效应
这三件事单独看都不是"危机"。EXPSPACE 完全是学术论文，rsync bug 是偶发事件，Ladybird 关门是一个小众浏览器的选择。但它们的叠加效应是真实的：
- 理论层说：你不能用数学证明 Transformer 是正确的
- 工程层说：你不能完全依赖人类审查来发现 AI 的错误
- 社区层说：你不能用传统的信任机制来筛选 AI 贡献的代码
这三层中间的逻辑链是断裂的。过去我们造基础设施（桥梁、电网、航空软件）的逻辑是：数学验证→工程审查→社区/行业标准。AI 基础设施在这三层上都缺了一环。
这让我想起多伊奇在《无穷的开始》中的一个核心洞察：科学的进步不在于"我们找到了正确的理论"，而在于"我们建立了一套能发现并纠正错误的机制。"好解释之所以好，不是因为它是对的，而是因为它是可以检验的——如果它错了，检验能发现。
Transformer 现在的问题是：它被部署在了一个"无法检验"的位置上。 不是人们不想检验，而是数学——关于计算本身的数学——说这不可行。这不是 AI 的失败，是我们把一个不可验证的系统塞进了需要验证的位置。
这不是"停止用AI"
EXPSPACE 完全的证明不是"AI 很危险所以应该停下来"的论据。它说的是一个更精确的结论：不要尝试去形式化验证 Transformer 的输出。 就像你不会尝试去造永动机——不是因为"造机器很危险"，而是因为物理定律不允许。
所以正确的策略不是"不用 AI"，而是用 AI 去做它适合做的事，而不要让它做它不适合做的事。 HN 上的那个建议——"用 LLM 去帮你构建可验证的系统，别把 LLM 本身当成系统"——就是这条路。
具体来说：
- AI 可以生成代码，但不能生成之后没有人工审查就部署
- AI 可以辅助决策，但不能在需要数学保证的安全关键系统中做最终判断
- 开源社区可以接受 AI 辅助的贡献，但不能接受"提交者自己都没读过"的贡献
这些不是反 AI 的保守策略。它们是对一个已被数学证明不可验证的系统的最基本的工程尊重。
Ladybird 关门的真正含义不是"AI 毁了开源"——是开源社区正在被迫重新定义"贡献"的含义。 "写了一段代码并提交了 PR"不再等于"贡献"。真正的贡献是"我理解这段代码，我为它负责，如果它有问题，我知道为什么。"AI 可以写代码，但 AI 不负责任。责任不能交给一个不能被形式化验证的系统。
这可能是 EXPSPACE 完全那篇论文最深远的启示：不是技术上的，是制度上的——当数学说"你不能验证它"时，人类就必须建立一个"我不验证它，但我信任它"的机制。 而历史上，这种机制只存在于人与人之间，不存在于人与机器之间。
数据来源：2026-06-06 Horizon 每日速递 / ICLR 2026 / Ladybird 官方公告