CI/CD 失败诊断数据：一个被忽视的万亿 Token 级代码推理数据源
GitHub 上每天有数百万次 CI/CD 构建失败。每一次失败都包含一个完整的「症状→诊断→修复」推理链。本提案提出系统化挖掘这些公开可用的失败日志，构建代码错误诊断的中训练数据。
触发动机
这个想法来自一个很朴素的观察。在追踪代码类 benchmark（SWE-bench、EvoClaw、FeatureBench 等）的过程中，我注意到一个反复出现的失败模式：模型不是”写不出代码”，而是”不会调试”。EvoClaw 的数据尤其有说服力——孤立任务 >80% 但连续设置骤降到 38%，主要因为早期的小错误没被正确诊断。然后我想到：GitHub Actions 每天有数百万次 CI/CD 构建失败，每一次失败都是一个完整的”症状→诊断→修复”推理链——错误日志是症状，diff 是修复，中间的诊断过程可以从两端反推。这是一个规模巨大、公开可用、自带验证信号的数据源，但据我所知还没有人系统性地把它变成训练数据。
战略判断：为什么代码错误诊断是下一个关键能力
能力缺口分析
当前代码模型的核心弱点不是”写不出代码”，而是”不会调试”。
- SWE-bench Verified 最高分约 72%（Claude Opus 4），仍有 28% 的 Issue 无法解决
- 失败原因分析显示，超过 40% 的失败不是”代码写错了”，而是”没有正确定位问题根因”——模型看到错误日志后的诊断推理能力不足
- EvoClaw 的核心发现：模型在连续软件进化中性能悬崖式下降，主要因为错误累积——早期的小错误没被正确诊断，导致后续改动在错误基础上越走越远
数据机会
GitHub Actions 每天执行数百万次 CI/CD 构建。其中约 20-30% 是失败的。每一次失败都是一个天然的”错误诊断训练样本”：
症状：CI 日志中的 error/warning/traceback
诊断过程：开发者看到日志 → 定位问题 → 理解根因
修复：下一个 commit 的 diff（修了什么）
验证：修复后的 CI 是否通过这是一个万亿 Token 级别的公开数据源，但至今没有被系统化利用于模型训练。
重要性评估
- 规模巨大：GitHub 上每天数百万次 CI 失败，数据永远不缺
- 天然可验证：失败→修复→CI 通过，形成完整的闭环验证
- 直接对应能力缺口：SWE-bench 失败案例的 40%+ 可追溯到诊断推理不足
- 与长程任务协同：错误诊断能力是长程代码任务中最关键的子能力
核心洞察
现有代码训练数据的一个结构性盲区：几乎所有数据都是”正确代码”。
- 预训练语料：GitHub 上通过 CI 的代码
- SFT 数据：instruction → 正确代码
- 合成数据：LLM 生成 → 自验证 → 只保留正确的
模型大量见过”对的长什么样”，但很少见过”错的长什么样、为什么错、怎么从错到对”。
CI/CD 失败日志恰好填补这个空白：它是带标注的错误代码，标注来自真实世界的开发者行为（修复 commit），而且有自动化的正确性验证（修复后 CI 通过）。
方法论
数据采集 Pipeline
GitHub Actions Public Logs
↓
Step 1: 失败 Workflow Run 筛选
↓
Step 2: 关联修复 Commit
↓
Step 3: 提取 (日志, 代码上下文, 修复diff)
↓
Step 4: 诊断链合成
↓
Step 5: 质量过滤Step 1：失败 Workflow Run 筛选
GitHub REST API 可以查询公开仓库的 Workflow Runs。筛选条件：
status: failure- 仓库 stars > 50（过滤学生项目和垃圾仓库）
- 失败日志包含 traceback/error/assertion（排除网络超时等非代码问题）
- 日志长度 < 50KB（排除疯狂刷屏的日志）
Step 2：关联修复 Commit
关键的数据工程步骤——如何找到”修好这个 CI 失败”的 commit：
- 同 PR 内的后续 commit：最可靠。PR 中 CI 失败后，开发者推的下一个 commit 大概率是修复
- 时间窗口内的 commit：CI 失败后 24 小时内，同分支的 commit
- CI 状态翻转：找到同分支从 failure → success 的转折点
验证：关联的 commit 之后 CI 确实通过了。
Step 3：三元组提取
每个样本是一个三元组：
{
"failure_log": "CI 失败的完整日志（截断到关键部分）",
"code_context": "失败时的相关代码文件（失败日志中提到的文件）",
"fix_diff": "修复 commit 的 diff",
"fix_commit_message": "开发者写的 commit message",
"ci_result_after_fix": "pass/fail"
}Step 4：诊断链合成
原始三元组缺少”诊断推理过程”。用 LLM 补全：
给定 (failure_log, code_context, fix_diff)，让强模型生成诊断推理链：
1. 症状识别：CI 日志显示 [具体错误]
2. 定位范围：错误出现在 [文件:行号]，涉及 [函数/模块]
3. 根因分析：根本原因是 [具体原因]，因为 [解释]
4. 修复方案：需要 [具体修改]
5. 验证预期：修复后应该 [预期行为]质量控制：合成的诊断链必须与实际的 fix_diff 一致——诊断出的问题必须是 fix_diff 实际修改的部分。不一致 → 丢弃。
Step 5：错误分类与多样性
按错误类型分类，确保训练数据覆盖完整的错误谱系：
| 错误类型 | 预估占比 | 诊断难度 | 训练价值 |
|---|---|---|---|
| 语法/类型错误 | 15% | 低 | 低——模型已经很好 |
| 依赖/版本冲突 | 25% | 中 | 高——常见但模型经常忽略 |
| 逻辑错误（测试失败） | 30% | 高 | 极高——需要理解代码意图 |
| 环境/配置错误 | 15% | 中 | 中——场景特异性强 |
| 竞态/并发问题 | 5% | 极高 | 极高——最稀缺的诊断能力 |
| 性能退化 | 10% | 高 | 高——需要量化分析 |
规模估算
- GitHub 每天 CI 失败次数（可公开获取的）：保守估计 50 万+
- 筛选后（stars>50 + 有效错误 + 日志合理）：~50K/天
- 成功关联修复 commit：~15K/天（30% 关联率）
- 诊断链合成 + 质量过滤（60%）：~9K/天
- 一个月即可产出 ~270K 条高质量错误诊断训练样本
Token 数：平均每条 ~3K tokens（日志 + 代码 + 诊断链 + diff）= ~810M tokens/月
独特价值：为什么这个数据别人很难复制
- 数据源公开但工程壁垒高：GitHub Actions 日志是公开的，但大规模采集、关联修复 commit、质量控制的工程量巨大
- 时效性：新的代码、新的框架、新的错误模式不断涌现，数据集天然保鲜
- 标注免费：开发者通过修复行为提供了免费的”正确答案”标注
- 可验证：CI 从 failure→success 就是客观验证
落地路径
- Week 1：GitHub API 采集 pipeline，先跑 100 个高 star Python 仓库一周的 CI 失败
- Week 2：修复 commit 关联算法，在 1000 条样本上验证关联准确率
- Week 3：诊断链合成 prompt 迭代，确保合成质量
- Week 4：扩展到 Top 5000 仓库，开始量产
- Week 5-6：错误分类 + 配比优化 + 首批数据注入训练实验