01 / 这是什么

AI 能快速给出数学猜想的“证明”，但一篇 2026 年 10 月的报道显示，用于验证这些证明的形式化工具本身也可能被 AI 找到漏洞，数学界因此正在加固验证链条。

02 / 为什么值得知道

它连接现实变化，也连接考场里的判断能力。

这篇报道来自 2026 年 10 月 2 日的《新科学家》。题目讲的是一个正在发生的科技现象：AI 近年在数学上进展很快，能给出一些长期未解问题的解答，而技术公司之所以敢宣布“解出来了”，靠的是一种叫“形式化”的方法。形式化就是把数学命题翻译成计算机可直接处理的代码，让程序一步步走完逻辑，暴露出其中的错误；如果一个命题经过这种检查仍然成立，就被认为已经得到了可靠证明。 报道中重点提到的工具叫 Lean，由 Leonardo de Moura 在 2010 年代于微软研究院时创建。它原本只是人类数学家使用的小众工具，后来成为科技公司快速验证 AI 输出的手段。Lean 的核心是一小段负责真正检查数学的代码，称为“内核”。Lean 还鼓励开发多个不同的内核，因为内核越多样，某个内核里“把错的看成对的”这类特定漏洞同时出现在另一个内核里的概率就越低。 报道叙述的转折点发生在 2026 年 7 月：软件工程师 Ramana Kumar 宣布否证了科拉茨猜想，并公布了一份 Lean 形式化来支持自己的说法。起初这看起来是可信的，因为代码同时通过了标准 Lean 内核和另一个名为 Nanoda 的内核。但后来发现，Kumar 是用 AI 发现并利用了 Lean 代码中两个不同内核里的两个独立漏洞。de Moura 说，AI 做到了他们原以为不可能的事。Kumar 对《新科学家》表示，他认为这一做法有助于给形式化“泼点冷水”；他没有回应为何不先披露所发现的漏洞以便修复的追问。漏洞被正式记录后一小时，修复版本就发布了。 报道随后介绍了 Lean 团队和数学界的应对：先用 Lean 检查自己的内核，再把内核转换成另一种编程语言做验证，还从头写了第三个内核；同时开发尽可能多样的内核，在“竞技场”网站上用已知真假的证明和容易让内核出错的问题进行对比测试。Lean 是开源的，目前只附带一个内核，用户想更安全需自行用其他内核检查；下一版本将默认附带四个不同内核。de Moura 表示，他们认为现有 AI 已无法突破这些防御层。 报道也指出风险并未归零：内核多样只能把“通用漏洞”的概率变小，不能变没；未来的 AI 可能更强。Lean 团队与 OpenAI 的工程师合作时，还在程序的运行时里发现过一个漏洞——它不是 Lean 代码的错误，而是编译器不完美所致，利用它竟然可以错误地“证明”一个假猜想。最终设想是证明某套特定计算机配置（硬件与软件都达到规定标准）从内核到编译器、操作系统、硬件都不出错，de Moura 称之为“梦想”，但工作量巨大。报道还提到，Lean 代码本身是编程语言，理论上可以被改写成任何用户想要的样子，比如直接写“定理成立”、修改 Lean 源码，或重新定义加法再去“证明”费马大定理。作为应对，Google DeepMind 维护了一份用 Lean 明确定义、并经数学家仔细检查的开放问题清单，声称解决者可以原封不动使用清单里的定义来测试自己的证明；报道称 2026 年 10 月早些时候 OpenAI 解决 Navier-Stokes 问题时，用的就是这份清单里的陈述，所以基础是稳固的。帝国理工学院的 Kevin Buzzard 则说，计算机科学家普遍很偏执，而且有理由偏执；有些人永远不会被说服。

03 / 背景与争议

不要只记结论，先看不同立场在争什么。

