企业官网建设流程全解析

最近有个新闻值得停下来聊几句：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 可复用的四阶段任务拆解

从这类复杂验证任务的通用工作流来看，几乎必然包含下面四个阶段。这个模板不仅适用于数学证明，你把它拿去审代码、审文档、检查需求一致性，也是一样成立的。

这四步里，最容易出错的是第二步：骨架拆解。如果子任务切割得太碎，会因为缺少上下文导致验证失真；如果切得太粗，又会因为单个子任务太大而无法有效验证。这里的平衡点，要结合具体任务来微调。

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 上下文窗口不够用，长任务怎么“不失忆”

费马大定理的证明材料，如果全部塞进上下文窗口，绝大多数模型都装不下。所以长任务处理的核心技巧是：不要试图一次性把材料都灌进去。

我一般会采用“先给目录，再按需展开章节”的方式：

1. 先让 agent 扫描项目目录，生成文件清单和章节结构；
2. 根据结构拆分成多个子任务，每个子任务只加载需要的段落；
3. 子任务验证结束后，把结果写入独立文件；
4. 下一个子任务读取“已验证结论”的摘要，而不是重新读原文。

这样做还有一个额外好处：节省 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、函数、脚本文件或可运行程序的名称这类报错，先不要怀疑“安装失败了”。按这个顺序排查：

1. 确认 Node 和 npm 是否正常：node -v、npm -v；
2. 找到 npm 全局目录：npm root -g；
3. 确认全局 bin 目录是否已加入 PATH；
4. 安装完成后是否重新打开了终端；
5. 最后再试claude --version。

这几步能解决绝大多数安装后无法识别命令的问题。

4.2 VSCode 里的集成与模型配置

在 VSCode 里打开终端，运行claude，再指定一个项目目录，它就会扫目录、生成计划、开始执行任务。对写代码和验证文档来说，这种工作方式非常自然。

如果你用的是第三方兼容接口或本地模型，通常需要配置 base URL 和环境变量。常见写法是：

ANTHROPIC_BASE_URL=http://localhost:11434 ANTHROPIC_MODEL=your-local-model

也可以用 cc switch 这类工具在多个模型供应商之间切换。需要理解的是：cc switch 切换的是“底层模型提供方”，agent 主程序还是同一个。切换模型只能改变推理能力，不会自动解决任务拆解、输出格式、状态管理等工程问题。

4.3 最小验证流程：不要一上来就挑战费马大定理

我强烈建议第一个任务选小一点，比如让你手头的 agent 去验证一个代码文件里的函数是否符合文档描述。流程如下：

1. 写清楚任务范围、输入文件、输出文件；
2. 让 agent 先读取目录，生成 TODO 列表；
3. 只让它验证一个函数或一个模块；
4. 检查生成的验证报告和日志；
5. 再尝试扩展到两个、三个相关模块。

这个“先跑通最小任务，再扩大范围”的方式，看起来保守，其实最高效。因为如果你连最小任务的输入输出边界都没定义清楚，扩大范围只会得到更多不可靠的输出。

4.4 新手配置与进阶配置建议

4.5 常见问题排查链路

任务崩了，先别怀疑“AI 变笨了”。按顺序排查：

1. 现象：没有输出 / 报错 / 结果不一致；
2. 输入：文件是否可读、编码是否为 UTF-8、路径是否正确、文档结构是否匹配；
3. 环境：依赖是否安装、Node 版本是否过低、接口地址是否能连通、本地模型服务是否启动；
4. 参数：上下文是否被截断、子任务是否过大、超时时间是否太短；
5. 工具边界：检查是否触发了工具的版本限制或文件大小限制。

注意：不要一上来就怀疑“模型不行了”，先看任务描述和输入文件是否干净。大量所谓“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 跑一遍。等这类闭环积累得多了，你就会发现：真正的门槛从来不是模型够不够聪明，而是我们能不能把一个模糊问题，定义成一个清晰、可执行、可验证的任务。