1. 从“人机协作”到“人机共舞”Isabelle中的AI代理革命如果你是一位形式化验证的研究者或开发者听到“在Isabelle里直接输入”这句话第一反应可能是“这有什么新鲜的”。毕竟Isabelle/HOL作为一个交互式定理证明器其核心就是用户通过Isar语言输入证明脚本系统进行验证。但今天要聊的远不止于此。这个标题指向的是一场正在发生的、关于如何“教”AI理解并参与人类高阶数学推理的范式转变。它关乎AI代理如何从被动执行代码转变为能主动起草证明草稿、机械化证明步骤并能从人类给出的提示中泛化出新的证明策略。想象一下这个场景你面对一个复杂的引理心中有一个模糊的证明思路轮廓。传统上你需要将这个思路精确地翻译成Isabelle的语法一步步构建证明项过程中还要不断与系统的类型检查和证明状态“搏斗”。而现在你可以用更接近人类数学讨论的语言给AI一个“提示”Hint比如“试试用归纳法并对第二个子目标使用反证法。” AI代理能够理解这个提示的意图自动生成对应的Isabelle证明脚本草稿完成那些繁琐但规范的步骤“机械化”甚至能举一反三在遇到结构类似但表述不同的新问题时应用相似的证明策略。这不再是简单的代码补全而是将人类直觉与机器精确性深度融合的“共舞”。这背后的核心价值是极大地降低形式化验证的门槛和提升效率。它让数学家、算法设计者等领域的专家能更专注于创造性的、高层的证明思路而将大量细节性、重复性的验证工作交给AI代理。关键词“Drafting, Mechanizing, and Generalizing”精准地概括了这一过程的三部曲起草将思路转化为结构化草稿、机械化填充标准化细节、泛化学习并迁移策略。接下来我们就深入拆解这每一个环节是如何在Isabelle的生态中实现的以及在实际操作中我们会遇到哪些挑战又有哪些实用的技巧和工具。2. 理解“提示”的层次从自然语言到证明策略的桥梁AI代理工作的起点是“Human Hints”人类提示。这里的“提示”并非随意的一句话而是一个有结构、有层次的沟通媒介。理解不同层次的提示是有效利用这类AI代理的关键。2.1 提示的三种典型形态在实际操作中人类给出的提示大致可以分为三类其信息量和可操作性逐级递增高层策略描述这是最接近人类数学思维的提示。例如“对变量n进行数学归纳”“使用反证法假设结论不成立并推导矛盾”“考虑使用柯西-施瓦茨不等式”。这类提示指明了证明的宏观方向但离具体的Isabelle代码还有很大距离。AI代理需要理解这些数学术语在当前上下文中的具体含义并映射到Isabelle的相应策略如induction n rule: nat.induct,apply (rule ccontr),apply (rule Cauchy_Schwarz_inequality)。中层目标分解这类提示更具体涉及对当前证明状态的干预。例如“现在需要证明集合A是B的子集可以尝试用apply (rule subsetI)引入任意元素x”“这个等式两边很相似试试apply (auto simp add: field_simps)进行化简”。它直接关联到Isabelle的证明命令tactic告诉AI“下一步可以做什么”。AI代理需要准确解析当前目标goal判断提示的适用性并生成正确的apply或by语句。底层代码片段这是最精确的提示几乎就是部分的Isabelle代码。例如“这里需要一个引理lemma aux: “x y 0” when “x 0” “y ≥ 0” by auto”或者“在这个have语句之后使用also have “... ?rhs” by algebra”。AI代理的角色更像是高级的代码补全和语法校正确保片段能无缝嵌入到现有的证明上下文中。从我实际尝试各种集成AI的工具如Proof Advisor, GPT-Isabelle接口的经验来看最有效的提示往往是“中层目标分解”与“高层策略描述”的结合。先给出方向再在关键步骤点出具体策略。例如“这个函数是单调递增的尝试用归纳法证明。归纳步骤中注意利用单调性假设可能需要apply (simp add: Suc_le_eq)来处理后继情况。” 这样的提示既提供了框架又给出了可能遇到的技术细节线索能极大提高AI生成代码的准确率。2.2 提示的语境与歧义消除给出提示时最大的挑战在于语境Context。Isabelle的证明状态是动态的、包含大量隐含信息如已导入的理论、定义的符号、当前的局部假设。一个简单的词如“它”在人类对话中指向明确但对AI来说可能是歧义的。注意在向AI代理提供提示时务必显式地引用关键对象。与其说“对它使用归纳法”不如说“对变量list使用结构归纳法induction list”。与其说“用之前的引理”不如说“使用我们刚刚证明的引理helper_lemma”。AI代理需要能够访问并理解完整的证明上下文。这通常通过两种方式实现全状态快照将当前的整个证明目标状态包括所有子目标、局部事实、理论上下文以某种结构化格式如JSON提供给AI模型。增量式交互在每一步交互中只传递相对于上一步的变化部分模型需要内部维护或推断出完整状态。目前大多数研究原型采用第一种方式因为它更简单可靠但对模型的输入长度和上下文理解能力要求极高。在实际使用中如果感觉AI代理“答非所问”首先应该检查它是否“看到”了你所看到的完整证明状态。有时手动在提示中重申关键假设和当前目标能显著改善效果。3. “起草”阶段从模糊意图到结构化证明骨架收到提示后AI代理的“起草”工作正式开始。这个阶段的目标不是生成一个完全正确、可立即通过的证明而是构建一个结构合理、大方向正确的证明草稿。这就像建筑师先画出设计草图而不是直接给出施工图。3.1 起草的核心任务与常见模式起草过程主要解决以下几个问题证明方法选择与框架搭建根据高层提示确定是使用apply风格的脚本线性应用策略还是proof-qed块结构的Isar语言。对于复杂的、需要清晰逻辑流的证明Isar是更好的选择。AI代理需要生成相应的proof语句和初始的assume-show框架。示例如果提示是“证明如果n是偶数则n²是偶数”AI可能会起草一个Isar框架lemma square_even: “even n ⟹ even (n^2)” proof - assume “even n” then obtain k where n_def: “n 2 * k” by (auto elim: evenE) show “even (n^2)” ... qed中间引理与辅助事实的提出在证明过程中经常需要引入一些小的、过渡性的断言have语句。有经验的证明者能预见到这些需要。AI代理可以根据当前目标和已知事实提议可能有用的中间引理。例如在证明关于列表的函数时它可能会自动插入have “length (map f xs) length xs” by simp。策略链的初步序列对于apply风格的证明起草意味着生成一系列可能有效的策略。例如针对一个等式目标AI可能会生成apply (simp add: field_simps) apply (arith)。这些策略不一定一次成功但它们构成了一个合理的“攻击序列”。3.2 实操心得如何评估和修正AI起草的草稿AI起草的草稿几乎不可能完美。我们的角色从“编码员”变成了“编辑”和“教练”。以下是我总结的几个评估和修正要点检查结构一致性确保整个证明的语体风格一致。如果开头是Isar风格后面突然变成一堆apply这通常是个坏信号可能需要手动调整或给AI更明确的风格提示。关注“洞”的类型AI起草的证明中常会出现...或sorry跳过证明占位符。重要的是看这些“洞”出现在哪里。如果是在引用了某个外部定理之后可能意味着AI错误地认为该定理能直接推出结论需要你检查定理的精确形式。如果是在复杂的代数化简中间可能只是需要更具体的化简规则提示。利用系统的即时反馈将AI生成的草稿直接放入Isabelle如VSCode的Isabelle插件中。系统会实时标记出类型错误、未定义的引用或无法闭合的子目标。这些错误信息本身就是极好的“修正提示”。你可以把错误信息连同原有草稿一起再次反馈给AI代理“这个apply步骤失败了错误是‘No matching rule for goal’。当前目标是...你有什么其他建议”从失败中学习AI代理的“泛化”能力部分就来源于此。当你反复修正某一类提示下生成的草稿时一些先进的AI代理如果具备在线学习或微调能力会逐渐调整其内部模型在未来遇到类似情境时表现得更好。这形成了一个正向反馈循环。起草阶段是人机协作最密集的阶段需要耐心和迭代。不要期望AI一次就给出完美证明而是把它看作一个能快速生成多种可能路径的伙伴由你来选择和引导最佳方向。4. “机械化”阶段填充细节与确保正确性如果“起草”是画出骨骼那么“机械化”就是填充血肉和经络确保每一个关节都能活动每一步逻辑都严丝合缝。这个阶段的目标是将一个结构正确的证明草稿转化为Isabelle能够完全接受、无需sorry的完整证明。这是AI代理体现其“不知疲倦”和“绝对精确”优势的主战场。4.1 机械化的主要内容自动化简与重写这是最直接、最常见的机械化任务。给定一个目标如(a b) ^ 2 - a^2 - 2*a*b b^2AI代理需要选择合适的化简规则集simprules。这不仅仅是调用by auto或by simp那么简单。关键在于规则的选择与排序。技巧告诉AI代理使用特定的化简规则库。例如by (simp add: algebra_simps power2_eq_square)就比泛泛的by auto更精确、更可能成功。AI需要理解algebra_simps包含了基本的环运算规则而power2_eq_square是处理平方的关键引理。常见坑过度化简。有时auto或simp会应用一些意想不到的规则将表达式化简成一个虽然正确但形式完全不同的东西导致后续步骤无法进行。这时需要更精细的控制比如使用by (simp only: specific_rule1 specific_rule2)。自动实例化存在量词与全称量词在证明中经常需要“取一个满足条件的k”或“对任意x成立”。AI代理可以自动完成这些实例化。示例对于目标∃k. n 2*k证明n是偶数如果上下文有even nAI应能自动生成obtain k where “n 2*k” using ‹even n› by (auto elim: evenE)。难点当存在多个可能的选择时AI需要根据上下文选择最合适的一个。这依赖于对理论库的熟悉程度和简单的推理。自动完成归纳证明的标准步骤数学归纳法是形式化验证中的常客。其基础步骤和归纳步骤有固定的模式。AI代理可以自动化这些模式。模式识别给定一个关于自然数n的命题P(n)和提示“用归纳法”AI应能生成proof (induction n) case 0 show ?case by ... next case (Suc n) assume IH: “P(n)” show “P(Suc n)” ... qed更复杂的归纳对于结构归纳如列表、树、强归纳法AI需要生成对应的induction规则参数。自动搜索引理与定理这是机械化阶段的高级能力。当证明卡住时AI代理可以基于当前目标Goal和已知前提Premises从已导入的理论库中搜索可能适用的定理。这类似于Isabelle内置的find_theorems命令但更智能。工作原理AI将目标转化为一个特征向量例如包含的主要函数、关系、量词结构然后在定理数据库中进行近似匹配或向量相似度搜索。实操限制目前这项功能在通用大语言模型LLM驱动的代理中精度有限容易搜到不相关或形式不匹配的定理。但在专门针对某个数学领域如图论、分析微调过的模型上表现会好很多。4.2 经验分享让机械化更高效的策略分而治之不要试图让AI一次性机械化整个证明。将证明分解成多个独立的子目标subgoal然后让AI分别处理每一个。这样更容易定位问题也降低了AI的推理难度。提供“武器库”在开始证明前通过imports或unfolding语句显式地告诉AI和Isabelle你将主要使用哪些理论中的定义和定理。例如如果要做实数不等式证明确保导入了HOL-Analysis库并unfold相关的不等式定义。使用中间断言如果AI在机械化一个长链条的等式或不等式推导时失败可以手动插入一些have语句将长链条切成短链条。让AI先证明第一个have再证明第二个最后连接起来。这比让它直接证明最终结论要容易得多。拥抱交互式修正机械化失败是常态。Isabelle给出的错误信息如“failed to finish proof”、“type unification error”是黄金信息。将这些错误信息连同当前的局部证明状态作为新的提示反馈给AI。例如“上一步apply (rule conjI)失败了因为当前目标不是合取式。当前目标是A ⟶ B。我们应该换什么策略”机械化阶段是人将繁琐、重复的验证工作委托给AI的过程。成功的标志不是你完全不用动手而是你动脑思考“做什么”的时间占比远高于动手“怎么做”的时间。5. “泛化”能力从具体提示到通用策略的学习“泛化”是AI代理最具革命性也最具挑战性的能力。它意味着AI不仅能解决当前这个具体问题还能从人类给出的提示和最终的证明中学习提炼出可复用的证明策略或模式并将其应用到未来新的、但结构相似的问题上。这标志着AI从“计算器”向“助手”乃至“合作伙伴”的演进。5.1 泛化是如何发生的泛化不是魔法其背后通常依赖于机器学习模型特别是经过代码和数学文本训练的大语言模型LLM。其过程可以抽象为模式提取当AI代理成功完成一个证明例如通过归纳法证明了一个关于列表长度的性质它会分析这个证明的结构。它会注意到诸如“当目标形如P (x # xs)时使用了cases xs或induction xs”、“在化简步骤中频繁使用了simp add: list.map list.set”等模式。特征关联AI将提取出的模式与问题的“特征”关联起来。这些特征可能包括目标中出现的核心函数length,map,set、涉及的数据类型list,nat、使用的关键前提如单调性、可加性。策略库更新将这些“特征-策略”对以某种形式存储或更新到模型的内部参数中。在一些系统中这体现为一个可增长的策略建议库在端到端的LLM中这可能是模型权重基于此次成功经验的微调。未来应用当遇到一个新问题时AI会先提取新问题的特征然后在其内部策略库中搜索相似的特征。如果匹配成功它就会优先建议或直接应用关联的证明策略。5.2 实现泛化的技术路径与现状目前在Isabelle环境中实现泛化主要有几种技术路径各有优劣基于示例的学习系统维护一个证明示例数据库。当用户提出新目标时系统在数据库中检索证明目标最相似的已解决示例然后将其证明结构作为草稿推荐给用户。这种方法直接但泛化能力受限于数据库的规模和覆盖度。强化学习将证明过程建模为一个马尔可夫决策过程MDP每一步选择哪个证明策略tactic是动作成功证明获得正奖励失败或陷入循环获得负奖励。AI代理智能体通过大量与Isabelle环境的交互试错来学习一个策略网络。著名的DeepMind项目HOList和GPT-f就采用了类似思路。这种方法能学到非常通用的策略但需要海量的训练数据和计算资源。大语言模型微调使用包含大量Isabelle证明脚本如Archive of Formal Proofs的语料库对预训练的LLM如Codex, GPT-Neo进行监督微调。模型学习的是证明语言的统计规律和常见模式。其泛化能力取决于预训练模型的知识广度和微调数据的质量。这是目前最活跃的研究方向许多开源项目如Proof Advisor、Isabelle-GPT都在探索这条路。5.3 实操中的泛化我们能期待什么以我参与测试一些研究原型系统的经验来看当前的泛化能力还处于“有趣但尚不稳健”的阶段。在同构问题中表现良好如果新问题与学习过的问题几乎同构例如把证明length (filter P xs) ≤ length xs的经验用于证明card {x∈xs. P x} ≤ length xsAI代理经常能给出正确的策略建议。对抽象层次的提升困难例如AI从几个具体例子中学会了使用“反证法”但当遇到一个需要创造性选择反设前提的新问题时它可能无法识别出该用反证法或者会选择一个错误的反设。极度依赖提示质量泛化不是完全自主的。一个精确的高层提示如“这类似于我们之前证明过的关于集合基数的引理试试用类似的包含关系论证”能极大激发AI的泛化能力引导它找到正确的策略记忆。因此现阶段对泛化能力的合理期待是作为一个强大的“记忆外挂”和“模式推荐器”。它可以帮助你回忆起之前用过的类似证明技巧在你思考时提供几个高可能性的候选策略减少你从头构思的时间。但不能指望它完全自主地发现全新的、深刻的证明思路。6. 当前工具链与实战集成指南理论很美好但最终要落地到工具上。目前将AI代理集成到Isabelle工作流中主要有以下几种方式各有其适用场景和配置复杂度。6.1 主流工具与平台概览工具/项目名称类型核心能力集成方式适用场景Proof Advisor研究原型/插件基于LLM的证明策略建议、草稿生成。与Isabelle/jEdit或VSCode集成较好。本地或远程API调用。需配置Python环境和模型端点。日常证明辅助获取下一步策略建议。Isabelle-GPT开源接口项目提供与OpenAI GPT系列模型交互的框架将证明状态转换为自然语言提示。需要OpenAI API密钥通过脚本或简单UI与Isabelle交互。实验性探索利用GPT-4等模型的通用推理能力。PISA研究框架专注于搜索和定理证明使用强化学习等方法训练专用证明AI。通常作为独立系统运行与Isabelle通过文件或进程通信。研究环境用于自动化证明难度较高的猜想。Hammers(如Sledgehammer)Isabelle内置工具非AI但相关。使用外部自动定理证明器ATP和SMT求解器寻找证明。内置命令如sledgehammer。首选实战工具。当你有明确目标但不知如何下手时用它寻找证明片段。VSCode Isabelle 插件官方IDE提供优秀的代码补全、实时错误检查、文档查看为AI集成提供了良好基础。官方支持安装即用。所有工作的基础平台建议作为主要开发环境。6.2 以VSCode Sledgehammer 自定义脚本为核心的实战流程对于大多数希望提升效率的Isabelle用户我推荐一个务实且强大的组合VSCode 内置Sledgehammer 自定义Python脚本调用通用LLM。基础环境搭建安装VSCode和官方“Isabelle”插件。配置好Isabelle路径。插件提供无与伦比的实时反馈和导航体验。第一响应使用Sledgehammer当你在证明中卡住时首先尝试sledgehammer。将光标放在待证明的目标行在命令面板运行“Isabelle: Sledgehammer”或直接输入命令。Sledgehammer会调用外部ATP如E, Vampire, CVC4尝试证明你的目标。如果成功它会给出一个by语句通常使用metis或smt方法并列出它所使用的关键事实。经验Sledgehammer找到的证明可能非常简洁但难以理解一堆metis。你可以接受它快速过关也可以将其作为“提示”研究它使用了哪些引理这常常能给你新的证明思路。进阶辅助集成通用LLM作为“策略顾问”当Sledgehammer失败常见于需要归纳或更复杂构造的问题或者你需要更符合人类阅读习惯的Isar证明时可以求助于LLM。方法写一个简单的Python脚本其核心功能是从当前Isabelle缓冲区或通过插件API获取当前的证明状态焦点目标、局部假设。将这些信息与你的自然语言提示如“尝试用归纳法”组合构造一个详细的Prompt。调用OpenAI API或本地部署的Llama、CodeLlama等开源模型。解析返回的文本提取出Isabelle代码建议并插回编辑器。Prompt设计技巧prompt f 你是一个Isabelle/HOL定理证明助手。当前理论上下文包含以下定义和定理{context}。 我们正在尝试证明以下目标 Goal: {goal} 可用的局部假设有{assumptions} 用户提示{human_hint} 请给出接下来最可能成功的1-3个Isabelle证明策略tactic或一小段Isar证明脚本。只输出Isabelle代码。 重要警告永远不要盲目信任LLM生成的代码。必须将其放入Isabelle中验证。LLM经常会“幻觉”出语法正确但逻辑错误或引用不存在的定理的代码。人机协作循环你给出一个高层思路提示。AILLM脚本生成一段证明草稿或几个策略建议。你将其放入Isabelle执行。如果失败将Isabelle的错误信息作为新提示的一部分反馈给AI。重复2-4步直到证明完成。将最终成功的证明作为新的学习数据可以手动整理后加入你的“提示-证明”示例库用于未来微调本地模型实现个性化的泛化能力提升。这个流程将Isabelle的强大验证能力、Sledgehammer的自动化搜索能力以及LLM的灵活生成能力结合在一起形成了当前最实用的“AI辅助证明”工作流。7. 挑战、局限与未来展望尽管“Just Type It”的愿景令人兴奋但我们必须清醒地认识到当前技术面临的挑战和局限。这些不是否定其价值而是为了更有效地利用它。7.1 当前面临的主要挑战形式化语言与自然语言的语义鸿沟这是最根本的挑战。人类的一句“显然”背后可能隐藏着多步逻辑跳跃和深厚的背景知识。AI要准确理解“对n做归纳”并生成正确的induction n需要精确对齐数学概念与Isabelle的具体语法和规则。任何歧义都会导致生成错误的代码。长程依赖与全局上下文一个复杂的证明可能长达数百行涉及多个引理和定义。AI代理尤其是基于有限上下文窗口的LLM可能“忘记”或无法有效利用很早之前定义的概念或证明的中间结果导致生成的建议前后矛盾或无效。组合爆炸与搜索空间即使在一个简单的子目标上可用的证明策略也有数十种。策略之间可以无限组合。纯粹的生成式方法容易陷入低效的随机尝试。如何引导AI进行有方向的、启发式的搜索是一个核心难题。评估与信任如何评估AI生成的证明“草稿”的质量除了Isabelle最终的“绿灯”验证在生成过程中我们还需要一些中间评估指标比如生成的步骤是否朝着目标前进、是否引入了不必要的复杂性等。否则我们会浪费大量时间在验证明显错误的路径上。7.2 对从业者的实用建议面对这些挑战我的建议是保持主导权始终记住你是证明的负责人AI是助手。你的价值在于提出关键思路、识别证明结构、判断AI建议的合理性。不要沦为AI生成代码的调试员。从小处着手不要一开始就让AI证明整个定理。让它帮你完成一个具体的子目标、化简一个复杂的表达式、或者搜索一个可能适用的引理。积累小的成功建立信任。构建个人知识库将你成功使用AI辅助证明的典型案例包括最初的提示、AI的多次反馈、最终证明保存下来。这既是你的个人笔记未来也可以作为微调个性化AI模型的数据。理解工具的局限性知道Sledgehammer擅长什么一阶逻辑、等式知道LLM擅长什么模仿模式、生成结构化文本知道你自己擅长什么数学洞察、策略规划。将正确的问题分配给正确的“解决者”。7.3 未来可能的发展方向“Just Type It”的终极形态或许是一个深度理解特定数学领域如组合数学、抽象代数的专家系统与通用语言模型结合的产物。它不仅能理解“归纳法”这个策略还能理解你正在研究的“图论”中“归纳法”的常用变体它不仅能在失败时给出另一个策略还能解释为什么先前的策略失败了以及新策略为什么可能有效。另一个方向是交互模式的革新。也许未来的证明环境不再是线性的文本编辑而是一个混合的可视化界面其中部分证明步骤由AI以“黑盒”或“可折叠”的方式自动完成人类只需在高层的“证明蓝图”上进行标注和指引。无论如何AI代理在形式化验证中的应用其意义不在于取代人类而在于放大人类的数学智慧。它负责处理那些我们觉得枯燥、繁琐但机器擅长的工作让我们能更专注于创造性的思考。这个过程正如标题所言是“Drafting, Mechanizing, and Generalizing from Human Hints”——一场始于人类灵光一闪由人类与机器共同完成的、严谨而优美的思维之舞。 AI代理在Isabelle中的证明辅助：从提示到机械化验证
1. 从“人机协作”到“人机共舞”Isabelle中的AI代理革命如果你是一位形式化验证的研究者或开发者听到“在Isabelle里直接输入”这句话第一反应可能是“这有什么新鲜的”。毕竟Isabelle/HOL作为一个交互式定理证明器其核心就是用户通过Isar语言输入证明脚本系统进行验证。但今天要聊的远不止于此。这个标题指向的是一场正在发生的、关于如何“教”AI理解并参与人类高阶数学推理的范式转变。它关乎AI代理如何从被动执行代码转变为能主动起草证明草稿、机械化证明步骤并能从人类给出的提示中泛化出新的证明策略。想象一下这个场景你面对一个复杂的引理心中有一个模糊的证明思路轮廓。传统上你需要将这个思路精确地翻译成Isabelle的语法一步步构建证明项过程中还要不断与系统的类型检查和证明状态“搏斗”。而现在你可以用更接近人类数学讨论的语言给AI一个“提示”Hint比如“试试用归纳法并对第二个子目标使用反证法。” AI代理能够理解这个提示的意图自动生成对应的Isabelle证明脚本草稿完成那些繁琐但规范的步骤“机械化”甚至能举一反三在遇到结构类似但表述不同的新问题时应用相似的证明策略。这不再是简单的代码补全而是将人类直觉与机器精确性深度融合的“共舞”。这背后的核心价值是极大地降低形式化验证的门槛和提升效率。它让数学家、算法设计者等领域的专家能更专注于创造性的、高层的证明思路而将大量细节性、重复性的验证工作交给AI代理。关键词“Drafting, Mechanizing, and Generalizing”精准地概括了这一过程的三部曲起草将思路转化为结构化草稿、机械化填充标准化细节、泛化学习并迁移策略。接下来我们就深入拆解这每一个环节是如何在Isabelle的生态中实现的以及在实际操作中我们会遇到哪些挑战又有哪些实用的技巧和工具。2. 理解“提示”的层次从自然语言到证明策略的桥梁AI代理工作的起点是“Human Hints”人类提示。这里的“提示”并非随意的一句话而是一个有结构、有层次的沟通媒介。理解不同层次的提示是有效利用这类AI代理的关键。2.1 提示的三种典型形态在实际操作中人类给出的提示大致可以分为三类其信息量和可操作性逐级递增高层策略描述这是最接近人类数学思维的提示。例如“对变量n进行数学归纳”“使用反证法假设结论不成立并推导矛盾”“考虑使用柯西-施瓦茨不等式”。这类提示指明了证明的宏观方向但离具体的Isabelle代码还有很大距离。AI代理需要理解这些数学术语在当前上下文中的具体含义并映射到Isabelle的相应策略如induction n rule: nat.induct,apply (rule ccontr),apply (rule Cauchy_Schwarz_inequality)。中层目标分解这类提示更具体涉及对当前证明状态的干预。例如“现在需要证明集合A是B的子集可以尝试用apply (rule subsetI)引入任意元素x”“这个等式两边很相似试试apply (auto simp add: field_simps)进行化简”。它直接关联到Isabelle的证明命令tactic告诉AI“下一步可以做什么”。AI代理需要准确解析当前目标goal判断提示的适用性并生成正确的apply或by语句。底层代码片段这是最精确的提示几乎就是部分的Isabelle代码。例如“这里需要一个引理lemma aux: “x y 0” when “x 0” “y ≥ 0” by auto”或者“在这个have语句之后使用also have “... ?rhs” by algebra”。AI代理的角色更像是高级的代码补全和语法校正确保片段能无缝嵌入到现有的证明上下文中。从我实际尝试各种集成AI的工具如Proof Advisor, GPT-Isabelle接口的经验来看最有效的提示往往是“中层目标分解”与“高层策略描述”的结合。先给出方向再在关键步骤点出具体策略。例如“这个函数是单调递增的尝试用归纳法证明。归纳步骤中注意利用单调性假设可能需要apply (simp add: Suc_le_eq)来处理后继情况。” 这样的提示既提供了框架又给出了可能遇到的技术细节线索能极大提高AI生成代码的准确率。2.2 提示的语境与歧义消除给出提示时最大的挑战在于语境Context。Isabelle的证明状态是动态的、包含大量隐含信息如已导入的理论、定义的符号、当前的局部假设。一个简单的词如“它”在人类对话中指向明确但对AI来说可能是歧义的。注意在向AI代理提供提示时务必显式地引用关键对象。与其说“对它使用归纳法”不如说“对变量list使用结构归纳法induction list”。与其说“用之前的引理”不如说“使用我们刚刚证明的引理helper_lemma”。AI代理需要能够访问并理解完整的证明上下文。这通常通过两种方式实现全状态快照将当前的整个证明目标状态包括所有子目标、局部事实、理论上下文以某种结构化格式如JSON提供给AI模型。增量式交互在每一步交互中只传递相对于上一步的变化部分模型需要内部维护或推断出完整状态。目前大多数研究原型采用第一种方式因为它更简单可靠但对模型的输入长度和上下文理解能力要求极高。在实际使用中如果感觉AI代理“答非所问”首先应该检查它是否“看到”了你所看到的完整证明状态。有时手动在提示中重申关键假设和当前目标能显著改善效果。3. “起草”阶段从模糊意图到结构化证明骨架收到提示后AI代理的“起草”工作正式开始。这个阶段的目标不是生成一个完全正确、可立即通过的证明而是构建一个结构合理、大方向正确的证明草稿。这就像建筑师先画出设计草图而不是直接给出施工图。3.1 起草的核心任务与常见模式起草过程主要解决以下几个问题证明方法选择与框架搭建根据高层提示确定是使用apply风格的脚本线性应用策略还是proof-qed块结构的Isar语言。对于复杂的、需要清晰逻辑流的证明Isar是更好的选择。AI代理需要生成相应的proof语句和初始的assume-show框架。示例如果提示是“证明如果n是偶数则n²是偶数”AI可能会起草一个Isar框架lemma square_even: “even n ⟹ even (n^2)” proof - assume “even n” then obtain k where n_def: “n 2 * k” by (auto elim: evenE) show “even (n^2)” ... qed中间引理与辅助事实的提出在证明过程中经常需要引入一些小的、过渡性的断言have语句。有经验的证明者能预见到这些需要。AI代理可以根据当前目标和已知事实提议可能有用的中间引理。例如在证明关于列表的函数时它可能会自动插入have “length (map f xs) length xs” by simp。策略链的初步序列对于apply风格的证明起草意味着生成一系列可能有效的策略。例如针对一个等式目标AI可能会生成apply (simp add: field_simps) apply (arith)。这些策略不一定一次成功但它们构成了一个合理的“攻击序列”。3.2 实操心得如何评估和修正AI起草的草稿AI起草的草稿几乎不可能完美。我们的角色从“编码员”变成了“编辑”和“教练”。以下是我总结的几个评估和修正要点检查结构一致性确保整个证明的语体风格一致。如果开头是Isar风格后面突然变成一堆apply这通常是个坏信号可能需要手动调整或给AI更明确的风格提示。关注“洞”的类型AI起草的证明中常会出现...或sorry跳过证明占位符。重要的是看这些“洞”出现在哪里。如果是在引用了某个外部定理之后可能意味着AI错误地认为该定理能直接推出结论需要你检查定理的精确形式。如果是在复杂的代数化简中间可能只是需要更具体的化简规则提示。利用系统的即时反馈将AI生成的草稿直接放入Isabelle如VSCode的Isabelle插件中。系统会实时标记出类型错误、未定义的引用或无法闭合的子目标。这些错误信息本身就是极好的“修正提示”。你可以把错误信息连同原有草稿一起再次反馈给AI代理“这个apply步骤失败了错误是‘No matching rule for goal’。当前目标是...你有什么其他建议”从失败中学习AI代理的“泛化”能力部分就来源于此。当你反复修正某一类提示下生成的草稿时一些先进的AI代理如果具备在线学习或微调能力会逐渐调整其内部模型在未来遇到类似情境时表现得更好。这形成了一个正向反馈循环。起草阶段是人机协作最密集的阶段需要耐心和迭代。不要期望AI一次就给出完美证明而是把它看作一个能快速生成多种可能路径的伙伴由你来选择和引导最佳方向。4. “机械化”阶段填充细节与确保正确性如果“起草”是画出骨骼那么“机械化”就是填充血肉和经络确保每一个关节都能活动每一步逻辑都严丝合缝。这个阶段的目标是将一个结构正确的证明草稿转化为Isabelle能够完全接受、无需sorry的完整证明。这是AI代理体现其“不知疲倦”和“绝对精确”优势的主战场。4.1 机械化的主要内容自动化简与重写这是最直接、最常见的机械化任务。给定一个目标如(a b) ^ 2 - a^2 - 2*a*b b^2AI代理需要选择合适的化简规则集simprules。这不仅仅是调用by auto或by simp那么简单。关键在于规则的选择与排序。技巧告诉AI代理使用特定的化简规则库。例如by (simp add: algebra_simps power2_eq_square)就比泛泛的by auto更精确、更可能成功。AI需要理解algebra_simps包含了基本的环运算规则而power2_eq_square是处理平方的关键引理。常见坑过度化简。有时auto或simp会应用一些意想不到的规则将表达式化简成一个虽然正确但形式完全不同的东西导致后续步骤无法进行。这时需要更精细的控制比如使用by (simp only: specific_rule1 specific_rule2)。自动实例化存在量词与全称量词在证明中经常需要“取一个满足条件的k”或“对任意x成立”。AI代理可以自动完成这些实例化。示例对于目标∃k. n 2*k证明n是偶数如果上下文有even nAI应能自动生成obtain k where “n 2*k” using ‹even n› by (auto elim: evenE)。难点当存在多个可能的选择时AI需要根据上下文选择最合适的一个。这依赖于对理论库的熟悉程度和简单的推理。自动完成归纳证明的标准步骤数学归纳法是形式化验证中的常客。其基础步骤和归纳步骤有固定的模式。AI代理可以自动化这些模式。模式识别给定一个关于自然数n的命题P(n)和提示“用归纳法”AI应能生成proof (induction n) case 0 show ?case by ... next case (Suc n) assume IH: “P(n)” show “P(Suc n)” ... qed更复杂的归纳对于结构归纳如列表、树、强归纳法AI需要生成对应的induction规则参数。自动搜索引理与定理这是机械化阶段的高级能力。当证明卡住时AI代理可以基于当前目标Goal和已知前提Premises从已导入的理论库中搜索可能适用的定理。这类似于Isabelle内置的find_theorems命令但更智能。工作原理AI将目标转化为一个特征向量例如包含的主要函数、关系、量词结构然后在定理数据库中进行近似匹配或向量相似度搜索。实操限制目前这项功能在通用大语言模型LLM驱动的代理中精度有限容易搜到不相关或形式不匹配的定理。但在专门针对某个数学领域如图论、分析微调过的模型上表现会好很多。4.2 经验分享让机械化更高效的策略分而治之不要试图让AI一次性机械化整个证明。将证明分解成多个独立的子目标subgoal然后让AI分别处理每一个。这样更容易定位问题也降低了AI的推理难度。提供“武器库”在开始证明前通过imports或unfolding语句显式地告诉AI和Isabelle你将主要使用哪些理论中的定义和定理。例如如果要做实数不等式证明确保导入了HOL-Analysis库并unfold相关的不等式定义。使用中间断言如果AI在机械化一个长链条的等式或不等式推导时失败可以手动插入一些have语句将长链条切成短链条。让AI先证明第一个have再证明第二个最后连接起来。这比让它直接证明最终结论要容易得多。拥抱交互式修正机械化失败是常态。Isabelle给出的错误信息如“failed to finish proof”、“type unification error”是黄金信息。将这些错误信息连同当前的局部证明状态作为新的提示反馈给AI。例如“上一步apply (rule conjI)失败了因为当前目标不是合取式。当前目标是A ⟶ B。我们应该换什么策略”机械化阶段是人将繁琐、重复的验证工作委托给AI的过程。成功的标志不是你完全不用动手而是你动脑思考“做什么”的时间占比远高于动手“怎么做”的时间。5. “泛化”能力从具体提示到通用策略的学习“泛化”是AI代理最具革命性也最具挑战性的能力。它意味着AI不仅能解决当前这个具体问题还能从人类给出的提示和最终的证明中学习提炼出可复用的证明策略或模式并将其应用到未来新的、但结构相似的问题上。这标志着AI从“计算器”向“助手”乃至“合作伙伴”的演进。5.1 泛化是如何发生的泛化不是魔法其背后通常依赖于机器学习模型特别是经过代码和数学文本训练的大语言模型LLM。其过程可以抽象为模式提取当AI代理成功完成一个证明例如通过归纳法证明了一个关于列表长度的性质它会分析这个证明的结构。它会注意到诸如“当目标形如P (x # xs)时使用了cases xs或induction xs”、“在化简步骤中频繁使用了simp add: list.map list.set”等模式。特征关联AI将提取出的模式与问题的“特征”关联起来。这些特征可能包括目标中出现的核心函数length,map,set、涉及的数据类型list,nat、使用的关键前提如单调性、可加性。策略库更新将这些“特征-策略”对以某种形式存储或更新到模型的内部参数中。在一些系统中这体现为一个可增长的策略建议库在端到端的LLM中这可能是模型权重基于此次成功经验的微调。未来应用当遇到一个新问题时AI会先提取新问题的特征然后在其内部策略库中搜索相似的特征。如果匹配成功它就会优先建议或直接应用关联的证明策略。5.2 实现泛化的技术路径与现状目前在Isabelle环境中实现泛化主要有几种技术路径各有优劣基于示例的学习系统维护一个证明示例数据库。当用户提出新目标时系统在数据库中检索证明目标最相似的已解决示例然后将其证明结构作为草稿推荐给用户。这种方法直接但泛化能力受限于数据库的规模和覆盖度。强化学习将证明过程建模为一个马尔可夫决策过程MDP每一步选择哪个证明策略tactic是动作成功证明获得正奖励失败或陷入循环获得负奖励。AI代理智能体通过大量与Isabelle环境的交互试错来学习一个策略网络。著名的DeepMind项目HOList和GPT-f就采用了类似思路。这种方法能学到非常通用的策略但需要海量的训练数据和计算资源。大语言模型微调使用包含大量Isabelle证明脚本如Archive of Formal Proofs的语料库对预训练的LLM如Codex, GPT-Neo进行监督微调。模型学习的是证明语言的统计规律和常见模式。其泛化能力取决于预训练模型的知识广度和微调数据的质量。这是目前最活跃的研究方向许多开源项目如Proof Advisor、Isabelle-GPT都在探索这条路。5.3 实操中的泛化我们能期待什么以我参与测试一些研究原型系统的经验来看当前的泛化能力还处于“有趣但尚不稳健”的阶段。在同构问题中表现良好如果新问题与学习过的问题几乎同构例如把证明length (filter P xs) ≤ length xs的经验用于证明card {x∈xs. P x} ≤ length xsAI代理经常能给出正确的策略建议。对抽象层次的提升困难例如AI从几个具体例子中学会了使用“反证法”但当遇到一个需要创造性选择反设前提的新问题时它可能无法识别出该用反证法或者会选择一个错误的反设。极度依赖提示质量泛化不是完全自主的。一个精确的高层提示如“这类似于我们之前证明过的关于集合基数的引理试试用类似的包含关系论证”能极大激发AI的泛化能力引导它找到正确的策略记忆。因此现阶段对泛化能力的合理期待是作为一个强大的“记忆外挂”和“模式推荐器”。它可以帮助你回忆起之前用过的类似证明技巧在你思考时提供几个高可能性的候选策略减少你从头构思的时间。但不能指望它完全自主地发现全新的、深刻的证明思路。6. 当前工具链与实战集成指南理论很美好但最终要落地到工具上。目前将AI代理集成到Isabelle工作流中主要有以下几种方式各有其适用场景和配置复杂度。6.1 主流工具与平台概览工具/项目名称类型核心能力集成方式适用场景Proof Advisor研究原型/插件基于LLM的证明策略建议、草稿生成。与Isabelle/jEdit或VSCode集成较好。本地或远程API调用。需配置Python环境和模型端点。日常证明辅助获取下一步策略建议。Isabelle-GPT开源接口项目提供与OpenAI GPT系列模型交互的框架将证明状态转换为自然语言提示。需要OpenAI API密钥通过脚本或简单UI与Isabelle交互。实验性探索利用GPT-4等模型的通用推理能力。PISA研究框架专注于搜索和定理证明使用强化学习等方法训练专用证明AI。通常作为独立系统运行与Isabelle通过文件或进程通信。研究环境用于自动化证明难度较高的猜想。Hammers(如Sledgehammer)Isabelle内置工具非AI但相关。使用外部自动定理证明器ATP和SMT求解器寻找证明。内置命令如sledgehammer。首选实战工具。当你有明确目标但不知如何下手时用它寻找证明片段。VSCode Isabelle 插件官方IDE提供优秀的代码补全、实时错误检查、文档查看为AI集成提供了良好基础。官方支持安装即用。所有工作的基础平台建议作为主要开发环境。6.2 以VSCode Sledgehammer 自定义脚本为核心的实战流程对于大多数希望提升效率的Isabelle用户我推荐一个务实且强大的组合VSCode 内置Sledgehammer 自定义Python脚本调用通用LLM。基础环境搭建安装VSCode和官方“Isabelle”插件。配置好Isabelle路径。插件提供无与伦比的实时反馈和导航体验。第一响应使用Sledgehammer当你在证明中卡住时首先尝试sledgehammer。将光标放在待证明的目标行在命令面板运行“Isabelle: Sledgehammer”或直接输入命令。Sledgehammer会调用外部ATP如E, Vampire, CVC4尝试证明你的目标。如果成功它会给出一个by语句通常使用metis或smt方法并列出它所使用的关键事实。经验Sledgehammer找到的证明可能非常简洁但难以理解一堆metis。你可以接受它快速过关也可以将其作为“提示”研究它使用了哪些引理这常常能给你新的证明思路。进阶辅助集成通用LLM作为“策略顾问”当Sledgehammer失败常见于需要归纳或更复杂构造的问题或者你需要更符合人类阅读习惯的Isar证明时可以求助于LLM。方法写一个简单的Python脚本其核心功能是从当前Isabelle缓冲区或通过插件API获取当前的证明状态焦点目标、局部假设。将这些信息与你的自然语言提示如“尝试用归纳法”组合构造一个详细的Prompt。调用OpenAI API或本地部署的Llama、CodeLlama等开源模型。解析返回的文本提取出Isabelle代码建议并插回编辑器。Prompt设计技巧prompt f 你是一个Isabelle/HOL定理证明助手。当前理论上下文包含以下定义和定理{context}。 我们正在尝试证明以下目标 Goal: {goal} 可用的局部假设有{assumptions} 用户提示{human_hint} 请给出接下来最可能成功的1-3个Isabelle证明策略tactic或一小段Isar证明脚本。只输出Isabelle代码。 重要警告永远不要盲目信任LLM生成的代码。必须将其放入Isabelle中验证。LLM经常会“幻觉”出语法正确但逻辑错误或引用不存在的定理的代码。人机协作循环你给出一个高层思路提示。AILLM脚本生成一段证明草稿或几个策略建议。你将其放入Isabelle执行。如果失败将Isabelle的错误信息作为新提示的一部分反馈给AI。重复2-4步直到证明完成。将最终成功的证明作为新的学习数据可以手动整理后加入你的“提示-证明”示例库用于未来微调本地模型实现个性化的泛化能力提升。这个流程将Isabelle的强大验证能力、Sledgehammer的自动化搜索能力以及LLM的灵活生成能力结合在一起形成了当前最实用的“AI辅助证明”工作流。7. 挑战、局限与未来展望尽管“Just Type It”的愿景令人兴奋但我们必须清醒地认识到当前技术面临的挑战和局限。这些不是否定其价值而是为了更有效地利用它。7.1 当前面临的主要挑战形式化语言与自然语言的语义鸿沟这是最根本的挑战。人类的一句“显然”背后可能隐藏着多步逻辑跳跃和深厚的背景知识。AI要准确理解“对n做归纳”并生成正确的induction n需要精确对齐数学概念与Isabelle的具体语法和规则。任何歧义都会导致生成错误的代码。长程依赖与全局上下文一个复杂的证明可能长达数百行涉及多个引理和定义。AI代理尤其是基于有限上下文窗口的LLM可能“忘记”或无法有效利用很早之前定义的概念或证明的中间结果导致生成的建议前后矛盾或无效。组合爆炸与搜索空间即使在一个简单的子目标上可用的证明策略也有数十种。策略之间可以无限组合。纯粹的生成式方法容易陷入低效的随机尝试。如何引导AI进行有方向的、启发式的搜索是一个核心难题。评估与信任如何评估AI生成的证明“草稿”的质量除了Isabelle最终的“绿灯”验证在生成过程中我们还需要一些中间评估指标比如生成的步骤是否朝着目标前进、是否引入了不必要的复杂性等。否则我们会浪费大量时间在验证明显错误的路径上。7.2 对从业者的实用建议面对这些挑战我的建议是保持主导权始终记住你是证明的负责人AI是助手。你的价值在于提出关键思路、识别证明结构、判断AI建议的合理性。不要沦为AI生成代码的调试员。从小处着手不要一开始就让AI证明整个定理。让它帮你完成一个具体的子目标、化简一个复杂的表达式、或者搜索一个可能适用的引理。积累小的成功建立信任。构建个人知识库将你成功使用AI辅助证明的典型案例包括最初的提示、AI的多次反馈、最终证明保存下来。这既是你的个人笔记未来也可以作为微调个性化AI模型的数据。理解工具的局限性知道Sledgehammer擅长什么一阶逻辑、等式知道LLM擅长什么模仿模式、生成结构化文本知道你自己擅长什么数学洞察、策略规划。将正确的问题分配给正确的“解决者”。7.3 未来可能的发展方向“Just Type It”的终极形态或许是一个深度理解特定数学领域如组合数学、抽象代数的专家系统与通用语言模型结合的产物。它不仅能理解“归纳法”这个策略还能理解你正在研究的“图论”中“归纳法”的常用变体它不仅能在失败时给出另一个策略还能解释为什么先前的策略失败了以及新策略为什么可能有效。另一个方向是交互模式的革新。也许未来的证明环境不再是线性的文本编辑而是一个混合的可视化界面其中部分证明步骤由AI以“黑盒”或“可折叠”的方式自动完成人类只需在高层的“证明蓝图”上进行标注和指引。无论如何AI代理在形式化验证中的应用其意义不在于取代人类而在于放大人类的数学智慧。它负责处理那些我们觉得枯燥、繁琐但机器擅长的工作让我们能更专注于创造性的思考。这个过程正如标题所言是“Drafting, Mechanizing, and Generalizing from Human Hints”——一场始于人类灵光一闪由人类与机器共同完成的、严谨而优美的思维之舞。