UTPS形式化验证之路：用Lean 4构建完整数学证明体系

UTPS 这个缩写乍看有点神秘，第一次在朋友圈刷到《贾子 UTPS 完整数学证明体系》这个项目名时，我还以为是某个偏微分方程数值解算器。结果点进去才发现，它讨论的是一整套面向非标准分析场景的数学理论框架，并且作者给它配了一个雄心勃勃的目标：用交互式定理证明器把这套体系从公理开始，一步步形式化验证到底。

我当时的第一个反应是，这活儿太大了。做形式化验证的人都知道，把一个成熟的数分教材形式化都够一个博士团队忙活好几年，更别说一套自洽的公理体系、包含无穷小与无穷大运算规则的完整证明系统。但反过来想，如果 UTPS 真有原创的理论内核，那在当下这个依赖大数据和自动推理的时代，给这套体系嵌进一个机器可检查的证明内核，反而是它区别于普通数学笔记的关键分水岭。这篇文就是想从工程和理论两个角度，拆一拆如果我们要把 UTPS 完整形式化落地，路该怎么走、坑会在哪里、工期和工具链应该怎么选。

1. UTPS 的数学内核到底是什么：先把混沌的标题翻译成工程语言

很多朋友看到“完整数学证明体系”这种短语，第一反应是数学论文，第二反应是哲学讲义。但把它拿到形式化验证的语境里，UTPS（Unified Theory of Point and Segment，统一点段理论，或根据作者实际定义调整）真正值得被形式化的，是三块核心资产：

• 一整套自定义的对象类型体系，而非直接借用实数集或自然数集，比如“点”“段”“邻域”“无穷小量”这些对象在 UTPS 里有独立的结构化定义；
• 一套处理无穷小和无穷大的运算规则，这部分和经典的非标准分析思路有亲缘关系（罗宾逊的超实数、内集理论），但 UTPS 可能有意选择了更贴近柏拉图主义几何直观的表述方式；
• 从对象定义到核心定理（连续性、完备性、可微性等）的完整推导链，这部分是“证明体系”四个字的底气所在。

把这三块翻译成形式化验证工程的输入，就是三个决定项目成败的早期选择：用什么逻辑内核、用什么类型论、怎么建模“个体”与“集合”之间的关系。

我在搭建自己项目的理论层时踩过一个很大的坑：一开始总想去适配定理证明器已有的实数库，觉得能省时间。但形式上我们要验证的不是经典数学分析，而是一套可能有自定义无穷小规则的新体系，直接用标准实数库反而会引入一堆用不上的公理，严重的还会在定义处和 UTPS 的无穷小对象产生公理冲突。正确的做法是，在一开始就接受“从零建立对象层”的成本，把 UTPS 的“点”和“段”看成和自然数、实数平级的基础对象，自己定义归纳类型和运算规则，而不是去教科书库里找一个蹩脚的替身。

2. 形式化证明工具选型：Lean 4 还是 Coq 还是 Isabelle，为什么我倾向 Lean

技术选型不应该是写代码前最后一刻才拍脑袋的决定。UTPS 形式化体系涉及大量自定义代数结构、拓扑结构、序结构，在主流证明助手里，Lean 4、Coq、Isabelle/HOL 都能跑通，但体验差异非常大。

我在几个项目里分别用 Coq 和 Lean 4 写过拓扑相关的证明。Coq 的强项是策略语言丰富、历史积淀厚，三代人积累的数学库让基础归纳写法更稳健；Isabelle/HOL 则在文档生成和可读性上占优，适合把证明写成接近教科书风格的版本；Lean 4 的优势在于编译速度、宏系统、以及 Mathlib 里大量现代数学结构自动化的能力，尤其适合那些需要在对象层疯狂自定义代数结构的项目。

UTPS 要处理无穷小对象和点段几何结构，这类对象的层级比较深，类型类的隐式推导在 Lean 4 里非常好用——我可以在底层定义 “Point” 和 “Segment” 这两个类型，然后通过类型类自动给它们附加加法、乘法、偏序、拓扑结构，而不是为每个操作手动穿针引线。

具体到搭建 UTPS 的形式化骨架，我的建议是这样的：

我最后定下来的是 Lean 4，核心原因有三个：第一，Lean 4 的宏机制让定义一套类似 “点段符号” 的自定义记号系统非常灵活，UTPS 的理论表达可以更接近原论文；第二，Mathlib 里面的网（net）和滤（filter）体系，能让我不必重造轮子就能定义邻域和收敛；第三，Lean 4 社区近几年对非标准分析、超实数相关主题的讨论频率在增加，遇到问题更容易找到同路人。

