一次完成的庞加莱猜想形式化
一支四人小团队最近完成了千禧年难题之一——庞加莱猜想——的完整形式化验证。整个工程用 Lean 证明助手写成，总规模约 470 万行代码，其中约 270 万行是最后两周在 AI 协助下集中写出的。成品里没有用任何“sorry”占位，所有内容都通过了 Lean 内核的检查。
这不是数学界第一次对庞加莱猜想给出肯定答案——佩雷尔曼在 2002 至 2003 年已经完成证明，2006 年前后经过几组数学家长达几百页的详细审读，结论才被广泛接受。真正的新变化在于：这一次，证明被翻译成了一台计算机可以逐行核验的语言，而且翻译过程绝大部分由 AI 完成。
这件事对谁有用
这次形式化验证的价值，并不在于再次确认一个早已被数学界接受的猜想，而在于把“数学证明”从一份需要同行花几年逐页审读的文本，变成了一个可以由机器即时判定对错的可执行文件。由此带来三类受益场景。
对数学研究者而言，可执行证明意味着审稿周期被压缩，任何人都可以独立核对每一行推理是否成立，无需依赖作者的口头解释或引用文献中那些“读者应该已经懂”的默认知识。对数学教育而言，形式化后的证明可以作为高年级课程和讨论班的素材，让学生逐步跟着 Lean 学写证明。对软件与系统验证领域而言，这次工作的整套 AI 协作流程——拆任务、派活、验收、骨架先行——本身就是一份可借鉴的工程模板。
更现实的一点是：当一个证明的篇幅超过几百万行时，人类逐行审查已经不可能，但 Lean 内核可以。这让以前“太长太复杂没人敢接”的大定理，重新变得可以被独立验证。
关键技术拆解
整个工程的代码量结构，可以从三个层次看。
第一层是佩雷尔曼三篇论文对应的内容，加起来约 66 万行，只占总量的六分之一。第二层是数学共同体默认“读者应该懂”的基础数学——分析学约 109 万行，微分几何约 77 万行。其中 Ricci 流短时存在性这一定理单独占用了 89 万行，因为 DeTurck 技巧所需的 Sobolev 空间、谱理论等工具都必须从零写起。第三层是整个工程的“重量级选手”——典范邻域定理本身就用掉 272 万行代码，占整条依赖链的三分之二。
AI 在其中的角色分工是这次工作最值得参考的部分。整个系统分为三层：最上层是“领队”，它不写证明，只守住数学路线，决定接下来该证什么；中层是常驻后台的“调度”智能体，负责把大目标拆成可派发的小任务，并在收到结果后做验收；最下层是一批做完即退出的临时智能体，负责具体地写证明、挑错、查资料。人类作者位于最顶端，只负责选定义、定命题，以及确认 Lean 里证出来的东西没有偏离数学原意。
这次用到的主力模型是 ChatGPT Astra 用于通用写作，Claude Fable 用于啃硬骨头，OpenAI 的编程智能体 Codex 负责按派工单写代码。冲刺阶段，团队采取“骨架先行”策略——先把整段证明的接口搭好，证不了的地方暂时用 sorry 占位，让结构问题尽早暴露，再逐一替换为完整证明。这些占位文件单独存放，所以最终进入主库的代码里一个 sorry 也没有。
如何用起来
对希望复现或参与类似工作的读者，工程团队已经把大部分基础和工具开放了出来。
第一份可参考的代码库是团队放在 GitHub 上的 differential-geometry 仓库，里面包含约 200 万行用于补齐 Mathlib 中缺失的微分几何基础工具的代码，例如黎曼几何和 Ricci 流相关定义。这是任何想从零开始形式化几何定理的人绕不开的起点。第二份资源是同仓库里的 auto-formalizing-skills 目录，沉淀了团队把自然语言证明翻译成 Lean 时的提示词与工作流模板。第三份资源是 Ben Chow 的个人页面 LeanOnMe，列出了线上学习班的全部讲义与练习。
对学习者来说，上手顺序可以这样安排：先在本地装好 Lean 4 与 Mathlib，跑通官方教程里的基本例子；然后用 LeanOnMe 的讲义熟悉 Ricci 流相关的形式化定义；接着克隆 differential-geometry 仓库，尝试只读浏览其中几个定理的证明，理解“基础分析 + 几何对象 + 大定理”这三层结构；最后在 auto-formalizing-skills 仓库里挑一个小例子，测试 AI 模型对一段数学叙述的翻译质量，再考虑扩展到自己的课题。
需要注意，这次冲刺能跑通，依赖的是团队成员之一长期与多家模型厂商保持直接沟通，模型本身的代码与上下文能力也在 9 月份刚好达到所需门槛。个人或小团队复现时，模型选型和上下文窗口长度仍是首要约束。
选择标准与成本考量
对任何打算把 AI 用于大型形式化项目的团队，以下几个标准值得提前评估。
模型能力上，要看候选模型能否稳定写出符合 Lean 语法、可被编译接受的代码段，以及在长上下文里是否仍然能记住前面的定义与未证命题。流程设计上，要从一开始就区分“守路线的领队”“拆任务的调度”“干活的临时工”三层，让人类作者只承担选定义、定命题和最终审阅的工作，避免 AI 在关键数学判断上越权。质量控制上，必须坚持每一段证明都通过 Lean 内核检查后再并入主库，任何“sorry”占位都要单独存放，绝不能混入最终交付物；遇到命题不成立时，应按约定停下并给出反例，而不是修改命题使其可证。
成本方面，这次工作的代码量折算下来相当于一个中等规模软件项目，但人力只有四人和若干 AI 智能体。主要开销集中在两个阶段——为补齐基础数学而长达七个月的预写阶段，以及最后两周需要大量 AI 算力的冲刺阶段。前者吃的是人月，后者吃的是 token。
落地建议是：先用三个月左右写出一个约 50 万行的最小可运行骨架，验证团队 AI 协作流程是否顺畅，再决定是否扩展到完整规模。在扩展过程中，把“哪些证明必须由人来写、哪些可以放心交给 AI”这一边界尽早固定下来，比单纯提高代码量更重要。这次工作证明，当分层结构清楚、AI 角色分工明确、人类守住数学判断权时，AI 协助下的大型形式化项目已经从概念变为可交付的工程实践。