把训练过程直播半个月：公开的到哪一层才算可复现
一、”开源”和”可复现”不是同一个词
据公开报道，有厂商把一款具身模型的训练全流程连续半个月公开直播，并宣布即将开源，展示的是从训练到迭代的过程。这件事对工程侧的价值不在于直播这种形式，而在于它把一个平时被混用的区分摆到台面上：公开了什么，就决定了第三方能验证到哪一步。本篇不评价模型效果，也不涉及任何训练规模参数，只把”可复现”这件事分层。
我们内部一直用五层来描述可复现的程度：结果可跑、环境可跑、数据可描述、评测可比、过程可回放。这五层不是同一件事的五种说法，而是五种不同的交付物，成本差别很大，用途也完全不同。把它们混为一谈，就会出现两种典型争议：一方以为给了权重就等于给了可复现，另一方发现自己在别人的机器上一次也跑不出来。
分层的另一个好处是它可以谈判。作为采购方，不必要求对方做到第五层，而是明确说”我们要第三层和第四层，不要第五层”，对方也能明确回答给不给得起。模糊要求”请提供可复现材料”，通常只会换回一份 README。
二、五层各自需要什么，以及各自用来回答什么问题
| 层次 | 需要的内容物 | 能回答的问题 | 拿不到的后果 |
|---|---|---|---|
| 结果可跑 | 权重文件与最小推理示例 | 这个模型能不能在我的输入上出结果 | 接入靠猜测，示例都跑不通 |
| 环境可跑 | 镜像或依赖清单、精度与算子组合、硬件与并行配置 | 换一台机器还是不是同一个东西 | 分数差异被归因到模型本身 |
| 数据可描述 | 数据构成说明、来源类别与采样比例、清洗与去重规则 | 它见过什么、没见过什么 | 无法判断任务是否在其覆盖范围 |
| 评测可比 | 评测脚本、提示模板、解码参数、判分规则 | 你的分数和我的分数是不是同一个量 | 双方各说各的分数 |
| 过程可回放 | 随机种子、检查点与中间日志、配置版本记录 | 这个结果是怎么走到的、能否定位到某一步退化 | 只能整体接受或整体怀疑 |
前三层通常一起被称作”开源”，第四层以上才进入”可验证”的范围。第五层的用途常被误解：它不是为了让别人重训一遍（多数买家没有这个预算，也不该有），而是为了在出问题时有地方可查。当一个结果无法解释时，能否定位到某个检查点前后的行为变化，决定了这是一次可修的缺陷还是一次无解的怀疑。
三、为什么只给权重往往只到第一层
权重文件本身携带的信息比想象中少。它能说明”这个参数矩阵长什么样”，不能说明这些参数是在什么依赖版本、什么数值精度、什么并行切分下得到的，也不能说明推理时该怎么调用。
三个常见的缺口。第一是数值与算子组合：同一份权重在不同精度与不同算子实现下的输出会有差异，而这个差异在长序列生成上会被放大，最终表现为”官方分数我复现不出来”。第二是上下文处理：位置编码的外推方式、截断策略、以及多轮拼接顺序，都不写在权重里，却直接决定行为。第三是最小示例的质量：一个只有 happy path 的调用样例，等于没写；示例至少要包括一组固定输入与期望输出，让买家能在自己的环境里先验证一致性，再去做业务评测。
顺序也因此要固定：先验证”在你的示例上我们跑出了你的数字”，再验证”在我们的任务上跑出我们的数字”。跳过第一步的复现工作，通常会把环境与调用问题误判成模型能力问题，浪费的时间比补这一步多得多。
四、评测可比的三个陷阱
第四层最难，因为它不需要额外算力，只需要克制。三个最常踩的坑都发生在”分数怎么来的”这一侧。
提示模板不同。同一道题，指令措辞、示例数量、格式要求任意一项变化，都能拉开明显差距，而公开材料里往往只写”我们使用标准评测”。对策是把提示模板作为版本化文件随评测脚本一起给出，禁止只给结论。
解码参数不同。温度、Top-p、最大长度、是否使用链式提示、是否允许重试，都会改变分数；温度大于零时，单次分数没有意义，至少要给重复次数与统计口径。对策是评测脚本内固定解码参数，并在报告里显式列出，不接受”默认配置”这种写法。
上下文截断不同。长输入被从哪里截、截掉的是前文还是后文，对依赖远距信息的行为影响巨大，也是跨团队对比里最隐蔽的一项。对策是评测时记录每条样本的输入长度分布与截断比例，截断超过一定比例的题目单独成组，不与完整题混着报。
这三个陷阱的共同点在于：它们都不是造假，只是没写。而没写的代价由所有后来者分摊。
五、把可复现要求写进供应商验收
这一层划分对采购方同样好用，因为它是可谈判、可验收的。我们把它压缩成四项要求。
- 要数据卡片。写清数据来源类别、构成与采样比例、清洗与去重规则、已知覆盖不到的场景。数据卡片描述的是”它没见过什么”，这一项对判断任务适配度比分数更有用。
- 要评测脚本能自跑。脚本、提示模板、判分规则三件齐备，且买方可在自己的环境里跑出与供应商一致的相对排序。只给分数不给脚本的，验收时按”不可验证”处理。
- 要固定版本。权重、镜像、依赖清单、提示模板、解码参数各给版本号，并声明这五个版本构成一个可复现的组合。缺一件，任何后续差异都无法归因。
- 要变更日志。任何影响行为的更新，至少要能看出”这次改动影响哪一类输入”。变更日志不要求解释为什么，但要求能定位到”从哪一版开始不一样”。
验收条款的写法也有讲究：把这四项按场景分级，而不是一刀切要求全部。替换既有组件的选型，要求到第四层就够；要长期依赖且需要解释失败模式的场景，才值得争取第五层；只是做一次离线对比，第一层加第三层即可。按场景分级还有一个作用，是让供应商知道你在为什么付费，从而避免拿一份 README 来充当全套交付。
六、企业内部缺的也是这一层，还有一处例外
同样的分层放到自己团队里，问题一模一样，而且更普遍。模型迭代记录只留了最好的一版，中间尝试全部消失；实验没有留下配置快照，过两周同样的命令跑出不同结果；失败实验不留档，于是三个人在两个月里踩同一条死路，重复投入的正是被丢掉的那部分。我们的处置方式很轻：实验记录里必须存配置快照与评测版本，失败实验也要留一段”观察到什么、因此排除什么”，只写这两句，坚持下来就能省下相当比例的重复工作。
用 AI 做产品时，同一件事换了名字但内容不变：提示与检索配置要版本化，评估集要冻结，任何一次调参都要能说清”在同一个评估集上比较”。评估集一旦被随手修改，之前所有对比结论同时作废，这和第四层陷阱是同一个错误。
有一个例外要说明，否则分层要求容易被滥用。纯 API 消费方通常不需要要求可复现，因为你并不持有实现，要求别人公开训练过程也不现实。这类场景该盯的是另外两件：服务等级与变更通知（版本升级前是否有可验证的窗口），以及回滚路径（新版本效果变差时能不能退回旧版本并锁定）。把”要可复现”改成”要可回滚”，才是对消费方有效的条款。
公开到哪一层才算可复现，答案不在于层数，而在于是否说清每一层给了什么、没给什么。这份材料本身，比直播更能说明一个团队的工程成熟度。洹拓在选型和交付两侧都用同一张五层表，就是为了让这种说明成为默认动作，而不是事后追问。