把大模型写出的代码蒸馏给小模型，最容易丢掉什么？

当教师模型能够连续生成大量代码时，团队很自然会想：把这些代码作为训练数据交给更小的学生模型，能否用更低成本复现同样的软件能力？答案取决于你蒸馏的对象究竟是什么。只复制源代码，通常会丢掉四类关键内容。

第一类：上下文

一段函数依赖的不是函数本身，而是数据结构、版本约束、调用顺序和外部资源。脱离上下文训练，学生可能生成语法正确但无法接入系统的代码。数据集至少要保留模块边界、接口定义和依赖版本。

第二类：失败信息

成功代码最容易被保存，失败尝试却常常被删除。可失败信息说明了哪些方案不能用、哪个条件必须满足。对于图像和视频软件，损坏文件、超大素材、缺少字体和渲染设备差异，都是不能省略的样本。

第三类：测试意图

测试用例不是附属文件，它告诉学生作者想保护什么行为。将断言、边界条件和回归原因一起保存，学生才可能从“实现一个函数”走向“维护一个行为”。

第四类：取舍关系

教师在资源不足时可能选择速度、精度或内存中的一项。学生若只看到最终版本，不知道这个取舍的条件，遇到新任务就会盲目照搬。蒸馏数据需要标记适用范围，而不是把所有代码都当成无条件答案。

怎样设计数据

可以把每条样本组织成任务、上下文、候选实现、失败结果、最终实现和验证方式。学生输出后，使用独立任务检查编译、行为和回归。代码文本相似度只能做辅助指标，不能代替运行结果。

公开报道中，ArtCraft 项目被描述为使用 Claude Opus 5.5 辅助开发七款 Rust 软件替代品，但项目仍处于早期阶段，不能由此推断已经完成了能力蒸馏。它提醒我们，生成工具越强，数据工程和验收反而越重要。

如果学生模型能在新模块、新格式和故障输入下完成修改，并且不破坏既有行为，才可以说迁移了一部分软件能力。否则，它只是更快地复述教师写过的代码。
这件事最值得讨论的，不是一个模型能在几天内生成多少代码，而是生成出来的代码是否真的保留了原软件的行为约束。软件能力包含界面、数据结构、状态变化、错误处理、文件兼容、性能和长期维护。只看截图或菜单数量，无法证明这些能力都已经迁移。

代码样本还要绑定版本

同一个接口在不同版本中可能有不同返回值，旧代码并不一定适用于新依赖。数据集如果不记录提交版本、运行环境和测试结果，学生模型会把互相冲突的实现当成同一答案。

评测时，可以让学生完成一个训练中没有出现过的改动，再运行原有回归测试。若新功能通过但旧功能失败，说明学生只完成了局部生成，没有掌握系统约束。

代码相似度不是能力指标

两段实现可以写法不同但行为相同，也可以文本很像却在边界输入上表现不同。因此，代码蒸馏应把编译、运行、错误处理和回归结果放在相似度之前。

一个可执行的评测样例

假设学生模型要为图像编辑器增加一种导出格式。先给它接口文档和一组正常文件，再给出损坏文件、超大文件和缺少元数据的样本。验收不只看新格式是否导出，还要看原有格式是否仍能打开、失败时是否留下半成品，以及日志能否说明失败位置。

这个过程能把“代码会不会写”转换成“系统行为是否保持”。它也能帮助团队判断哪些监督信号值得加入下一轮训练。

让失败样本真正参与训练

失败样本不能只写成“模型答错了”。还要记录触发条件、错误表现、预期行为和修复后的差异。学生模型看到完整链路，才可能知道哪些做法需要避免，以及怎样验证修复没有带来新的回归问题。

最终报告应同时保存输入、输出和环境信息。没有这些上下文，即使模型下次生成了同样的代码，也无法判断问题来自代码、依赖还是运行条件。

给监督信号加上“适用条件”

同一段代码在桌面端、浏览器端和低内存设备上的要求可能不同。数据集如果只保存实现，不保存运行条件，学生模型会把特定环境下的答案误当成通用方案。

每条样本都标记输入规模、依赖版本和资源限制，能帮助学生理解一个方案为什么在这里成立、换条件后需要怎样调整。

这种标记会让评测结果更接近真实部署，而不是只反映训练环境里的偶然成功。
否则结果很难复现。