3. UTPS 公理层落地：当数学公理遇上 Inductive Type 时的边界拉扯

这一章是整个工程最关键的部分。UTPS 作为一套新的理论体系，必然有自己的公理系统。而形式化验证一个公理系统和从零写一个数学定义完全不同，它要求你把每条公理转化为类型论里可以直接判定的语句——也就是说，你得把“点存在、段由两点确定”这种看似显然的陈述，逐条翻译成可计算、可比较、可推理的严格形式。

我尝试过把 UTPS 的公理翻译成 Lean 4 的 inductive type 时会遇到两类冲突：
一类是“存在性公理”与“构造性逻辑”的冲突。UTPS 如果包含类似“对任意非空集合，存在一个点作为它的聚点”这种经典实分析式陈述，在 Lean 4 的默认逻辑里不能直接用，因为 Lean 是构造性逻辑（带 Choice 时除外）。这个时候必须做出选择：要么引入经典 choice 公理，要么把命题翻译成带有存在对象映射的形式，显式地构造那个聚点。前者省事，但会削弱建造过程的可计算性；后者工程量大，但理论上更纯净。UTPS 的完整证明体系如果强调“构造性”，那就值得专门走纯粹路线，否则直接用 Classical.choice 也不是不行——重点是要在项目文档里把这个选择标出来，别让机器检查者在下游某个地方突然报出一个公理依赖错误。
另一类是“几何直觉”与“类型限制”的冲突。点、段、线的关系在几何直觉里是连续的，但 inductive type 的要求是可枚举的构造规则。所以在 Lean 4 里建模“线段”时，不能直接定义一个无限集合的拓扑结构，而要先定义出一个 Segment 类型，其成员要么是单点、要么是两个端点之间的开/闭区间对象，然后在类型层面外挂连续性公理。这个过程不能图省事直接引入经典实数库，必须让 Segment 成为一套独立的自定义归纳类型，否则后续想证明 UTPS 独有的“无穷小微积分基本定理”时，会被实数库的完备性公理绑得死死的。

实际动手做的时候，我建议按“五层架构”来组织代码仓库：

五层架构的妙处是，每一层都能独立检查和调试。我不会在自己还没把对象层稳定下来时，就去写核心定理的证明，否则一旦底层算法变一下，上面几百行证明脚本就全塌了。UTPS 这种完整体系必须按照层级推进，每层提交前都要跑完 vet 检查。

4. UTPS 中的“无穷小”对象：比非标准分析更激进的场景怎么建模

UTPS 这套体系如果只和经典实分析一样，那就没有太大形式化的必要。它真正有意思的地方在于无穷小和无穷大的运算规则。传统非标准分析用超滤子构造超实数，但那个构造在证明助手里实现起来非常痛苦，因为要处理选择公理、超滤子存在性和商结构等一系列高难度设施。

我为了在自己的理论框架里跑通类似机制，试过两条路：

第一条路，直接在 Lean 4 里定义超滤子、自然数幂集、商结构，用 *-embedding 嵌入实数得到超实数。这条路的好处是理论正宗，证明体系完备；缺点是需要形式化不少集合论与模型论知识，工期会肉眼可见地膨胀。如果 UTPS 的“无穷小”定义与经典超实数完全一致，那这条路的终点最稳。

第二条路，用一种更轻量级的“公理化无穷小”方案：不显式构造超实数域，而是直接给无穷小定义一个公理接口，声明存在一个无穷小量、无穷小相加依然是无穷小、单位区间内有无穷多个无穷小可排序等基本性质。这样对象层更薄，证明工作会更集中在最终的拓扑性质上。UTPS 的完整证明体系如果要避开超滤子，我认为这条路反而是它的正解——尤其是当你的重点在“几何直觉完整性”而不是“模型论构造性”时。

在工程实现层面，轻量方案里的无穷小对象可以用一个自定义 inductive type 的 Limit 符号和基础量组合起来，配合 Lean 4 的 [Poset] 或 [LinearOrder] typeclass 去推算大小关系。关键是所有关于无穷小的命题必须落在“标准部分”和“非标准部分”的映射关系上，否则后续做微分的时候会寸步难行。

5. UTPS 形式化的核心定理链条：从完备性到不动点，机器可检查的证明怎么写出来

