AI辅助数学研究：从流体方程到Claude与Codex的实践与争议

我关注数学界和 AI 圈的交叉新闻有一阵子了，Buckmaster 这次把 Claude 和 Codex 用在流体方程研究上，还把与 OpenAI 的沟通记录一并公开，这事儿值得仔细拆一拆。表面上这是一次"数学家尝试用 AI 工具做研究"的个案，但往深了看，它同时碰了三条线：AI 辅助数学证明靠不靠谱、Codex 这类编码代理能不能真正承担数值验证、以及厂商使用条款和学术公开之间到底有多大的裂缝。我平时的工作里，Claude Code 负责帮我理推导思路，Codex 负责跑数值实验，所以对这个事件的各个环节都有自己的体感。这篇我不打算复述新闻，而是想从那套工具链出发，讲讲 AI 辅助数学研究的完整流程、容易踩的坑，以及那场争议里真正值得掰扯的细节。

1. 事件还原：数学家为什么在流体方程研究里用上 Claude 和 Codex

1.1 流体方程到底难在哪，AI 能帮上什么忙

流体方程这个领域，尤其是 Navier-Stokes 方程的正则性和唯一性问题，属于那种"看着简单，动起手来极其绝望"的数学问题。方程本身写出来就几行，但它的解在三维空间里可能在哪里出现奇点、能量会不会在有限时间内爆掉，这类问题从理论到数值都难啃。传统做法是两条路并行：理论数学家拿着估计和不等式一点点往前推，计算数学家搭高精度的数值格式去观测可能的爆破行为。两条路都慢，而且中间有巨大的翻译成本——理论推导需要把泛函分析里的抽象估计转成可验证的数值条件，数值模拟的结果又很难直接变成严格的数学证明。

Buckmaster 这次的做法有意思在他把 AI 工具放在了一个更靠前的位置。根据公开的材料，他让 Claude 参与符号层级的推导，让 Codex 去写数值实验代码，再把两者结果对照。这等于是在原来的两条路中间加了一个"翻译器"：Claude 负责把数学直觉整理成可执行的推导步骤，Codex 负责快速验证这些步骤在具体算例里是否成立。AI 不是直接给出了最终证明，而是把研究者从重复的代数展开和调代码里解放出来，让他能把精力放在更关键的奇点判断上。

我自己的体会是，流体方程这类问题特别适合 AI 辅助，不是因为 AI 理解流体力学，而是因为这类问题里充斥着大量"标准操作"：分部积分、插值不等式、基本的能量估计、数值格式的稳定性检查。这些步骤对专家来说不难，但非常费时间，而且容易因为笔误或者符号错误导致整页推导作废。Claude 和 Codex 这类工具能把"标准操作"的成本压到极低，这正是它们进入数学研究的最合理入口。

1.2 Buckmaster 的公开路径：从结论到工具链

公开资料里能看到一个很清晰的操作路径。Buckmaster 没有把 AI 工具当成黑箱，而是把整个工作流程都摊开了：Claude Code 负责在终端里帮他分析和改写推导片段，Codex 在另一侧负责生成、运行和调试数值实验代码，两边的中间产物他会手动检查，最后结论和 AI 的对话记录一起挂出来。这么做有几个直接好处：第一，任何人可以复现他的每一步推导；第二，AI 生成的中间结果是否可靠，读者能自己判断；第三，如果结论有问题，可以通过对话记录快速定位哪一步被 AI 带偏了。

这种"全程留痕"的做法在数学社区里其实很新。以前我们用 Mathematica、SageMath，只会保存脚本和输出，不会保存"我和软件之间怎么讨论"的过程。但和 AI 协作的时候，提示词怎么写的、模型改了几版、哪一个版本引入了错误假设，这些都是有价值的信息。Buckmaster 选择公开这些记录，相当于把 AI 辅助研究的元数据也当成了成果的一部分。

