每年 MCM/ICM 出分之后，总能听到这样的复盘：「我们模型其实挺好，就是论文没写完」「第三天还在换思路」「队友通宵改格式」。限时建模赛本质上是一场团队工程——三个人、四天、一篇 25 页的英文论文，任何协作上的低效都会被 96 小时的倒计时放大。这篇文章整理一套经过大量队伍验证的协作框架。
先说分工。经典的三人分工是「建模手、编程手、写作手」，但严格三分在实际比赛中很难维持——模型边建边改，代码边跑边调，论文边写边补。更现实的理解是三个「责任人」而非三个「工种」：建模手对模型的正确性负责，编程手对结果的可复现负责，写作手对论文的最终形态负责。责任到人意味着：任何时刻有人能对某块工作拍板说「这样定了，往下走」。
三人之外，还有一个隐形的第四角色：队长。队长的职责不是技术最强的那个，而是节奏的守护者——他盯时间表、做取舍决策、在分歧僵持时拍板。比赛第二天的「换不换思路」之争，往往就是缺一个能拍板的人。建议开赛前就明确：技术分歧 30 分钟内谈不拢，队长征集各方一句话理由后决定，决定后不再翻案。
再说节奏。以 96 小时为例，一个被广泛验证的时间表是：第一天（0-24h）只做两件事——彻底审题与方案设计。通读题目三遍以上，把每小问拆成「输入是什么、要输出什么、用什么方法」的一页纸任务清单；晚上锁死总体方案与论文大纲，写好摘要的初稿框架。第二天（24-48h）全力建模与编程，出第一批结果，哪怕粗糙——有结果比结果完美重要。第三天（48-72h）完善模型、补灵敏度分析，写作手同步把前两天的内容成文。第四天（72-96h）全天写作：摘要精修、图表统一、格式检查，最后 6 小时只做校对与提交演练，不碰模型。
两条铁律值得单独强调。第一，摘要最后写但最先被读：建议把摘要的精修放在第四天上午头脑最清醒的时段，全队三个人一起逐句过。第二，图表的统一性：三人各画各的图是重灾区——配色、字号、坐标轴风格全不一样。开赛第一天就约定一套统一的图表规范（工具、模板、命名），后续所有图表都从同一个模板出。
工程细节上，几条实践建议：所有代码与文档放在共享目录（或同一个 Git 仓库），按「论文-图表-代码-数据」四目录组织，文件名带序号；关键结果（表格、图）每更新一版就同步到论文草稿，不要攒到最后；每天固定两个 15 分钟的站会（早晚各一次），同步进度与阻塞点，其余时间各自深潜。
协作事故排行榜上，前三名常年是这些：其一，「沉默的两小时」——有人卡住了不说，队友以为进展顺利，两小时后发现整块工作没动。对策：任何卡壳超过 30 分钟必须在群里喊出来。其二，「版本灾难」——终稿前发现论文里引用的是旧版结果。对策：结果文件带版本号，论文引用时注明版本。其三，「通宵的幻觉」——凌晨三点改出的东西，第二天上午看全是错的。对策：最后 24 小时强制不熬夜改核心内容，只做轻量校对。
还有一个容易忽视的维度：和指导老师的协作边界。HiMCM 与 IMMC 允许（甚至要求）配备指导老师，但规则通常限定老师不能参与解题与写作。指导老师的正确用法是：赛前陪练、赛后复盘，赛期内只做后勤与情绪支持。把老师当「场外求助热线」既违规，也会打乱自己的节奏。
最后说心态。96 小时中一定会有那么几个小时，全队陷入「这个模型是不是不对」的自我怀疑——这是正常现象，几乎每支队伍都会经历。判断标准很简单：只要任务清单还在按天推进、论文页数在稳定增长，就说明节奏没崩。反之，如果第二天晚上还没有任何成文的东西，果断砍掉最花时间的次要问题，保主体、保完成度。
想看协作与节奏的成品长什么样？去本站论文库挑两篇 MCM/ICM 的 O 奖论文，重点看它们的图表规范与摘要写法——那些「看起来毫不费力」的论文，背后都是一套被严格执行的协作流程。你的第一场比赛不需要做到满分，但把这套框架跑顺一遍，第二次自然知道往哪儿优化。
