1. 为什么要在 Lean 4 里让 AI 帮忙写证明Lean 4 是一门把「写程序」和「写数学证明」绑在一起的语言。你写下一个定理编译器不会只看语法对不对它会要求你给出一个完整的证明项类型检查通过才算数。这件事的好处是只要编译过了命题就是真的在公理系统一致的前提下。坏处也很直接——证明得一行一行写一个simp没命中目标Infoview 里就挂着一堆⊢等着你。我最初用 Lean 4 做数学建模时卡点几乎全在「证明骨架」上。比如把逻辑斯蒂方程dP/dt rP(1 - P/K)形式化之后想证明「当 P K 时增长率为 0」数学上一步就完了但在 Lean 里得先展开定义、再做类型转换、再让ring收尾。这些步骤对人是常识对刚上手的人是折磨。AI 在这里的价值不是替你「想数学」而是替你搭骨架把自然语言描述的证明思路翻译成by块里的 tactic 序列你负责检查类型、补引理、修错误。这篇教程就聚焦这条链路——本地 Lean 4 项目 AI 补全证明步骤从自然语言建模一路跑到 Lean 4 编译器接受。适合已经装过 Lean 4、想让 AI 真正参与形式化验证的开发者也适合做数学建模、想把模型假设写成机器可验证命题的人。核心检索词先摆出来Lean 4 与 AI 结合做数学建模本质是用 AI 生成定理证明骨架再用 Lean 4 编译器做形式化验证。下面所有配置和代码都围绕这个目标。2. TaoToken 统一 Key 接入给 Lean 4 的 AI 助手配一个稳定入口Lean 4 本身不带 AI。你要么用编辑器插件要么用命令行工具把「当前证明目标」发给一个大模型让它返回 tactic 建议。问题在于不同模型的 API 格式、鉴权方式、Base URL 都不一样今天用这个明天换那个配置散落在各个插件里很难维护。TaoToken 在这里扮演的是「统一入口」它提供一套兼容常见大模型调用格式的 API你拿一个 Key就能在多个 AI 辅助工具里复用。对 Lean 4 场景来说最实用的两个接入点是一是编辑器侧的 AI 补全插件比如支持自定义 OpenAI 兼容端点的补全工具把 Base URL 指向 TaoToken模型 ID 填你选的模型就能在.lean文件里直接请求证明建议。二是命令行/脚本侧你自己写一个小工具把 Infoview 里的目标文本拼成 prompt调用 TaoToken 的对话接口把返回的 tactic 贴回文件。这种方式最灵活也最适合做「证明骨架批量生成」。需要先说明TaoToken 不是 Lean 的替代品它不参与类型检查也不保证 AI 输出一定正确。它只是把「调用大模型」这件事标准化让你把精力放在验证 AI 输出上。Lean 4 编译器才是最终裁判。拿 Key 的路径很简单访问官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册后在控制台创建 API Key。控制台地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite Key 管理页在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。API 的基础地址是 https://taotoken.net/api 这个不加 UTM直接用于配置。选模型时做 Lean 证明骨架建议优先选推理能力强的模型因为 tactic 序列对逻辑连贯性要求高。你可以在模型对话页 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 先手动试几条 Lean 相关的 prompt看看哪个模型对simp、ring、linarith这些 tactic 的用法更靠谱再决定写进配置。如果你打算长期做 Lean 4 形式化调用量会比较大每次补全都是一次请求可以考虑 Coding Plan地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 适合高频编码/Agent 场景。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 配置格式以文档为准。一句话总结这一节TaoToken 给你一个统一的 Key 和 Base URL让 Lean 4 周边的 AI 工具都能指向同一个入口省掉多模型切换的配置成本。3. 可复制配置Lean 4 项目 AI 补全的 settings 与请求片段这一节给可直接复制的配置。分三块Lean 4 项目初始化、编辑器 AI 插件配置、命令行请求脚本。先建项目。Lean 4 用lake管理项目确保你装了 elan 之后lake new lean_ai_demo cd lean_ai_demo lake updatelakefile.lean里加上 Mathlib4 依赖形式化数学建模基本离不开它import Lake open Lake DSL package lean_ai_demo require mathlib from git https://github.com/leanprover-community/mathlib4.git [default_target] lean_lib LeanAIDemo然后lake update拉取 Mathlib4第一次会比较久。拉完后lake build确认环境正常。接下来是编辑器侧。以支持 OpenAI 兼容端点的补全插件为例配置通常是一个 JSON 文件不同插件路径不同常见的是.vscode/settings.json或插件自己的配置文件。核心字段就三个Base URL、API Key、Model ID。写成这样{ aiAssistant.provider: openai-compatible, aiAssistant.baseUrl: https://taotoken.net/api, aiAssistant.apiKey: sk-你的TaoToken密钥, aiAssistant.model: 你选定的模型ID, aiAssistant.maxTokens: 1024, aiAssistant.temperature: 0.2 }注意temperature调低一点证明骨架需要稳定不需要发散。maxTokens给到 1024 通常够一个定理的 tactic 序列。如果你用的是命令行脚本方式可以写一个 Python 小工具把 Lean 目标发出去。请求体格式OpenAI 兼容import requests TAOTOKEN_BASE https://taotoken.net/api API_KEY sk-你的TaoToken密钥 MODEL_ID 你选定的模型ID def ask_lean_tactic(goal_text: str) - str: url f{TAOTOKEN_BASE}/v1/chat/completions headers { Authorization: fBearer {API_KEY}, Content-Type: application/json, } payload { model: MODEL_ID, temperature: 0.2, messages: [ { role: system, content: 你是 Lean 4 证明助手。只返回 tactic 序列不要解释不要 markdown 代码块。, }, { role: user, content: f当前证明目标\n{goal_text}\n请给出 Lean 4 tactic 证明。, }, ], } resp requests.post(url, headersheaders, jsonpayload, timeout60) resp.raise_for_status() return resp.json()[choices][0][message][content] if __name__ __main__: goal ⊢ 1 1 2 print(ask_lean_tactic(goal))这段脚本的关键在于 system prompt 里明确「只返回 tactic 序列」否则模型很容易给你一段带解释的文字贴进 Lean 就报语法错。temperature同样压低。三件套对照表方便你检查配置是否齐全配置项值说明Base URLhttps://taotoken.net/api统一入口不加 UTMAPI Keysk-开头控制台创建勿泄露Model ID你选定的模型建议推理型先手动试配置完成后先别急着上复杂定理。用一个最小文件验证链路通不通下一节讲。4. 验证请求从自然语言建模到 Lean 4 编译通过这一节跑一个完整流程自然语言描述 → AI 生成骨架 → 人工修正 → Lean 编译通过。用逻辑斯蒂方程做例子。先建文件LeanAIDemo/Logistic.lean写模型定义import Mathlib.Analysis.Real.Basic import Mathlib.Data.Real.Positive variable (r K : ℝ₊) def LogisticGrowthRate (P : ℝ≥0) (r K : ℝ₊) : ℝ : r * (P : ℝ) * (1 - (P : ℝ) / K)这里有个细节P是ℝ≥0参与实数乘法时要显式转成ℝ写成(P : ℝ)。AI 生成时经常漏这个转换导致类型不匹配。现在要证明的命题是当P K时增长率为 0。自然语言描述发给 AI请为定理theorem growth_rate_zero_at_K (r K : ℝ₊) : LogisticGrowthRate (K : ℝ≥0) r K 0提供 Lean 4 证明使用 unfold、simp、ring 等 tactic。AI 返回的骨架大概是theorem growth_rate_zero_at_K (r K : ℝ₊) : LogisticGrowthRate (K : ℝ≥0) r K 0 : by unfold LogisticGrowthRate simp ring贴进文件lake build或直接在 VS Code 里看 Infoview。如果显示no goals说明证明完成。如果卡住Infoview 会告诉你还剩什么目标。再试一个需要拆解的P K时增长率为正。这个 AI 一次给对的概率低通常需要你补步骤。骨架可能是theorem growth_rate_pos_when_P_lt_K (P r K : ℝ₊) (h : P K) : LogisticGrowthRate (P : ℝ≥0) r K 0 : by unfold LogisticGrowthRate apply mul_pos · exact r.2 · apply mul_pos · exact P.2 · rw [sub_pos] exact h这里r.2和P.2是取ℝ₊的正性证明ℝ₊本质是带正性证明的子类型。rw [sub_pos]把1 - P/K 0转成P/K 1再配合h收尾。如果 AI 没给全你就在 Infoview 里看剩余目标一步步补。验证成功的标志很明确文件无红色波浪线Infoview 显示no goalslake build退出码为 0。到这一步说明「自然语言 → AI 骨架 → Lean 编译」这条链路跑通了。实测下来AI 对simp、ring、linarith这类收尾 tactic 的命中率不错但对「该用哪条 Mathlib 引理」经常给错名字。所以流程应该是AI 搭结构你查引理。Mathlib 检索可以用在线工具或者直接在 VS Code 里用exact?和apply?让 Lean 自己找。5. 常见报错排查401、类型不匹配、tactic 失败怎么修这一节对照真实报错。你在接入和验证过程中大概率会撞上下面几个。401 Unauthorized / invalid api key。这是 Key 的问题。检查三处Key 是否复制完整有没有多余空格、请求头是不是Authorization: Bearer sk-xxx、Base URL 是不是https://taotoken.net/api。如果插件里填的是完整 endpoint注意有些插件要求填到/v1有些不要求以接入文档为准。401 和 Lean 无关纯粹是鉴权没过。local proxy failed / connection refused。这类报错说明请求根本没发出去。常见原因是本地网络配置或插件代理设置冲突。先确认你能用 curl 直接打通curl https://taotoken.net/api/v1/models \ -H Authorization: Bearer sk-你的密钥如果这条通说明是插件配置问题如果不通检查 Base URL 拼写。注意不要在任何地方配置系统级代理来「绕过」什么正常网络环境下直连即可。type mismatch / has type ℝ≥0 but expected ℝ。这是 Lean 侧最高频的错。原因就是ℝ≥0和ℝ没转换。修法在参与实数运算的地方显式写(P : ℝ)。AI 生成代码时经常忽略你要养成检查习惯。tactic failed / unsolved goals。simp或ring没把目标消掉。这时看 Infoview 剩余目标通常是缺一条引理或缺一个前提。比如ring对含除法的目标可能不适用得先field_simp或rw化简。把剩余目标原文发给 AI问「这个目标该用什么 tactic」比让它从头生成更有效。unknown identifier / unknown namespace。引理名或库没导入。Mathlib4 的引理名会随版本变AI 训练数据里的名字可能过时。用exact?让 Lean 搜或去 Mathlib 文档查当前名字。OAuth / token expired。如果你用的是带 OAuth 的工具链比如某些 CLI 的登录流程token 过期会报这个。重新走一遍授权或改用 API Key 方式。Lean 4 本身不涉及 OAuth这通常是周边工具的问题。排查顺序建议先确认 401 类鉴权问题curl 打通再确认 Lean 类型问题Infoview 看目标最后才是 tactic 选择问题。把这三层分开定位会快很多。6. 把 AI 补全变成日常Lean 4 形式化建模的稳定工作流跑通单次流程之后真正提升效率的是把它变成习惯。我自己的做法是固定一个循环写定义 → 写定理陈述 → 把目标发给 AI 要骨架 → 贴回 → Infoview 看剩余目标 → 补引理 → 编译通过。这个循环里AI 负责的是「从目标到 tactic 序列」的翻译你负责的是「类型正确性」和「引理准确性」。两者分工明确不要指望 AI 一次给对也不要自己从零硬写。几个实用技巧。第一把常用 prompt 存成模板system prompt 固定为「只返回 tactic不解释」减少清洗成本。第二复杂定理拆成多个小引理每个小引理单独让 AI 生成比让它一次证明大定理成功率高得多。第三善用have把中间结论显式写出来这样 AI 每次只需要处理一个清晰的小目标。如果你做的是长期的形式化项目调用频率高Coding Plan 会比按次调用更省心地址在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。接入细节和最新配置以文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 为准Key 在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 管理。最后提醒一句Lean 4 编译器是唯一裁判。AI 说得再顺编译不过就是不过。把验证权牢牢握在编译器手里AI 才是加速器而不是噪音源。
阅读完成 · 觉得有帮助?