今年 4 月我参加了华中杯数学建模比赛。那会儿 GPT-5.5 刚发布，我用 Codex 桌面端断断续续跟它聊了十来个小时，写完一篇论文，拿了一等奖，还被选进官网优秀论文。那是我第一次接触数学建模，没装任何现成的建模工具包，也没让 AI 独自跑长任务。当时我已经相信 AI 在我的辅助下能做完建模，但对“全交给它”这种玩法有两点顾虑：一是任务越长越烧钱，二是不太相信模型能自己扛完从读题到交论文的一整条链路。
7 月底的一个晚上，我拿到了几个免费的 Claude Max 20x 账号。正常人大概会拿它写代码、读论文，或者一天问上几百个问题；我第一反应却是想试点别的：把一整道建模题原封不动丢给 Claude Code（Anthropic 出的命令行版 AI 助手，能自己读文件、写代码、跑程序），自己尽量不插手，看它能走多远。
于是我把赛题 PDF、四份 Excel 数据和提交说明放进同一个文件夹，把模型切到 Opus 5 的 1M上下文档位（上下文＝AI 一次能记住的内容量，越大越能记住整个项目），然后只给了一句很随意的指令：
https://github.com/XiaoMaColtAI/math-modeling-skill 请你自主添加这个数学建模 skills，并自主完成这个 A 题的全部建模任务，直到产出完整论文给我交付。必要时可以开 subagent 完成更快任务，按照国赛的要求来。
这不是那种精雕细琢过几十版的“神级提示词”，甚至有点口语化。我真正依赖的是里面的两样东西：一份现成的 skill（skill 就是给 AI 预装的一套工作手册，规定它该按什么步骤干活），也就是 math-modeling-skill；以及 Claude Code 自己调工具、自己找帮手、把任务持续推下去的能力。剩下的时间，我就在旁边看着它干活。
它替我做完了什么，又漏掉了什么
从想模型、写代码、跑实验，到排版成 PDF，绝大部分活确实是 Claude Code 干的——我把任务发出去就睡了。凌晨那次会话在最后一次登录过期时中断（白嫖来的账号被封了），第二天下午我让 Codex 接手收尾，拿到手的是一份看着挺像样的论文，外加代码和支撑材料。
但更晚一些，我亲自用 Codex 做了一次逐段复查，发现了几处直接影响结论的证据问题。于是我开始往回捋：AI 到底是在哪几步出的错，为什么会这么错？是模型不够聪明，还是Agent编排（让它干活的方式）有问题？
值得强调的是，这一晚我几乎没插过手：切过一次工作模式、输入过两次“继续”、掉线后重新登录了一次，日志里就这些。这三个动作只负责让任务别停下，没有参与任何建模决策。
这套自动流程具体是怎么跑起来的
第一次接触这类 AI 编程助手（业内叫 coding agent）的人，很容易把它想成“更会写代码的聊天机器人”。可真跑起来，它更像一个临时拉队伍的项目经理。
主 AI 先读赛题、附件和工作手册，把建模、编程、查文献、验证、画图、写论文这些活拆开，再按需要“叫人”——这些被叫来的分身叫 subagent（子代理），你可以理解成主 AI 临时雇的临时工，每个只干一件事，干完把结果交回来。有的子代理只负责核对参考文献，有的只读模型报告然后挑错，有的专门想办法证明求解程序是错的，还有的假装评委来审论文。主 AI 收到结果后决定是返工还是继续。这一晚的日志里，一共留下了 25 个子代理的工作记录。
子代理分两类。默认开启的只有五道质检关卡；查文献、清点附件、试算法原型、跑额外实验这些属于“锦上添花”的协作任务默认关闭，我不点名就不会启用。
还有一条比数量更关键的规矩：审的人不能是写的人。审模型的那个分身没写过模型报告，审代码的那个分身没改过代码，它们只拿到必要的证据，只回答“通过”或“不通过”，不许自己动手改任何正式文件。
五道关卡：M1 到 W2 才是这套手册的真正骨架
多请几个 AI 帮手只是手段，真正决定质量的是关卡设计。
这套工作手册把一整道题拆成三个角色——建模手、编程手、论文手——中间插进五道必须按顺序通过的检查：M（Modeling）1、P（Programing）1、P2、W（Writing）1、W2。它们的作用有点像游戏里的存档点：上一关没过，下一关就不该开始。否则前面的错误会被后面的图表和文字一层层包起来，越做越像真的。
M1 是“模型定稿检查”。建模手交出题目分析报告和术语表、自己检查完之后送审。审的是：题目里的每个小问有没有全覆盖、假设有没有依据、公式和符号前后是否一致、单位和约束条件对不对、模型数量是不是超标、方案在工程上能不能真的实现、打算怎么验证、引用能不能查到出处。过了这一关，才允许开始写代码。
P1 是“最小可运行版本检查”。数据能读进来、能预处理、核心计算第一次跑通，就送审。这时候不要求图表、不要求敏感性分析（就是“参数变一变，结果会怎么变”的测试），只要求打通一条最窄的通路。审查的分身必须亲手把命令跑一遍，核对程序有没有正常结束、关键结果、单位、数值范围和约束条件是否和模型说明里写的那份“合同”对得上。过了这一关，才允许算全量数据、正式画图、扫参数。
P2 是“代码定稿检查”。等代码、结果表、三类候选图（每类至少三张，且覆盖全部小问）和一份“复现清单”全部冻结之后进行。复现清单里要写清随机数种子、输入文件的 SHA-256（可以理解成文件的指纹，内容改一个字，指纹就完全变样）、依赖的软件版本，以及一条唯一的复现命令。审查的分身照着清单独立复现一遍，核对输入文件指纹、关键数值、边界情况和单位量纲，还要看每个小问的图表在数量和含义上站不站得住。过了这一关，才进入论文阶段。
W1 是“证据大纲检查”。它不产出任何交付物，只做一件事：动笔写正文之前，先把“我要下的每个结论 ↔ 支撑它的证据”一条条列出来，每个结论都必须指向具体的公式、结果表的哪一行、哪个图文件、哪段程序输出，或者已核实的文献。说白了，它逼作者先回答“这句话凭什么成立”。过了这一关，才允许写长篇正文和排版。
W2 是“论文终检”。等所有格式检查跑完之后收口，审当年的官方规则、结论与证据的对应关系、数值与单位、图表引用、参考文献，以及最终渲染出来的实际页面。过了这一关，才允许交付并宣称完成。
除了顺序，还有两条容易被忽略的规矩：
- “不通过”不能由主 AI 一句话推翻，必须带着回执里写明的文件、命令和数值，回到对应角色去改，改完再交给没参与修改的人复验。
- 被审的东西一旦有实质改动，之前的“通过”立刻作废，后面所有关卡跟着失效，只能退回最早失效的那一关重来。
这套机制一开始确实管用。晚上 9 点 19 分，独立的 M1 审查第一次判“不通过”，指出模型报告和代码对某类道路限制的处理不一致。Claude 没有强行宣布过关，而是改文档、改代码、再送审，一直折腾到 11 点 20 分，P1 才通过。写的人和验的人不是同一个角色，审查也没有敷衍成一句“整体不错”。
它还抓到过一些相当具体的 bug。比如有一件货物比当时剩余小货车的载重还大，程序却不停地派空车去装，直到把 185 辆车全耗光，然后报告“这题无解”。程序不崩溃，成本函数也不报警，结果却在悄悄变坏——这种问题，普通的“代码能跑就行”式测试根本发现不了。
切到 ultracode 之后
凌晨 1 点 02 分，我把工作强度切到了 ultracode 档，终端当时的解释是“最高思考强度 + 动态流程编排”。
紧接着 Claude 启动了一轮14 个分身的对抗式代码审查：第一批分头去看成本与时间的核心计算、求解程序、动态调度、结果导出、以及“模型说明和代码是否一致”；第二批的任务是专门去推翻第一批提出的问题（防止误报）；最后再安排人汇总。日志记下的数字是：37 个疑似问题、8 个进入验证、4 个最终确认属实。
这大概是整晚最有“未来感”的画面：主程序在后台算着，另一批 AI 同时在翻代码；问题一旦被确认，主 AI 就修复并重启计算。再往后它又开了 6 个论文分身，分别检查官方格式、证据链、建模严谨性、中文表达、排版，以及做最终裁决。
不过它不是一个“按下去就保证正确”的按钮。第一次越过流程边界其实发生在切档之前——论文的排版稿在 P1 还没通过时就开始生成了。ultracode 更像个放大器：好的流程被它放得更强，缺硬约束的流程也跑偏得更快。
转折点：计算还没停，论文审查先开工了
凌晨 2 点 04 分，日志里出现了一句很值得记住的话：论文的结构和论证“不依赖最终数值”，所以可以和计算并行审查。
听上去挺合理：摘要怎么写、章节怎么排、参考文献有没有引用，好像确实不用等最后一个数字落地。可建模论文和说明书不一样——章节结构、图的标题和结论的强弱，本来就该由结果决定。
更麻烦的是，论文审查分身收到的指令里明确写着：部分结果还在重算，文中的 ??（排版工具在引用还没生成时留下的占位符）和 12 张占位图是正常现象，不要报成缺陷。
于是局面变得很微妙：系统名义上做了一轮 W1 式的证据链审查，却主动蒙住了自己一只眼睛——它可以检查引用、句子和版式，唯独不能开口要求“先把证据拿给我看”。与此同时，第一问、第二问、第三问还在同时改写同一批结果文件，论文读的是一块仍在施工的地面。
断在了最不该断的地方
那一晚一共掉线两次。第一次在 1 点 47 分，重新登录之后任务继续；第二次在 3 点 54 分，恰好撞上第三问的计算刚刚结束。
后来的文件时间戳还原出一个五分钟的错位：论文里的数值是 3 点 49 分生成的，而第三问的新结果 3 点 54 分才写进硬盘。也就是说，计算结果已经更新，论文引用的却还是旧快照。随后会话中断，再没有任何 AI 回来重新生成数值、同步图片、重新编译 PDF，更没有人补做 P2、W1、W2 三道关卡。
这暴露了当时流程最根本的问题：“现在做到哪一步了”这个信息，只活在聊天记录和临时待办清单里，没有落到硬盘上。
人类团队不会只靠某个人脑子里记着“我们现在在 P2 阶段”，我们有看板、交接单、版本号和验收记录。可这个流程里没有任何一份文件能回答：M1 到 W2 各是什么状态？某次“通过”针对的是哪一版代码和哪一批结果？接手的人该继续排版，还是退回去重审？会话一断，这些信息就全散了。
Codex 把论文收得很干净，但忽略了“进度状态”
第二天下午 1 点 48 分，我给 Codex 的话同样很短：
这是 Claude Code 做了一半的任务，请你接手继续完成这个任务。
它做的第一件事是清点现场：这不是一个 Git 仓库（Git 是程序员用的版本管理工具，能回溯每一次改动），所以没有历史可查；结果文件比论文 PDF 还新；PDF 有 132 页，里面还有 92 个 ?? 占位符。
132 页也不代表内容丰富——Claude 误判了赛方要求，把 5568 行源代码逐行塞进了附录，真正的正文只有三十页左右。
接下来 Codex 补了一条很扎实的工程流水线：锁定 Python 运行环境、补上漏装的计算库，把“三问求解 → 回归测试（改完代码后重跑一遍老用例，确认没把原来对的地方改坏）→ 独立成本复算 → 刷新论文数值 → 同步图片 → 重新排版 → 打包材料”串成一条链，顺手处理了字体缺字、命名冲突、表格串列和超出页宽的问题。
最终交付看上去很漂亮：31 页、25 张图、10 项回归测试全过、644 条路线独立复算误差为 0、所有占位符清零。
如果我在这里停下，这会是一个非常顺滑的故事：一句话，睡一觉，论文出来了。
问题是——文件完整不等于结论可靠。Codex 拿到的目标是“完成未完成的任务”，没人要求它重建 Claude 留下的进度状态、再从 P2 重审一遍，所以它很合理地只关心：最新结果有没有进论文、代码能不能复现、PDF 能不能交付。工程上的关卡都过了，意义层面的关卡却没人补。
一个点，凭什么叫曲线
后来我用最严格的模式重新审核论文，才认真看见下面这张图。
先别管公式，只看横轴：所有点的横坐标都是 0。图上确实有几个彩色的点，但它们代表的是不同情景在同一个预留比例下的结果，并没有沿着横轴扫过一串取值。
底层的结果文件其实试过 0%、2%、5%、10%、15% 五档，但只有 0% 被程序判定为可行，画图时又自动把不可行的项过滤掉了。最后坐标轴被自动拉成 -5% 到 5%，看着像一张正常的实验图，正文却把它描述成“凸成本曲线”，还顺势讨论了“最优预留比例应该取多少”。
可一个横坐标取值说明不了曲线的形状，更支撑不了“中间某处有最优解”这种结论。这张图外观没坏，坏的是图形证据和文字结论之间的关系。
同一轮审核还翻出几处同类问题：
- 一张所谓的“最优方案边界”里，混着几个明显被其他方案全面碾压的点；
- 两组政策实验的排放变化方向相反，却被拼成了同一个“临界价格”结论；
- 某个采购建议的最优值刚好落在扫描范围的最边上，却没有继续往外多试几档。
它们的共同点是：全都能顺利穿过“程序正常退出、PDF 没有占位符、表格没有溢出”这一类检查。完整复审报告留在本地，原始日志也不随文章公开。
责任该怎么分
把锅全推给 Claude 或者那套工作手册都太简单了，这次其实是四层问题叠在一起。
第一层，模型的局部判断。 主 AI 认为“论文结构不依赖最终数值”，于是提前写、提前审。这个判断在普通软件文档里也许成立，在结果驱动的建模论文里不成立。
第二层，任务编排。 长时间计算和论文写作共用同一个结果文件夹，没有“这是第几次运行”的编号、没有“算完了”的标记、也没有“要么全部更新、要么一个都不更新”的发布机制。审查读到什么，全看那一秒文件正好写到哪儿。分身请再多，也没有一个全局的进度管理机制能拦住主 AI 提前跨关。
第三层，工作手册当时的写法。 M1 到 W2 更像操作手册里的“要求”，而不是程序能强制执行的“锁”。模型“知道”有这些关卡，但在时间压力和并行机会面前照样能绕过去。
第四层，交接。 Codex 只收到一句“接手完成”，没有任何交接单，它既不知道哪些“通过”已经过期，也不会自己推断出应该重建 P2、W1、W2。
概括起来就是：触发点是模型判断，放大器是高并发编排，根因是关卡没被做成机器约束，最后由一次信息不足的交接，把问题一路送进了成品。
这一夜烧掉的 token
先解释一下：token 是 AI 计费和计算量的基本单位，可以粗略理解成“字”——中文一个字大约一到两个 token。
Claude Max 是包月订阅，不按 token 单独出账，所以日志里的用量不能直接换算成花费（真要折成钱，我在另一篇文章里按中转站的直连价算过，一亿 Opus token 大约 58 元），但能看出资源都去哪儿了。
按请求编号去重之后粗算，这批日志包含 917 次独立响应、约 514 万“新写入缓存”的 token、2.44 亿“从缓存读取”的 token，以及 56.4 万输出 token；输入侧大约 97.9% 来自缓存读取。
这里的缓存指的是：AI 把之前聊过的内容存起来，下次不用重新读一遍全文，费用也便宜很多。97.9% 的命中率看着很高，但不等于便宜到可以忽略。
切到 ultracode 之后，我只输入了两个字“继续”，紧接着那次响应的日志是：2 个新输入 token，配 73 万个缓存读取 token。模型确实没有重新写入全部上下文，但仍要反复读一段已经大得吓人的对话历史。
资源大头也不在最后写论文，而在主 AI 长期背着完整历史反复思考、轮询后台任务、读大段工具输出。多个分身做审查本身有价值，但让每个阶段都继承一整晚的对话则完全没有必要。
我后来的改法很朴素：同一阶段内保持稳定上下文，跨阶段改用一张简短的交接单；子代理只收到冻结好的证据包；长任务降低查询频率、结束后写一个完成标记。缓存仍然有用，只是不再拿它替代真正的上下文管理。
把这些经验写回工作手册
事后我让 Codex 把这次复盘合并进了最新版 skill，放在这个公开分支：ccckfg/math-modeling-skill。
我没有再往指令里堆一页要求，而是把流程改成了可恢复的：
项目现在会保存一份进度状态文件，并为 M1、P1、P2、W1、W2 各自生成交接记录；每道关卡都绑定代码、结果和论文文件的指纹（SHA-256），文件一变，后面的“通过”自动作废。长时间计算写进各自独立的运行目录，跑完之后才一次性发布成正式结果。
这样即使换了会话、换了 AI，接手的人也能先审计“现在到底做到哪一步了”，再决定从哪一步继续。
结果的“含义”也被写进了检查范围，比如：
- 两个点最多支持“存在差异”或“一条线段”，不能包装成完整趋势；
- 只有一个可行横坐标时，禁止使用“曲线”“中间存在最优”之类的表述；
- 叫“最优边界”的点必须两两互相比较，不能留下明显被碾压的方案；
- 正文、表格和敏感性实验必须引用同一批结果，结果指纹一变，W1 和 W2 必须重做。
这类规则看起来没有大模型那么聪明，但比一句“请认真检查”可靠得多。
顺带一提，工作手册装多了之后，目录本身也会变成负担：同一份 skill 在 Claude Code、Codex、Cursor 里各放一份，改完一个还得想想其他目录要不要跟着改。我后来专门写了个 Agent Skills Manager，把 21 个 AI 工具的 skill 收进同一个中央仓库再统一分发。
如果你也想试一次
我现在不会建议新手照抄我那句过于宽松的开场指令——它能把任务启动起来，却把太多决定留给了运行中的模型。可以改成这样：
使用 math-modeling skill 的 full 模式完成附件题目。必须按 M1 → P1 → P2 → W1 → W2 顺序执行并把状态落盘；任一门禁未 PASS，不得进入下一阶段。长计算写入独立 run 目录，成功后再发布，论文只能读取已冻结的正式结果。会话中断或产物哈希变化时，先审计并失效下游门禁。任何“趋势、曲线、最优、阈值、前沿”结论都要检查有效点数、边界、重复实验和数学定义。最终同时交付论文、代码、结果、复现清单与门禁记录。
然后，人最好在五个位置各露一次面：看 M1 的模型假设，看 P1 的小样结果，看 P2 的异常点和图，看 W1 的证据大纲，最后看 W2 的成品 PDF。
你不需要亲自写算法，但要对“这句话凭什么成立”保持一点不信任。如果时间实在紧，宁可删掉一个证据不足的漂亮结论，也别让 AI 帮你把一个点写成一条曲线。
写在最后
这次实验最让我兴奋的，不是 Claude Code 能写出五千多行代码，也不是它一晚上拉起 25 个分身，而是 AI 已经能组织起一条相当复杂的知识生产流水线：发现真实的 bug、请人独立审查、修完重新运行、再把结果写进论文。
让我后背发凉的也是同一件事——流水线跑得越顺，错误被排版、图表和测试结果包裹起来之后，就越像一份可信的成果。
我现在更愿意把这类 AI 助手看成一位速度极快、还会自己叫人来帮忙的项目负责人。它值得用，但不能只给目标，还要给它停线的条件、版本的边界，和一份能交出去的进度记录。
所谓“全自动”，最容易省掉的是人的操作，最不该省掉的是验收。
附：那份论文本身
上面说的都是这一份 PDF——这次实验最终交出的成品：Claude Code 自主完成、Codex 收尾交付，31 页、25 张图。
文中指出的那几处证据问题我一处都没改，就按当时交付的样子放上来——这篇文章讲的正是“看起来完整”和“结论可靠”之间的差距，改过就不算证据了。
参与讨论