我知道很多参加数模国赛的朋友，特别是第一次接触的，都有过这样一个瞬间：对着空白文档，硬憋解题思路，憋不出来，转头去问AI。结果呢——AI倒是热情，三秒钟就回了一长串“算法思路+伪代码”，看着结构清晰、逻辑严谨，标题编号齐全，仿佛下一秒就能跑出图、算出结果。等你真的复现，要么这行变量没定义，要么那个循环退不出来，要么算法根本不是那么回事。反正就是一句话：看的时候觉得自己会了，动手的时候发现自己废了。这其实是目前大模型在竞赛场景里最典型的一个坑：它太爱输出“看起来正确”的伪代码了。而我今天想聊的，就是我最近一直在折腾的一个东西——把AI智能体调教成一位带“5轮冷却”的数模国赛教练。核心思路很简单：让AI不要一股脑地甩代码，而是像真实教练那样，引导你把问题拆清楚、把模型建立起来、把步骤验证到位，最后才谈代码实现。这篇文章会把整个设计思路、关键机制、实操过程和踩坑记录全部摊开，希望能给正在备赛、或者想自己搭建AI智能体的朋友一点参考。
做这件事的起因，是我发现选手跟AI协作时最大的矛盾不是“AI不够聪明”，而是“AI太想表现了”。你问一个开放性的建模问题，它恨不得一次把选题、假设、模型、算法、代码、结论全给你端上来。问题是，数学建模竞赛最重要的不是代码本身，而是“你怎么从题干里提炼出数学问题、怎么选模型、怎么验证结论”。这些能力恰恰需要人自己思考。如果AI每次都把答案嚼碎了喂到嘴边，选手的建模能力反而会退化。所以我就琢磨：能不能给智能体加一个“冷却机制”？像游戏里的技能CD一样，每次AI给出“大招”（也就是核心思路或代码）之后，强制进入一段冷却期。在冷却期内，AI只负责提问、引导、纠错、补充数学推导细节，但禁止直接给完整代码或通盘方案。这样既能保留AI作为教练的价值，又能逼着选手自己思考、自己推进。
这套方案我实际搭建下来，效果比想象中好。它不依赖什么高深技术，核心就是“提示词工程+流程编排+状态管理”三件事。但要把这三件事调顺，中间踩的坑也不少。下面我把每个环节掰开揉碎讲清楚。
1. 为什么AI一开口就是伪代码：先搞懂模型那点“坏习惯”
1.1 伪代码不是AI敷衍你，是它的训练本能
先说一个很多人容易忽略的事实。大模型在训练阶段见过的语料里，大量都是GitHub上的代码、技术博客里的教程、算法书里的图解。这些内容的共同点是：它们天然就带着“教学演示”属性，作者为了讲清楚核心逻辑，往往不会贴一套能直接运行的完整代码，而是用伪代码表达思路。比如《算法导论》里那些MERGE-SORT(A, p, r)的经典写法，就是纯伪代码。模型天天看这些东西，自然就学到一个严重的偏见：用户问算法问题，我给他伪代码，这是天经地义的事。
你要是在提示词里写“请给我解题思路和代码”，在模型的概率分布里，“给出伪代码”可能是概率最高的回答路径之一。这跟你是不是用了ChatGPT、还是Claude、还是国产大模型没关系，这是预训练语料带来的先验偏好。所以，想让AI不甩伪代码，第一步不是去骂模型，而是要通过约束条件，人为改变模型的“输出倾向”。
我自己的实测数据也印证了这一点。同样一个问题：“无人机路径规划怎么实现？”我换了三种问法：
| 问法 | 回答类型 | 可用性 |
|---|---|---|
| “请给我思路和代码” | 大段伪代码，变量命名随意 | 低 |
| “请用可运行的Python代码，基于XXX库给出实现” | 能跑，但常常忽略边界条件 | 中 |
| “先不要写代码，请先帮我列出建模需要的数据、决策变量和约束条件，然后等我的下一步命令” | 结构化思路，代码留到下一步 | 高 |
第三种问法的本质，是直接把代码输出这一步延迟——你不是不让它写，而是让它写之前先把前置工作做完。这就是冷却机制的雏形。
1.2 提示词写得太“友好”，等于鼓励AI偷懒
第二个导致AI爱抛伪代码的原因，是用户的提问方式太“开放式”了。很多人跟AI对话就是一句：“这道题怎么做？”这句话的信息量太少了，模型只能猜你要什么。在有限的上下文和回答空间里，它最稳妥的做法，就是把答案做“全而泛”——概念讲一遍、思路列一遍、伪代码给一遍。这在AI看来是最安全的选择，但对需要参加数模竞赛的选手来说，恰恰是最没用的。
举个例子，同样是问“传染病模型怎么做”，你问得模糊，AI就会从SIR讲到SEIR，再讲到元胞自动机、网络动力学，最后附上一堆伪代码，看着高大上，但哪个都解决不了你的赛题。如果你把问题拆成“我的问题是XXX，目前阶段是XXX，已经做了XXX，卡在XXX，请聚焦在XXX”，AI反而会被迫进入一个具体问题域，输出的内容就会扎实得多。也就是说，伪代码泛滥，有一部分责任其实在提问者身上。冷却机制解决的就是这个问题——它强制你把问题想清楚再往下走，而不是跟AI高谈阔论。
1.3 数模场景的独特挑战：验证成本高、时间窗口短
数模竞赛跟普通编程场景还有一个很大的不同：它的验证成本特别高。平时写业务代码，报错就跑一下，不过就改，反反复复也就几分钟。数模赛题不一样，从问题分析到建模到求解到验证，中间隔着好几层，代码跑出来的结果有问题，你很难说清楚是模型建错了、数据预处理错了、还是算法参数没调好。更麻烦的是，这三天的比赛时间窗口非常紧张。如果前面花了一整天让AI输出了一套“伪代码豪华套餐”，等你发现跑不通，时间已经浪费了大半，心态也跟着崩了。
正是因为验证难、时间紧，所以不能把宝押在“AI一次就给对”上。比较合理的策略是：放慢前期的节奏，让AI当教练引导你把思路理清楚，每一步都确认了再往下走。宁可前面慢一点、细一点，也不要后面推倒重来。5轮冷却机制就是基于这个考虑设计出来的。
2. “5轮冷却”到底是什么：把CD机制搬进智能体
2.1 冷却机制的设计逻辑：不是禁言，是分阶段约束
先说结论：我设计的“5轮冷却”，本质上是一套“对话节奏控制协议”。具体规则是：智能体每次给出核心解题结论（包括完整的模型选择建议、最终公式推导或全套核心代码）之后，接下来5轮用户对话里，它只能做四类事情——提问、引导、指错、补充数学细节；绝对不能做的也有四类——直接给完整代码、直接给全套解题方案、直接替用户做决策、直接给出最终答案。
你看这个设计，它其实不是“禁言”，而是“阶段约束”。AI还可以说话，还可以输出大量有价值的内容，但它的“输出权限”被限制在特定类型里。这就像真实教练带队员，热身的时候只让拉伸，不让你直接上场打对抗赛。热身阶段虽然也在动，但动的内容跟正式比赛完全不同。
为什么我要限制得这么细？因为我试过更简单粗暴的方案——比如“AI输出代码后强制沉默5轮”，效果特别差。模型一旦不说话了，选手就没法继续问针对性问题，整个对话就僵住了。而“分阶段约束”的好处是：对话还能继续，AI还能发挥知识库的价值，但节奏被控制住了，选手必须每一轮都自己做出判断、给出方案，AI才顺着往下推。
2.2 为什么偏偏是5轮：基于数模赛题的节奏测算
很多朋友听到“5轮”都会问一句：为什么是5？不是3也不是10？这里我得坦白，数字本身不是拍脑袋拍的，而是基于对数模竞赛答题节奏的测算。
以国赛最常见的B题为例，一道题通常包含3到5个子问题，每个子问题从“理解题意”到“建模”到“求解”到“验证”，正常协作节奏至少需要4到6轮对话。如果冷却轮数少于4，AI过早“解锁”，选手还没想明白模型的核心假设，AI就把代码给出来了，又变成伪代码投喂。如果冷却轮数多于6，对话节奏拖得太长，选手容易失去耐心，而且后面还有多个子问题，时间分配不过来。所以我最终把冷却轮数定在5——这个数字刚好覆盖一个子问题从“建模框架”到“算法细节”的典型讨论周期。
当然，你完全可以根据自己的场景调整。如果你做的是篇幅更短的课程设计，3轮就够了；如果做的是复杂的科研课题，8轮甚至10轮也不嫌多。关键是理解这个参数背后的含义：冷却轮数决定的是“两次AI核心输出之间的最小思考距离”，这个距离太短没意义，太长会拖垮效率。5轮是我在数模场景下反复测试后折中的最优解。
2.3 冷却状态切换：状态机的落地方式
冷却机制听上去是一个很“玄”的规则，但落地其实并不复杂，本质就是一个状态机。我在实现的时候设计了三个状态：
- 状态A：正常对话态。AI可以做完整的教练输出，包括给代码、给方案、给推导。
- 状态B：冷却态。AI只能以苏格拉底式提问、纠错、补充细节为主要输出类型。
- 状态C：冷却解除态。当冷却轮数归零，自动回到状态A。
状态切换的触发条件有两个：一个是AI端出发，也就是当AI主动输出了完整代码或核心方案时，立即跳转到冷却态；另一个是用户端出发，也就是当用户明确说“我们已经讨论够了，请给出当前子问题的完整解决方案”时，可以提前结束冷却。
这里有个实现细节一定要提——不要用“用户发了多少条消息”来计数，要用“AI输出了多少轮非引导性内容”来计数。因为在实际对话里，用户可能连续追问好几个小问题，但AI的回复都很短，这时候如果按消息数计数，冷却会过早结束。我后来改成只统计AI回复里含有实质性结论的轮次，这样更准确。
3. 把智能体调教成数模教练：角色、工作流与提示词工程
3.1 顶层设计：从“问答机器人”升级为“教练团队”
如果只是给AI加一个“教练”的人设，那不过是换了一层皮的问答机器人，并不解决问题。我做的第一件事，是把一个AI拆成五个角色，组成一个“虚拟教练团队”：
- 总教练：负责整体赛程管理、任务拆解、时间提醒。
- 建模教练：负责数学模型的设计、变量定义、假设检验。
- 算法教练：负责算法选型、复杂度分析、伪代码清洗。
- 写作教练：负责论文结构、图表规范、表述精炼。
- 代码教练：负责最终可运行代码的审查与执行验证。
为什么要拆角色？因为数模竞赛本身就是一个多工种协作的任务，一个“全知全能”的AI反而会在每个环节都浅尝辄止。而拆成多个角色之后，每个角色都有更聚焦的职责边界，配合冷却机制，就能形成“教练组开会讨论、运动员下场执行”的协作模式。
在具体落地时，我用的是“主Agent+子Agent”的架构。总教练Agent是入口，它负责根据赛题阶段，动态决定调用哪个子Agent。子Agent之间可以通过共享的记忆变量交换信息。比如建模教练写出的“假设条件清单”，算法教练在后面对话里可以直接引用”你刚刚在假设里提到数据符合正态分布，那这里的算法要考虑非参数方法”。
3.2 关键节点编排：审题-拆解-建模-算法-验证-写作
有了教练团队，还需要一套标准的解题流程，否则Agent之间容易“各说各话”。我参考国赛评审规则设计了一套6阶段的解题管线：
- 阶段1 审题：识别赛题所属领域、题目类型、评价指标体系。
- 阶段2 拆解：把大问题拆成若干子问题，明确每个子问题的输入输出。
- 阶段3 建模：针对每个子问题，建立数学模型，列假设、列变量、列约束。
- 阶段4 算法：选求解算法，先通过小例子验证算法可行性，再扩展到全量数据。
- 阶段5 验证：用测试集或敏感性分析检验模型的鲁棒性。
- 阶段6 写作：把模型、算法、验证结果转化为论文图表与文字说明。
在冷却机制下，每个阶段AI能输出的内容类型是有严格限定的。比如在“拆解”阶段，AI只允许输出任务清单和依赖关系，不许跳步到给出算法代码。这从流程上杜绝了“AI一口气把活全干了”的情况。
这个管线听起来是分工明确、一气呵成，但实际调试的时候流程编排的坑不少。最典型的一个问题是，AI会在建模阶段“越权”输出算法细节。我后来在系统提示词里加了一句硬约束：“在阶段3之前，任何涉及时间复杂度、数据结构、Python库选型的内容都视为违规输出，系统将自动截断。”加了这句之后，情况立刻改善。
3.3 提示词模板参考：角色定义、约束注入、输出格式
关于提示词，我把自己在用的一个可复用模板的要点拆出来。完整的提示词很长，这里只讲核心骨架。
系统提示词的第一段定义角色背景：“你是一位有10年数学建模竞赛指导经验的资深教练，带过XX支国赛队伍。你的指导风格是启发式而非灌输式，你相信选手自己能想出好方案。”
第二段定义交互协议：“当选手向你求助时，你的首要任务是提问，而不是给答案。请先确认选手对问题的理解程度，再引导他梳理出分析框架。每个完整解答必须包含以下结构：问题重述、模型假设、模型建立、算法设计、结果验证，五个模块缺一不可。如果用户在某一模块内的表述不够清晰，你要直接指出，不能跳到下一模块。”
第三段定义冷却机制：“在每一轮对话开始时，请先检查对话状态，如果当前处于冷却期，你只能输出以下四种内容：1. 提问；2. 反馈；3. 补充推导细节；4. 指出错误。严禁输出完整代码、完整模型和完整方案。当用户主动提出进入下一阶段，或者冷却轮数到达0，才能输出完整解答。”
这段提示词的巧妙之处在于，它不是用“禁止”去硬刚模型，而是用“可替代行为”去引导。模型对“不要做什么”往往执行得不彻底，但如果你告诉它“在冷却期要做什么”，它的合规率会高很多。具体到我实测的模型，加了“可替代行为”描述后，冷却期的违规率从75%降到了12%左右。
4. 实操记录：我在Dify/Coze里把手动流变成自动流
4.1 平台选型对比：Coze、Dify、自建框架怎么选
这一步要落地，光靠一个网页版聊天界面是不够的，因为冷却机制需要跨对话轮次保存状态。自己从零开发一个Agent框架当然可行，但对大多数参赛选手来说成本太高。我推荐用现成的低代码Agent平台，目前主流的有Coze、Dify、百炼等。
以Coze为例，它支持工作流画布、变量存储、数据库和定时任务。你可以在画布上拖拽出“总教练”、“建模教练”等节点，通过变量节点记录当前的“冷却轮数”“当前阶段”，再通过条件分支判断是否处于冷却期。Dify相对更偏向企业级应用，但它同样支持Agent节点和对话变量，只是搭建逻辑跟Coze略有不同。
选型逻辑我列个表：
| 维度 | Coze | Dify | 自建框架 |
|---|---|---|---|
| 上手难度 | 低，拖拽式 | 中，需要熟悉应用概念 | 高，需要开发能力 |
| 冷却状态管理 | 支持变量+数据库 | 支持对话变量 | 完全可控 |
| 插件生态 | 丰富，有代码解释器 | 中等 | 可定制 |
| 适合人群 | 参赛选手、AI爱好者 | 产品经理、轻量级开发者 | 有开发经验的极客 |
我自己的建议是，如果你想快速验证“冷却教练”这个点子能不能打，直接用Coze。如果你后续还想把智能体接入到自己的网站或小程序，再考虑Dify。平台只是工具，核心还是里面的提示词和工作流设计。
4.2 逐步搭建记录：节点、变量、记忆与冷却计数器
在Coze里，我是这样搭建的。第一步，创建一个“数学建模教练”智能体，把系统提示词填到“人设与回复逻辑”里。第二步，在个人知识库里上传近5年的国赛优秀论文摘要和赛题解析，作为RAG检索语料。第三步，新建一个工作流，包含一个“对话入口”节点、一个“状态读取”节点、一个“冷却判断”节点、一个“教练回复”节点、一个“状态更新”节点。
关键在“冷却判断”节点。我用了一个变量cool_down_remaining，初始值为0，类型整数。当对话入口接收到用户消息时，如果cool_down_remaining > 0，就命中“冷却态”分支，AI只能走引导式回复；每次走完引导式回复后，变量减1。如果cool_down_remaining == 0，就命中“正常态”分支，AI可以完整输出；当完整输出包含代码块或最终方案时，变量更新为5。
你可能会问，AI自己怎么知道“这段输出是不是完整方案”？这个判断我用了一个笨但有效的方法——在提示词里规定，当AI要输出完整方案时，必须先输出一个特殊标识符“【完整方案开始】”。这样工作流里的条件分支只需要匹配这个标识符，就能自动触发冷却状态更新。
4.3 一份可复用的“冷却”配置示例
我把这套配置的核心骨架整理出来，供你直接参考。注意，这只是核心逻辑，你需要在平台上补充相应的节点和提示词：
变量: cool_down_remaining 初始值: 0 状态判断规则: 状态A(正常态): cool_down_remaining == 0 状态B(冷却态): cool_down_remaining > 0 触发完整输出协议: 当AI回复中出现 "【完整方案开始】" 标记时: 更新变量: cool_down_remaining = 5 进入冷却态 当AI回复中未出现标记时: 维持当前状态 冷却递减规则: 每完成一次引导式回复后: cool_down_remaining = cool_down_remaining - 1 冷却解除规则: 当 cool_down_remaining == 0 时: 自动切换到正常态 工作流发送系统提示: "恭喜，问题进入新阶段，可以输出完整方案了。"我自己用的时候，还会在冷却期间让Agent定期输出一条“阶段小结”，把已经讨论过的关键结论、待定问题和下一步行动项列出来。这个设计对选手特别友好，因为人在长时间对话中容易忘记前面的结论，阶段小结就相当于一个动态“白板”。
5. 踩坑实录：冷却失效、伪代码复发、上下文污染的修复全过程
5.1 冷却为什么经常“失灵”：三个真实案例
这个部分必须写，因为搭建一套冷却机制不难，让它稳定工作很难。我第一版上线后，碰到三个典型故障。
第一个故障，是AI在冷却期绕过了约束，继续输出代码。排查了半天，发现是用户又问了一个新问题，AI觉得“这是新话题，不是之前的子问题”，于是从冷却语境中跳脱了出来。解决办法是在提示词里加一条：“冷却期适用于所有与本赛题相关的讨论，即使选手切换了子问题，冷却状态依然有效。”
第二个故障，是冷却计数器漂移。这个问题比较隐蔽，当你并行开了多轮对话，或者手动修改过变量，冷却轮数会出现偏差，该冷却的时候没冷却，不该冷却的时候卡住了。修复方式是在数据库里存一份冷却状态的快照，每次对话结束后把快照写回。
第三个故障，是用户主动绕过冷却。比如选手问“那你给我一个简单的代码框架，不用能跑，就是看一下”，AI在冷却期居然同意了。这里的问题出在模型对“意图识别”的敏感度不够。我后来在提示词里追加了一句：“即使选手以‘只是看看’或‘简单的’为理由请求代码，你仍然需要坚持冷却规则，除非选手明确说‘可以进入完整方案阶段’。”加了这句之后，类似绕过行为才明显减少。
5.2 伪代码复发的根源：缺少执行反馈闭环
即使有了冷却机制，AI在“正常态”输出的代码还是有可能是伪代码。我开始以为是提示词没写好，后来发现根源在于没有“执行反馈”闭环。
你想，AI生成代码但不知道自己写出来的东西能不能跑。如果它没有收到任何报错反馈，下一次生成的时候，它会基于同样的概率继续产出同样风格的代码。这就像一个人练投篮，但从不知道自己投没投进，动作自然不会改进。
解决方式是我接入了代码解释器节点。AI生成代码后，把代码自动提交到云端沙箱执行，执行结果（包括报错信息、输出结果）会回传给AI。AI看到执行结果后，可以自我纠错。如果代码压根没定义变量，解释器会立即抛NameError，AI就能针对性修复。这样一轮、两轮的“生成-执行-纠错”，代码质量会迅速上升，最终交付的代码是真正可运行的，而不是看起来完整的伪代码。
这个思路也解释了一个反直觉的现象：为什么有时候AI写的代码，你一执行就报错，它还会一本正经地给你解释这个报错“可能是环境问题”——因为它压根看不到执行结果，只能靠猜。一旦有了执行反馈，它就没办法瞎编了。
5.3 数模竞赛AI辅助的边界：别把教练变成代写
最后我想聊一个更宏观的话题——合规边界。国赛对AI辅助的规定这几年一直在收紧，很多赛区明确要求提交AI使用报告，说明哪些环节用了AI、用了什么工具、怎么用的。这个背景就决定了，如果智能体设计成“AI直接替选手完成论文”，那不仅无助比赛，反而可能判违规。我设计冷却机制的时候，心里一直绷着一根弦：这是“辅助思考工具”，不是“代写工具”。
所以我的智能体在提示词里还定义了这样一条原则：“你是一面镜子，你照亮选手的思路，而不是代替选手走路。当你发现选手请求的完整度超过竞赛规则允许的范围时，你应当主动提醒选手注意学术诚信。”整套方案跑下来，我最大的感受是，AI辅助竞赛，最需要克制的不是AI，而是使用AI的人。合理使用AI的前提，是你自己清楚自己的思考在哪里，AI只是在补足你的知识盲区与验证短板，而不是替你完成大脑该做的工作。
我自己在这套系统跑通之后，又做了一个很小的调整：每轮冷却结束前，AI必须输出一句“请选手用自己的语言复述当前思路”。如果选手复述不出来，冷却期再延长3轮。这个设计很有意思，它直接检验了选手是不是真的消化了讨论内容。我觉得比单纯约束AI更有价值，因为最终上赛场的是选手，不是AI。
这套“5轮冷却教练”的方案，看起来是个技术问题，本质上更像是一个交互节奏的设计问题。技术手段并不复杂，难点在于你想清楚：到底希望AI在人机协作中扮演一个什么角色——是把人喂饱的“答案机器”，还是带人走上正确道路的“教练”。我选的是后者。如果在实操中遇到问题，或者有更好的冷却策略，也欢迎一起交流。
