AI 给一个 PR 留下十条评论，开发者逐条看完，发现八条不用改。机器人很忙，代码审查却没有变快。

如果把这些评论原样拿去训练小模型，问题还会被放大：大模型偶尔猜错，小模型可能把猜错的方式学得很熟。

代码审查知识蒸馏的起点，是把经过验证的审查结果整理成样本。 大模型负责提出候选问题，测试与人工复核确认问题是否成立，小模型学习其中可重复的判断。能否降低成本，要再用未参与训练的 PR 验证。

2026 年 10 月 12 日，Vapi 发布了自研代码审查机器人的工程复盘。公司称，PR 从创建到合并的平均时间由超过 130 小时降至 65 小时。这篇复盘没有报告知识蒸馏实验，但它提供了一个值得借鉴的前置条件：让机器人证明自己的发现。

1. 先看清热点里的数据，别把提速当成蒸馏效果

Vapi 的机器人可以检查调用方、运行测试或写小型复现，再决定是否报告问题。分析任务和发评论任务分开执行：前者移除 Git 凭证，输出 JSON；后者验证文件并发布评论，不执行机器人生成的代码，也不能批准或推送。

这套设计同时解决了两个问题：评论要有证据，读取不可信代码的模型不能直接拿到发布凭证。

复盘还报告，在 2026 年 9 月 2 日至 10 月 2 日期间，机器人审查了 1,694 个 PR，在 276 个 PR 上提出 363 个 blocker 发现。其中超过一半与构建、测试、CI 或部署有关。这里的“提出”不能改写成“确认修复了”：作者明确说，活动报告尚未跟踪开发者采纳或驳回了哪些发现。

130 多小时到 65 小时，是这家团队报告的前后变化。PR 规模、人员安排、排队时间等因素也会影响结果，文章没有给出能隔离这些因素的对照实验。因此，不能用它承诺自己的审查时间也会减半，更不能说“小模型蒸馏后提速一倍”。

对蒸馏有用的启发更具体：先把候选评论变成可核验的缺陷记录，再考虑训练。

2. 小模型究竟要学什么？先缩到一类缺陷

“训练一个懂整个仓库的审查专家”很容易把项目做大。Vapi 的 blocker 有一半以上集中在构建、测试与 CI，说明这类问题既常见，又容易用工具取得证据，适合作为第一轮任务。第一轮更适合挑选一种输入边界清楚、证据容易获取的任务，例如判断新增测试是否真的被测试框架收集，或识别一类固定的鉴权遗漏。

本文用“测试没有被收集”做演示，以下样本和结果均为设计示例，未进行模型训练。

假设 PR 新增了 tests/payment_cases.py。仓库配置只收集 test_*.py 文件。CI 最终显示绿色，但这个新文件根本没有运行。

仅给模型文件里的断言，它可能觉得测试写得不错。给它测试收集配置、变更路径和实际收集结果，才有机会发现真正的问题。

这说明蒸馏输入必须包含推断所需的证据。如果教师能读取整个仓库并执行命令，而学生线上只收到一段 diff，那么两者面对的任务已经不同。训练集里的正确答案无法补上线上缺失的配置。

可以把工作拆成两段：固定程序负责收集路径、配置和测试清单；模型负责综合信息并生成简短说明。对于能用确定规则直接判断的部分，优先使用规则。没有必要为了蒸馏，把简单的文件匹配也交给模型。

3. 一条可用样本，要留下怎样的证据？

下面是内部记录结构示意，不是某个训练框架可以直接导入的格式：

{
  "sample_id": "demo-review-001",
  "repo_snapshot": "demo-commit-a",
  "task": "test_collection_review",
  "input": {
    "changed_file": "tests/payment_cases.py",
    "collection_rule": "test_*.py",
    "collected": false
  },
  "teacher_candidate": {
    "label": "test_not_collected",
    "summary": "新增测试文件不符合收集规则，未被执行。"
  },
  "verification": {
    "method": "test_collection_check",
    "result": "confirmed",
    "human_review": "accepted"
  },
  "target": {
    "label": "test_not_collected",
    "summary": "将文件重命名为符合 test_*.py 的名称，并重新检查收集清单。"
  }
}

collected: false 是工具已经得到的结果。若线上也提供这个字段，学生主要学习解释与建议，不能宣称它独立发现了未收集测试。若目标是让学生在执行前预测风险，就应设计另一套输入和评测，不把执行后的答案放进输入。

训练前再把记录转换成框架需要的输入与目标格式。教师评论、验证状态、人工结论属于溯源信息；学生输入只保留上线时实际能够取得的字段。

通常值得保留的还有：教师模型与版本、提示词版本、证据对应的仓库快照、缺陷是本次新增还是原有、适用的数据授权范围。模型更新或仓库规则变化后，这些信息能帮助定位数据为何失效。

涉及企业源码时，先确认代码可发送到所用服务，模型输出可用于目标训练用途。API 可以调用，不等于输出自动获得训练授权。

4. 教师说得像真的，也可能是误报

