从问题案例到训练数据

何时使用

• 生产出现 bad case：用户纠正、点踩、事后审计发现失败轨迹，想把它变成后训练输入
• 判断某类失败该修 Harness/工具/tokenizer，还是值得投入训练
• 构造 DPO 偏好对、轨迹前缀回归任务、决策边界示范
• 决定一个失败案例该进 SFT 数据、DPO 偏好对、PRM 负标签还是 RLVP 惩罚规则
• 训练后验证修复效果，担心"修好一个、弄坏一片"
• 从运行轨迹中提取可学习信号，而不是只存一个总分

核心原则

• 归因到首个错误步骤，不是整条轨迹。 以 Coding Agent "过早结束"为例：读代码、改代码可能都没错，错的是"在缺乏证据时下结论"那一个决策边界。归因记录必须落到这一步，训练数据才能对着它构造。
• 失败轨迹不应直接当作正确的 SFT 示范。 它的正确用法是：构造偏好对、发现任务覆盖缺口，或补上诊断与修复后再加入训练。
• 判定必须靠模型写不了的机制。 "是否完成"要由隐藏测试、状态断言或外部终止钩子给出；测试必须读取真实文件或环境状态，不能只检查模型是否说了"已完成"，否则模型会学会口头承诺验证而不真正验证。
• 边界集与保留集缺一不可。 边界集（任务未完成）看模型是否选择继续验证而非宣称完成；保留集（任务已完成）看模型是否仍能正常收尾。只盯边界集会把模型训练成永远不敢结束的过度矫正状态：每个任务都无限验证下去，延迟与成本崩溃。这是"改动不能破坏既有行为"在参数层面的版本。
• 训练与评估严格隔离。 训练集与评估集必须是不同的任务、不同的参数、不同的模板组合；参考解法、隐藏测试和验证器反馈不能泄露给模型。隔离规则应由单元测试强制检查，而不是靠人记得。
• 先排除非模型原因。 沿"文件原始字节 → 工具返回 → Harness 序列化 → 模型上下文 → 模型 token 输出 → 解码字符串 → JSON/tool-call 解析 → 工具匹配"逐层对比。只有模型收到的上下文与原始字符串完全一致、而模型输出是链路上首个出现差异的位置，才能标为模型能力问题。否则修工具/Harness/tokenizer，修完再看还剩多少。
• 小数据 DPO 必须混入通用任务数据。 案例数量少时，按小配比混入通用任务做 LoRA 微调，避免把"逢收尾必验证"学成新的过拟合，也降低灾难性遗忘风险。
• 学习信号必须带证据。 单一总分无法指出该改哪里。可供学习的评价至少包含：任务成功/部分成功/失败、每个维度各自的结论、每条结论对应的证据位置（哪一轮对话、哪一次工具调用）、失败的类型标签。验证器还应被允许在证据不足时拒绝评分, , 低置信度案例应排除在学习集之外，而不是当作事实固化。

实践模式

完整链路：失败归因 → 双集验证

① 采集与归因。 从用户纠正、点踩、事后审计三类生产信号收集失败轨迹，按错误分类定位首个错误步骤并记录错误类别。轨迹前缀回归任务就是从这个决策边界截取的。

② 分流：该不该训练。 先问 prompt、工具、代码约束、上下文管理能否解决；再沿字节链路排除工具/Harness/tokenizer 问题。都不要动权重时就不训练。

③ 选训练形态。 按第七章评估数据集的类型映射到第八章用法：

你手上的材料	训练用法
端到端回归任务（含验证器）	RL rollout 任务与可验证奖励（RLVR）；拒绝采样（RFT）的采样池
轨迹前缀回归任务	DPO 偏好对、决策边界的 SFT 示范、On-Policy Distillation 的教师状态
失败归因记录（首个错误步骤与错误类别）	过程监督的负标签（PRM）、RLVP 路径惩罚的规则来源
Rubric 多维评分与人工金标集	向量奖励的各维度、生成式奖励模型（GRM）的训练与校准数据

④ 截取轨迹前缀，构造偏好对。 在决策边界上截出"准备宣称完成"的轨迹前缀：rejected 是过早结束的错误行为，chosen 是"先运行测试、逐条核对验收条件，再下结论"的期望行为。chosen 由教师模型生成，再经规则验证器过滤（拒绝采样）。案例太少时用数据扩充（换任务类型、换缺失的验证项、换完成措辞）形成数百条偏好对。失败原因、适用条件和验证器应随样本保存，方便追溯和复查。