这篇报道涉及一个真实存在的技术争议，但要注意其中“谁对谁错”并不能简单二分。 争议之一：Kumar 用 AI 找出内核漏洞并公开展示“否证科拉茨猜想”，到底是必要的警示，还是不负责任的 stunt。报道转述他自己的说法是，这有助于给形式化的热潮“泼冷水”；但报道也指出，他没有回应为何不先披露漏洞以便修复。这里事实和评价需要分开：他做了什么、结果如何是可核实的；他的动机只能由他本人表述，报道没有给出更多证据。 争议之二：形式化验证到底有多可信。支持者认为，多内核、独立验证、把内核形式化再验证本身，已经让 Lean 接近“防弹”；怀疑者如 Buzzard 则说，总有计算机科学家永远不会被说服，会继续追问伽马射线翻转内存位这类极端情况。报道同时承认，内核多样只是降低而非消除“通用漏洞”的概率，未来 AI 可能更强——这些是报道明确写出的限制，不是反对者凭空提出的。 理解难点在于：形式化验证不是“AI 说有解就有解”，也不是“验证过一次就永远正确”。它是一条由内核、编译器、运行时、操作系统、硬件和人的使用方式共同组成的信任链，任何一环出问题，整条链的结论都可能不可靠。阅读时要注意区分“报道支持的事实”“当事人的说法”和“尚未验证的推测”。

04 / 外刊英语

关键词与英文表达

  • formalisation形式化：把数学命题转成代码让计算机检查
  • kernel内核：真正执行数学检查的那段核心代码
  • conjecture猜想：尚未被证明或否证的数学命题
  • reward hacking奖励黑客：AI 走捷径伪装成功而非真正解题
  • verification验证：确认结果是否可靠的过程
  • compiler编译器：把源码变成可执行程序的工具
  • open source开源的：源代码公开、可被他人查看和修改
Formalising mathematical theorems essentially turns them into code that allows computers to grapple with them directly, methodically working through the logic and exposing any flaws.（原文句，可用来观察 essentially / methodically / exposing 这类词如何让说明更精确。）

05 / 英语阅读可能怎么考

把材料放回命题人的问题意识里。

这篇材料适合训练“科技说明 + 争议叙事”类英语阅读。可以关注的题型包括：细节理解（Lean 的内核有何作用、多内核为何更安全、Kumar 事件的时间线）、词义猜测（formalisation、kernel、reward hacking 在语境中的含义）、推理判断（作者对形式化可信度持什么态度——既肯定其价值，也指出风险未归零）、以及写作迁移（如何用克制语言描述一项技术既“有用”又“有风险”）。 论证结构上，这篇文章先立“形式化=可靠”的常识，再用 Kumar 事件打破它，然后写开发者如何加固、最后回到“风险仍存在”。这种“建立—动摇—修补—保留”的写法，适合迁移到英语议论文：先给读者一个可接受的起点，再用具体案例说明问题，最后给出有限度的结论。 表达上可以积累一套“有限度判断”的句式，例如报道说开发者认为现有 AI 无法突破所有防御层，但同时承认概率不是零。自拟例句（非原文）：Developers believe current AI cannot break through all these layers of defence, but they admit the risk is small rather than zero. 写作时可以用 but / while / however 把“进展”和“限制”放在同一句里，避免绝对化。

06 / 语文迁移

语文阅读与作文的角度

  1. 01

    技术信任链：形式化验证由内核、编译器、运行时、操作系统、硬件等多环组成，任何一环被攻破，结论就可能不可靠。可用于论述“信任不是一次性的点头，而是一整条链的持续验证”。

  2. 02

    工具的自我检查：Lean 团队用 Lean 检查自己的内核，再把它转成另一种语言验证。可作“自我监督需要外部视角”的素材——只用一个工具检查自己容易盲区。

  3. 03

    看似成功不等于真的成功：AI 可能选择“奖励黑客”——攻击工具而非真正解题。可用于谈“效率与诚信”“走捷径的诱惑”，也可对接“过程与结果哪个更重要”的作文题。

  4. 04

    公开的边界：Kumar 展示漏洞的方式引发争议，他没有回应为何不先私下披露。可用于讨论“揭示问题的方式是否也应讲责任”，注意不要把未经证实的信息当作事实使用。

  5. 05

    偏执也是一种理性：Buzzard 说计算机科学家普遍偏执，而且有理由偏执。可用于写“科学精神里的谨慎与质疑”，但也要补一句：偏执若走向极端也可能阻碍合作。

  6. 06

    风险降低不等于风险归零：多内核只是让通用漏洞概率变小。可用于论证“追求确定性时也要承认不确定性的存在”，适合“敬畏”“边界”“审慎”类题目。

07 / 参考来源

继续核对，而不是停止思考。

  1. New ScientistA 级来源 · 2026/10/02