形式化验证项目的衡量标准从来不是“有没有写够代码量”，而是“有哪些核心定理过了机器检查”。对 UTPS 体系来说，我认为最值得优先攻克的四个定理如下：

• 连续函数在紧致区间上的有界性定理
• UTPS 版本的中值定理（无穷小定义下的导数）
• 完备性（戴德金完备或 UTPS 自定义完全性）
• 某个固定映射（像压缩映射）在完备空间中的不动点存在唯一性

这些定理链的证明写起来有很强的套路：先确立对象层的两个关键引理（比如有限覆盖引理、无穷小逼近引理），然后敲定理证明。在 Lean 4 里，如果你前期代码结构没污染，这个阶段主要是在跟策略脚本搏斗，而不是在跟模型理解搏斗。下面我贴一段自己写过的极小例子（不是直接对应 UTPS 但思路完全一致），展示“连续函数在紧致区间中有界”这类定理的形式化起点：

lean复制-- 一个极简的连续性与有界性衔接示范
import Mathlib.Topology.Basic
import Mathlib.Analysis.Calculus.Continuous

universe u

variable {X : Type u} [TopologicalSpace X]
variable {𝕜 : Type u} [LinearOrderedField 𝕜]

/-- 这种定义表达的是：在点 x 处连续 = f x 是 f 在 x 处的极限 -/
def IsContinuousAt (f : X → 𝕜) (x : X) : Prop :=
  ∀ ε > 0, ∃ U ∈ nhds x, ∀ y ∈ U, |f y - f x| < ε

/-- 紧致上的连续实值函数一定有界（这个例子省去了很多结构，只为展示证明骨架） -/
theorem continuous_on_compact_bounded
    {K : Set X} (hK : IsCompact K)
    {f : X → 𝕜} (hf : ∀ x ∈ K, IsContinuousAt f x) :
    ∃ B, ∀ x ∈ K, |f x| ≤ B := by
  classical
  -- 紧致性可以通过有限子覆盖来逼近
  -- 在这下面写完整证明需要拓扑库中 finite_subcover 的引理链
  sorry

UTPS 不是单纯为了证明而证明。它有“完整数学证明体系”的名头，也就意味着它的形式化版本必须具备相当的可读性、可审计性和可扩展性，不是给机器交差就完事。所以核心定理的证明脚本里，我习惯在重点步骤旁加注释，并且用一个单独的 README 文件登记“哪些定理已证明、哪些尚在推进、哪些卡在哪个引理上”，方便团队或后续维护者快速接手。这种“证明账簿”在一个长期项目里，价值不亚于证明本身。

6. 时间投入与团队配置：别在第一天就决定证明所有定理

我见过太多形式化项目死于贪大求全。UTPS 如果真的是一套完整理论体系，那么从零到核心定理全过机器检查的预估工期，对单人开发者来说，合理范围是 12-24 个月，前提是每周稳定投入 15-20 小时；如果有 2 人协作、且有一人有 Lean 4 实战经验，能压缩到 6-10 个月。为什么时间差这么多？因为大部分时间不是花在构思公理或弄懂数学含义，而是花在调试策略脚本的排列组合、处理隐式参数、收拾每一次底层定义微调引发的证明雪崩。

个体户路线的时间线大致可以掰成这么几段：

• 第一个月：搭建对象层和公理层，定义 Point/Segment 和十几条公理，产出项目骨架；
• 第二到第四个月：集中打运算层和命题层，把 UTPS 的加减法、距离、邻域等运算定义清楚，完成前两个简单引理的形式化验证；
• 第五到第七个月：攻第一个核心定理，这期间会大量重构底层定义，因为你会发现原来公理层的某个表述没法支撑后期证明；
• 第八个月往后：连续攻克剩余核心定理，并回溯修补。

如果是团队作战，我强烈建议在结构上采用“并行分离”策略：一个人盯着对象层和运算层打磨，另一个人拿着论文在命题层推演证明草图、把细节写成 Lean 可以翻译的伪代码。两边每天同步一次，避免出现证明逻辑和最终代码脱节的灾难。

7. UTPS 形式化路上的典型暗坑：我把踩过的都列出来

7.1 底层定义“欠规范化”，导致证明雪崩

在写形式化项目时，最反直觉的教训是：数学越接近日常直觉，形式化时越需要小心。因为一个看似无害的语义模糊（比如 Segment 包不包含端点）会在定理证明的第 200 行突然蹦出来，导致前面一大半证明脚本失效。