我知道不少人有疑虑：把 AI 对话记录公开，会不会泄露研究的核心思路？其实在数学领域，思路和证明过程本来就是公开发表的一部分，AI 对话记录更像是一份详细的工作笔记。真正需要保护的往往是一些还没成型的中间想法，而不是已经拿出来验证的推导。

1.3 为什么选 Claude Code 和 Codex，而不是传统数学软件

我见过很多人问：Mathematica、MATLAB 不是也能做符号推导和数值计算吗，为什么非要换 AI 工具？这里面的差别需要掰开来看。传统数学软件的核心是执行，你告诉它积分，它算积分；你告诉它解 PDE，它跑数值解。但研究者真正花时间的往往是"怎么描述问题"和"怎么分析结果"，这两步传统软件帮不上忙。

Claude Code 和 Codex 这类 AI 代理则把交互方式彻底换掉了。它们不是等你喂指令，而是可以理解一段残缺的描述，主动补全上下文。比如你在终端里说"我想测一下三维 Navier-Stokes 的某类弱解是否能出现有限时间爆破，帮我写一个最小化的谱方法数值实验"，Codex 会真的去生成一套可跑的代码，并且在你报错后续修。这种"会话式研究"的效率提升不是一星半点。

另一个维度是两者的分工不同。Claude 的强项在于大段符号推导的分析和解释，它能给出"这一步为什么要用 Hardy 不等式而不是 Poincaré"这类带有判断性的回答；Codex 的强项则在于代码生成和执行闭环，它更擅长把数学表达式落到 NumPy、PyTorch 或者专门的高阶谱方法库里。两者配合起来，刚好覆盖了从理清证明思路到验证算例的完整链条。

岔开说一句，传统数学软件并不过时，它们仍然是验证 AI 产出结果的"裁判"。我实际操作中遇到的情况是，Claude 给出的符号展开结果如果关键步骤很复杂，我会先用 SymPy 或 Mathematica 复核一遍关键项，再让 Codex 去跑数值。AI 提高的是效率，不是可信度。

2. AI 辅助科研的实操链路：从环境搭建到第一份结果

2.1 快速搭好 Claude Code 环境

如果你想把 Buckmaster 那套流程复制到自己项目里，第一步是本地把 Claude Code 跑起来。这个工具的核心是一个终端面的 CLI，它把 Claude 的对话能力直接放到了命令行里。我当时的操作流程是先用 Node.js 的包管理器安装官方 CLI，然后在项目目录下启动，它会读取你在 Anthropic 控制台创建的 API Key 或者订阅账号。安装命令各家系统差不多，关键在于确认 Node.js 版本不要太旧，否则可能会出现模块加载失败。

# 以官方 npm 包为例，具体包名以官方文档为准 npm install -g @anthropic-ai/claude-code # 进入工作目录 cd fluid-experiment # 初始化对话 claude

第一次启动会让你完成认证，常见的路径是粘贴 API Key 或者走 OAuth。这一步有耐心就行，别急着跳过。我之前踩过坑，为了省事直接复制了一个分享出来的 Key，结果用了几分钟就因为额度限制被踢下线，对话记录也丢了。研究场景里，API Key 必须自己申请、自己管理，这既是安全要求，也是对话可持续性的保障。

启动之后我习惯先让它读一下项目结构，再把研究目标写在README或一个GOAL.md里。这样 Claude 能通过工作区上下文快速理解你在做什么，而不是每次都要把方程式重新描述一遍。对于数学研究来说，把问题背景稳定在同一份上下文里非常重要，否则模型很容易在对话到一半的时候"忘记"你已经定义过的泛函空间。

2.2 Codex 在数值验证里的正确打开方式

Codex 给我的感觉更像一个"能自己干活的研究助理"。你给它一个任务，它会在工作区里创建脚本、运行、看报错、再修。如果你是做流体方程数值实验的，最常见的用法就是让它搭一个谱方法或者有限差分求解器，然后跑一组参数扫描。

