尧图网站建设 
简介这份资源是面向 Agda 语言开发者与函数式编程学习者的 VS Code 扩展用于在 VS Code 中提供 agda-mode 支持解决 Agda 代码编辑、类型检查与交互式证明缺少轻量编辑器集成的问题。资源包共 179 个文件以 67 个 js 与 64 个 res 源码文件为主另有 13 个 out 与 13 个 in 测试用例、5 个 json 配置、4 个 agda 示例文件及 less、yml、ttf 等样式与字体资源压缩包约 457KB结构紧凑。扩展支持通过 Cc Cl 等组合键加载 Agda 文件并引入仍处于开发阶段的 Agda 语言服务器启用后可在面板右上角看到 LSP 标识针对类型相关命令还提供不同规范化级别的按键映射方案弥补了无法像 Emacs 那样使用 Cu 前缀的限制。目前已有 236 人学习下载适合希望以 VS Code 替代 Emacs 进行 Agda 开发、并需要参考按键映射与测试用例的读者。1. 在 VS Code 里写 Agda为什么值得折腾以及谁适合入坑如果你写过一段时间的 Agda大概率经历过这种分裂一边是 Emacs 里 agda-mode 的顺滑交互一边是团队里其他人都在用 VS Code 写 TypeScript、Python、Rust你为了一个证明不得不单开一个终端窗口。agda-mode-vscode 要解决的就是这个割裂——把 Agda 的交互式证明开发搬进 VS Code让你在同一个编辑器里既写业务代码又写形式化验证。它适合三类人正在学依赖类型和定理证明的学生、需要把关键算法做形式化验证的工程师、以及已经习惯 VS Code 生态不想再学 Emacs 键位的开发者。核心能力包括目标与上下文实时显示、洞hole的交互式填充、表达式求值、类型检查反馈、以及大小写敏感的命令面板操作。说白了它把 Agda 那个黑匣子式的命令行交互变成了编辑器里可点、可看、可回退的图形化流程。2. agda-mode-vscode 的安装链路从 Agda 本体到编辑器插件2.1 先装 Agda 编译器别急着点插件安装很多人翻车的第一步是直接在 VS Code 扩展市场搜 agda-mode-vscode 然后点安装装完发现命令面板里所有 Agda 命令都是灰的。原因很简单这个插件本身不包含 Agda 编译器它只是一个前端适配层真正做类型检查、求值、证明搜索的是你系统里的agda可执行文件。所以顺序必须是先装 Agda 本体再装插件。在 macOS 上最省心的方式是 Homebrewbrew install agda在 Ubuntu/Debian 上可以用 apt 或者从 Haskell 工具链装# 方式一系统包管理器版本可能偏旧 sudo apt install agda # 方式二用 cabal 装最新版适合需要特定版本的情况 cabal update cabal install AgdaWindows 用户建议走 Haskell Platform 或者 WSL原生 Windows 下的 Agda 安装路径和库路径容易出玄学问题。装完后验证agda --version如果这条命令报 command not found说明 PATH 没配好插件后面也会找不到编译器。这一步没有捷径必须先过。2.2 插件安装与 agda 可执行文件路径绑定Agda 本体就绪后在 VS Code 扩展面板搜索agda-mode-vscode安装。装完重启 VS Code打开一个.agda文件如果左下角状态栏出现 Agda 的版本信息说明插件已经识别到了编译器。如果没有需要手动指定路径。在 VS Code 设置里搜索agda-mode找到Agda Mode: Executable Path这一项填入agda的绝对路径。比如 macOS 上 Homebrew 装的通常在/opt/homebrew/bin/agdaLinux 上可能在/usr/bin/agda或~/.cabal/bin/agda。填完后重新加载窗口。{ agda-mode.executablePath: /opt/homebrew/bin/agda, agda-mode.libraryPath: [ /opt/homebrew/share/agda/lib/prim, /opt/homebrew/share/agda/lib/prim/Agda ] }executablePath是编译器主程序路径libraryPath是标准库和 primitive 库的搜索路径。这两个参数配错表现是文件能打开但所有命令都超时或报找不到模块。我一般会先用agda --print-agda-lib-path确认库路径再填进去。2.3 最小可运行示例一个 Nat 加法证明装好之后别急着写复杂证明先用一个最小例子验证整条链路。新建Test.agdamodule Test where open import Data.Nat using (ℕ; zero; suc; __) open import Relation.Binary.PropositionalEquality using (_≡_; refl) -- 证明 0 n ≡ n -identityˡ : ∀ (n : ℕ) → zero n ≡ n -identityˡ n refl把光标放在refl上按C-c C-n或命令面板执行Agda: Normalize如果底部输出面板显示refl的类型和归一化结果说明插件、编译器、标准库三者已经打通。这个例子虽然简单但它覆盖了模块加载、导入解析、类型检查、表达式求值四个关键环节任何一环断了都会在这里暴露。3. 交互式证明的核心操作洞、目标、上下文与求值3.1 用 ? 和 C-c C-l 加载文件并生成洞Agda 的交互式开发围绕“洞”展开。你在证明里写一个?然后加载文件插件会把每个洞的位置、目标类型、当前上下文全部列出来。这是 agda-mode-vscode 最核心的价值——不用再靠记忆去推当前有哪些变量、目标是什么类型。-comm : ∀ (m n : ℕ) → m n ≡ n m -comm zero n ? -comm (suc m) n ?按C-c C-l加载后VS Code 会在洞的位置显示目标类型和上下文。你可以用C-c C-,查看当前洞的详细上下文用C-c C-.查看目标和上下文一起显示。这两个快捷键在 Emacs 里也有但 VS Code 的悬浮提示让信息更直观。3.2 用 C-c C-c 做 case split用 C-c C-r 做 refine洞有了之后下一步是填充。最常用的两个命令是 case split 和 refine。case split 的用法把光标放在变量上按C-c C-cAgda 会根据这个变量的类型自动拆分成多个构造子分支。比如上面-comm zero n ?里的ncase split 后会变成-comm zero zero ? -comm zero (suc n) ?refine 的用法把光标放在洞上按C-c C-rAgda 会尝试用当前上下文里类型匹配的表达式来填充这个洞。如果目标类型是_≡_它可能会自动填refl如果目标是一个函数类型它可能会引入 lambda 或让参数。-- refine 前 -comm zero n ? -- refine 后假设目标能直接 refl -comm zero n refl这两个命令的组合基本覆盖了 80% 的证明填充工作。剩下的 20% 需要手动写辅助引理或者用C-c C-s做证明搜索。3.3 求值与类型检查C-c C-n 和 C-c C-t 的实际用途C-c C-n是 normalize对光标处的表达式做归一化求值。这在调试证明时非常有用——你写了一个复杂的表达式不确定它化简后长什么样直接 normalize 看结果。C-c C-t是 infer type显示光标处表达式的类型。当你从别处复制了一段代码但不确定它的类型是否匹配当前目标时这个命令能快速验证。-- 把光标放在 (suc zero suc zero) 上按 C-c C-n -- 输出面板会显示 suc (suc zero) test : ℕ test suc zero suc zero这两个命令在 VS Code 里的输出会显示在底部面板而不是像 Emacs 那样在 minibuffer 里一闪而过。好处是可以回看坏处是面板会占空间。我一般会把输出面板设成自动隐藏需要时再拉出来。4. 避坑与排查agda-mode-vscode 最常见的五类翻车4.1 插件装了但所有命令灰色不可用现象扩展面板显示 agda-mode-vscode 已安装但打开.agda文件后命令面板里所有 Agda 命令都是灰的状态栏也没有版本信息。原因插件没有找到agda可执行文件。常见于 Agda 装在非标准路径、或者 VS Code 是从 GUI 启动导致 PATH 和终端不一致。解决在设置里显式配置agda-mode.executablePath为绝对路径。macOS 上如果是从 Dock 启动 VS CodePATH 可能不包含/opt/homebrew/bin必须手动填。填完后用Developer: Reload Window重载。4.2 文件加载超时或卡在 “Checking”现象按C-c C-l后底部一直显示 “Checking”几分钟不结束或者直接报超时。原因通常是标准库路径没配好Agda 在递归搜索模块时陷入死循环或者项目根目录的.agda-lib文件配置有误。解决先确认libraryPath包含标准库路径。然后在项目根目录建一个.agda-lib文件name: my-project include: . depend: standard-libraryinclude是项目源文件目录depend是依赖的库名。如果标准库是通过agda --install装的库名通常是standard-library。配好后重新加载。4.3 case split 后变量名冲突或自动生成的名字不可读现象C-c C-c拆分后Agda 自动生成的变量名像n₁、n₂、n₃嵌套深了之后完全分不清哪个是哪个。原因Agda 的自动命名策略是加数字后缀这是默认行为不是 bug。解决在设置里开启agda-mode.useUnicodeInput和自定义命名前缀或者手动在 case split 前先把变量重命名成有意义的名称。我一般会在拆分前把n改成n或者m这样自动生成的名字至少能区分层级。另外C-c C-c时可以给一个模式参数比如C-c C-c n指定用n作为基础名。4.4 Unicode 输入法冲突导致字符打不出来现象Agda 大量使用 Unicode 字符∀、→、≡、ℕ在 VS Code 里输入\forall后按 Tab 没有反应或者被其他输入法拦截。原因VS Code 的 Unicode 输入依赖插件的 keybinding如果和其他扩展比如 Vim 模式、输入法切换工具冲突就会失效。解决检查keybindings.json里是否有冲突的绑定。agda-mode-vscode 默认用\作为前缀触发 Unicode 输入如果这个键被占用可以在设置里改成其他前缀。另外确认没有开启 VS Code 的editor.unicodeHighlight相关干扰项。4.5 多文件项目下模块解析失败现象单文件能跑但项目里import其他模块时提示 “Failed to find module”。原因Agda 的模块解析依赖目录结构和.agda-lib的include配置。如果文件不在include指定的目录下或者模块名和文件路径不匹配就会找不到。解决确保每个模块的文件路径和模块声明一致。比如module Foo.Bar where必须放在Foo/Bar.agda。然后在.agda-lib里把项目根目录加进include。如果用了子目录每个子目录不需要单独声明只要根目录在include里Agda 会递归查找。5. 进阶技巧把 agda-mode-vscode 调成顺手的证明工作台5.1 自定义快捷键把高频命令绑到顺手的位置agda-mode-vscode 默认的快捷键继承自 Emacs 的C-c C-x体系在 VS Code 里按起来并不顺手。我一般会把最常用的几个命令重新绑定[ { key: ctrlaltl, command: agda-mode.load, when: editorLangId agda }, { key: ctrlaltc, command: agda-mode.case, when: editorLangId agda }, { key: ctrlaltr, command: agda-mode.refine, when: editorLangId agda }, { key: ctrlaltn, command: agda-mode.normalize, when: editorLangId agda } ]when条件限定只在 Agda 文件里生效避免和其他语言的快捷键冲突。load对应C-c C-lcase对应C-c C-crefine对应C-c C-rnormalize对应C-c C-n。绑完之后整个证明流程基本可以左手不离键盘完成。5.2 用 Agda 的 --safe 标志做严格模式检查Agda 有一个--safe编译标志开启后会禁用一些可能破坏一致性的特性比如postulate、{-# COMPILE #-}等。在项目里开启这个标志可以强制自己写出更干净的证明。在.agda-lib里加一行name: my-project include: . depend: standard-library flags: --safe或者在文件头部加 pragma{-# OPTIONS --safe #-}开启后任何使用不安全特性的地方都会报错。这个习惯在写需要长期维护的证明库时特别有用相当于给证明加了一层 lint。5.3 验证插件是否真正在工作三个检查点装完调完之后怎么确认 agda-mode-vscode 是真的在正常工作而不是碰巧没报错我一般会做三个检查检查项操作预期结果编译器识别打开.agda文件看状态栏显示 Agda 版本号类型检查按C-c C-l加载含洞的文件洞位置显示目标类型和上下文求值光标放在表达式上按C-c C-n底部面板输出归一化结果三个都通过说明插件、编译器、库路径、交互命令四条链路全部打通。任何一个失败回到第 4 章对应条目排查。5.4 我自己的习惯先写类型再写证明最后才 refine用了几年 Agda 之后我最大的教训是不要一上来就写?然后指望 refine 帮你填完。正确的顺序是先想清楚类型签名把引理拆到足够小每个引理的类型都写明确然后再用 case split 和 refine 去填。refine 很好用但它只能帮你做机械的填充不能帮你做证明设计。我见过太多人卡在一个大洞上反复 refine 失败最后发现是引理拆分粒度太粗。把大目标拆成三五个小引理每个小引理单独用洞交互效率反而更高。希望帮到你。本文还有配套的精品资源点击获取 VS Code 中配置 Agda 交互式证明：安装、避坑与进阶技巧
简介这份资源是面向 Agda 语言开发者与函数式编程学习者的 VS Code 扩展用于在 VS Code 中提供 agda-mode 支持解决 Agda 代码编辑、类型检查与交互式证明缺少轻量编辑器集成的问题。资源包共 179 个文件以 67 个 js 与 64 个 res 源码文件为主另有 13 个 out 与 13 个 in 测试用例、5 个 json 配置、4 个 agda 示例文件及 less、yml、ttf 等样式与字体资源压缩包约 457KB结构紧凑。扩展支持通过 Cc Cl 等组合键加载 Agda 文件并引入仍处于开发阶段的 Agda 语言服务器启用后可在面板右上角看到 LSP 标识针对类型相关命令还提供不同规范化级别的按键映射方案弥补了无法像 Emacs 那样使用 Cu 前缀的限制。目前已有 236 人学习下载适合希望以 VS Code 替代 Emacs 进行 Agda 开发、并需要参考按键映射与测试用例的读者。1. 在 VS Code 里写 Agda为什么值得折腾以及谁适合入坑如果你写过一段时间的 Agda大概率经历过这种分裂一边是 Emacs 里 agda-mode 的顺滑交互一边是团队里其他人都在用 VS Code 写 TypeScript、Python、Rust你为了一个证明不得不单开一个终端窗口。agda-mode-vscode 要解决的就是这个割裂——把 Agda 的交互式证明开发搬进 VS Code让你在同一个编辑器里既写业务代码又写形式化验证。它适合三类人正在学依赖类型和定理证明的学生、需要把关键算法做形式化验证的工程师、以及已经习惯 VS Code 生态不想再学 Emacs 键位的开发者。核心能力包括目标与上下文实时显示、洞hole的交互式填充、表达式求值、类型检查反馈、以及大小写敏感的命令面板操作。说白了它把 Agda 那个黑匣子式的命令行交互变成了编辑器里可点、可看、可回退的图形化流程。2. agda-mode-vscode 的安装链路从 Agda 本体到编辑器插件2.1 先装 Agda 编译器别急着点插件安装很多人翻车的第一步是直接在 VS Code 扩展市场搜 agda-mode-vscode 然后点安装装完发现命令面板里所有 Agda 命令都是灰的。原因很简单这个插件本身不包含 Agda 编译器它只是一个前端适配层真正做类型检查、求值、证明搜索的是你系统里的agda可执行文件。所以顺序必须是先装 Agda 本体再装插件。在 macOS 上最省心的方式是 Homebrewbrew install agda在 Ubuntu/Debian 上可以用 apt 或者从 Haskell 工具链装# 方式一系统包管理器版本可能偏旧 sudo apt install agda # 方式二用 cabal 装最新版适合需要特定版本的情况 cabal update cabal install AgdaWindows 用户建议走 Haskell Platform 或者 WSL原生 Windows 下的 Agda 安装路径和库路径容易出玄学问题。装完后验证agda --version如果这条命令报 command not found说明 PATH 没配好插件后面也会找不到编译器。这一步没有捷径必须先过。2.2 插件安装与 agda 可执行文件路径绑定Agda 本体就绪后在 VS Code 扩展面板搜索agda-mode-vscode安装。装完重启 VS Code打开一个.agda文件如果左下角状态栏出现 Agda 的版本信息说明插件已经识别到了编译器。如果没有需要手动指定路径。在 VS Code 设置里搜索agda-mode找到Agda Mode: Executable Path这一项填入agda的绝对路径。比如 macOS 上 Homebrew 装的通常在/opt/homebrew/bin/agdaLinux 上可能在/usr/bin/agda或~/.cabal/bin/agda。填完后重新加载窗口。{ agda-mode.executablePath: /opt/homebrew/bin/agda, agda-mode.libraryPath: [ /opt/homebrew/share/agda/lib/prim, /opt/homebrew/share/agda/lib/prim/Agda ] }executablePath是编译器主程序路径libraryPath是标准库和 primitive 库的搜索路径。这两个参数配错表现是文件能打开但所有命令都超时或报找不到模块。我一般会先用agda --print-agda-lib-path确认库路径再填进去。2.3 最小可运行示例一个 Nat 加法证明装好之后别急着写复杂证明先用一个最小例子验证整条链路。新建Test.agdamodule Test where open import Data.Nat using (ℕ; zero; suc; __) open import Relation.Binary.PropositionalEquality using (_≡_; refl) -- 证明 0 n ≡ n -identityˡ : ∀ (n : ℕ) → zero n ≡ n -identityˡ n refl把光标放在refl上按C-c C-n或命令面板执行Agda: Normalize如果底部输出面板显示refl的类型和归一化结果说明插件、编译器、标准库三者已经打通。这个例子虽然简单但它覆盖了模块加载、导入解析、类型检查、表达式求值四个关键环节任何一环断了都会在这里暴露。3. 交互式证明的核心操作洞、目标、上下文与求值3.1 用 ? 和 C-c C-l 加载文件并生成洞Agda 的交互式开发围绕“洞”展开。你在证明里写一个?然后加载文件插件会把每个洞的位置、目标类型、当前上下文全部列出来。这是 agda-mode-vscode 最核心的价值——不用再靠记忆去推当前有哪些变量、目标是什么类型。-comm : ∀ (m n : ℕ) → m n ≡ n m -comm zero n ? -comm (suc m) n ?按C-c C-l加载后VS Code 会在洞的位置显示目标类型和上下文。你可以用C-c C-,查看当前洞的详细上下文用C-c C-.查看目标和上下文一起显示。这两个快捷键在 Emacs 里也有但 VS Code 的悬浮提示让信息更直观。3.2 用 C-c C-c 做 case split用 C-c C-r 做 refine洞有了之后下一步是填充。最常用的两个命令是 case split 和 refine。case split 的用法把光标放在变量上按C-c C-cAgda 会根据这个变量的类型自动拆分成多个构造子分支。比如上面-comm zero n ?里的ncase split 后会变成-comm zero zero ? -comm zero (suc n) ?refine 的用法把光标放在洞上按C-c C-rAgda 会尝试用当前上下文里类型匹配的表达式来填充这个洞。如果目标类型是_≡_它可能会自动填refl如果目标是一个函数类型它可能会引入 lambda 或让参数。-- refine 前 -comm zero n ? -- refine 后假设目标能直接 refl -comm zero n refl这两个命令的组合基本覆盖了 80% 的证明填充工作。剩下的 20% 需要手动写辅助引理或者用C-c C-s做证明搜索。3.3 求值与类型检查C-c C-n 和 C-c C-t 的实际用途C-c C-n是 normalize对光标处的表达式做归一化求值。这在调试证明时非常有用——你写了一个复杂的表达式不确定它化简后长什么样直接 normalize 看结果。C-c C-t是 infer type显示光标处表达式的类型。当你从别处复制了一段代码但不确定它的类型是否匹配当前目标时这个命令能快速验证。-- 把光标放在 (suc zero suc zero) 上按 C-c C-n -- 输出面板会显示 suc (suc zero) test : ℕ test suc zero suc zero这两个命令在 VS Code 里的输出会显示在底部面板而不是像 Emacs 那样在 minibuffer 里一闪而过。好处是可以回看坏处是面板会占空间。我一般会把输出面板设成自动隐藏需要时再拉出来。4. 避坑与排查agda-mode-vscode 最常见的五类翻车4.1 插件装了但所有命令灰色不可用现象扩展面板显示 agda-mode-vscode 已安装但打开.agda文件后命令面板里所有 Agda 命令都是灰的状态栏也没有版本信息。原因插件没有找到agda可执行文件。常见于 Agda 装在非标准路径、或者 VS Code 是从 GUI 启动导致 PATH 和终端不一致。解决在设置里显式配置agda-mode.executablePath为绝对路径。macOS 上如果是从 Dock 启动 VS CodePATH 可能不包含/opt/homebrew/bin必须手动填。填完后用Developer: Reload Window重载。4.2 文件加载超时或卡在 “Checking”现象按C-c C-l后底部一直显示 “Checking”几分钟不结束或者直接报超时。原因通常是标准库路径没配好Agda 在递归搜索模块时陷入死循环或者项目根目录的.agda-lib文件配置有误。解决先确认libraryPath包含标准库路径。然后在项目根目录建一个.agda-lib文件name: my-project include: . depend: standard-libraryinclude是项目源文件目录depend是依赖的库名。如果标准库是通过agda --install装的库名通常是standard-library。配好后重新加载。4.3 case split 后变量名冲突或自动生成的名字不可读现象C-c C-c拆分后Agda 自动生成的变量名像n₁、n₂、n₃嵌套深了之后完全分不清哪个是哪个。原因Agda 的自动命名策略是加数字后缀这是默认行为不是 bug。解决在设置里开启agda-mode.useUnicodeInput和自定义命名前缀或者手动在 case split 前先把变量重命名成有意义的名称。我一般会在拆分前把n改成n或者m这样自动生成的名字至少能区分层级。另外C-c C-c时可以给一个模式参数比如C-c C-c n指定用n作为基础名。4.4 Unicode 输入法冲突导致字符打不出来现象Agda 大量使用 Unicode 字符∀、→、≡、ℕ在 VS Code 里输入\forall后按 Tab 没有反应或者被其他输入法拦截。原因VS Code 的 Unicode 输入依赖插件的 keybinding如果和其他扩展比如 Vim 模式、输入法切换工具冲突就会失效。解决检查keybindings.json里是否有冲突的绑定。agda-mode-vscode 默认用\作为前缀触发 Unicode 输入如果这个键被占用可以在设置里改成其他前缀。另外确认没有开启 VS Code 的editor.unicodeHighlight相关干扰项。4.5 多文件项目下模块解析失败现象单文件能跑但项目里import其他模块时提示 “Failed to find module”。原因Agda 的模块解析依赖目录结构和.agda-lib的include配置。如果文件不在include指定的目录下或者模块名和文件路径不匹配就会找不到。解决确保每个模块的文件路径和模块声明一致。比如module Foo.Bar where必须放在Foo/Bar.agda。然后在.agda-lib里把项目根目录加进include。如果用了子目录每个子目录不需要单独声明只要根目录在include里Agda 会递归查找。5. 进阶技巧把 agda-mode-vscode 调成顺手的证明工作台5.1 自定义快捷键把高频命令绑到顺手的位置agda-mode-vscode 默认的快捷键继承自 Emacs 的C-c C-x体系在 VS Code 里按起来并不顺手。我一般会把最常用的几个命令重新绑定[ { key: ctrlaltl, command: agda-mode.load, when: editorLangId agda }, { key: ctrlaltc, command: agda-mode.case, when: editorLangId agda }, { key: ctrlaltr, command: agda-mode.refine, when: editorLangId agda }, { key: ctrlaltn, command: agda-mode.normalize, when: editorLangId agda } ]when条件限定只在 Agda 文件里生效避免和其他语言的快捷键冲突。load对应C-c C-lcase对应C-c C-crefine对应C-c C-rnormalize对应C-c C-n。绑完之后整个证明流程基本可以左手不离键盘完成。5.2 用 Agda 的 --safe 标志做严格模式检查Agda 有一个--safe编译标志开启后会禁用一些可能破坏一致性的特性比如postulate、{-# COMPILE #-}等。在项目里开启这个标志可以强制自己写出更干净的证明。在.agda-lib里加一行name: my-project include: . depend: standard-library flags: --safe或者在文件头部加 pragma{-# OPTIONS --safe #-}开启后任何使用不安全特性的地方都会报错。这个习惯在写需要长期维护的证明库时特别有用相当于给证明加了一层 lint。5.3 验证插件是否真正在工作三个检查点装完调完之后怎么确认 agda-mode-vscode 是真的在正常工作而不是碰巧没报错我一般会做三个检查检查项操作预期结果编译器识别打开.agda文件看状态栏显示 Agda 版本号类型检查按C-c C-l加载含洞的文件洞位置显示目标类型和上下文求值光标放在表达式上按C-c C-n底部面板输出归一化结果三个都通过说明插件、编译器、库路径、交互命令四条链路全部打通。任何一个失败回到第 4 章对应条目排查。5.4 我自己的习惯先写类型再写证明最后才 refine用了几年 Agda 之后我最大的教训是不要一上来就写?然后指望 refine 帮你填完。正确的顺序是先想清楚类型签名把引理拆到足够小每个引理的类型都写明确然后再用 case split 和 refine 去填。refine 很好用但它只能帮你做机械的填充不能帮你做证明设计。我见过太多人卡在一个大洞上反复 refine 失败最后发现是引理拆分粒度太粗。把大目标拆成三五个小引理每个小引理单独用洞交互效率反而更高。希望帮到你。本文还有配套的精品资源点击获取