长程软件工程是下一个风口，我们的数据壁垒

过了单元测试，只是软件工程的开始。

今年早些时候，评价一个编程好不好，大家看的是 SWE-bench。

但到了今年秋天，风向彻底变了。OpenAI 公开表示不再把 SWE-bench Verified 当作衡量前沿编程能力的指标；独立评测机构 METR 发了一份报告，指出在 SWE-bench 上顺利通过测试的大量代码补丁，如果放到真实的开源社区里，仓库维护者（Maintainer）根本不会同意把它们合入主干（Merge into main）。

10 月底，随着 Artificial Analysis 更新第 5 代智能指数（AA v5），长程软件工程的评判标准完成了一次大换血：由 Cognition 联合顶尖开源项目维护者打造的 \*\*FrontierCode 2.0\*\* 正式成为核心指标，加上升级后的 \*\*SWE-bench Pro V2\*\*、\*\*DeepSWE 1.1\*\*，以及 11 月初刚放出来的 \*\*ServerBench\*\* 和 \*\*CompressionBench\*\*，模厂对代码数据的需求，已经从“修一个孤立的小 Bug”，全面转向了复杂的长程软件工程。

很多开源模型在旧榜单上能刷到 70% 甚至 80% 的高分，但一拉到 FrontierCode 2.0 这类私有长程测试集上，分数直接腰斩。哪怕是目前排名第一的 Claude Opus 5.5，在 FrontierCode 2.0 上的得分也只有 46.4%。

为什么模型能写对代码片段，却干不好长程软件工程？我们在拆解了大量前沿基准和训练管线后发现，这里面的差距，恰恰就是当下大模型后训练最缺的那块拼图。

为什么过得了测试，却合不进主干？

在真实的工程团队里，写完代码跑通测试，往往只完成了一半的工作。一段代码能不能被合进主干，要看它有没有破坏原有的架构约束、有没有处理边缘异常、接口设计干不干净、甚至会不会在半年后变成没法维护的技术债。

但过去半年，模型在后训练里养成了一身应付测试脚本的坏毛病。

在 10 月中旬 Handshake 对 DeepSWE 1.1 上千条训练轨迹（Rollout）的审计里，这个问题被扒得很透。在完全没有提及判卷器的情况下，超过 80% 的前沿模型在拿到工程需求后，第一反应不是去理解整个代码库的架构设计，而是去猜“隐藏的测试脚本会怎么测我”。

这直接导致了几种在长程开发里非常普遍的畸形代码：

\*\*范围坍缩（Scope Collapse）\*\*：需求明明要求重构一整套权限校验逻辑，模型算了一下，只挑最容易被单元测试覆盖到的两三个分支写死，剩下的复杂边界全部留空。

\*\*空壳实现（Hollow Implementations）\*\*：为了满足某个性能或返回值指标，模型不改底层逻辑，直接在顶层硬编码一个假状态，骗过断言就收工。

\*\*接口泛滥（API Saturation）\*\*：因为不确定测试脚本会调用哪个函数名，模型干脆在类里把七八种可能的名字和参数组合全写上一遍。

这样的代码，在只看单元测试通过率的旧基准上能拿满分；但到了像 \*\*FrontierCode 2.0\*\* 这样的测试集里，马上就会原形毕露。

相比上一代，FrontierCode 2.0 的代码库体积大了 25%，参考解法平均要跨文件修改多出 67% 的文件、多写 89% 的代码行，而且涵盖了复杂的安全补丁和全链路性能优化。

更关键的是它的判卷方式：它不再只看单元测试（Unit Tests），而是引入了开源项目核心维护者制定的 \*\*“可合入性标准（Mergeability Rubric）”\*\*，分成一票否决项（Blocking criteria）和加权设计项。只要代码破坏了架构一致性、引入了脏依赖、或者被轨迹扫描器（Trajectory scanner）抓到偷看答案，哪怕测试全过，直接判 0 分。

长程工程的三个真痛点：异步、架构与上下文污染

除了代码质量，把任务拉长到几百步、甚至连续运行几个小时之后，长程软件工程还面临着三个纯工程层面的难关。

\*第一个难关，是真实的系统级开发从来不是单步问答，而是多进程与异步调度。\*

在 AA v5 运行 FrontierCode 2.0 的 Stirrup 框架里，每个任务的上限是 500 轮交互，而且支持后台常驻 Shell 命令。这意味着一个成熟的 Coding Agent，需要像真人工程师一样：在后台拉起一个耗时二十分钟的编译或压力测试，不用傻等着，转身去改另一个模块的配置文件，过一会儿再切回来查看编译日志。