我用 Codex 做了一个简化版的 Burgers 方程粘性项验证实验，算是热身。问题很简单：对u_t + u u_x = nu u_xx做数值解，看不同粘性系数下的能量耗散趋势是否符合理论预期。我给 Codex 的任务描述大概是"写一个周期域上的谱方法求解器，时间推进用 RK4，输出能量随时间的变化，并且和理论衰减率做对比"。

import numpy as np from scipy.integrate import solve_ivp N = 128 L = 2 * np.pi dx = L / N x = np.linspace(0, L, N, endpoint=False) k = np.fft.fftfreq(N, d=dx) * 2 * np.pi nu = 0.01 def rhs(t, u_hat): u = np.fft.irfft(u_hat) u_x = np.fft.irfft(1j * k * u_hat) nonlinear = -np.fft.rfft(u * u_x) viscous = -nu * k**2 * u_hat return nonlinear + viscous u0 = np.fft.rfft(np.sin(x) + 0.2 * np.sin(2 * x)) sol = solve_ivp(rhs, [0, 10], u0, t_eval=np.linspace(0, 10, 100), method='RK45')

这段代码其实并不复杂，核心价值在于 Codex 能根据我的描述快速把 FFT 配点、去混叠选项、时间步判断这些细节补全，而不需要我一行行去翻文档。跑完之后我还让它把能量曲线和 -2 次衰减的理论斜率放在一张图上，几秒钟就能得到可视化的对照。

这里有一个经验：用 Codex 做数值验证时，不要让它一次生成整个大型模拟程序，而是先写一个最小可行版本，跑通之后逐步加功能。有一次我让它直接写三维 N-S 谱方法求解器加并行化，它生成的代码结构是完整的，但某个压力投影步的边界条件处理有误，调了半个下午才定位到。后来我改成先写二维版本，验证稳定后再扩展到三维，效率反而高很多。

2.3 让两个 AI 工具协同：符号推导 + 数值验证

单独用任何一个工具都没那么惊艳，真正有威力的是让它们协同。我的工作流大概是这样的：先在 Claude Code 里把要验证的数学命题拆成若干子步骤，让它把每一步的逻辑链列清楚。比如问题是一个非线性项的能量估计，我会让它从头推导|∫ u u u_x dx|的上界，它会写出分部积分和插值不等式的中间过程。

拿到这段符号推导结果后，我会挑几个关键不等式让 Codex 做数值验证。最简单的方式是把符号推导里的某个估计改写成数值测试：生成随机初值，跑求解器，然后在时间序列上检查每一步是否满足对应的能量不等式。如果数值结果显示在某个时刻不等式崩掉了，那就说明推导里大概率遗漏了一个边界项，或者题设里的正则性条件需要调整。

这种"符号推导 + 数值验证"的组合能够解决一个很尴尬的问题：AI 单次生成的内容总会有一两个隐藏错误，但如果让它自己扮演两种角色并且互相校验，错误就更容易暴露。在我的实践中，这种双工具交叉验证能把 AI 辅助推导的"直接可信度"从六成拉到九成以上。剩下的误差，需要靠实际书写证明来兜底。

2.4 科研场景下的提示词写法

很多人在科研里觉得 AI 不靠谱，其实是提示词写得太抽象。面对数学问题时，有一个有效的提示词结构：明确输入、明确变换、明确验收标准。

比如你让 Claude 处理一个积分估计，不要只说"帮我化简这个式子"，而是要说："对如下积分，我希望通过两次分部积分将其转化为一个可用 Hölder 不等式估计的形式，输出时保留所有边界项，并标注每一步使用了什么性质。"这个提示词里包含了目标、方法、输出格式和验收标准，模型很少会跑偏。

我一般会在项目里建一个prompts.md，把每个子问题的提示词和对应的 AI 回复摘要保存起来。下次遇到类似问题可以直接改边界条件复用，而不是从零开始描述。还要注意，在数学场景里，让 AI"解释为什么"比"直接给答案"重要得多。因为你需要的不是那个式子，而是式子背后的逻辑能不能连成证明。如果 AI 给了一个结论但解释含糊，你就该警惕，这往往是幻觉的开始。