我处理这类问题的方法是，在定义对象时就写一圈“定义自检引理”。比如定义完 Segment 以后，立刻验证 segment_ne_of_distinct_points 和 point_mem_segment_of_eq 这两个引理——它们看起来显然，但其作用是保证定义本身行为稳定。如果连自检引理都歪了，那肯定不是证明技术问题，而是定义错了，尽早纠偏的成本最低。

7.2 贪图巧妙的自动化策略，写了看不懂的证明

Lean 4 的 omega、linarith、aesop 这类自动化策略很好用，但如果不加节制地使用，会写出一堆“让机器觉得显然但人无法复核”的证明。UTPS 这种完整体系需要接受长期检查和他人阅读，证明可读性的价值有时候超过了证明精简化。过度使用自动化策略，后期维护就是一个灾难现场。

我给自己定了个铁律：关键核心定理的主线证明必须用有明确语义的基本策略（apply, intro, exact, calc）逐行推进，只在琐碎的算术/正则表达式场景里才把自动化策略放进来。这样读证明的人能一步步看到 UTPS 的逻辑推进路径，而不是面对一个黑盒。

7.3 直接依赖 Mathlib 的经典数学结构，却忘记了公理体系的独立性

UTPS 如果真的想作为一套有原创性的完整体系，它的公理层不应该悄悄混入和标准实数相关的默认设定。用 import Mathlib.Analysis.Calculus.Continuous 不代表你应该默认使用经典实数公理体系。解决方式是严格控制 import 的范围，尽量只使用 Mathlib 中的基础类型论、拓扑结构、代数结构，避免直接引入某个完整的数学分支库。或者说，必须在项目的 README 里显式声明哪些 import 仅用于辅助，不参与 UTPS 公理体系的构建。

7.4 不做版本冻结，导致一夜回到解放前

Mathlib 是滚动更新的。我这半年至少碰到两次，Lean 4 的版本升级导致同一个项目里的证明脚本大面积失效——不是逻辑错了，是接口改名了。UTPS 这种历时一年以上的项目，一定要固定 Lean 版本和 Mathlib 版本，最好用项目级的 lakefile 锁定依赖。宁可晚点享受新功能，也别在核心定理冲刺期被一个上游改动杀得措手不及。

8. 一版可执行的 UTPS 形式化启动清单

无论你自己是 UTPS 的作者，还是想把某套完整数学理论形式化的研究者，启动一个这样的项目，我建议照下面这几步走：

1. 用一周时间通读 UTPS 的论文原文，列出所有对象、公理、定理，按依赖关系画一张“非图片版”的分层清单（对象在前，命题在后）；
2. 选定 Lean 4 版本，用 lake 创建项目骨架，搞定依赖锁定；
3. 从对象层开始逐条翻译，先把 Point、Segment、Region 等类型定义完，不急着写公理；
4. 公理层每写一条，立刻写一个自检用例（构造一个满足该公理的最简单实例），确保不是空转；
5. 运算层完成后，开始跑第一个简单引理，目标是建立一条“对象到对象”的证明链；
6. 把核心定理拆成更小的引理建议，优先完成铺垫性引理，再碰主定理；
7. 每一步提交前都跑完整的 #check 与 #print axioms，确保没有混入预期之外的新公理——这是 UTPS 体系独立性的最后防线。

提示：如果中途发现原论文某个命题和机器检查结果对不上，先不要急着改代码去迎合机器。绝大多数情况是原论文的某个隐含假设没有写清楚，这时候补充形式化描述，反而是在帮 UTPS 自己的理论打磨严谨度。这是任何一个完整证明系统在面对机器裁判时都会经历的成长过程。

形式化验证 UTPS 这种完整数学体系，本质上是在给一套理论建立一座从直觉到工艺的桥梁。表面上看是在敲验证代码，实际是在逼问每个概念：你到底是什么意思？你有没有边界条件？你和系统中其他对象的关系是什么？这个过程比写一百页论文更能锤炼理论的精密度。不要指望所有目标一年内全部达成，更不要因为第一个核心定理卡了两周就怀疑项目价值——机器检查的残酷与诚实，恰恰是这套体系未来能立足的信任基石。等你真的跑通了 UTPS 在紧致性、完备性、不动点定理这些关键节点的机器证明之后，再回头看当初的设计文档，会明显感觉到整座理论建筑都变得更结实了。