[ArXiv 2026] SWE-CI：告别单次修复，AI 编程进入“持续维护”演进时代

TL;DR

软件开发的本质不在于“写出代码”，而在于“维护代码”。由中山大学与阿里巴巴团队联合提出的 SWE-CI 是全球首个聚焦于**持续集成（Continuous Integration）**过程的 AI 智能体基准测试。它不再考查 AI 能否修好一个 Bug，而是考查 AI 能否在长达半年的代码演进中，在不引入回归（Regression）的前提下持续交付新功能。

1. 痛点深挖：快照式评估的“欺骗性”

目前的编程大模型评估（如 HumanEval, SWE-bench）普遍存在一个致命缺陷：快照式短视（Snapshot-style myopia）。

在真实工程中，代码质量的差异通常在第二次、第三次修改时才会显现。一个“投机取巧”的智能体可以通过 hard-code 或 hack 的方式强行通过当前测试，但在下一次需求变更时，这些“技术债”会导致整个系统崩溃。

• 传统基准：输入 Issue -> 输出 Patch -> 测试通过（完事）。
• SWE-CI 直觉：软件质量的下降是一个熵增过程。只有在持续的 CI 循环中，观察智能体在 N 轮修改后的表现，才能识别出谁在写“烂代码”，谁在写“可持续代码”。

2. Methodology：双智能体与动态演进

SWE-CI 从 GitHub 筛选了 100 个具有真实演化史的任务，平均跨度 233 天。为了模拟真实的工业环境，它设计了一套 Architect-Programmer 双智能体协议。

2.1 架构设计

• Architect (架构师)：负责“看”。它扫描测试失败报告，定位根因，并撰写 1-5 条高层自然语言需求（Requirement Document）。它被严禁直接写代码。
• Programmer (程序员)：负责“做”。它根据架构师的需求文档进行增量开发。它看不到原始的测试失败信息，必须依赖架构师的抽象。

这种角色分离强迫智能体处理自然语言与视觉代码的对齐，极大地模拟了真实团队的 CI 协作流程。

2.2 EvoScore：为未来加权的评分指标

为了量化“维护能力”，作者提出了 EvoScore： $e=\frac{{\sum }_{i=1}^N{\gamma }^{i}a(c_i)}{{\sum }_{i=1}^N{\gamma }^i}$ 这里的 $\gamma \ge 1$。这意味着，越是后期的表现，对总分的影响越大。如果一个智能体在第 1 轮表现好但在第 20 轮因为代码太乱改不动了，它的得分将显著低于那些能够持之以恒的智能体。

3. 实验发现：谁是真正的“架构大师”？

3.1 性能梯队：Claude 定义了新高度

实验对 18 个模型进行了长达 100 亿 token 的压测。结果显示，Claude Opus 系列展现了断层式的领先优势。尤其是在演进的后期，Claude 表现出的稳定性（Stability）远超 GPT-4 系列。

3.2 致命弱点：回归（Regression）难题

所谓“回归”，就是指修好了新 Bug 却改坏了老功能。实验发现：

• 大多数模型的 Zero-regression Rate（零回归率） 低于 0.25。
• 这意味着在 20 轮的维护中，仅有极少数模型能保证不把代码改出新漏子。
• 这反映出即便模型懂得如何实现功能，它们对全量系统依赖的理解依然薄弱。

4. 深度洞察与总结

SWE-CI 的出现标志着 AI 编程评估进入了 2.0 时代。它告诉我们：

1. 代码的可维护性是可以量化的，且与单次生成的性能并不必然正相关。
2. 技术债务是 AI 的软肋。AI 往往倾向于局部最优解，而忽略了长期的全局一致性。
3. 厂商偏好差异：研究发现不同厂商（如 OpenAI, Anthropic, 阿里, 字节）的模型在短期冲刺与长期维护之间存在明显的“性格倾向”，这可能源于预训练数据中对重构代码与初始代码的配比差异。

总结 (Takeaway)：SWE-CI 证明了当前的 AI 智能体虽然能胜任“短期突击手”，但要成为真正的“长期合伙人”，还需要在理解系统复杂度和控制回归方面有本质的跨越。

编者注：该基准测试已在 Hugging Face 与 Github 开源，是衡量 Agent 架构能力的试金石。