3. 公开争议：AI 生成结果能不能直接发布，OpenAI 到底说了什么

3.1 争议的核心不是模型能力，而是使用条款

Buckmaster 把与 OpenAI 的沟通记录公开之后，圈里讨论最热的并不是 Codex 算得准不准，而是一个更现实的问题：AI 生成的内容被用在论文里，厂商的使用条款到底怎么算？这个问题在数学界尤其尖锐，因为数学成果的输出形态本来就是"一段文字 + 一串式子"，而这段文字恰好和 AI 回复的结构高度重叠。

根据公开的沟通信息，双方的分歧点主要落在服务条款关于"输出内容的使用"和"模型行为透明度"的表述上。研究者的立场是：我用自己的专业判断验证了每一步结果，AI 只是工具，所以最终成果应该由使用者全权负责并自由发布。而厂商的自动化回复则倾向于提醒用户查看条款中关于输出所有权、商业用途和第三方分发的限制条款。两边其实没有直接对立，但放在学术发布场景里，任何一行"限制"都会让期刊审稿人和机构法务部门紧张。

我个人的理解是，这类争议的真正根源是条款滞后于实践。厂商制定条款时主要考虑的是防止用户拿模型输出去做违规的事情，比如批量生成垃圾内容、绕过安全机制，并没有专门为"数学家在论文里引用 AI 推导过程"设计清晰的授权路径。结果就是一线研究者必须靠猜。

3.2 从沟通记录看学术透明度的两难

公开沟通记录的另一个价值，是把"学术透明度"这个词从口号变成了具体操作问题。Buckmaster 的做法是：不仅公开结果，还把 AI 的参与过程全部公开。这种透明当然值得鼓励，但它也带来一个尴尬：如果所有的推导都要像"实验记录"一样标注哪些步骤用了什么 AI 提示词、模型输出了什么版本，论文会变得极其臃肿。

我在实际写作时会采取一个折中方案：正文里只保留经过我完全验证的推导，附录里列出 AI 工具的版本、主要提示词和关键中间输出，若有需要再提供完整对话记录的归档链接。这样既给了同行复核的基础，又不至于让可读性崩溃。

另外，学术透明还有一个反向问题：即便研究者公开了完整的 AI 交互记录，读者也难以判断哪些地方研究者被 AI 带偏过。因为对话记录往往会经过筛选。这也是为什么我认为 Buckmaster 把原始记录直接公开的姿态很有意义——哪怕只是部分公开，也比声称"未使用 AI"要可信得多。

3.3 科研人员和 AI 厂商打交道时的几个注意点

经过这些事，我对科研人员使用商业 AI 服务有几点很实际的建议。首先，在使用任何 AI 工具前，保存好当天的服务条款版本，最好截图或者存 PDF。条款是会变的，万一未来出现争议，你至少能证明"当时的规定是什么"。

其次，申请 API 时用机构邮箱，并且把项目用途写得具体一点。不要只写"研究用"，最好写"用于流体方程数值实验和符号推导验证"。这样如果触发了平台的自动审核，你会有更充分的说明材料。

第三，如果涉及大规模抓取数据、跑长时任务，或者要做商业授权，建议提前通过官方渠道提交商务咨询，不要直接在对话里要求客服放行。客服没有权限解释条款，大概率只会给你返回一段模板。

最后，和任何厂商沟通时都保持书面留痕。Buckmaster 选择公开沟通记录，本身也说明书面记录在这里面有多重要。虽然和 AI 厂商的沟通通常不涉及法律纠纷，但一封正式邮件有时能省掉好几天来来回回的解释。

4. 踩坑实录：我用 Claude/Codex 做数学验证时遇到的问题

4.1 提示词导致的幻觉结果

我在实际使用 AI 辅助数学研究时，遇到最多的问题就是"模型一本正经地胡说八道"。有一个特别典型的案例：我让 Claude 对一个涉及分数阶 Sobolev 空间的插值不等式做推导，它给出了一个看起来很完整的证明，还引用了某篇论文的引理。仔细检查后发现，那个引理的确存在，但条件是对整数阶 Sobolev 空间成立的，Claude 在推导过程中悄悄放宽了条件，导致最后的估计差了半阶。

