“刚刚Claude 挑战黎曼猜想失败数学家却看懵了”这个话题最近在技术社区里的热度不低。第一次看到这类表述时我的第一反应是这大概率是标题党。一个连人类顶尖数学家都悬而未决超过一百年的猜想一个本质上基于概率生成文本的模型跑去证明出来这本身就不太符合常识。但把这句话拆开细看会发现真正值得讨论的可能不是“失败”这个结果而是“失败的方式”——到底是什么样的输出会让有数学背景的人短暂地愣一下如果把这件事当成一次关于 AI 数学能力的观察样本而不是一条真假难辨的新闻头条那它会比“又翻车了”或者“AI 要取代数学家了”更有信息量。这也是这篇文章真正想聊的问题像 Claude 这样的语言模型面对黎曼猜想这种高阶数学难题时它的能力边界在哪里我们又应该如何设计实验去验证它在数学推理上的真实水平而不是被一段流畅的证明文本带偏1. 先拆开这个判断题Claude 挑战黎曼猜想输在哪里1.1 黎曼猜想不是靠“语言冲击”就能撞开的门先说一个技术常识。黎曼猜想断言的是黎曼 ζ 函数的所有非平凡零点的实部都等于 1/2。它之所以难不是因为缺少一个漂亮的公式也不是因为缺一个灵感而是因为它横跨了解析数论、复分析、代数几何等多个领域整个证明必须是由有限步骤构成、每一环都能被严格验证的逻辑链条。而语言模型生成文本的方式本质上是在给定上下文之后预测下一个 Token 的概率分布。它没有“执行无限步演绎”的能力也不具备“每一步都必须逻辑自洽”的约束。你给它一段数学推导它有可能生成一个看起来非常合理的证明框架但框架里的关键跳跃可能只是一个基于语料统计的合理补全而不是真正可验证的数学事实。所以Claude 挑战黎曼猜想失败不是意外是预期内结果。真正需要注意的是另一件事它的失败未必是“完全跑题”的失败而可能是一种“看起来像那么回事”的失败。这种失败恰恰比输出一堆乱码更值得警惕。1.2 数学家为什么会被“看懵”似是而非比明显错误更有信息量假如你在聊天框里输入“请尝试证明黎曼猜想”Claude 通常会给出一个结构比较完整的回答引入 ζ 函数、讨论解析延拓、提到临界带、给出零点分布与素数定理之间的关系甚至可能写出一段带编号的推导过程。如果一个人不具备足够的数论背景只看自然语言流畅度很容易会觉得“好像有点道理”。这里就出现了“数学家看懵”的可能。不是说数学家觉得它证明了而是震惊于模型能把数学论文的“表面纹理”模仿到这个程度。它懂一些定义记得一些经典结论能用符号和函数方程做几层推演甚至能指出某条路线的方向。但一旦你沿着它给出的推导链条逐行验算就会发现某个关键的“由上式可得”其实是伪逻辑某个积分估计并不成立某个函数方程的使用条件没有满足。这种“似是而非”比明显错误的信息量更大。它说明模型已经从语料里吸收了大量的数学表达模式但它没有能力判断这些模式在逻辑上是否真正连通。对于普通人来说这个现象提醒我们阅读 AI 生成的数学证明时绝不能用文本的流畅度来替代证明的严格性。对于研究者来说这反而是一种值得利用的“随机探索工具”如果带着验证框架去使用它。2. 从头条回到工程现场要真去试先得装好 Claude Code2.1 为什么实验前的第一道坎是环境很多人在热点讨论里最想问的问题其实是我怎么亲自去试试网页聊天窗口当然可以用但对于想做一些可复现实验的开发者来说更顺手的路径是把 Claude 接入本地命令行和编辑器。于是安装 Claude Code 成了第一道坎。从最近各种安装报错热搜就能看到不少人在这一步就被卡住了。有人遇到“无法将‘claude’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”有人碰到“错误claude原生二进制未安装”还有人遇到“您的组织已禁用 claude subscription access for claude code”这类账号策略问题。这些问题本质上都不是模型能力问题而是工程环境问题。2.2 最小可用安装流程先把安装路径捋一遍。大多数情况下Claude Code 是作为一个 Node.js 命令行工具发布的官方文档里会给出安装命令。下面是一个常见的安装方式具体命令以你当前看到的官方文档为准npm install -g anthropic-ai/claude-code安装完成后先做一次最低限度的验证claude --version如果这一步能正常输出版本号说明 CLI 已经被系统找到了。接下来在项目目录里直接运行claude就能进入交互式会话。这是我个人建议的最小可用流程先确认安装成功再进入具体需求不要在第一步还没验证通过时就开始问复杂数学问题。2.3 常见安装错误与排查链路遇到问题不要急着重新安装。先按现象分层排查输入、环境、权限、版本、账号。报错或现象大概率原因排查方向claude不是内部或外部命令也不是可运行的程序npm 全局安装目录不在系统 PATH 中或安装未完成检查 Node.js 和 npm 是否安装执行npm ls -g重启终端确认 PATH 配置error: claude native binary not installed.安装过程中的 postinstall 脚本没有成功执行检查网络、安装权限重新执行安装命令留意安装日志是否被安全软件拦截claude在 Windows 上出现 cmdlet 识别失败PowerShell 没有正确继承 PATH或执行策略限制用Get-Command claude检查尝试重新打开终端不要使用可疑的“绕过”方式unfortunately, claude is not available to new users right now.平台侧账号可用性限制查看官方支持页面确认自己的账号状态不要轻信第三方“代开”服务your organization has disabled claude subscription access for claude code企业订阅策略关闭了该功能与团队管理员确认策略而不是自行修改配置这个排查链路的顺序很重要先看现象本身再看输入路径和环境变量接着看权限和版本最后看账号侧限制。很多人卡住之后第一反应是重装但重装只能解决部分环境问题解决不了 PATH 配置错误和账号策略问题。2.4 在 VSCode 里使用时的注意点把 Claude Code 接进编辑器有两条常用路径一是在项目终端里直接运行claude二是在扩展市场里安装官方或社区提供的编辑器扩展。实际使用中最容易被忽视的问题是终端环境差异。VSCode 内部终端默认使用的 shell 和你在系统外部使用的 shell 不一定一致可能导致外部终端能运行claude但 VSCode 里提示找不到命令。通常的解法是重启 VSCode让编辑器重新加载环境变量或者在设置里确认默认终端类型。还有一个更关键的原则遇到任何登录、订阅或验证相关问题都应该走官方文档和正常账号流程而不是找绕过验证的方式。不少账号问题与地区、订阅套餐、企业策略有关绕过方案不仅不稳定还可能触发平台的风控标记最终影响的还是自己的使用体验。3. 用代码而不是空想去验证 Claude 的数学能力3.1 把“证明”降级成“实验”装好工具之后很多人会犯的一个错误是上来就问一个超大问题。比如“请尝试证明黎曼猜想”。这就像刚会开车就要上赛道一样既检验不出真实水平也很容易翻车。更合理的做法是给模型布置“可验证的小实验”。这里的逻辑很简单语言的流畅度很容易骗人但可运行代码和数值结果很难一直骗人。你让模型写一段数字计算的代码然后自己在本地跑一遍它的推理能力立刻就会现出原形。我建议一个“三段式实验框架”拆命题把一个大问题拆成几个可以利用计算工具进行验证的小步骤做实验让模型针对其中一个小步骤输出代码、数值结果或具体的符号推导再验证用你自己准备好的脚本、符号计算工具或论文资料去核查模型的每一步输出。这个框架的价值不在于让模型输出正确答案而在于把模型的输出拉到可以被验证的平面上。3.2 一个最小可运行实验先验证前几个零点的位置举一个非常小的例子。黎曼猜想关心的是非平凡零点的实部但它不是靠验证有限个零点成立的。作为实验我们可以先让 Claude 写一段代码计算 ζ 函数前几个非平凡零点的数值位置然后观察结果是否落在临界线上。一种常见做法是使用 Python 的mpmath库from mpmath import mp, zetazero mp.dps 15 for n in range(1, 6): z zetazero(n) print(n, z)在标准数值精度下这段代码会输出前五个非平凡零点在复平面上的位置。你既可以直接运行也可以把它拿给 Claude 解释。更好的做法是让 Claude 自己写代码而不是替模型写代码。一个更接近真实使用的提示词可以是这样请先用 Python mpmath 计算黎曼 zeta 函数前 5 个非平凡零点的数值位置并输出到小数点后 8 位。 然后解释 1. 这些数值是否满足“实部等于 1/2”这一局部特征 2. 数值验证和数学证明之间的区别是什么 3. 如果只依赖前 5 个零点为什么不能得出黎曼猜想成立的结论。这种提问方式的价值在于它把模型从“生成证明”拉回到“做实验并解释实验边界”的位置。如果模型能说出“前 5 个零点不能证明猜想”说明它对验证边界有一定认识如果它直接宣称这些数值已经证明猜想那你很容易识别出它的回答不可靠。3.3 判断模型输出质量的三个信号在上述实验流程中我一般会看三个信号是否主动区分“计算验证”和“数学证明”。如果模型把数值实验说成是证明它的数学判断能力就不可信。是否承认工具边界。一个可靠的模型往往会提醒你数值精度有限、零点的数目是有限的、严格证明需要更多步骤。如果它全程保持绝对自信反而要警惕。给出的代码是否能直接运行。代码中是否存在虚构的参数、不存在的库函数、忽略边界条件等问题。这三个信号比“它最终输出的结论对不对”更本质。因为结论对错可能是偶然碰上的而这三个信号反映的是模型是否真的理解数学方法论的底线。4. 数学模型实验的边界哪些能做哪些不要期待4.1 模型真正擅长什么在使用 Claude 辅助数学实验时我会先承认它的强项。它比较擅长把宽泛的问题拆成可讨论的子问题能够把已知证明的大致脉络整理成便于检索的要点也可以生成数值计算、符号推演的代码框架。它还能在给定一个方向后快速列出几种可能的推进路径。这些都是有用的能力。数学研究的很多时间其实花在“梳理已知结论”和“设计验证实验”上。模型如果能把这两件事做得更顺手就已经能显著提升前期探索效率。4.2 模型不擅长什么但它确实不擅长长程严格推理。这里的“长程”指的是超过若干步、需要依赖大量前序结论、且中间每一步都不可跳跃的逻辑链条。语言模型在短距离内可以保持局部一致性但一旦链条拉长状态之间的依赖关系就容易丢失。它也不擅长判断“哪一步是不能绕开的难点”。人类数学家面对一个证明时通常会有直觉这个位置必须引入某个新工具那个位置可能需要构造反例。模型没有这种对问题结构的深层判断它更多是在重组已有文本模式。你要让它用自己的判断告诉你“这个方向基本行不通”它往往会给你一个更乐观的、看似可能但模糊的答案。另一个边界是模型很难真正产出从未出现在语料中的全新数学结构。它可能会把两个不同领域的工具拼在一起拼出一个对研究者有启发的组合但那个组合本身并不等于新定理。它更像是“概念的拼接机”而不是“概念的创造者”。4.3 落地工作流模型给方向人去验证基于这些边界我在实际使用中会坚持这样一个循环当有一个数学实验思路时用自然语言让 Claude 把它拆成可验证的小问题让 Claude 输出代码、计算方案或文献关键词用更可靠的工具去复核数值计算、符号计算、形式化证明助手或者已有的论文与教材只保留通过验证的结论记录下失败原因把失败原因带回下一轮 Prompt让模型避免同样的错误。这里最核心的一句话是验证权必须留在人手里。这不仅适用于高阶数学问题也适用于任何用 AI 辅助编程或研究的场景。模型负责扩大候选范围人负责缩小可信范围。如果不这样做很容易进入一个“越自信越危险”的循环。5. 长期视角AI 不是来替人类证明猜想的而是来改变探索方式的5.1 从“结果论”转向“过程协作”如果只盯着“AI 是否证明了黎曼猜想”这个结果那这类工具短期内大概率会让你失望。但如果我们换一个视角把它当作一个参与研究过程的协作者情况就完全不同了。数学研究的成本通常分布在两个环节产生候选思想和验证候选思想。过去产生候选思想主要靠数学家个人的积累和灵感验证则靠推导、计算和交流。现在大语言模型让“产生候选思想”这件事的速度变得非常快甚至可以做到“一次提出几十个不一样的方向”。但验证环节依然需要人来完成。这意味着什么意味着 AI 真正改变的不是结论的生产速度而是试错过程的上限。过去你可能一周只能试三个方向现在可以一天试完三十个方向的初步线索再挑出最值得深入的三个。这种改变不会让“证明”这件事显得更廉价反而会让验证环节的地位更高。5.2 给数学爱好者和开发者的最小行动建议如果你也想亲自体验这类实验下面这几条是我自己会带去实践的建议先装好 Claude Code第一件事不是问大问题而是跑一个最小的claude --version和一次简单会话实验目标要设成“可复现、可验证”不要设成“证明一个猜想”尽量让模型输出代码、计算步骤、数值结果而不是让模型直接输出长篇大论准备一个自己的验证清单例如代码能否运行、数值是否合理、关键推导条件是否满足、是否和已有文献一致不要尝试绕过任何平台的账号验证、订阅限制或企业策略遇到不可用状态就查官方文档或者等官方修复。这些建议不复杂但很多人在热点驱动下往往会跳过它们直接去问“你能证明黎曼猜想吗”然后因为一个糟糕的答案断言“AI 数学能力为零”。这样的判断既不准确也不公平。回到开头的标题。如果 Claude 挑战黎曼猜想失败数学家却看懵了那真正的收获可能并不关于答案而关于“相似性”的迷惑性。我们不需要替它辩解说“失败也很了不起”也不必急着把这次尝试当作笑料。更值得做的是去认识一个语言模型在数学推理上的真实能力曲线它能做局部推导能生成可实验的代码能整理资料但它缺乏对无限推导链的严格掌控。在接下来的很长一段时间里人类和 AI 在数学领域的配合方式大概都会是“模型提供高密度假设人类守住验证底线”。这并不浪漫但它足够真实也足够有效。所以下一次再看到“AI 挑战某个数学难题失败”这类消息时你可以顺手把它拆成一个工程问题和验证问题而不是一次博眼球的输赢判断。如果能做到这一点你其实已经比大多数人更接近这类工具的正确使用方式了。