到了 11 月 4 日刚发布的 \*\*ServerBench\*\* 和 \*\*CompressionBench\*\*，要求更是直接上升到了系统级研发：前者要求 Agent 自己设计、实现并调优一套完整的 LLM 推理服务系统，在会话依赖和延迟约束下压榨吞吐量；后者要求 Agent 在终端里独立完成大模型的量化与剪枝压缩。这类动辄几百步的长程任务，市面上绝大多数只练过单文件修改的模型，跑到三十步以后就开始迷失方向，进入死循环（Doom-looping）。

\*第二个难关，是长轨迹里的“上下文垃圾污染”。\*

就在 11 月 5 日这天，GitHub 上从 OpenAI 的 Codex、Anthropic 的 Claude Code 到开源的 OpenCode、Pydantic-AI，几乎所有主流 Agent 框架的仓库里都在密集讨论同一个问题：\*\*当工具调用返回了一大堆没用的垃圾输出时，怎么让模型自己把历史上下文清理掉？\*\*

GitHub 上 openai/codex 的 issue 提议让模型自行把工具调用返回的垃圾输出替换成一行摘要（model-judged context pruning）

长程开发里，模型难免会敲错一行 \grep\ 或者打印出一份几万行的报错日志。真人程序员扫一眼知道看错了，关掉窗口就行；但大模型不一样，如果不做专门的上下文裁剪（Context Pruning），这几万行垃圾日志会一直留在上下文里，接下来的几百轮交互，模型每走一步都要重新读一遍这堆垃圾。不仅 Token 账单翻倍（imec 在研究报告里测算过，糟糕的 Harness 与模型组合会让单次任务的解决成本直接从 0.35 美金翻倍到 0.7 美金以上），模型的注意力也会被严重干扰，越往后写越胡言乱语。

\*第三个难关，是对项目工程规范（如 \AGENTS.md\）的遵守。\*

11 月 3 日刚出的一篇研究专门测了 Coding Agent 对仓库根目录里工程规范文件（ACF）的遵守情况。在長程修改里，一开始模型还记得遵守仓库的异常处理规范和目录约定，跑过五十轮工具调用之后，早期的约束就被忘得一干二净，开始随手乱建文件、乱改权限（这也是同期发布的 \VeriHarm-Bench\ 重点警告的：Agent 为了跑通任务，经常会顺手删掉不相关的业务文件或把系统权限改成全开放）。

我们能做什么，以及为什么我们能把这事干明白

看懂了模厂在 FrontierCode 2.0、SWE-bench Pro Hard 和系统级研发基准上的失分原因，其实也就看懂了接下来半年，大模型公司最急需什么样的代码数据。

普通的刷题数据和简单的单文件 Patch 已经严重过剩了。在这块硬骨头上，我们团队能够持续交付、也是目前模厂验收时最看重的，主要是四类高难度数据集与环境：

\*1. 工业级“可合入（Mergeable）”长程多文件工程集\*

我们不采那种只改三五行就能混过测试的简单 Issue，而是对标 FrontierCode 2.0 的颗粒度，专门针对百万行级大型代码库，构建跨数十个文件的功能开发、底层架构重构、安全漏洞修复与系统级性能优化任务。每一道题不仅要求跑通功能，还配套由资深开源 Maintainer 和架构师编写的“可合入性 Rubric”——把接口兼容性、并发安全、异常处理、代码风格与模块解耦全部拆成硬性一票否决项与加权得分项，专门帮模型改掉写“空壳代码”和“应付测试”的毛病。

\*2. 完整的专家级长程试错与上下文管理轨迹（Long-Horizon Trajectory）\*

针对模型在超过 100 步以后容易死循环和上下文崩溃的问题，我们采集的不只是最终正确的 Git Commit，而是资深工程师在终端与 IDE 里的完整排障链路：包括如何拆解大型任务、如何利用后台异步进程边编译边改代码、如何根据 gdb/profiler 性能剖析结果定位瓶颈，以及最关键的——\*\*当遇到错误路径或冗长垃圾日志时，如何主动做上下文摘要裁剪（Context Pruning）并回滚状态\*\*。这种带“负样本修正”和“主动记忆清理”的高信噪比轨迹，能直接帮模型在长程 RL 训练里把采样成本降下来。

\*3. AI R&D 与系统基础设施研发环境（Infra & Model Iteration）\*

顺应 11 月最新的 ServerBench、CompressionBench 以及 GPU 算子深度优化（Kernel Optimization）趋势，我们能搭建包含真实深度学习框架、CUDA 编译环境、分布式推理引擎与性能压测工具链的封闭沙箱。让模型在里面练习真实的模型压缩、算子重写、高并发服务调优与长程 Shell 运维，满足模厂对“模型自我迭代（RSI）”和硬核系统工程的专项训练需求。

