大语言模型（LLMs）通过结合其强大的语义理解、代码生成能力与依赖类型系统（如 Lean、Coq）的符号推理引擎，实现了证明自动化的显著突破。其核心机制是让 LLM 充当"证明策略生成器"或"证明助手"，自动生成或补全证明步骤，从而大幅降低人工编写证明的负担。
一、核心实现方式
| 实现方式 | 核心原理 | 典型工具/案例 | 优势 |
|---|---|---|---|
| 战术推荐与生成 | LLM 将非形式化的证明意图或当前证明状态（Goal）转化为依赖类型系统能执行的证明策略（Tactic）序列。 | LeanCopilot、PALM方法 | 直接集成到证明交互环境，提供实时、交互式的证明建议。 |
| 全自动证明搜索 | LLM 结合符号推理引擎（如 Aesop），通过生成大量候选证明路径或前提优化，进行深度和广度兼具的自动化搜索。 | Seed-Prover系统、LeanCopilot+Aesop 流水线 | 能处理更复杂的定理，证明能力更强，自动化程度高。 |
| 代码与证明协同生成 | 在编写依赖类型程序时，LLM 同时生成满足类型规范（即命题）的代码及其正确性证明。 | 使用 LLM 在 Lean 中编写 Zstandard 解压缩器并自动生成证明 | 将"编程"与"验证"过程统一，提升高可靠性软件开发的效率。 |
二、关键技术流程与代码示例
一个典型的 LLM 辅助证明自动化流程如下，以 Lean 语言为例：
- 状态解析：系统将当前的证明目标（Goal）和上下文（Context）以文本形式提供给 LLM。
- 策略生成：LLM 基于对数学逻辑和 Lean 语法的理解，生成可能的证明策略。
- 策略执行与验证：依赖类型系统的内核（Kernel）执行策略，验证其正确性。如果失败，可反馈给 LLM 进行迭代。
lean
-- 示例：LLM 辅助证明一个简单命题
theorem simple_arithmetic (a b : Nat) (h : a = b) : a + 1 = b + 1 := by -- 当前证明目标: `a + 1 = b + 1`
-- 上下文: `a : Nat`, `b : Nat`, `h : a = b`
-- LLM 可能生成的策略: `rw [h]`
rw [h] -- LLM 建议使用 rewrite 策略，利用假设 h 将 a 重写为 b -- 证明完成，目标变为 `b + 1 = b + 1`，由系统自动验证为真。在更复杂的系统中，如 LeanCopilot，LLM 被深度集成：
python
# 简化示意：LeanCopilot 调用 LLM 生成策略的流程
def suggest_tactics(goal_state: str) -> List[str]:
prompt = f"""
你是一个 Lean 定理证明助手。当前证明状态如下：
{goal_state}
请给出可能推进证明的 Lean 策略。只输出策略代码。
"""
# 调用 LLM API（如 GPT-4, Claude）
llm_response = call_llm_api(prompt)
return parse_tactics(llm_response)而 Seed-Prover 这类系统则采用了更复杂的迭代优化机制，结合了深度推理（如思维链）和广度搜索（如蒙特卡洛树搜索），以探索更大的证明空间。
三、优势与挑战
优势：
- 降低门槛：使依赖类型编程和形式化验证更易被软件工程师接受。
- 提升效率：将原本耗时数小时甚至数天的证明工作压缩到分钟级别。
- 工程实用化：有望解决传统依赖类型语言因证明负担过重而难以投入实际工程的问题。
挑战与局限：
- 证明可靠性：LLM 可能生成语法正确但逻辑错误的策略，最终仍需依赖类型系统的内核进行严格校验，这保证了证明的最终正确性。
- 规模扩展性：对于极其复杂的定理或大规模代码验证，LLM 的生成可能变得低效或需要大量计算资源。
- 领域依赖性：LLM 在特定数学领域或复杂算法（如 FSE 表构造）上的表现，依赖于其训练数据和质量。
四、应用前景
- 教育：作为学习交互式定理证明的智能导师。
- 高可靠软件：加速操作系统内核（如 seL4）、加密算法等安全关键代码的形式化验证。
- 编译器与优化验证：结合经过形式化验证的汇编语义（如 AWS 的 LNSym），验证编译器优化或手写汇编代码的正确性。
总之，LLMs 并非取代依赖类型系统的逻辑内核，而是作为强大的"超级证明策略自动生成器"，与符号推理引擎协同工作，填补了人类直觉与机器严格验证之间的鸿沟，正在推动形式化方法走向更广泛的实用化。