代码领域长上下文数据构建：从文件级到仓库级
系统梳理代码大模型长上下文训练数据的构建方法，覆盖预训练数据组织、仓库级对齐、SWE Agent 训练数据合成三条路线
代码领域长上下文数据构建：从文件级到仓库级
覆盖范围：预训练数据组织 · 仓库级上下文对齐 · SWE Agent 训练数据合成
核心论文：12 篇关键工作
时间跨度：2024.01 — 2026.03
Tuntang 研究 | 2026.04.01
目录
第一部分：问题框架
第二部分：预训练阶段的数据组织 3. 仓库级语料构建：DeepSeek-Coder 路线 4. 跨文件依赖与 Fill-in-the-Middle 5. 长上下文窗口的扩展策略
第三部分：对齐阶段的仓库级数据 6. COLA：跨文件上下文对齐 7. SWE-QA-Pro：仓库级理解合成管线 8. 代码长上下文的能力瓶颈
第四部分：SWE Agent 训练数据合成 9. SWE-Gym：第一个 Agent 训练环境 10. SWE-smith：大规模 Bug 合成 11. DeepSWE：纯 RL 路线
第五部分：总结与展望 12. 方法论对比与选型建议 13. 展望：代码长上下文数据的下一步
一、代码长上下文为什么难
代码的长上下文与自然语言有本质区别。一段自然语言文本中的远距离依赖通常是语义层面的——指代消解、话题延续。而代码中的远距离依赖是结构性的：一个函数调用可能跨越 5 个文件、3 层抽象，不理解调用链就无法正确补全一行代码。
这种结构性带来三个数据层面的挑战：
挑战一：信息密度不均匀。 一个仓库中 80% 的文件对当前补全任务可能毫无关联，真正有用的跨文件上下文可能只有几十行——但它散落在几个不同文件中。模型需要从 128K token 的上下文里精确定位这些碎片。
挑战二：依赖关系是隐式的。 Python 的 import 只是最表层的依赖声明。真正的依赖链涉及继承关系、回调注册、配置文件引用、运行时动态分发。这些在训练数据的纯文本形式中几乎不可见。
挑战三：评估需要执行。 代码的正确性可以通过测试验证——这是代码领域相对于自然语言的巨大优势，但也意味着数据构建管线需要搭建可执行环境，成本远高于文本数据。
LONGCODEU (Li et al., 2025) 的实证数据直接印证了这些挑战：当代码长度超过 32K token，所有主流长上下文模型的性能都急剧下降，即使它们声称支持 128K 甚至 1M 的上下文窗口。其中最难的任务类别是”代码单元间关系理解”——正是跨文件依赖解析的核心能力。
二、三层数据需求
代码长上下文的数据需求可以分为三个递进层次，每层的构建方法和成本都有质的不同：
| 层次 | 目标 | 数据形态 | 典型规模 | 关键方法 |
|---|---|---|---|---|
| 预训练 | 建立跨文件语义理解 | 仓库级代码语料 | 万亿 token | 依赖排序、FIM、长窗口 |
| 对齐 | 强化跨文件上下文利用 | 仓库级指令数据 | 十万级样本 | COLA、合成管线 |
| Agent | 学习仓库级任务解决 | Agent 轨迹数据 | 万级实例 | Bug 合成、RL 环境 |
这三层的关系是：预训练建立”能读懂”代码的基础，对齐教会模型”主动利用”跨文件信息，Agent 训练则让模型学会在真实仓库中”做事”。当前的瓶颈主要在第二和第三层——预训练数据已经不缺量，缺的是让模型真正学会跨文件推理的高质量对齐和 Agent 数据。
三、仓库级语料构建：DeepSeek-Coder 路线
DeepSeek-Coder (Guo et al., 2024) 为代码预训练数据构建建立了一个标准范式。其核心不是简单地将 GitHub 代码按文件拼接，而是在仓库级别做了精细的数据工程。
数据规模与组成
- 总量：2 万亿 token，87% 代码 + 13% 自然语言（英文和中文）
- 来源：GitHub 公开仓库，经过 StarCoder Data 同源过滤规则
- 上下文窗口：16K token
仓库级文件排序
DeepSeek-Coder 的关键创新在于文件排序策略。不是随机拼接同一仓库的文件，而是：
- 解析依赖图：分析仓库内文件之间的
import关系，构建依赖有向图 - 拓扑排序：按依赖顺序排列文件——被依赖的文件排在前面
- 上下文窗口内打包：将排序后的文件序列打包进 16K 的训练窗口
这种排序的意义在于：模型在训练时看到的文件顺序与它们的逻辑依赖关系一致。当模型学习预测某个文件中的代码时，它所需要的依赖定义已经出现在上文中。
局限性
这种方法本质上是在预训练阶段用数据组织来隐式教模型理解依赖关系。但它有几个固有局限：
- 静态依赖 ≠ 运行时依赖：
import声明只是冰山一角 - 16K 窗口的物理限制：大型仓库的完整上下文远超 16K
- 缺乏显式的跨文件任务：模型只是在”看”跨文件代码，并没有被要求”用”跨文件信息
四、跨文件依赖与 Fill-in-the-Middle
Fill-in-the-Middle (FIM) 是代码预训练中的核心数据增强策略。标准的 FIM 将一段代码分成前缀(prefix)、中间(middle)、后缀(suffix) 三部分，训练模型根据前缀和后缀预测中间部分。
从文件级到仓库级 FIM
传统 FIM 在单文件内操作。要让它服务于长上下文能力，需要扩展到仓库级：
Dataflow-Guided Retrieval (ACL 2024) 提出基于数据流分析的跨文件上下文检索。不同于简单的 import 关系或文本相似度，它分析变量的定义-使用链（def-use chain），找到与补全目标真正相关的跨文件代码片段。
这启发了一种数据构建范式：在构建 FIM 训练样本时，用数据流相关性而非物理距离来选择上下文。一个函数调用的参数类型定义可能在另一个文件里——传统的文件拼接策略未必能把它纳入上下文窗口，但数据流引导的检索可以。
BigCode / StarCoder 的实践
StarCoder 系列的实践表明，将 FIM 与长上下文结合时有两个关键发现：
- 更长的上下文 = 更低的困惑度：在仓库级代码上，增加上下文长度带来的困惑度下降比自然语言更显著——因为代码的远距离依赖是确定性的
- 仓库边界很重要：跨仓库拼接的效果远不如仓库内拼接，因为前者引入了不相关的噪声依赖
五、长上下文窗口的扩展策略
从 2K 到 16K 到 128K，代码模型的上下文窗口在持续扩展。但对于代码领域，这不仅仅是位置编码外推的问题——更核心的问题是：有没有足够长的、有意义的代码训练数据来填满这个窗口？
仓库打包策略
一个常见做法是将多个相关文件打包成长序列。但”相关”的定义很关键：
- 按目录结构打包：简单但有效，同目录文件往往有高内聚性
- 按调用图打包：更精确，但需要静态分析基础设施
- 按 commit 历史打包：将经常一起修改的文件打包，捕获隐式协作关系
稀疏注意力的必要性
当上下文扩展到 128K+，代码中的跨文件依赖呈现出高度稀疏的注意力模式：模型只需要关注几个关键位置（API 定义、类型声明、配置项），而非整个上下文。
LongCoder (Guo et al., 2023) 验证了这一点，提出了稀疏 Transformer 架构来处理长代码输入。但从数据构建的角度看，更有意义的启示是：我们可能不需要真的把所有相关文件都塞进上下文——而是需要教模型识别和检索最关键的跨文件片段。
六、COLA：跨文件上下文对齐
aiXcoder-7B-v2 (Li et al., 2025) 提出了 COLA (Code Long-context Alignment)，第一个专门解决”模型看到了跨文件上下文但不会用”这个问题的数据驱动方案。
问题诊断
研究者发现一个令人不安的现象：即使将正确的跨文件上下文放进模型的输入窗口，模型仍然倾向于依赖本地上下文（当前文件的邻近代码）来做预测。这种预训练与仓库级补全之间的错位是可量化的——模型对远距离跨文件上下文的注意力权重显著低于对本地上下文的。
COLA-132K 数据集构建
COLA 的解决方案是构建专门的对齐数据：
步骤 1：识别跨文件依赖。 扫描仓库中的代码，找出所有显式调用了跨文件 API 或引用了跨文件类型的位置。
步骤 2：构造”上下文感知代码”训练样本。 每个样本包含：
- 来自多个文件的跨文件上下文（最长 128K token）
- 一段必须参考跨文件上下文才能正确生成的目标代码
步骤 3：两阶段训练。
- 第一阶段：继续预训练，让模型适应长跨文件输入
- 第二阶段：对齐微调，显式训练模型关注和利用远距离上下文
效果
在 COLA-132K 上训练后，aiXcoder-7B 在仓库级代码补全的精确匹配率提高了 19.7%。更重要的是，这种能力可以跨语言泛化——在 Python 数据上训练，Java 和 TypeScript 上也有提升。
这说明”利用跨文件上下文”是一种通用能力，不限于特定编程语言。
我的评论
COLA 的价值在于它诊断了一个被忽视的问题：预训练不等于对齐。模型在预训练中”看到”了跨文件代码，但没有被显式训练去”使用”它。这与自然语言领域的 RLHF 逻辑一致——预训练建立能力基础，对齐阶段激活和引导这些能力。
COLA-132K 的构建方法——通过静态分析找到跨文件依赖点，然后围绕这些点构造训练样本——是一个可推广的范式。
七、SWE-QA-Pro：仓库级理解合成管线
SWE-QA-Pro (Cai et al., 2026) 从评估角度切入，但其可扩展合成数据管线同样有数据构建的启示。
核心问题
现有的代码理解评估和训练数据有两个致命问题：
- 头部偏差：集中在 PyTorch、Django 等流行仓库，模型可以靠记忆而非推理来”作弊”
- 主题不均衡：某些任务类型（如简单函数补全）过度代表，复杂的跨文件推理任务不足
合成数据管线
SWE-QA-Pro 提出的管线有两个关键设计：
问题驱动的聚类：不是随机生成任务，而是先对可能的任务类型做聚类，确保每个类别都有足够代表。
难度校准：过滤掉不需要仓库探索就能回答的简单问题。在基准测试中，Agent 工作流比直接回答高出约 13 个百分点——证明这些问题确实需要跨文件探索能力。
两阶段训练
利用合成数据的两阶段训练：
- SFT：用合成的仓库级 QA 数据做有监督微调
- RLAIF：用 AI 反馈做强化学习进一步优化
效果：Qwen3-8B 经此训练后超越了 GPT-4o，证明小模型+高质量仓库级数据可以打败大模型+通用训练。
八、代码长上下文的能力瓶颈
在讨论更多数据构建方法之前，值得梳理当前代码模型在长上下文上的真实能力边界。
LONGCODEU 的发现
LONGCODEU (Li et al., 2025) 从四个维度评估长代码理解：
| 维度 | 说明 | 代表性任务 | 最佳模型表现 |
|---|---|---|---|
| 代码单元感知 | 识别代码中的实体 | 函数/类定位 | 较好 |
| 单元内理解 | 理解单个单元的语义 | 函数功能总结 | 中等 |
| 单元间关系 | 理解跨单元依赖 | 调用链追踪 | 最差 |
| 文档理解 | 理解代码+文档组合 | API 文档问答 | 中等 |
关键发现：32K 是一个分水岭。在 32K 以下，主流模型表现尚可；超过 32K，所有模型性能急剧下降。这意味着当前的预训练和对齐数据在 32K+ 的代码上下文上严重不足。
RepoQA 的补充发现
RepoQA (Liu et al., 2024) 评估了 26 个模型在仓库级代码理解上的表现：
- 最好的开源模型和闭源模型之间仍有差距
- 不同编程语言的难度差异显著——Python 最容易，Rust 最难
- 模型在长上下文中的”迷失”现象与自然语言中的 “lost in the middle” 一致
这些发现指向一个明确的结论：代码长上下文的数据构建还远未解决，尤其是 32K+ 区间的跨文件推理数据。
九、SWE-Gym：第一个 Agent 训练环境
SWE-Gym (Pan et al., 2024) 是代码 Agent 训练数据的开创性工作。在此之前，SWE 领域只有评测基准（SWE-bench），没有训练环境。
环境构建
SWE-Gym 的核心贡献是构建了可执行的训练环境：
- 2,438 个任务实例，来自真实的 Python 仓库
- 每个实例包含三个要素：
- 一个可执行的代码库（带运行时环境）
- 单元测试（用于验证任务是否完成）
- 自然语言任务描述
训练方法
SWE-Gym 支持两种训练范式：
有监督微调：收集强模型（如 GPT-4）在这些任务上的 Agent 轨迹，用于微调较小的模型。
验证器训练：在 Agent 轨迹上训练验证器，用于推理时的自我验证。
效果
- SWE-Bench Verified 上达到 32.0% 解决率
- 相比未训练基线，绝对提升 19%
- 将微调后的 Agent 与验证器结合，进一步提升性能
数据构建视角的启示
SWE-Gym 的核心洞察是：代码 Agent 的训练数据不能只有静态的代码片段，需要包含完整的交互轨迹——模型如何搜索文件、如何阅读代码、如何定位 bug、如何验证修复。这种轨迹数据的信息密度远高于传统的代码补全数据。
但 2,438 个实例显然不够。
十、SWE-smith：大规模 Bug 合成
SWE-smith (Yang et al., 2025) 解决了 SWE-Gym 的规模瓶颈——从 2K 级扩展到 50K 级。
核心思路：反转问题
传统的 SWE 数据集收集方式是找真实的 bug report 和对应的 fix commit。这个过程极度依赖人工，难以扩展。
SWE-smith 反转了这个思路：不是从 bug 到 fix，而是从正确代码出发合成 bug。
Bug 合成策略
给定一个 Python 仓库，SWE-smith 的流程：
- 构建执行环境：为仓库搭建可运行的 Docker 环境
- 选择变异目标：识别有测试覆盖的代码区域
- 应用变异策略：
- 语法变异（修改运算符、交换参数）
- 语义变异（修改逻辑分支、删除边界检查）
- 结构变异（修改继承关系、改变调用顺序）
- 验证变异：确保变异后的代码能让原有测试失败
- 生成任务描述：根据失败的测试和变异位置，生成自然语言的 bug 描述
数据规模
- 50,137 个任务实例
- 来自 128 个 GitHub 仓库
- 比 SWE-Gym 大一个数量级
训练效果
SWE-agent-LM-32B，在 SWE-smith 数据上训练后：
- SWE-bench Verified Pass@1 达到 40.2%
- 开源模型 SOTA
我的评论
SWE-smith 的”合成 bug”范式有一个优雅的对称性：真实的 bug 是无意引入的，SWE-smith 有意地引入——但对训练模型来说，两者在功能上等价。测试用例提供了天然的验证信号，不需要人工标注。
但这种方法也有局限：合成的 bug 可能缺乏真实 bug 的多样性（真实 bug 往往涉及对需求的误解、异步竞态等更复杂的原因）。我推测，将 SWE-smith 的合成数据与少量真实 bug 数据混合训练，效果会优于纯合成。
十一、DeepSWE：纯 RL 路线
DeepSWE (Together AI, 2025) 走了一条不同的路：完全依赖强化学习（RL），不使用 SFT。
方法
- 基础模型：Qwen3-32B
- 训练环境：R2E-Gym 提供的高质量 SWE 环境
- 训练信号：纯 RL——测试通过即奖励，测试失败即惩罚
- 无需人工标注或轨迹示范
效果
DeepSWE 在 SWE-Bench Verified 上达到了与 SWE-smith 接近的性能，但完全不依赖有监督数据。
数据构建视角的启示
DeepSWE 的成功暗示了一个重要趋势：对于有执行环境的代码任务，RL 可能逐步替代 SFT 成为主要训练范式。 这意味着数据构建的重心会从”构建大量的标注轨迹”转向”构建高质量的执行环境和奖励信号”。
构建环境的成本不低——每个仓库需要搭建可复现的执行环境、维护测试套件。但一旦环境就绪，RL 可以自动生成无限的训练数据。
十二、方法论对比与选型建议
| 方法 | 阶段 | 数据规模 | 构建成本 | 核心创新 | 适用场景 |
|---|---|---|---|---|---|
| DeepSeek-Coder | 预训练 | 2T token | 低（自动化） | 依赖排序+FIM | 代码基座模型 |
| COLA-132K | 对齐 | 132K 样本 | 中（需静态分析） | 跨文件上下文对齐 | 仓库级补全增强 |
| SWE-QA-Pro | 对齐 | 合成+长尾 | 中 | 问题聚类+难度校准 | 仓库级 QA 能力 |
| SWE-Gym | Agent | 2.4K 实例 | 高（需执行环境） | 首个 Agent 训练环境 | Agent 微调种子数据 |
| SWE-smith | Agent | 50K 实例 | 中（自动 bug 合成） | 反转合成 | Agent 大规模训练 |
| DeepSWE | Agent | 环境驱动 | 高（需环境） | 纯 RL 无 SFT | Agent RL 训练 |
选型建议：
- 如果在训练代码基座模型：DeepSeek-Coder 的仓库级数据组织已是行业标准，关键在于数据量和质量
- 如果在增强已有模型的仓库级能力：COLA 的跨文件对齐数据是投入产出比最高的方案
- 如果在训练 SWE Agent：SWE-smith 提供了规模化的起点，但应考虑补充真实 bug 数据
- 如果有充足的计算资源：DeepSWE 的纯 RL 路线可能是未来方向
十三、展望：代码长上下文数据的下一步
趋势一：从静态补全到动态交互
当前的大部分工作还停留在”给定上下文，补全代码”的范式。但真实的开发场景是动态的：开发者不断地浏览文件、搜索定义、阅读文档、运行测试。
下一步数据需要的是完整的开发会话轨迹——不仅包含最终的代码变更，还包含开发者如何在仓库中导航、如何理解代码库。这类数据可以从 IDE 遥测数据中提取，但涉及隐私和许可问题。
趋势二：执行环境即数据工厂
SWE-smith 和 DeepSWE 的成功表明，可执行环境比静态数据更有价值。环境可以无限生成训练信号——每次 bug 合成、每次测试执行都是一个新的训练样本。
这个方向的技术挑战在于：如何高效地为大量仓库构建和维护执行环境？当前的做法（Docker 容器化）对每个仓库都需要单独配置，成本不低。
趋势三：跨语言和跨模态
当前的仓库级数据几乎全部集中在 Python 上——因为 Python 的测试生态最成熟。但真实的软件系统通常涉及多种语言（前端 TypeScript、后端 Go、基础设施 Terraform）。
多语言仓库级数据的构建是一个尚未被充分探索的方向。难点在于：不同语言的静态分析工具、测试框架、执行环境差异很大。
此外，仓库理解还需要代码之外的模态：文档（README、设计文档）、Issue 讨论、PR Review 评论、CI/CD 日志。这些都是跨文件推理的重要信息源，但当前的训练数据几乎没有包含它们。
趋势四：代码+推理的融合
随着长链推理（Long CoT）模型的发展，代码领域的一个有趣方向是在代码补全/修复任务中引入显式的推理链。不仅要生成正确的代码，还要生成”我为什么这样写”的推理过程——这需要构建带有推理标注的代码数据。
SWE-QA-Pro 已经在这个方向上迈出了第一步（要求模型在解决任务时展示推理过程），但推理链的质量和验证仍是未解决的问题。
我的判断
短期（6 个月内）最有价值的方向：
- COLA 式的对齐数据扩展到更多语言——Java、Go、TypeScript 都有大量的开源仓库和测试套件，技术上可行
- SWE-smith + 真实 bug 的混合训练——结合合成数据的规模和真实数据的多样性
- IDE 遥测数据的挖掘——如果能解决隐私问题，这是最自然的”人类如何在仓库中推理”的数据源
中期（1-2 年）的关键突破点：
- 自动化环境构建——让任意仓库都能零配置地变成 RL 训练环境
- 多模态仓库理解数据——将代码、文档、Issue、CI 日志统一建模
- 代码推理链的自动验证——不仅验证最终代码是否正确，还验证推理过程是否合理
参考文献
- Guo et al. “DeepSeek-Coder: When the Large Language Model Meets Programming.” arXiv:2401.14196, 2024.
- Li et al. “aiXcoder-7B-v2: Training LLMs to Fully Utilize the Long Context in Repository-level Code Completion.” arXiv:2503.15301, 2025.
- Li et al. “LONGCODEU: Benchmarking Long-Context Language Models on Long Code Understanding.” arXiv:2503.04359, 2025.
- Liu et al. “RepoQA: Evaluating Long Context Code Understanding.” arXiv:2406.06025, 2024.
- Pan et al. “Training Software Engineering Agents and Verifiers with SWE-Gym.” arXiv:2412.21139, 2024.
- Yang et al. “SWE-smith: Scaling Data for Software Engineering Agents.” arXiv:2504.21798, 2025.
- Cai et al. “SWE-QA-Pro: A Representative Benchmark and Scalable Training Recipe for Repository-Level Code Understanding.” arXiv:2603.16124, 2026.
- Together AI. “DeepSWE: Training a Fully Open-sourced, State-of-the-Art Coding Agent by Scaling RL.” 2025.
- ACL 2024. “Dataflow-Guided Retrieval Augmentation for Repository-Level Code Completion.”
- Guo et al. “LongCoder: A Long-Range Pre-Trained Language Model for Code Completion.” ICML 2023.
- ACL 2025. “On the Impacts of Contexts on Repository-Level Code Generation.”
- ACL 2025. “SWE-Dev: Building Software Engineering Agents with Development Process.”