PR/issue 不是用来驱动任务的——它们是 Dev 卡住时的后备提示。
如果按 PR 粒度给任务，等于直接告诉 Dev 改什么，任务太简单，轨迹没有训练价值。所以要故意把里程碑粒度做粗，让 Dev 面对一个大的、模糊的开发目标——必须自己探索。
而 PR/issue 的真正价值在于：它们是现成的、ground truth 级别的提示储备。Dev 卡住时，系统只需按粒度逐步释放这些已有信息。不需要 LLM 合成提示——repo 里已经有了。
粗粒度 → 任务难 → 轨迹有价值。PR/issue 作为后备提示 → 保证不会卡死。
| 层级 | 信息来源 | 释放条件 | 示例 |
|---|---|---|---|
| L0 最模糊 | Issue 标题 | 初始就可见（需求背景） | "QuerySet union() 与 annotate() 不兼容" |
| L1 方向级 | Issue 描述 + 复现步骤 | 连续 3 次失败 | "在 union 后调用 annotate，SQL 缺少列投影" |
| L2 模块级 | PR 标题 + 描述 | 连续 5 次失败 | "Fix union/intersection with annotate" |
| L3 文件级 | PR 的文件列表 | 连续 8 次失败 | query.py, compiler.py |
| L4 代码级 | PR diff 关键片段 | 连续 12 次（最后手段） | Query.combine() 第 542 行 |
先设计任务，再收集轨迹
4 个 LLM 角色串行依赖
PM Agent 动态合成提示
每个 Feature 独立执行
任务间无关联
前置设计（靠假设）
先收集轨迹，再提炼任务
2 个 LLM + 规则/脚本
PR/issue 作为后备提示按需释放
沿里程碑持续开发
前序代码是后序的上下文
后置分析（靠数据）
| 维度 | v1 | v2 | 为什么更好 |
|---|---|---|---|
| 设计哲学 | 先设计任务，再收集轨迹 | 先收集轨迹，再提炼任务 | 数据驱动 vs 假设驱动 |
| 核心流程 | 串行耦合 | 三阶段完全解耦 | 任何阶段可独立迭代 |
| LLM 角色 | 4 个 | 2 个 + 规则/脚本 | 复杂度大幅降低 |
| 提示机制 | PM Agent 动态合成 | 粗粒度保证难度，PR/issue 按需释放 | 不需要 LLM 合成提示 |
| Dev 模型 | Sonnet-4.5（外部） | HY3.0（默认）/ Opus-4.6（备选） | 目标模型低成本；强模型高质量轨迹 |
| 失败处理 | 任务失败 → 丢弃 | STUCK → 给提示 → 继续 | 失败本身是训练信号 |
| 最小验证 | 需要全部角色就绪 | Stage 2 单独跑 3 天即可 | 快速 Go/No-Go |
| SWE-bench | SWE-smith | CoderForge | Nebius | HarnessForge v2 | |
|---|---|---|---|---|---|
| 任务类型 | Bug fix | Bug 注入 fix | Bug fix | Bug fix | Feature+重构+fix |
| 轨迹 | ❌ 无 | ✅ 单任务 | ✅ 单任务 | ✅ 单任务 | ✅ 长程连续 |
| 交互 | ❌ | ❌ | ❌ | ❌ | ✅ Mentor 提示 |
| 多语言 | Python | Python | Python | Python | Py/TS/Go/Rust |
| 规模 | 2.3K | 50K | 258K | 80K | 上限极高 |
| Dev 模型 | — | — | 固定 | 固定 | HY3.0（目标模型） |
| 信息密度 | 低 | 中 | 中 | 中 | 高 |
| 规模弹性 | 固定 | 固定 | 固定 | 固定 | Repo×Release×策略 |
有了详细的完整轨迹，筛选出好的 task 不是难事。
每条轨迹里天然包含了所有关键信号：卡住了多少轮、需不需要提示、提示后有没有调整方向、最终是否通过。这些信号是结构化的、可量化的——基本的规则过滤就能完成大部分筛选。
在没有数据的时候设计数据处理流程——这正是 v1 犯过的错误，不能重蹈覆辙。
| 信号 | 如何识别 | 价值 |
|---|---|---|
| 卡点 | 连续 N 次 edit→test→fail，错误类型不变 | 天然的 hard task |
| 方向调整 | 提示前后搜索/编辑的文件发生变化 | "从反馈中调整"的训练数据 |
| 渐进成功 | 测试通过数从 0 → N 逐步增加 | 问题分解和逐步推进 |
| 无效探索 | Dev 走一个方向多轮后回退 | 负样本——什么不该做 |
| 高效路径 | < 15 轮完成，无需提示 | 正样本——什么该做 |
| 输出 | 描述 | 确定程度 |
|---|---|---|
| 完整里程碑轨迹 | 全部 turns，训练长程能力 | 基本确定 |
| 卡点片段 | 从卡住到解决的 10-20 轮 | 基本确定 |
| 按阶段切割 | 探索→规划→编码→debug 各自独立 | 待验证 |
| 更复杂的提炼 | 取决于数据实际长什么样 | 完全待定 |
什么时候做：Phase 1 拿到第一批轨迹后，先人工看 5-10 条，理解数据特征，再设计具体规则。不排除"整条轨迹直接训练效果就很好"的可能性。让数据说话。
一开始让 Dev 自由发挥。拿到数据后，再考虑加 Harness 组件。
| 版本 | 复杂度 | 新增组件 | 何时引入 |
|---|---|---|---|
| V0（当前） | ★ | Dev + Mentor + Recorder | 初始版本 |
| V1 | ★★ | + Plan 要求：Dev 每个里程碑先输出开发计划 | 数据显示 Dev 无规划就动手、频繁返工 |
| V2 | ★★★ | + Plan 审查：计划与 ground truth 对比，偏差大时纠正 | V1 数据显示 Dev 计划质量差 |
| V3 | ★★★★ | + 阶段检查点：每改完一个模块，检查中间状态 | V2 数据显示 Dev 中途偏离但最后才发现 |
关键原则：每一级增强都基于前一级的数据反馈，不预设。
渐进式增强本身也产出高价值训练信号——"plan → 被纠正 → 修正 plan → 执行"的轨迹训练规划和自我修正能力。但这些都是未来选项，先跑通 V0。
选 1 个 repo（Django），3 个里程碑。Docker 环境 + HY3.0 作为 Dev，手动充当 Mentor。记录完整轨迹，人工分析。
成功标准：3 个里程碑的轨迹中，至少提炼出 5 个有训练价值的 task。
编写 milestone_runner.py + mentor_service.py + recorder.py。5 个 repo，~70 个里程碑轨迹。Stage 3 分析脚本：卡点识别 / 试错修正对提取 / 片段切割。
15 个 repo 全量执行。消融实验：长程 vs 单任务、有交互 vs 无交互、HarnessForge v2 vs CoderForge 头对头。RL 训练 + SWE-bench 评测。
| 风险 | 严重程度 | 缓解 |
|---|---|---|
| Dev 在复杂里程碑上完全卡死 | 高 | Phase 1 就能发现；用更强模型做 Dev 备选 |
| 长程轨迹在 RL 训练中不如短任务有效 | 中 | 消融实验验证；Stage 3 片段切割兜底 |
| 上下文窗口溢出 | 中 | 每个里程碑重置上下文 + 保留摘要 |
| Mentor 提示后 Dev 无方向变化 | 中 | Mentor 用 Opus + ground truth；Phase 1 验证 |
| 里程碑依赖太紧，某个失败后续全崩 | 低 | STUCK 时用 verify_commit 强制推进 |
| 预训练数据污染——Dev "记住了答案"而不是在探索 | 高 | 见下方专节讨论 |
我们选的高 star 知名 repo，恰好是预训练数据中覆盖最充分的那批。HY3.0 的训练集里大概率包含了 Django 的每一个 commit、每一条 PR。当我们给它"实现 GeneratedField"的任务时，它可能不是在探索，而是在回忆。
这种轨迹拿去做 RL，强化的是记忆而不是推理能力。
预训练学到的是"知识"，RL 要训练的是"行为"。一个人读过 Django 源码，不代表他能在一个复杂 bug 中高效定位问题。RL 训练的是后者。
✓ 天然 unseen 的信号
✗ 需要警惕的信号
| 阶段 | 措施 | 具体做法 |
|---|---|---|
| Stage 1 Repo 筛选 | 混入低污染 repo | 2025 年底之后新建的 repo（cutoff 之后）、star 500-2000 的小众高质量项目、知名 repo 的最新 release（接近 cutoff 边界） |
| Phase 1 验证 | 直接测量 contamination | 给 Dev 里程碑任务，零提示观察：前 3 轮精准定位 = 疑似记忆；10+ 轮搜索试探 = 较真实。统计比例，超 50% 需调整 |
| Stage 3 轨迹提炼 | contamination 过滤 | 从未走错方向 + 从未需要提示 + 从未回退 → 标记为"疑似记忆"，降低权重或排除 |
| RL 训练 验证 | held-out unseen repo | 留出一组不在任何训练数据中的新项目，作为 RL 效果的真实测量基准 |
坦率的判断：这个风险是真实的，但不是致命的。RL 训练的核心目标是行为策略，不是知识。即使 repo 见过，执行层面的探索行为仍然是新的。通过 repo 选择、Phase 1 测量、Stage 3 过滤，可以量化并控制风险。
最坏情况：即使 contamination 严重，Stage 3 仍然能识别出真实的探索片段——只是量会少一些。
不要在没有数据的时候做优化。
v1 设计了精巧的五角色系统来"合成高质量任务"。这些设计全建立在未经验证的假设上。
退后一步问"最简单的方式是什么？"——让 Agent 直接去开发，把过程录下来，之后再分析。
这和预训练数据的核心经验一致：数据采集和数据筛选应该解耦。没有人试图在爬取阶段就"只爬高质量数据"。v1 犯了同样的错误：在轨迹采集阶段做了任务设计的事。
先采集，再筛选。让数据说话。