我关注数学界和 AI 圈的交叉新闻有一阵子了Buckmaster 这次把 Claude 和 Codex 用在流体方程研究上还把与 OpenAI 的沟通记录一并公开这事儿值得仔细拆一拆。表面上这是一次数学家尝试用 AI 工具做研究的个案但往深了看它同时碰了三条线AI 辅助数学证明靠不靠谱、Codex 这类编码代理能不能真正承担数值验证、以及厂商使用条款和学术公开之间到底有多大的裂缝。我平时的工作里Claude Code 负责帮我理推导思路Codex 负责跑数值实验所以对这个事件的各个环节都有自己的体感。这篇我不打算复述新闻而是想从那套工具链出发讲讲 AI 辅助数学研究的完整流程、容易踩的坑以及那场争议里真正值得掰扯的细节。1. 事件还原数学家为什么在流体方程研究里用上 Claude 和 Codex1.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 或者专门的高阶谱方法库里。两者配合起来刚好覆盖了从理清证明思路到验证算例的完整链条。工具擅长场景典型用法不擅长的点Claude Code推导分析、定理结构的拆解、代数展开让模型解释某一步估计的由来重写推导片段长时间大规模数值计算Codex代码生成、数值实验、脚本调试让模型写 PDE 求解器、批处理实验对纯数学概念进行原创性证明Mathematica严格符号积分、代数化简验证分部积分后每一项是否一致自然语言交流、自主调试MATLAB数值线性代数、快速原型流场可视化、矩阵计算复杂证明策略的建议SageMath开源符号与数值结合代数数论、有限元建模会话式的推导交互岔开说一句传统数学软件并不过时它们仍然是验证 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, endpointFalse) k np.fft.fftfreq(N, ddx) * 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_evalnp.linspace(0, 10, 100), methodRK45)这段代码其实并不复杂核心价值在于 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文件显式声明每个工具需要的密钥变量而不是全局设置。报错现象常见原因我习惯的排查顺序命令找不到全局 bin 不在 PATH 或安装失败检查 Node 版本重新安装查看安装日志API Key 认证失败环境变量被覆盖或 Key 失效检查.env确认 Key 在控制台是否可用模型返回空结果上下文过长或输入格式不符合要求清空会话把任务拆小重新描述数值实验结果和理论不符公式离散错误或者初值/边界条件设错先跑标准算例再检查每一项离散格式4.4 把 AI 产出变成可复核的科研资产我在这个项目上最深的体验是AI 工具可以帮你算得快但只有你自己才能决定哪些算出来的东西值得写进论文。所以在日常工作中我会把「和 AI 的交互记录」视作和实验日志同等级的研究资产。具体做法是定期把对话导出成 Markdown 或 JSON放在项目仓库的archive/目录里并在提交论文初稿时同步打一个 tag。这样如果审稿人问起某个推导步骤是怎么来的我可以在十分钟内找到完整的上下文。同时我会给每个 AI 生成的关键结果打上一个验证级别标签。比如未验证、数值验证、符号验证、人工完全验证。在写作时只引用后两类的成果前两类只作为内部参考。这不是不信任 AI而是制度化的风险管理。数学研究的容错率很低一个错误引理可能浪费别人好几年时间所以在最终输出端把好关是必要成本。如果你也想在自己的研究里引入 Claude 和 Codex 这套流程我的建议是从一个小问题开始不要第一次就让它们处理完整的定理证明。先让 Claude 分析一个你已经知道答案的引理让 Codex 复现一个教科书上的数值算例感受一下它们的行为方式。等摸清了各自容易在哪里犯错再逐步扩大应用范围。我自己的体会是AI 辅助科研最大的价值不是替代思考而是把那些重复劳动压缩到几乎为零让你有更多精力去质疑那些看似理所当然的假设。这一点在 Buckmaster 这个事件里体现得尤其明显——他公开的并不是一个 AI 给出的答案而是一套人和工具相互校验的工作方式。
我关注数学界和 AI 圈的交叉新闻有一阵子了Buckmaster 这次把 Claude 和 Codex 用在流体方程研究上还把与 OpenAI 的沟通记录一并公开这事儿值得仔细拆一拆。表面上这是一次数学家尝试用 AI 工具做研究的个案但往深了看它同时碰了三条线AI 辅助数学证明靠不靠谱、Codex 这类编码代理能不能真正承担数值验证、以及厂商使用条款和学术公开之间到底有多大的裂缝。我平时的工作里Claude Code 负责帮我理推导思路Codex 负责跑数值实验所以对这个事件的各个环节都有自己的体感。这篇我不打算复述新闻而是想从那套工具链出发讲讲 AI 辅助数学研究的完整流程、容易踩的坑以及那场争议里真正值得掰扯的细节。1. 事件还原数学家为什么在流体方程研究里用上 Claude 和 Codex1.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 或者专门的高阶谱方法库里。两者配合起来刚好覆盖了从理清证明思路到验证算例的完整链条。工具擅长场景典型用法不擅长的点Claude Code推导分析、定理结构的拆解、代数展开让模型解释某一步估计的由来重写推导片段长时间大规模数值计算Codex代码生成、数值实验、脚本调试让模型写 PDE 求解器、批处理实验对纯数学概念进行原创性证明Mathematica严格符号积分、代数化简验证分部积分后每一项是否一致自然语言交流、自主调试MATLAB数值线性代数、快速原型流场可视化、矩阵计算复杂证明策略的建议SageMath开源符号与数值结合代数数论、有限元建模会话式的推导交互岔开说一句传统数学软件并不过时它们仍然是验证 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, endpointFalse) k np.fft.fftfreq(N, ddx) * 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_evalnp.linspace(0, 10, 100), methodRK45)这段代码其实并不复杂核心价值在于 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文件显式声明每个工具需要的密钥变量而不是全局设置。报错现象常见原因我习惯的排查顺序命令找不到全局 bin 不在 PATH 或安装失败检查 Node 版本重新安装查看安装日志API Key 认证失败环境变量被覆盖或 Key 失效检查.env确认 Key 在控制台是否可用模型返回空结果上下文过长或输入格式不符合要求清空会话把任务拆小重新描述数值实验结果和理论不符公式离散错误或者初值/边界条件设错先跑标准算例再检查每一项离散格式4.4 把 AI 产出变成可复核的科研资产我在这个项目上最深的体验是AI 工具可以帮你算得快但只有你自己才能决定哪些算出来的东西值得写进论文。所以在日常工作中我会把「和 AI 的交互记录」视作和实验日志同等级的研究资产。具体做法是定期把对话导出成 Markdown 或 JSON放在项目仓库的archive/目录里并在提交论文初稿时同步打一个 tag。这样如果审稿人问起某个推导步骤是怎么来的我可以在十分钟内找到完整的上下文。同时我会给每个 AI 生成的关键结果打上一个验证级别标签。比如未验证、数值验证、符号验证、人工完全验证。在写作时只引用后两类的成果前两类只作为内部参考。这不是不信任 AI而是制度化的风险管理。数学研究的容错率很低一个错误引理可能浪费别人好几年时间所以在最终输出端把好关是必要成本。如果你也想在自己的研究里引入 Claude 和 Codex 这套流程我的建议是从一个小问题开始不要第一次就让它们处理完整的定理证明。先让 Claude 分析一个你已经知道答案的引理让 Codex 复现一个教科书上的数值算例感受一下它们的行为方式。等摸清了各自容易在哪里犯错再逐步扩大应用范围。我自己的体会是AI 辅助科研最大的价值不是替代思考而是把那些重复劳动压缩到几乎为零让你有更多精力去质疑那些看似理所当然的假设。这一点在 Buckmaster 这个事件里体现得尤其明显——他公开的并不是一个 AI 给出的答案而是一套人和工具相互校验的工作方式。
