尧图网站建设 
写 Isabelle/HOL 证明的人大概都见过这种画面某天为了一个新需求把一个递归函数从f 0 0改成f 0 1保存后整个理论文件里几十条 lemma 瞬间变红。后续引理全部建立在旧定义上逐条修少的几分钟多的几小时而且很容易在修补过程里改出一条“看起来能过、实际上不对”的证明。这次我们看的项目叫CAPRIContract-Aware Proof Repair for Isabelle。名字已经把核心思路写在脸上了它面向 Isabelle 这类交互式定理证明器专攻“定义或规格变更后已有证明脚本大批失效”的问题。它不把证明整体重来而是利用契约信息做“感知式证明修复”。这是目前形式化验证社区比较活跃的方向也是 Isabelle 生态里一个有代表性的研究原型。一句话评价CAPRI 不是装完就能接管你所有项目的开箱工具它的价值更多体现在方法论和可复现验证流程上。最值得关注的点有三个第一它把“修证明”从语法补丁升级到契约语义层第二它把 Isabelle 理论维护中最耗人力的“连锁失效”问题尝试自动化第三它给做验证平台的人提供了一套可以对照评估的修复工作流。这篇文章会做几件事先说明 CAPRI 解决什么问题再拆解 Proof Repair 和 Contract-Aware 这两个关键概念然后给出 Isabelle 本地部署环境检查、一个最小的“损坏到修复”验证闭环、批量任务与 CI 接入思路、性能观察方法以及常见问题排查。适合的读者是写过或正在写 Isabelle/HOL 证明的人维护大型验证库的工程师以及准备把证明修复接入 CI 的平台开发者。1. CAPRI 是什么面向 Isabelle 的契约感知证明修复框架CAPRI 的完整名称是Contract-Aware Proof Repair for Isabelle。从名称可以明确判断它工作在 Isabelle 生态内目标是针对 Isabelle 理论文件中已经失效的证明做自动修复。这里的“损坏”不是语法错误而是语义不一致当某个函数、定义或诱导规则发生变更依赖它的证明在新定义下不再成立。CAPRI 的“契约感知”体现在修复依据上。简单说它不只告诉你要把by auto改成by (induct n) auto而是先分析变更前后函数对外承诺的规格差异再用这些差异指导补丁生成。这种做法比纯粹依赖 error 信息的修复更接近人和人协作修改证明的真实方式。从项目定位看它可能涉及的能力边界如下表所示具体版本和适配范围要以公开仓库为准能力维度说明项目类型面向 Isabelle 的证明修复研究原型输入对象发生定义变更后的 Isabelle/HOL 理论文件或 session核心思路通过旧契约与新契约的差异定位失效证明并生成补丁依赖平台Isabelle/HOL使用 Isar / apply-style 证明脚本主要收益减少定义变更后手工修证明的人力成本成熟度研究性质工程接入前应验证对目标理论库的覆盖与前人工作的区别不依赖纯语法重写引入契约语义作为修复锚点如果你准备尝试这个框架最需要先确认两件事它支持哪个 Isabelle 发布版本它对 Isar 结构化证明、apply脚本、sledgehammer生成式证明的覆盖各自到什么程度。研究原型通常会对理论库的模式有较强假设不能默认它能处理一切 Isabelle 工程。2. 核心能力速览这里把 CAPRI 和常见 Isabelle 工具的差异放在一起看有助于判断它到底适合什么场景也方便后续做技术选型。工具/能力解决什么问题修复依据典型使用位置Isabelle/jEdit Isabelle/build交互式编写、编译校验全量理论无只报告失败开发者本机、CISledgehammer搜索自动证明减少手工写 tactic目标本身单个 lemma 卡住时手工修证明按错误信息逐条调整人的领域知识所有场景CAPRI 类框架定义变更后批量修复失效证明旧契约/新契约差异大规模验证库重构后从这个表中能看出 CAPRI 的实际定位。它不适合做单条引理的日常探索式证明那是 Sledgehammer 和try的活。它更适合在“改一个底层定义影响几十个上层引理”的场景里出现。这类场景在真实项目中很常见算法换版本、数据结构加字段、前置条件收紧都会让原本的证明瞬间失去依据。需要注意CAPRI 不会消除形式化验证本身的高成本。它消除的是“同样一堆逻辑错误在不同 lemma 里反复出现”的重复劳动。对于一条引理是否需要新的归纳假设、是否需要引入中间引理契约信息只能提供方向真正的正确性仍然需要 Isabelle 内核校验。3. 它解决的问题为什么 Isabelle 证明需要 Repair要理解 CAPRI先理解 Isabelle 里一次“日常变更”会造成多大的连锁反应。一个 Isabelle/HOL 理论文件不是 Markdown 文档理论之间存在强依赖函数定义生成规则规则支撑 lemmalemma 又支撑更上层的 theorem。中间任何一层变化下层结论都可能不再成立。考虑一个非常小的例子。假设有这样一个递归函数theory DemoOk imports Main begin fun bump :: nat ⇒ nat where bump 0 0 | bump (Suc n) Suc (bump n) lemma bump_id: bump n n by (induct n) auto end这条bump_id证明可以通过没有任何问题。现在因为产品需求底层定义从“从 0 递增”改成“从 1 递增”theory DemoBroken imports Main begin fun bump :: nat ⇒ nat where bump 0 1 | bump (Suc n) Suc (bump n) (* 这行会失败bump n 已经不再等于 n *) lemma bump_id: bump n n by (induct n) auto end真实项目里的变化当然不会这么简单但基本模式是一样的。底层函数只改了一个 case上层几十条引理就要全部重新检视。更难受的是有些上层引理虽然引用旧定义但结论本身依然成立只是证明路径断了另一些引理则在语义上已经错误需要改成新的结论。前者适合“证明修复”后者需要“规格迁移”。如果工具只能机械地重新跑一遍证明无法区分这两种情况就会给出危险的补丁。契约感知要解决的核心问题正是这个语义判断哪条引理在新契约下仍然应该成立哪条已经失去了成立的基础。这也是 CAPRI 值得单独立项去做研究的原因。Isabelle 社区已有大量求助于自动化证明的工具但“定义变更之后如何保护已有证明资产”这一问题长期依赖人工。研究证明修复本质上是在为大型形式化库做重构工具价值随着理论库规模增长而放大。4. 关键概念拆解Proof Repair 与 Contract-Aware 的理解CAPRI 名称里有两个关键词如果对这两个词的理解不到位后面看它的流程设计会非常吃力。4.1 什么是 Proof RepairProof Repair 直译是“证明修复”指的是在一个证明因外部变更而失效后通过自动化或半自动化手段恢复其正确性。它不是把目标丢给 Sledgehammer 重新搜一遍而是尽量保留原证明里的有效结构只替换变化影响到的部分。例如一条多步骤的 Isar 证明里可能只有中间某一步依赖了被修改的定义。手工修复时我们会保留前后的证明块只补一个新的中间引理或调整归纳方式。Proof Repair 的自动化目标就是把这个过程交给程序定位失效步骤、分析失败原因、生成最小补丁、在 Isabelle 内核中验证补丁。一个容易被忽视的点是修复和重新证明对证明库质量的影响完全不同。重新证明可能生成一条语法正确但风格混乱的证明而修复更强调保留原有证明逻辑。这一点对需要长期维护的验证库很重要。4.2 什么是 Isabelle 场景中的 ContractContract 在日常编程语境里通常指“前置条件、后置条件、副作用承诺”。在 Isabelle 场景中它没有那么强的命令式语言色彩核心含义仍然是一个函数或组件对外承诺的可验证行为。这些承诺可以体现为定理本身的陈述也可以体现在与旧版本行为差异的推导上。举一个贴近逻辑表达的例子。一个函数的新旧两个版本可能有如下契约维度旧版本新版本对证明的影响输入类型未变未变签名相关证明无需大改完成性对全部输入有定义对全部输入有定义终止性证明可能受影响基本行为f n nf n n 1所有等于关系引理要改结论归纳结构标准结构归纳结构归纳但基础 case 改变依赖基础 case 的证明失效契约在这里就像一张行为对照表。CAPRI 利用旧契约告诉系统“原本承诺了什么”利用新契约告诉系统“现在承诺了什么”然后计算两者差异判断某条引理是因为证明路径断了还是因为承诺本身变了。4.3 Contract-Aware 为什么比纯语法修复更可靠纯语法修复会遇到一个经典困境错误信息只告诉你“这一步没有通过”不会告诉你“为什么不应该通过”。如果程序只看到一条 lemma 失败它可能尝试各种 tactic 把它强行证出来一旦 tactic 成功它甚至会高亮绿色但结论早已不是用户想要的真命题。这就是“假修复”。Contract-Aware 的价值在于修复前先做语义层面的判断。如果新契约仍然蕴含 lemma 的目标系统可以放心去补证明路径如果新契约已经与 lemma 目标矛盾系统不应该试图证明它而应该报告“该引理需要升级”。这个判断能力把证明修复从“能过就行”扭转到“应该过才过”是它和普通自修复工具最本质的区分。5. CAPRI 的修复工作流从变更定位到补丁验证虽然 CAPRI 的原始论文没有在材料中给出端到端脚本但从“Contract-Aware Proof Repair”这个标题可以还原它的目标工作流。理解这条流程对你评估和复现它会很有帮助。整套修复流程通常包含以下几个阶段变更差异定位对比修改前后的定义、函数签名和生成规则建立“哪些事实发生变化”的清单。契约抽取从旧理论中提炼旧契约从新理论中验证或推导新契约。这里的契约可以来自已有的 theorem也可以是用户提供的规范。失效传播分析找出所有以旧定义为基础的 lemma判断每条是仍在新契约下成立还是已经失效。修复策略选择对仍然成立的 lemma搜索新的证明路径对已经不成立的 lemma尝试根据契约差异生成新结论并补证。内核验证与回归把补丁后的理论重新交给 Isabelle 内核校验保证没有使用sorry或未经验证的恢复手段。这个流程和 CI 里的回归测试非常相似只是“测试用例”换成了 Isabelle lemma。CI 里的回归测试失败时工程师拿到的是失败日志CAPRI 这类工具的理想输出是带有语义解释的修复建议或可直接应用的 patch。在研究原型里各阶段能力往往不均衡。最容易做到的是失效传播分析因为依赖关系可以从 Isabelle 的 theory 依赖图直接拉取最难做到的是修复策略选择因为这需要理解每条 proof step 为什么失败以及如何从旧证明结构中复用有效部分。6. Isabelle 环境准备与 CAPRI 原型部署CAPRI 基于 Isabelle所以无论你是想直接运行它还是想复现它修复过的理论案例都要先准备好一套可用的 Isabelle 环境。以下步骤按通用流程给出具体版本号请以你下载的官方发布包为准。6.1 系统与依赖检查Isabelle 官方支持 Linux、macOS 和 Windows。Linux 和 macOS 下通常是直接解压官方 tar 包Windows 下使用官方安装向导或 WSL 都可行。开始之前建议先确认下面几项至少剩余 5 GB 磁盘空间主要用于 Isabelle 基础库和 heap image。如果使用 GPU这里先说清楚定理证明主要是 CPU 密集型任务GPU 不会明显加速 Isabelle 内核计算。依赖的 Java 运行时通常由安装包或环境提供主要用于 jEdit 界面。本机可以访问 Isabelle 官方下载源下载正式发布包。6.2 安装 Isabelle 与预编译基础库下面以 Linux 环境的通用命令为例# 解压官方发布包文件名按下载版本替换 tar -xzf Isabelle2024_linux.tar.gz cd Isabelle2024 # 预编译 HOL 基础 heap image ./bin/isabelle build -b HOL # 启动 jEdit 交互界面 ./bin/isabelle jedit -l HOL执行完第一步后~/.isabelle目录下会生成配置和 heap 文件。预编译HOL基础库通常需要一些时间这一步不是可选优化后续加载任何 HOL 理论都会依赖这个基础 image。如果跳过jEdit 打开理论文件时会反复等待自动构建。6.3 获取 CAPRI 原型与注册 SessionCAPRI 这类研究原型通常以源码仓库形式发布。拿到源码后不要直接双击运行可执行文件应该先阅读仓库 README重点看三处支持的 Isabelle 版本、复现命令、样例理论目录。如果你打算在自己的项目里测试可以把 CAPRI 相关理论聚合成一个 Isabelle session。在理论目录下创建ROOT文件示例session RepairDemo HOL options [document false] theories RepairDemo然后在目录下运行isabelle build -D .如果 CAPRI 仓库自带 session则把命令指向仓库根目录即可。注意不同 Isabelle 版本的 session 描述语法可能有差异以官方文档为准。7. 最小验证实验构造一次“损坏到修复”的闭环下面给出一套可以在你自己的 Isabelle 环境里复现的最小实验。它不是 CAPRI 的官方 benchmark但能让你直观理解什么叫做“定义变更导致证明失效”以及契约感知修复为什么需要判断“该修路径还是该修结论”。建议按三个文件顺序操作不要直接跳到第三个文件。第一步先创建通过版本theory RepairDemoOk imports Main begin fun bump :: nat ⇒ nat where bump 0 0 | bump (Suc n) Suc (bump n) lemma bump_id: bump n n by (induct n) auto end在 jEdit 中加载确认bump_id行没有红色标记。第二步修改基础 casetheory RepairDemoBroken imports Main begin fun bump :: nat ⇒ nat where bump 0 1 | bump (Suc n) Suc (bump n) (* 此证明会失败bump n 已经不等于 n *) lemma bump_id: bump n n by (induct n) auto end此时 Isabelle 会报出 proof failure。如果只做纯语法修复最危险的做法是不断换 tactic 让这条 lemma 通过但在当前定义下bump n n显然是假命题任何合法 tactic 都不可能通过。如果遇到by (* 某个 magic *)能通过请立刻检查是不是使用了sorry或未证假设。第三步根据契约差异修复。旧版本契约可以概括为bump n n新版本的变化是基础 case 增加 1因此新契约应更新为bump n Suc n。修复后的引理应表述新契约而不是硬证旧结论theory RepairDemoRepaired imports Main begin fun bump :: nat ⇒ nat where bump 0 1 | bump (Suc n) Suc (bump n) (* 根据新契约修正原引理 *) lemma bump_suc: bump n Suc n by (induct n) auto end这条实验虽然简单但点出了 CAPRI 的价值判断如果工具能自动识别“旧目标已不可能成立”并向用户建议新的目标形如bump n Suc n那么用户就不用逐层手工猜测。这里的失败原因和修复方向都清楚实际大型库里的模式会复杂得多但本质是同一个逻辑。你可以把这类“损坏—修复”闭环扩展到更多测试方向把函数从递归改成尾递归观察依赖原递归规则的证明情况。给某个函数增加前置条件观察原先无条件成立的 lemma 失效数量。把 lemma 证明从apply风格改成 Isar 风格观察修复是否保留原证明块。8. 批量任务、命令行与 CI 接入方式CAPRI 要真正服务工程逃不开批量任务和 CI 接入。在 Isabelle 项目里批量校验所有理论的标准做法是 session 构建isabelle build -D .这个命令会按依赖顺序编译 session 内所有理论文件并给出失败清单。理论上CAPRI 可以在这一层插入修复流程先用isabelle build找出所有失败 session再对每个失败理论运行修复最后再次构建验证。如果在你的项目里尝试这一思路建议用“构建—收集失败—修复—复建”四段式流水线# 第一次构建记录失败输出 isabelle build -D . first_build.log 21 || true # ... 运行 CAPRI / 修复脚本 ... # 第二次构建确认所有失败被消除 isabelle build -D .无论 CAPRI 提供的是命令行程序还是库接口CI 集成都应该遵循一个原则修复补丁必须在第二次isabelle build通过后才能合入。任何一步通过sorry、admit或axiomatization绕过的修复都不应该视为成功这一点可以直接写进 CI 检查逻辑。需要说明的是公开材料里没有显示 CAPRI 提供稳定的 REST API。如果你希望把它封装成服务合理的做法是做一个薄命令行封装输入为 Isabelle theory 路径和“定义变更说明”输出为补丁和新的理论文件再由 CI 决定是否合入。不要先期待有现成的微服务可用研究原型更多是给你一个可以二次开发的算法骨架。批量修复时另一个要注意的是失败隔离。如果一次变更引发了 50 条 lemma 失败其中 10 条已经失去成立基础工具可能在它们身上浪费大量时间。更合理的策略是给每条修复任务设置超时超过阈值就标记为“需要人工处理”避免一个卡死的证明阻塞整个批量任务。9. 资源占用与性能观察方法Isabelle 本身是一个 CPU 和内存敏感的应用CAPRI 这类证明修复框架因为要反复尝试修复策略资源消耗会更明显。观察资源占用不能只看 CPU 厂商广告里的“线程数”要重点看这几个指标单个证明的耗时jEdit 输出面板会显示命令耗时isabelle build也会在 verbose 模式下打印 session 耗时。heap image 大小预编译基础库会生成HOL等 heap image占用集中在~/.isabelle目录注意磁盘水位。并行负载isabelle build支持并行任务但并行度过高会导致内存暴涨尤其在大型 session 上。失败重试成本CAPRI 这类工具遇到失败证明时可能会多次尝试不同策略每次尝试都是一次真实证明内核调用。查看耗时和内存可以结合系统命令# 观察构建过程中的 CPU 和内存占用 isabelle build -D . pid$! top -p $pid如果内存吃紧可以通过减小 session 范围、拆分子理论、降低并行任务数来降低峰值。不要想着用 GPU 加速 Isabelle除非你在跑的是某些大规模搜索式工具否则这里的瓶颈在证明搜索路径而不是浮点计算。性能观察要形成记录习惯。每次跑 CAPRI 或手工修复批量证明建议记录三项信息失败 lemma 数、修复成功数、总构建时间。没有这些基线你无法判断一个新策略到底是在优化还是在拖慢流程。10. 常见问题与排查方法CAPRI 相关实践里很多坑不是 CAPRI 自己的 bug而是 Isabelle 环境和证明修复理解导致的。下面这张表可以直接拿去排查。问题现象可能原因排查方式解决方案jEdit 打开 .thy 后一直等待HOL heap image 未预编译确认是否执行过isabelle build -b HOL先预编译基础库再打开文件isabelle build报 session 找不到ROOT 文件缺失或路径不对查看当前目录是否有 ROOTROOT 内 session 名与调用是否一致在理论目录创建 ROOT 并保证 session 名匹配修复后仍然大量 lemma 失败修复补丁覆盖不完整查看失败 lemma 之间是否有共同依赖先修底层依赖 lemma再回归上层某条旧 lemma 怎么都证不过新契约下该 lemma 已不成立检查新函数行为是否仍蕴含原结论更新 lemma 结论不要强行修补证明使用sorry后才通过验证流程把sorry当作成功搜索.thy中的sorry和admit删除sorry补充完整证明后才能通过内存或 CPU 占用飙升并行 session 过度证明搜索top观察多个 Isabelle 进程降低并行任务数或拆分子 session一次变更影响范围超出预期理论依赖层级过深用 theory 依赖图梳理变更波及面增加中间 lemma隔离底层变化CAPRI 给出的补丁在自己项目无法加载版本不兼容或证明风格不匹配对照仓库要求的 Isabelle 版本统一 Isabelle 版本后重试这些坑里最值得强调的是sorry问题。定理证明器的真正价值就是“机器内核校验”一旦验证流程允许sorry进入整套系统的可信度就归零。任何自动化修复工具的实际效果都应该以“不使用 sorry 且完整通过isabelle build”为验收标准。11. 最佳实践在 Isabelle 项目里养成可修复的工作习惯不管最终你是否采用 CAPRI下面这些工程习惯都能显著降低 Isabelle 证明修复成本。第一把契约当作一等公民。不要在函数定义旁只写“这个函数会做 XX”的注释尽量把对外承诺表达为 theorem 或 lemma。这样当定义变更时你能快速判断是底层契约失效还是上层证明路径断裂。契约表达式越精确修复工具能利用的信息就越多。第二确认第一条可编译版本后再做重构。Isabelle 项目不是普通代码工程一个红掉的fun会污染所有依赖理论。改动前先跑一次isabelle build -D .拿到全绿基线再动手改定义。改完立刻构建利用错误清单确定影响范围。第三把失败导出成结构化清单。让 CI 在构建失败后输出“哪个理论、哪条 lemma、什么错误类型”格式最好是机器可读的 CSV 或 JSON方便批量统计和后续接入修复工具。第四保留修复前后对照。每次升级定义时将变更前的理论和变更后的理论分别保存到不同分支或目录避免修复工具误判导致不可逆破坏。第五涉及版权、许可证和团队协作材料时也要合规处理。Isabelle 理论库是团队资产如果使用公共的开源理论注意确认许可证是否允许你修改和再发布如果把自己的协议作为契约用于训练或工具评估也要事先获得授权。发现自动化工具建议的修复与业务语义矛盾时必须以人的确认为准不能交给工具独自决定。12. 总结与下一步CAPRI 最值得尝试的点不是“它能替我把所有证明写对”而是“它能提示我一条失效证明到底该修路径还是该更新结论”。这个判断能力是手工修证明时代我们习以为常、但一直缺少自动化表达的东西。如果你决定亲自验证这个方向建议按下面顺序推进先用最小.thy复现“定义变更导致 lemma 失效”再在更大理论库上统计一次变更的失效传播比例最后才考虑把 CAPRI 或类似工作流接入 CI。最容易踩的坑有三个忘记先预编译 HOL heap、把sorry当成功、以及用 GPU 思维去优化 CPU 密集的证明搜索。后续可以扩展的方向包括把 CAPRI 的思路接回 Isar 证明结构修复、增加与 Sledgehammer 的联动、把修复结果做差异对比并自动生成变更评审说明以及为大型验证库建立“变更影响门禁”。对这些方向感兴趣的读者建议直接找 CAPRI 对应论文和仓库代码阅读重点看它的数据集约简逻辑和失败分类方式。结合自己的 Isabelle 项目跑一遍比对修复前后证明数量与构建时间的变化比任何抽象介绍都有说服力。 CAPRI：Isabelle 的契约感知证明修复框架
写 Isabelle/HOL 证明的人大概都见过这种画面某天为了一个新需求把一个递归函数从f 0 0改成f 0 1保存后整个理论文件里几十条 lemma 瞬间变红。后续引理全部建立在旧定义上逐条修少的几分钟多的几小时而且很容易在修补过程里改出一条“看起来能过、实际上不对”的证明。这次我们看的项目叫CAPRIContract-Aware Proof Repair for Isabelle。名字已经把核心思路写在脸上了它面向 Isabelle 这类交互式定理证明器专攻“定义或规格变更后已有证明脚本大批失效”的问题。它不把证明整体重来而是利用契约信息做“感知式证明修复”。这是目前形式化验证社区比较活跃的方向也是 Isabelle 生态里一个有代表性的研究原型。一句话评价CAPRI 不是装完就能接管你所有项目的开箱工具它的价值更多体现在方法论和可复现验证流程上。最值得关注的点有三个第一它把“修证明”从语法补丁升级到契约语义层第二它把 Isabelle 理论维护中最耗人力的“连锁失效”问题尝试自动化第三它给做验证平台的人提供了一套可以对照评估的修复工作流。这篇文章会做几件事先说明 CAPRI 解决什么问题再拆解 Proof Repair 和 Contract-Aware 这两个关键概念然后给出 Isabelle 本地部署环境检查、一个最小的“损坏到修复”验证闭环、批量任务与 CI 接入思路、性能观察方法以及常见问题排查。适合的读者是写过或正在写 Isabelle/HOL 证明的人维护大型验证库的工程师以及准备把证明修复接入 CI 的平台开发者。1. CAPRI 是什么面向 Isabelle 的契约感知证明修复框架CAPRI 的完整名称是Contract-Aware Proof Repair for Isabelle。从名称可以明确判断它工作在 Isabelle 生态内目标是针对 Isabelle 理论文件中已经失效的证明做自动修复。这里的“损坏”不是语法错误而是语义不一致当某个函数、定义或诱导规则发生变更依赖它的证明在新定义下不再成立。CAPRI 的“契约感知”体现在修复依据上。简单说它不只告诉你要把by auto改成by (induct n) auto而是先分析变更前后函数对外承诺的规格差异再用这些差异指导补丁生成。这种做法比纯粹依赖 error 信息的修复更接近人和人协作修改证明的真实方式。从项目定位看它可能涉及的能力边界如下表所示具体版本和适配范围要以公开仓库为准能力维度说明项目类型面向 Isabelle 的证明修复研究原型输入对象发生定义变更后的 Isabelle/HOL 理论文件或 session核心思路通过旧契约与新契约的差异定位失效证明并生成补丁依赖平台Isabelle/HOL使用 Isar / apply-style 证明脚本主要收益减少定义变更后手工修证明的人力成本成熟度研究性质工程接入前应验证对目标理论库的覆盖与前人工作的区别不依赖纯语法重写引入契约语义作为修复锚点如果你准备尝试这个框架最需要先确认两件事它支持哪个 Isabelle 发布版本它对 Isar 结构化证明、apply脚本、sledgehammer生成式证明的覆盖各自到什么程度。研究原型通常会对理论库的模式有较强假设不能默认它能处理一切 Isabelle 工程。2. 核心能力速览这里把 CAPRI 和常见 Isabelle 工具的差异放在一起看有助于判断它到底适合什么场景也方便后续做技术选型。工具/能力解决什么问题修复依据典型使用位置Isabelle/jEdit Isabelle/build交互式编写、编译校验全量理论无只报告失败开发者本机、CISledgehammer搜索自动证明减少手工写 tactic目标本身单个 lemma 卡住时手工修证明按错误信息逐条调整人的领域知识所有场景CAPRI 类框架定义变更后批量修复失效证明旧契约/新契约差异大规模验证库重构后从这个表中能看出 CAPRI 的实际定位。它不适合做单条引理的日常探索式证明那是 Sledgehammer 和try的活。它更适合在“改一个底层定义影响几十个上层引理”的场景里出现。这类场景在真实项目中很常见算法换版本、数据结构加字段、前置条件收紧都会让原本的证明瞬间失去依据。需要注意CAPRI 不会消除形式化验证本身的高成本。它消除的是“同样一堆逻辑错误在不同 lemma 里反复出现”的重复劳动。对于一条引理是否需要新的归纳假设、是否需要引入中间引理契约信息只能提供方向真正的正确性仍然需要 Isabelle 内核校验。3. 它解决的问题为什么 Isabelle 证明需要 Repair要理解 CAPRI先理解 Isabelle 里一次“日常变更”会造成多大的连锁反应。一个 Isabelle/HOL 理论文件不是 Markdown 文档理论之间存在强依赖函数定义生成规则规则支撑 lemmalemma 又支撑更上层的 theorem。中间任何一层变化下层结论都可能不再成立。考虑一个非常小的例子。假设有这样一个递归函数theory DemoOk imports Main begin fun bump :: nat ⇒ nat where bump 0 0 | bump (Suc n) Suc (bump n) lemma bump_id: bump n n by (induct n) auto end这条bump_id证明可以通过没有任何问题。现在因为产品需求底层定义从“从 0 递增”改成“从 1 递增”theory DemoBroken imports Main begin fun bump :: nat ⇒ nat where bump 0 1 | bump (Suc n) Suc (bump n) (* 这行会失败bump n 已经不再等于 n *) lemma bump_id: bump n n by (induct n) auto end真实项目里的变化当然不会这么简单但基本模式是一样的。底层函数只改了一个 case上层几十条引理就要全部重新检视。更难受的是有些上层引理虽然引用旧定义但结论本身依然成立只是证明路径断了另一些引理则在语义上已经错误需要改成新的结论。前者适合“证明修复”后者需要“规格迁移”。如果工具只能机械地重新跑一遍证明无法区分这两种情况就会给出危险的补丁。契约感知要解决的核心问题正是这个语义判断哪条引理在新契约下仍然应该成立哪条已经失去了成立的基础。这也是 CAPRI 值得单独立项去做研究的原因。Isabelle 社区已有大量求助于自动化证明的工具但“定义变更之后如何保护已有证明资产”这一问题长期依赖人工。研究证明修复本质上是在为大型形式化库做重构工具价值随着理论库规模增长而放大。4. 关键概念拆解Proof Repair 与 Contract-Aware 的理解CAPRI 名称里有两个关键词如果对这两个词的理解不到位后面看它的流程设计会非常吃力。4.1 什么是 Proof RepairProof Repair 直译是“证明修复”指的是在一个证明因外部变更而失效后通过自动化或半自动化手段恢复其正确性。它不是把目标丢给 Sledgehammer 重新搜一遍而是尽量保留原证明里的有效结构只替换变化影响到的部分。例如一条多步骤的 Isar 证明里可能只有中间某一步依赖了被修改的定义。手工修复时我们会保留前后的证明块只补一个新的中间引理或调整归纳方式。Proof Repair 的自动化目标就是把这个过程交给程序定位失效步骤、分析失败原因、生成最小补丁、在 Isabelle 内核中验证补丁。一个容易被忽视的点是修复和重新证明对证明库质量的影响完全不同。重新证明可能生成一条语法正确但风格混乱的证明而修复更强调保留原有证明逻辑。这一点对需要长期维护的验证库很重要。4.2 什么是 Isabelle 场景中的 ContractContract 在日常编程语境里通常指“前置条件、后置条件、副作用承诺”。在 Isabelle 场景中它没有那么强的命令式语言色彩核心含义仍然是一个函数或组件对外承诺的可验证行为。这些承诺可以体现为定理本身的陈述也可以体现在与旧版本行为差异的推导上。举一个贴近逻辑表达的例子。一个函数的新旧两个版本可能有如下契约维度旧版本新版本对证明的影响输入类型未变未变签名相关证明无需大改完成性对全部输入有定义对全部输入有定义终止性证明可能受影响基本行为f n nf n n 1所有等于关系引理要改结论归纳结构标准结构归纳结构归纳但基础 case 改变依赖基础 case 的证明失效契约在这里就像一张行为对照表。CAPRI 利用旧契约告诉系统“原本承诺了什么”利用新契约告诉系统“现在承诺了什么”然后计算两者差异判断某条引理是因为证明路径断了还是因为承诺本身变了。4.3 Contract-Aware 为什么比纯语法修复更可靠纯语法修复会遇到一个经典困境错误信息只告诉你“这一步没有通过”不会告诉你“为什么不应该通过”。如果程序只看到一条 lemma 失败它可能尝试各种 tactic 把它强行证出来一旦 tactic 成功它甚至会高亮绿色但结论早已不是用户想要的真命题。这就是“假修复”。Contract-Aware 的价值在于修复前先做语义层面的判断。如果新契约仍然蕴含 lemma 的目标系统可以放心去补证明路径如果新契约已经与 lemma 目标矛盾系统不应该试图证明它而应该报告“该引理需要升级”。这个判断能力把证明修复从“能过就行”扭转到“应该过才过”是它和普通自修复工具最本质的区分。5. CAPRI 的修复工作流从变更定位到补丁验证虽然 CAPRI 的原始论文没有在材料中给出端到端脚本但从“Contract-Aware Proof Repair”这个标题可以还原它的目标工作流。理解这条流程对你评估和复现它会很有帮助。整套修复流程通常包含以下几个阶段变更差异定位对比修改前后的定义、函数签名和生成规则建立“哪些事实发生变化”的清单。契约抽取从旧理论中提炼旧契约从新理论中验证或推导新契约。这里的契约可以来自已有的 theorem也可以是用户提供的规范。失效传播分析找出所有以旧定义为基础的 lemma判断每条是仍在新契约下成立还是已经失效。修复策略选择对仍然成立的 lemma搜索新的证明路径对已经不成立的 lemma尝试根据契约差异生成新结论并补证。内核验证与回归把补丁后的理论重新交给 Isabelle 内核校验保证没有使用sorry或未经验证的恢复手段。这个流程和 CI 里的回归测试非常相似只是“测试用例”换成了 Isabelle lemma。CI 里的回归测试失败时工程师拿到的是失败日志CAPRI 这类工具的理想输出是带有语义解释的修复建议或可直接应用的 patch。在研究原型里各阶段能力往往不均衡。最容易做到的是失效传播分析因为依赖关系可以从 Isabelle 的 theory 依赖图直接拉取最难做到的是修复策略选择因为这需要理解每条 proof step 为什么失败以及如何从旧证明结构中复用有效部分。6. Isabelle 环境准备与 CAPRI 原型部署CAPRI 基于 Isabelle所以无论你是想直接运行它还是想复现它修复过的理论案例都要先准备好一套可用的 Isabelle 环境。以下步骤按通用流程给出具体版本号请以你下载的官方发布包为准。6.1 系统与依赖检查Isabelle 官方支持 Linux、macOS 和 Windows。Linux 和 macOS 下通常是直接解压官方 tar 包Windows 下使用官方安装向导或 WSL 都可行。开始之前建议先确认下面几项至少剩余 5 GB 磁盘空间主要用于 Isabelle 基础库和 heap image。如果使用 GPU这里先说清楚定理证明主要是 CPU 密集型任务GPU 不会明显加速 Isabelle 内核计算。依赖的 Java 运行时通常由安装包或环境提供主要用于 jEdit 界面。本机可以访问 Isabelle 官方下载源下载正式发布包。6.2 安装 Isabelle 与预编译基础库下面以 Linux 环境的通用命令为例# 解压官方发布包文件名按下载版本替换 tar -xzf Isabelle2024_linux.tar.gz cd Isabelle2024 # 预编译 HOL 基础 heap image ./bin/isabelle build -b HOL # 启动 jEdit 交互界面 ./bin/isabelle jedit -l HOL执行完第一步后~/.isabelle目录下会生成配置和 heap 文件。预编译HOL基础库通常需要一些时间这一步不是可选优化后续加载任何 HOL 理论都会依赖这个基础 image。如果跳过jEdit 打开理论文件时会反复等待自动构建。6.3 获取 CAPRI 原型与注册 SessionCAPRI 这类研究原型通常以源码仓库形式发布。拿到源码后不要直接双击运行可执行文件应该先阅读仓库 README重点看三处支持的 Isabelle 版本、复现命令、样例理论目录。如果你打算在自己的项目里测试可以把 CAPRI 相关理论聚合成一个 Isabelle session。在理论目录下创建ROOT文件示例session RepairDemo HOL options [document false] theories RepairDemo然后在目录下运行isabelle build -D .如果 CAPRI 仓库自带 session则把命令指向仓库根目录即可。注意不同 Isabelle 版本的 session 描述语法可能有差异以官方文档为准。7. 最小验证实验构造一次“损坏到修复”的闭环下面给出一套可以在你自己的 Isabelle 环境里复现的最小实验。它不是 CAPRI 的官方 benchmark但能让你直观理解什么叫做“定义变更导致证明失效”以及契约感知修复为什么需要判断“该修路径还是该修结论”。建议按三个文件顺序操作不要直接跳到第三个文件。第一步先创建通过版本theory RepairDemoOk imports Main begin fun bump :: nat ⇒ nat where bump 0 0 | bump (Suc n) Suc (bump n) lemma bump_id: bump n n by (induct n) auto end在 jEdit 中加载确认bump_id行没有红色标记。第二步修改基础 casetheory RepairDemoBroken imports Main begin fun bump :: nat ⇒ nat where bump 0 1 | bump (Suc n) Suc (bump n) (* 此证明会失败bump n 已经不等于 n *) lemma bump_id: bump n n by (induct n) auto end此时 Isabelle 会报出 proof failure。如果只做纯语法修复最危险的做法是不断换 tactic 让这条 lemma 通过但在当前定义下bump n n显然是假命题任何合法 tactic 都不可能通过。如果遇到by (* 某个 magic *)能通过请立刻检查是不是使用了sorry或未证假设。第三步根据契约差异修复。旧版本契约可以概括为bump n n新版本的变化是基础 case 增加 1因此新契约应更新为bump n Suc n。修复后的引理应表述新契约而不是硬证旧结论theory RepairDemoRepaired imports Main begin fun bump :: nat ⇒ nat where bump 0 1 | bump (Suc n) Suc (bump n) (* 根据新契约修正原引理 *) lemma bump_suc: bump n Suc n by (induct n) auto end这条实验虽然简单但点出了 CAPRI 的价值判断如果工具能自动识别“旧目标已不可能成立”并向用户建议新的目标形如bump n Suc n那么用户就不用逐层手工猜测。这里的失败原因和修复方向都清楚实际大型库里的模式会复杂得多但本质是同一个逻辑。你可以把这类“损坏—修复”闭环扩展到更多测试方向把函数从递归改成尾递归观察依赖原递归规则的证明情况。给某个函数增加前置条件观察原先无条件成立的 lemma 失效数量。把 lemma 证明从apply风格改成 Isar 风格观察修复是否保留原证明块。8. 批量任务、命令行与 CI 接入方式CAPRI 要真正服务工程逃不开批量任务和 CI 接入。在 Isabelle 项目里批量校验所有理论的标准做法是 session 构建isabelle build -D .这个命令会按依赖顺序编译 session 内所有理论文件并给出失败清单。理论上CAPRI 可以在这一层插入修复流程先用isabelle build找出所有失败 session再对每个失败理论运行修复最后再次构建验证。如果在你的项目里尝试这一思路建议用“构建—收集失败—修复—复建”四段式流水线# 第一次构建记录失败输出 isabelle build -D . first_build.log 21 || true # ... 运行 CAPRI / 修复脚本 ... # 第二次构建确认所有失败被消除 isabelle build -D .无论 CAPRI 提供的是命令行程序还是库接口CI 集成都应该遵循一个原则修复补丁必须在第二次isabelle build通过后才能合入。任何一步通过sorry、admit或axiomatization绕过的修复都不应该视为成功这一点可以直接写进 CI 检查逻辑。需要说明的是公开材料里没有显示 CAPRI 提供稳定的 REST API。如果你希望把它封装成服务合理的做法是做一个薄命令行封装输入为 Isabelle theory 路径和“定义变更说明”输出为补丁和新的理论文件再由 CI 决定是否合入。不要先期待有现成的微服务可用研究原型更多是给你一个可以二次开发的算法骨架。批量修复时另一个要注意的是失败隔离。如果一次变更引发了 50 条 lemma 失败其中 10 条已经失去成立基础工具可能在它们身上浪费大量时间。更合理的策略是给每条修复任务设置超时超过阈值就标记为“需要人工处理”避免一个卡死的证明阻塞整个批量任务。9. 资源占用与性能观察方法Isabelle 本身是一个 CPU 和内存敏感的应用CAPRI 这类证明修复框架因为要反复尝试修复策略资源消耗会更明显。观察资源占用不能只看 CPU 厂商广告里的“线程数”要重点看这几个指标单个证明的耗时jEdit 输出面板会显示命令耗时isabelle build也会在 verbose 模式下打印 session 耗时。heap image 大小预编译基础库会生成HOL等 heap image占用集中在~/.isabelle目录注意磁盘水位。并行负载isabelle build支持并行任务但并行度过高会导致内存暴涨尤其在大型 session 上。失败重试成本CAPRI 这类工具遇到失败证明时可能会多次尝试不同策略每次尝试都是一次真实证明内核调用。查看耗时和内存可以结合系统命令# 观察构建过程中的 CPU 和内存占用 isabelle build -D . pid$! top -p $pid如果内存吃紧可以通过减小 session 范围、拆分子理论、降低并行任务数来降低峰值。不要想着用 GPU 加速 Isabelle除非你在跑的是某些大规模搜索式工具否则这里的瓶颈在证明搜索路径而不是浮点计算。性能观察要形成记录习惯。每次跑 CAPRI 或手工修复批量证明建议记录三项信息失败 lemma 数、修复成功数、总构建时间。没有这些基线你无法判断一个新策略到底是在优化还是在拖慢流程。10. 常见问题与排查方法CAPRI 相关实践里很多坑不是 CAPRI 自己的 bug而是 Isabelle 环境和证明修复理解导致的。下面这张表可以直接拿去排查。问题现象可能原因排查方式解决方案jEdit 打开 .thy 后一直等待HOL heap image 未预编译确认是否执行过isabelle build -b HOL先预编译基础库再打开文件isabelle build报 session 找不到ROOT 文件缺失或路径不对查看当前目录是否有 ROOTROOT 内 session 名与调用是否一致在理论目录创建 ROOT 并保证 session 名匹配修复后仍然大量 lemma 失败修复补丁覆盖不完整查看失败 lemma 之间是否有共同依赖先修底层依赖 lemma再回归上层某条旧 lemma 怎么都证不过新契约下该 lemma 已不成立检查新函数行为是否仍蕴含原结论更新 lemma 结论不要强行修补证明使用sorry后才通过验证流程把sorry当作成功搜索.thy中的sorry和admit删除sorry补充完整证明后才能通过内存或 CPU 占用飙升并行 session 过度证明搜索top观察多个 Isabelle 进程降低并行任务数或拆分子 session一次变更影响范围超出预期理论依赖层级过深用 theory 依赖图梳理变更波及面增加中间 lemma隔离底层变化CAPRI 给出的补丁在自己项目无法加载版本不兼容或证明风格不匹配对照仓库要求的 Isabelle 版本统一 Isabelle 版本后重试这些坑里最值得强调的是sorry问题。定理证明器的真正价值就是“机器内核校验”一旦验证流程允许sorry进入整套系统的可信度就归零。任何自动化修复工具的实际效果都应该以“不使用 sorry 且完整通过isabelle build”为验收标准。11. 最佳实践在 Isabelle 项目里养成可修复的工作习惯不管最终你是否采用 CAPRI下面这些工程习惯都能显著降低 Isabelle 证明修复成本。第一把契约当作一等公民。不要在函数定义旁只写“这个函数会做 XX”的注释尽量把对外承诺表达为 theorem 或 lemma。这样当定义变更时你能快速判断是底层契约失效还是上层证明路径断裂。契约表达式越精确修复工具能利用的信息就越多。第二确认第一条可编译版本后再做重构。Isabelle 项目不是普通代码工程一个红掉的fun会污染所有依赖理论。改动前先跑一次isabelle build -D .拿到全绿基线再动手改定义。改完立刻构建利用错误清单确定影响范围。第三把失败导出成结构化清单。让 CI 在构建失败后输出“哪个理论、哪条 lemma、什么错误类型”格式最好是机器可读的 CSV 或 JSON方便批量统计和后续接入修复工具。第四保留修复前后对照。每次升级定义时将变更前的理论和变更后的理论分别保存到不同分支或目录避免修复工具误判导致不可逆破坏。第五涉及版权、许可证和团队协作材料时也要合规处理。Isabelle 理论库是团队资产如果使用公共的开源理论注意确认许可证是否允许你修改和再发布如果把自己的协议作为契约用于训练或工具评估也要事先获得授权。发现自动化工具建议的修复与业务语义矛盾时必须以人的确认为准不能交给工具独自决定。12. 总结与下一步CAPRI 最值得尝试的点不是“它能替我把所有证明写对”而是“它能提示我一条失效证明到底该修路径还是该更新结论”。这个判断能力是手工修证明时代我们习以为常、但一直缺少自动化表达的东西。如果你决定亲自验证这个方向建议按下面顺序推进先用最小.thy复现“定义变更导致 lemma 失效”再在更大理论库上统计一次变更的失效传播比例最后才考虑把 CAPRI 或类似工作流接入 CI。最容易踩的坑有三个忘记先预编译 HOL heap、把sorry当成功、以及用 GPU 思维去优化 CPU 密集的证明搜索。后续可以扩展的方向包括把 CAPRI 的思路接回 Isar 证明结构修复、增加与 Sledgehammer 的联动、把修复结果做差异对比并自动生成变更评审说明以及为大型验证库建立“变更影响门禁”。对这些方向感兴趣的读者建议直接找 CAPRI 对应论文和仓库代码阅读重点看它的数据集约简逻辑和失败分类方式。结合自己的 Isabelle 项目跑一遍比对修复前后证明数量与构建时间的变化比任何抽象介绍都有说服力。