Vapi 做过一个有意思的实验：在同一个 PR 上测试 101 个开头指令，得到 803 条原始发现，归并成 57 个不同问题。一个不知道各问题出现频次的 AI 评判器将其中 32 个判为真实、24 个判为错误，1 个无法验证。

复盘还提到，任何单次运行找到的真实问题都不超过 32 个中的 10 个：只采样一次会漏掉大量问题。

这不是跨仓库的准确率，也不是人工最终裁决。作者明确提醒：每个提示词只跑一次，实验只有一个 PR，判断者还是 AI。

但它暴露了数据清洗里的常见陷阱：同一个错误被反复说出，并不使它变成真问题。多次采样的结果可能高度相关，不能把“多数教师都同意”当成证据闭环。

建议为候选记录保留四种状态：

状态	含义	第一轮训练如何处理
confirmed	复现、测试或代码证据支持，且完成复核	作为正样本候选
rejected	有明确反证，或不符合任务定义	作为已标注负样本候选
inconclusive	证据不够，暂时不能判断	暂不进入确定标签集合
out_of_scope	可能成立，但不属于本次任务	单独保存，不混入目标标签

“开发者没有回复”不等于 rejected；“CI 绿色”也不等于没有缺陷。负样本应当来自确认满足目标规则的改动，以及有反证的误报。否则学生容易学成一个到处挑毛病的机器人。

复现任务本身也要有权限边界。未知 PR 的测试脚本应在隔离环境中运行，移除敏感凭证，限制网络和写入范围。证据采集不能成为代码获得更高权限的机会。

5. 从样本到蒸馏实验，最容易漏的是数据拆分

用经过验证的教师答案做监督微调，属于输出层面的蒸馏（DeepSeek-R1 的蒸馏模型就采用这类路线）。路线成立，不代表代码审查任务会自动受益。

训练技术可从所选开源模型支持的 SFT 或 LoRA 方案开始，但先把评测设计好。

PR 里的文件、同一缺陷的不同评论、重跑记录，经常互相重复。如果随机按评论划分，训练集见过的问题可能以另一种措辞进入测试集，分数会显得很好。

至少做到：同一个 PR 及其重跑记录在同一分区；同一缺陷的近似样本聚合后再拆分；需要测试时间泛化时，用较早的数据训练、较新的数据测试。若目标是服务多个仓库，再额外做仓库之间的留出评估。

比较四个候选方案：规则程序、未经微调的学生、蒸馏后的学生、教师方案。给各模型可比的输入和工具权限，冻结测试集和判断规则。若教师独享额外工具，单独标明，这是系统差异，不能只归因于模型大小。

学生上线前先“影子运行”：生成结果并记录，由人检查，暂不自动向 PR 发评论。这个阶段最适合发现它是否学会了准确说“不需要报告”。

6. 怎么判断值得部署？同时看漏报、误报和总成本

以下是演示数据：留出集有 100 个独立 PR，经复核存在 20 个目标缺陷。学生报告 25 个去重后的缺陷，其中 15 个正确、10 个错误，还漏掉 5 个目标缺陷。

• 精确率为 15 / 25 = 60%，表示发出的发现有多少成立。
• 召回率为 15 / 20 = 75%，表示目标缺陷找回了多少。

计数单位是缺陷；同一 PR 可以包含多个缺陷。实际评测还要约定位置匹配、重复发现归并方式，否则不同方案的数字无法比较。

60% 的精确率意味着开发者仍要核查不少误报。对于影响付款、权限或部署的缺陷，漏掉一个严重问题可能比多报几条轻微问题更昂贵，不能只按总准确率选模型。

还应记录每个 PR 的人工核查时间、端到端 P95 延迟、工具执行成本，以及升级给教师的比例。

上线成本可以拆为：学生推理、证据工具、教师兜底、人工复核；项目成本另加样本生产、训练和后续维护。减少模型调用费用，却让开发者多花十分钟看评论，未必划算。

可以从简单规则开始升级：缺少关键上下文、出现未覆盖的缺陷类型、涉及高影响代码时交给教师或人工。学生自己给的“置信度 0.95”不能直接当成 95% 正确率，阈值需要用验证集校准。

7. 第一轮实验，交付这四样就够了

选定一个缺陷类型后，先完成：固定输入规范、带证据的正负样本、无泄漏的留出集，以及规则／学生／教师对照报告。样本规模根据缺陷频率和学习曲线调整，不存在通用的“收集一千条就够了”。

若规则已经能稳定解决问题，就保留规则。若蒸馏后的学生减少了核查成本，又没有突破严重漏报的接受范围，再逐步扩大任务。

Vapi 的案例值得学的是让评论接受检验。沿着这一步继续走，代码审查记录才可能成为知识蒸馏的数据资产；跳过验证，只会把一份嘈杂的评论历史训练成另一个嘈杂的审查员。

作者注：本文作者来自 147AI 团队。文中流程与具体接入平台无关；无论通过哪家服务调用教师模型，都需要单独核对模型可用性和输出训练授权。

参考资料

1. Vapi：AI 代码审查机器人工程复盘（Amanda Martin），2026 年 10 月 12 日。
2. DeepSeek-R1 官方仓库与许可说明。