Coding 数据
仓库级 Coding 任务应该交付什么
一份仓库级 Coding 任务的价值在于接收方能还原起点 理解要完成的改动 并独立判断补丁是否满足要求 交付清晰的任务边界比单纯增加代码量更重要
先固定任务起点
使用明确的仓库版本和任务说明作为起点 记录 Agent 可修改的文件范围以及运行所需依赖 仅提供持续变化的分支名会让复验难以区分模型错误与仓库变化
SWE-bench 的原始评测围绕仓库 Issue 修复展开 可以参考其任务组织方式 但不能据此把公开评测样本表述为自有训练数据
把交付拆成五个部分
要求交付清单能够定位每个组成部分 将任务输入与参考补丁 私有验收测试分开 这样既能核验完整性 也能避免在执行前把答案暴露给 Agent
| 组成部分 | 检查问题 |
|---|---|
| 仓库快照 | 能否还原到指定版本 |
| 任务说明 | 预期行为与修改边界是否明确 |
| 环境清单 | 运行依赖与初始化命令是否固定 |
| 补丁与轨迹 | 代码改动能否关联到本次执行 |
| 验收证据 | 独立审查者能否重新执行检查 |
用分页修复理解验收边界
以下为自拟场景 并非商业数据样本 某事件 API 的连续分页出现重复记录 任务需要说明排序规则 游标约定以及多条记录时间相同时的处理方式 验收关注这些条件下的稳定分页
先在修改前复现已知问题 再检查修复结果及空页 缺失游标等相邻情况 保留原始测试报告 即使目标测试通过也能识别新引入的回归问题
先排除环境问题再评价补丁
依赖下载失败不能直接证明补丁错误 需要把初始化失败和代码失败分别记录 保留镜像标识 初始化日志 测试命令 退出状态与证据位置 让结论可以追溯
首批验收可覆盖不同仓库和依赖模式 对选中的任务分别检查一次干净环境恢复与独立补丁复验 在扩大交付规模前约定不可用依赖的处理方式
- 明确训练任务与留出评测任务的边界
- 同时记录任务版本与验证器版本
- 核查源码及衍生产物的允许用途