解决这个问题没有银弹，只能靠两条腿走路：一是提示词里强制要求"每一步必须标明使用定理的完整条件"，二是用另一个工具或者自己的手算复核关键节点。我一般会让 Codex 写一个数值实验来验证最终估计的临界指标，数值上如果对不上，推导就有问题。AI 幻觉在纯符号推导里特别隐蔽，因为形式上每一步都合理，但隐藏假设被偷换了。

4.2 代码生成对了但数学公式写错

有一次让 Codex 生成一个关于涡量输运方程的数值求解器，脚本本身没任何问题，不报错、速度也快，但我感觉结果不对。检查代码逻辑时发现，某一项散度的离散格式里系数写成了 1/2，而正确公式应该是 1/3。这个错误不影响程序运行，甚至不会让数值立即发散，只会让结果在长时间演化后出现微小的系统性偏差。

这个案例给我的教训是：使用 AI 生成的科研代码，必须对关键公式逐项做"数学复位"。最好的办法是拿一个已知解析解做标准测试，比如让粘性项单独作用，比较衰减率是否和理论值一致；或者从某个已知稳态初值出发，看数值解能不能保持稳态。不能因为代码能跑、图画得漂亮就默认它是对的。

4.3 安装和版本兼容问题

我在配置环境时也遇到过不少坑，尤其是 npm 全局安装后命令行找不到命令的情况，多半是 Node.js 的全局 bin 目录没有加入 PATH。另外一个常见问题是claude和codex不同版本对系统环境的要求不一样，高版本可能会要求新的 glibc，低版本又会有安全补丁缺失。我现在的习惯是固定主要版本，不频繁升级，同时在项目目录里用package.json或者虚拟环境把 CLI 工具锁定下来。

如果你的工作流同时依赖多个 AI 工具，要注意它们的配置目录可能会互相影响，尤其是共享同一个认证目录时的密钥读取冲突。我碰到过一次 Codex 读取不到 API Key 的情况，排查了很久才发现环境变量名被之前的脚本覆盖了。所以最好在切换项目时用.env文件显式声明每个工具需要的密钥变量，而不是全局设置。

4.4 把 AI 产出变成可复核的科研资产

我在这个项目上最深的体验是：AI 工具可以帮你算得快，但只有你自己才能决定哪些算出来的东西值得写进论文。所以在日常工作中，我会把「和 AI 的交互记录」视作和实验日志同等级的研究资产。具体做法是定期把对话导出成 Markdown 或 JSON，放在项目仓库的archive/目录里，并在提交论文初稿时同步打一个 tag。这样如果审稿人问起某个推导步骤是怎么来的，我可以在十分钟内找到完整的上下文。

同时，我会给每个 AI 生成的关键结果打上一个"验证级别"标签。比如：未验证、数值验证、符号验证、人工完全验证。在写作时只引用后两类的成果，前两类只作为内部参考。这不是不信任 AI，而是制度化的风险管理。数学研究的容错率很低，一个错误引理可能浪费别人好几年时间，所以在最终输出端把好关是必要成本。

如果你也想在自己的研究里引入 Claude 和 Codex 这套流程，我的建议是从一个小问题开始，不要第一次就让它们处理完整的定理证明。先让 Claude 分析一个你已经知道答案的引理，让 Codex 复现一个教科书上的数值算例，感受一下它们的行为方式。等摸清了各自容易在哪里犯错，再逐步扩大应用范围。我自己的体会是，AI 辅助科研最大的价值不是替代思考，而是把那些重复劳动压缩到几乎为零，让你有更多精力去质疑那些看似理所当然的假设。这一点在 Buckmaster 这个事件里体现得尤其明显——他公开的并不是一个 AI 给出的答案，而是一套人和工具相互校验的工作方式。