从AI对话到任务执行：费马大定理机器检验证明背后的工程启示

最近有个新闻值得停下来聊几句Claude 在 11 天里完成了费马大定理的首个机器检验证明。很多人的第一反应是“AI 已经强到能证明 357 年悬案了”这个理解一半对一半容易跑偏。先对齐一个基本事实费马大定理在 1994 年已经被怀尔斯完整证明357 年指的是从费马在书边写下那个著名留言到最终给出严格证明的跨度。Claude 这次做的不是重新发现定理也不是给出一个全新的人类可读证明而是把一套极其复杂的证明材料变成一条可以被机器逐行核验的逻辑链条。换句话说这次的主角是“机器检验证明”不是“AI 解出了数学难题”。这个区分非常重要。因为它意味着我们从“AI 替你写答案”进入到了“AI 替你审证据”的阶段。如果只看热闹你可能觉得这只是又一个大模型炫技的新闻如果看门道你会发现它真正改变的是人和复杂任务之间的协作方式。我下面会展开聊聊为什么机器检验证明比“AI 证明定理”更值得关注、11 天这个工程流程是怎么运转的、真正卡住人的地方在哪里以及你手头那些代码、文档、论文审稿任务能不能复用同样的方法论。1. 先放下“AI 证明定理”这个说法重点是“机器检验证明”1.1 费马大定理难在“没有答案”其实是难在“证明太复杂无法被完整核验”1637 年费马在《算术》一书的页边写下一段话他发现了一个绝妙的证明但空白处太小写不下。这个命题简单到中学生都能读懂当整数 n 大于 2 时不存在三个正整数 a、b、c 满足 a 的 n 次方加 b 的 n 次方等于 c 的 n 次方。但就是这样一个表述极简的命题拖了三百多年。直到 1994 年怀尔斯才给出完整证明。这个证明不是几页纸能写完的而是融合了椭圆曲线、模形式、伽罗瓦表示等大量现代数学工具总篇幅超过上百页。更关键的是这个证明在最初提交后评审过程中还真被发现存在一个 gap后来怀尔斯和泰勒花了一段时间才修补完成。很多人不理解为什么数学证明会这么难验证。其实这里存在一个长期被忽视的“验证危机”数学家在不断地生产越来越复杂的证明但判断一个证明是否成立仍然主要靠少数领域专家花几个月甚至几年逐行通读。怀尔斯的证明是 20 世纪最重要的数学成果之一即便如此真正完整理解并核验过全部逻辑的人在整个数学圈里也是极少数。费马大定理的这次机器检验证明本质上是把“人读人判”的环节部分替换成了“机器读、机器校验、人做最终判断”。这就是它真正值得关注的原因。1.2 机器检验证明是什么它更像审计而不是“做数学题”机器检验证明的基本思路是先把证明从自然语言文章转换成一个可以被机械规则核验的对象。比如每一步推导都必须标明引用了哪条公理、哪个引理、哪次等价变形。然后程序检查整条链条是否完整闭合、是否每一步都符合既定规则。可以把它理解成金融审计审计员不需要重新发明一套记账方法也不需要重新做一遍公司业务而是拿已有的账本逐笔核对凭证和流水看逻辑是否连续、依据是否充足。所以 Claude 这次扮演的角色更像一个“审计员”而不是“创新者”。它做的事情是让一个已经被人类接受多年的证明获得一种新的可追踪、可复核、可机器判定的形态。这句话听起来好像没什么了不起但在一个证明动辄上百页、引用几十篇论文的领域这种“审计能力”本身就是稀缺能力。当然机器检验也有它的元问题用什么样的形式化语言来写证明接受哪些公理作为起点转换过程是否会引入原始文本里没有的错误这些问题的答案决定了机器验证结论的可靠性。这也意味着机器验证从来不是“一键得到正确答案”而是在一套严格规则下寻找逻辑漏洞的过程。1.3 Claude 这次为什么值得关注公开报道里有两个关键词11 天首个机器检验证明。严格从数学史角度说“首个”这个说法是否能在专业圈获得一致认可我没有能力考证。但从工程视角看这件事真正值得关注的点在于它是一次完整的 agent 工作流任务而不是一次大模型对话。原因很简单费马大定理的相关证明材料太庞大了上下文窗口再大也不可能一次性装完。要完成检验必须把任务拆开、建立索引、分阶段验证、保存中间结果、处理失败步骤、最后再汇总形成报告。这一整套流程已经不是一个聊天对话框能承载的。换句话讲这件事展示的是大模型从“一次性问答工具”进化成了“能长期工作的任务执行者”。一旦任务可以被拆解、被追踪、被人工复核AI 能介入的工作范围就会从“写段代码、改段文案”扩大到“验证一套复杂证明”“审计一个大型代码库”“通读几十份需求文档并检查一致性”。这也是我理解费马大定理新闻的核心视角真正值得关注的不是“模型变聪明了”而是“模型开始有完整的工程流程了”。2. 11 天不是“算得快”而是“工程流程完整”2.1 为什么要用工程化视角看费马大定理检验如果只是“问一下”大模型让它判断题某个证明步骤是否成立它可能几分钟内就能给出一个直觉判断。但那种判断的质量是不可控的它可能说得很自信可是没有引用原文、没有回溯上下文、没有检查每一步推导规则。11 天这个时间量级说明 Claude 做的不只是“回答”而是一个完整工程要读入大量证明材料建立定理、引理、推论之间的依赖关系把证明拆成可以逐一验证的片段对每个片段执行校验校验失败时要能定位问题、重新加载上下文、再试最后把所有验证过的片段重新组装成一条完整逻辑链。这就像让一个人去审计一家大型企业的财务账目。真正拖时间的不是阅读单张凭证而是把整个账目结构建立起来、交叉核对、追溯异常、再形成审计报告。2.2 可复用的四阶段任务拆解从这类复杂验证任务的通用工作流来看几乎必然包含下面四个阶段。这个模板不仅适用于数学证明你把它拿去审代码、审文档、检查需求一致性也是一样成立的。阶段核心目标典型动作关键交付物材料理解把长文本转成结构化摘要扫描章节、标记定理和引理、建立术语表定理地图、文档索引骨架拆解拆成可独立验证的子任务识别引理依赖关系、为每个子任务定义输入输出依赖图、TODO 列表逐步验证逐个执行逻辑校验对每个引理运行规则检查标记失败点并重试分步验证日志记录复查重建完整逻辑链检查各片段衔接是否闭合整理验证报告最终验证报告这四步里最容易出错的是第二步骨架拆解。如果子任务切割得太碎会因为缺少上下文导致验证失真如果切得太粗又会因为单个子任务太大而无法有效验证。这里的平衡点要结合具体任务来微调。2.3 中间结果保存是成败关键任何一个长时间运行的 agent 任务最怕的就是中途丢失状态。费马大定理这种体量的任务如果模型在某一步失去上下文或者任务中断而之前验证过的结果没有保存那就意味着要从头再来。11 天可能变成 22 天甚至直接失败。正确做法是持续把中间结果写入磁盘验证到哪一步、某个引理是否通过、哪个步骤存在可疑点、下一次从哪里继续全部保存成结构化文件。这样模型的核心能力就不再依赖“上下文窗口能装多少”而是依赖“工作目录里留存了什么”。这个思路做产品经理的会比较熟悉任何一次重要的评审都必须有会议纪要。AI 做长任务也一样必须有“工作底稿”。没有底稿的结论无论来自人还是 AI都不可信。2.4 Agent 工具的出现补齐了大模型对话缺的那块拼图过去一年里以 Claude Code 为代表的 agent 工具逐渐进入开发者视野。它不是又一个聊天窗口而是能访问文件系统、执行命令、维护 TODO 列表、读取目录结构的命令行助手。你可以这样理解普通大模型对话是“你问我答”信息停留在聊天记录里agent 工具是“你布置任务它进项目目录干活”信息保存在项目文件里。因为它能读文件、跑脚本、创建新文件、修改配置所以可以把一个复杂的验证任务实际执行起来。费马大定理的机器检验证明之所以能在 11 天内完成靠的正是这种 agent 能力模型不再是凭空生成回答而是可以反复读取材料文件、调用检查脚本、把中间结果写进状态文件、再读取状态继续下一步。这种工作方式已经把“单轮问答”提升到了“执行一个项目”的级别。3. 复杂验证任务真正卡人的地方不是模型智能是任务工程3.1 怎么把一个模糊目标变成可执行规范很多人用 AI 做复杂任务时第一步就错了指令太模糊。“帮我验证费马大定理的证明”是一件不可能直接执行的事。正确的任务表述应该是任务验证论文第三章中引理 3.2 到定理 3.4 的推导链。 输入材料/research/proof/chapter3.md 输出目录/research/output/verification_report.md 校验规则 - 只允许使用经典一阶逻辑和论文第二节列出的引理。 - 每个推理步骤必须标记依据。 - 如果发现某一步不成立停止在该步并返回足够的上下文块。这样写的好处是范围明确、输入输出明确、规则明确、失败处理方式明确。AI 才不会靠“感觉”去完成一个本来就不清晰的任务。3.2 上下文窗口不够用长任务怎么“不失忆”费马大定理的证明材料如果全部塞进上下文窗口绝大多数模型都装不下。所以长任务处理的核心技巧是不要试图一次性把材料都灌进去。我一般会采用“先给目录再按需展开章节”的方式先让 agent 扫描项目目录生成文件清单和章节结构根据结构拆分成多个子任务每个子任务只加载需要的段落子任务验证结束后把结果写入独立文件下一个子任务读取“已验证结论”的摘要而不是重新读原文。这样做还有一个额外好处节省 token。已经验证过的引理可以打包成一个“黑盒”后续步骤直接引用黑盒的验证结论不必反复把原推理过程重新灌给模型。3.3 自动纠错与人工复核分工必须清楚用一个表格来看三类角色的分工角色职责典型动作模型生成候选推导、执行子任务、解释逻辑试错、重写、定位可疑点自动化工具做确定性检查、快速验证格式和语法跑测试、比对规则、检查目录人工定义任务边界、抽查高风险步骤、做最终验收阅读验证报告、复核关键引理这个分工的关键在于模型负责“生成和定位”工具负责“判定”人负责“定义和法律效力”。三者不能互相替代。3.4 成本与配额免费额度下的资源规划其实长期跑 agent 任务最大的限制往往不是“模型不够聪明”而是 token 费用和调用配额。像费马大定理这种体量的完整验证消耗的资源是惊人的。如果你只依赖免费额度11 天任务基本跑不完。可行策略是分级别使用模型拆解任务、读取文档、定位信息使用成本更低、速度更快的模型关键推理校验和风险判断送到能力更强的高级模型格式检查、日志整理、文件操作本地小模型或普通脚本处理敏感材料如果涉及隐私或未公开内容优先使用本地模型加本地 agent 工具不要让数据出本地环境。把 AI 验证当成一个“算力预算项目”来管理比纠结“哪个模型最强”要实际得多。4. 想在自己的项目里复现类似流程从最小可用验证开始4.1 环境准备装好命令行 agent别卡在第一个报错上如果你想实际体验 agent 工作流最常见的入口是安装 Claude Code。常见安装方式npm install -g anthropic-ai/claude-code安装完成后在终端输入claude启动。如果你在 Windows 上遇到claude 不是内部或外部命令或无法将“claude”项识别为 cmdlet、函数、脚本文件或可运行程序的名称这类报错先不要怀疑“安装失败了”。按这个顺序排查确认 Node 和 npm 是否正常node -v、npm -v找到 npm 全局目录npm root -g确认全局 bin 目录是否已加入 PATH安装完成后是否重新打开了终端最后再试claude --version。这几步能解决绝大多数安装后无法识别命令的问题。4.2 VSCode 里的集成与模型配置在 VSCode 里打开终端运行claude再指定一个项目目录它就会扫目录、生成计划、开始执行任务。对写代码和验证文档来说这种工作方式非常自然。如果你用的是第三方兼容接口或本地模型通常需要配置 base URL 和环境变量。常见写法是ANTHROPIC_BASE_URLhttp://localhost:11434 ANTHROPIC_MODELyour-local-model也可以用 cc switch 这类工具在多个模型供应商之间切换。需要理解的是cc switch 切换的是“底层模型提供方”agent 主程序还是同一个。切换模型只能改变推理能力不会自动解决任务拆解、输出格式、状态管理等工程问题。4.3 最小验证流程不要一上来就挑战费马大定理我强烈建议第一个任务选小一点比如让你手头的 agent 去验证一个代码文件里的函数是否符合文档描述。流程如下写清楚任务范围、输入文件、输出文件让 agent 先读取目录生成 TODO 列表只让它验证一个函数或一个模块检查生成的验证报告和日志再尝试扩展到两个、三个相关模块。这个“先跑通最小任务再扩大范围”的方式看起来保守其实最高效。因为如果你连最小任务的输入输出边界都没定义清楚扩大范围只会得到更多不可靠的输出。4.4 新手配置与进阶配置建议维度新手建议进阶建议任务范围单个函数或引理跨章节、跨模块让 agent 自动拆解输出粒度结论加简短依据完整验证报告含失败点与上下文回溯中间产物输出到单独文件建立 input/output/log/state 固定目录结构上下文管理一次塞入小材料先建索引再按需加载复核机制人工逐条检查高风险步骤抽样 自动化测试辅助成本控制默认模型限 token小模型粗筛 大模型处理关键步骤4.5 常见问题排查链路任务崩了先别怀疑“AI 变笨了”。按顺序排查现象没有输出 / 报错 / 结果不一致输入文件是否可读、编码是否为 UTF-8、路径是否正确、文档结构是否匹配环境依赖是否安装、Node 版本是否过低、接口地址是否能连通、本地模型服务是否启动参数上下文是否被截断、子任务是否过大、超时时间是否太短工具边界检查是否触发了工具的版本限制或文件大小限制。注意不要一上来就怀疑“模型不行了”先看任务描述和输入文件是否干净。大量所谓“AI 突然变笨”的问题本质是输入没给对、期望没写清楚。5. 机器检验的边界在哪里别把“看起来对”当成“真的对”5.1 模型会一本正经地给出“不严谨但其实错误”的链条大模型的本质是概率生成文本不是像定理证明器那样做穷举推导。它很容易生成一段读起来很流畅、看起来逻辑完整的验证报告但中间某个关键步骤其实并不成立。所以只依赖大模型说“验完了”“没问题”是非常危险的。正确做法是让大模型当“生成器”和“定位器”真正做最终判定的一定是明确规则、自动检查工具和人工复核。5.2 机器只能验证“在给定规则下是否闭合”不能判断“公理是否合理”机器检验的前提是接受一组公理和推理规则。如果这组公理本身就有缺陷或者在把自然语言证明转换成形式化语言时产生了理解偏差那么机器验证再完整结论也可能错误。这就像代码检查工具只能检查语法和已知模式不能判断业务需求是否合理。AI 验证证明验证的是“链条是否闭合”而不是“链条是否该这么搭”。5.3 对论文审稿和代码审查的引申以后审稿人确实可以借助 agent 工具快速通读论文让 AI 找出逻辑薄弱处、标注引用缺失、检查术语是否一致。agent 也能自动跑代码测试、检查覆盖缺口、找空指针风险。它可以是一个相当称职的“第一轮审计员”。但它替代不了领域专家对创新性的判断也替代不了架构师对“这个模块是否根本不该存在”的决策。5.4 哪些场景不适合用 AI 自动验证涉及法律效力或安全审计责任时不能只拿 AI 报告当唯一依据材料高度机密或涉及个人隐私时要优先选择本地模型和本地执行环境领域知识过于前沿、公开训练数据缺乏时AI 生成的内容容易“像模像样但错误离谱”当一个任务连人类专家自己都无法清晰定义输入输出时AI 能提供的价值非常有限。更稳的路线是让模型去写候选方案让公式化工具去验证方案让人类专家去判断“我们验证的是不是本来就该被验证的东西”。6. 这次事件对普通开发者意味着什么6.1 以后你调的不只是“对话”而是一个可配置的验证助理以前我们让 AI 写代码、回答问题现在可以让 AI 读文件、跑命令、生成报告、维护 TODO在终端里长时间执行一个任务。整个工作流开始从“人问 AI 答”转向“人定义任务AI 执行任务人复核结果”。费马大定理的机器检验证明就是这条链路推到极限后的展示。6.2 可以迁移到哪些日常场景代码 review让 agent 自动检查 PR 变更点对照需求文档找逻辑遗漏长文档一致性让 agent 检查论文摘要和结论、需求规格和测试用例是否对应日志分析让 agent 先扫描错误模式再生成分类报告最后给出排查建议配置基线检查在合规环境下让 agent 对系统配置做一致性检查输出审计报告。这些场景的共同点在于重点不是让 AI 去“创作”而是让 AI 去“核验”。6.3 长期建议逐步建立自己的“验证模板库”每次做完一个验证任务不要跑完就结束。花十分钟把任务模板、输入输出格式、失败原因整理成一个文档。积累三五个之后你会发现自己形成了一套定制化的验证流程比如“检查文档一致性”“审计代码模块”“验证配置变更”都可以直接复制历史模板换上新材料再跑。这种模板库比单次验证结果更有价值。单次结果会过期模板可以长期复用和迭代。6.4 今天可以先做的事找一个手头最小的任务例如一个 200 行的代码文件让 agent 检查它是否符合项目的命名规范、是否存在明显的空指针风险、主要分支是否都有覆盖。然后把它的结论当草稿自己逐一核对。目标是先体验一遍“定义任务 → 自动执行 → 人工复核”的完整循环而不是一开始就挑战大工程。357 年悬案11 天完成机器检验证明。这个标题很容易被读成“AI 又行了”但我更愿意把它理解成另一种信号AI 正在从“能说会道”走向“能长期干活、能被追踪、能接受复核”。费马大定理的证明早在 1994 年就已经完成这次被检验的并不是定理本身而是我们能不能给 AI 一个足够有边界的任务让它像审计员一样把复杂链条中的漏洞一个个找出来。这起事件真正撬动的不只是数学界而是所有依赖“长文本、多步骤、高严谨性”的脑力劳动场景。对普通开发者来说下一步不是急着去挑战数学难题而是先把手头最小的代码、文档或配置任务交给 agent 跑一遍。等这类闭环积累得多了你就会发现真正的门槛从来不是模型够不够聪明而是我们能不能把一个模糊问题定义成一个清晰、可执行、可验证的任务。