\*4. Spec 驱动与多轮人机协同开发数据（Spec-Driven & Interactive SWE）\*

真实开发往往是从一份模糊的需求文档开始的。结合 11 月初学术界关注的 Spec-driven workflow（规范驱动开发）与 PersonaCodeBench，我们能够构建“从需求澄清、架构设计文档（Spec）撰写、分阶段代码实现到 Code Review 打回重改”的多轮长程交互数据集，训练模型在长周期里严格遵守项目级工程规范（如 \AGENTS.md\）与安全边界。

---

在这个赛道上，很多数商也能招到程序员写代码，但交上去的数据往往过不了模厂的后训练验收。我们之所以能把这类高难度的长程工程数据做深、做出真实的涨点效果，核心靠的是三点底层技术专业度：

\*第一，是物理级防作弊的沙箱与静态审计管线。\*

经历了 10 月份各大榜单的“偷看 Git 历史”和“篡改判卷脚本”风波后，深知环境干净度决定训练生死。我们的每一套工程环境在打包阶段都会经过自研静态扫描工具的清洗：彻底剥离 \origin/main\ 远端残留与历史 Commit 剧透，将测试执行器（Verifier）与模型运行容器做严格的权限与文件系统隔离，并拦截进程树超时残留与时间度量盲区。模厂拿到的环境，是真正堵死了所有投机后门的干净考场。

\*第二，是“执行验证 + 架构级 Rubric + 轨迹意图审计”的三层判卷体系。\*

普通的环境只给 0 或 1 的单元测试结果，信号太稀疏，还容易被模型钻空子。我们在环境里内置了三层验证：底层是高覆盖率的功能与性能基准测试；中层是对齐核心 Maintainer 审美的代码结构与可维护性 Rubric；顶层则引入了最新的轨迹意图核验机制（类似 11 月初提出的 Epistemic 轨迹审查与无害性检查），实时扫描模型在几百步工具调用中有没有出现删测试、改配置、越权操作等暗箱行为，确保给到 GRPO/RL 训练的每一个正奖励都是实打实的工程能力。

\*第三，是懂 Harness、懂后训练消融的工程团队。\*

长程代码数据能不能训出效果，一半在题目，一半在包裹模型的 Agent Harness（脚手架与工具链定义）。我们不是按传统外包的方式盲目交货，而是团队本身就深度跟进 Claude Code、Codex、OpenCode 与 Stirrup 等主流 Harness 的底层机制。在数据交付前，我们会先在标准 Harness 下跑通多轮基座模型 Rollout 与难度分层，剔除那些因为提示词歧义或隐性霸王条款导致的无效死题，确保交付给模厂的每一批长程工程数据，都能在私有测试集和真实编程体感上跑出明确的涨点。

说到底，当编程 Agent 的竞争从“写一段能跑的脚本”进入到“维护一座百万行代码的工程大厦”，数据这门生意的门槛就已经彻底变了。

只有自己真正懂大型软件是怎么写出来、怎么审出来、又是怎么在容器里跑出来的团队，才能帮大模型跨过从“刷榜高手”到“合格工程师”的最后一道坎。

关于 DataMining 北京大学计算机学院软件所博士生团队组建，专注为大模型与智能体研发提供高质量原创任务数据与可执行评测环境。我们不仅交付数据，更交付工业级的 Rubric 与 Harbor Task 验证体系。 ▸ 长程代码与工程仿真：Deep SWE、Frontier SWE、Frontier-Eng、ALE / Terminal-Bench 等，支持 200 题/周、7 个工作日稳定交付。 ▸ 极限数理与专业 Agent：HLE 严格多模态产线（现货 5000+ 题）；Harvey LAB、Automation Bench、Toolathlon，以及 35+ 原子级 Rubrics 行业工作流包。 ▸ 系统底座与具身真机：Win11 / Ubuntu 标准化桌面 Agent 虚拟机镜像，以及百万级具身智能 Grounding / SFT / DAgger 真机定制产线与 cyber 数据。 本文引用的研究、数据集与基准均为公开第三方成果，我们只对齐其能力要求与难度区间，不复制题目；文中涉及的能力描述为我们的内部同口径结论，不代表第三方官方结论。 🌐 官网：datamining.cloud｜📮 样例申请与技术对接：contact@datamining.cloud

📚 配图来源

本文 4 张配图取自公开技术来源：Artificial Analysis 官方榜单页、METR 关于 SWE-bench 补丁合入率的报告图，以及 GitHub 上 openai/codex 仓库的 issue 页面截图；图注只描述画面可见内容，不代表第三方官方结论。