近年来，AI 大模型的编程能力突飞猛进，各大 AI 厂商在编程基准测试上你追我赶，不断刷新纪录。这让不少程序员开始担忧：AI 是不是很快就要抢走我们的饭碗了？

然而，中山大学与阿里巴巴联合发布的一项最新研究给程序员们吃下了一颗 " 定心丸 "。

3 月 4 日，两家机构联合发布了一项评测结果。这项测试名为 "SWE-CI：通过持续集成评估智能体维护代码库的能力 "（SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration），首次对包括 Anthropic、OpenAI、Kimi 和 DeepSeek 等 8 家主流厂商的 18 款 AI 大模型的长期代码维护能力进行了严苛的系统性评估测试。

测试包含 100 项任务，总 Token 消耗超 100 亿。结果显示，Claude Opus 系列综合表现领跑。

在控制性能退化方面，千问、DeepSeek、MiniMax、Kimi 和豆包等大多数 AI 大模型的表现明显不佳。也就是说，AI 在长期代码维护过程中，可能将代码 " 越改越糟 "。

100 项任务！中国团队推出全球首个评估 AI 大模型长期代码维护能力的评测系统

长期以来，AI 编程能力的主流评测基准的共同特点是快照式评测，以 " 单次接收需求、一次性输出解决方案 " 为核心。

然而，这种评估方式仅检验大模型是否能写出功能正确的代码，无法反映真实软件开发中持续迭代、长期维护的核心需求。

在现实中，成熟的软件很少是一蹴而就的，而是长期维护的结果。雷曼定律表明，软件质量会随着维护的进行而自然下降。而维护工作占软件生命周期总成本的 60% 到 80%。

为评估 AI 在长期代码维护中的表现，中山大学与阿里巴巴团队联合推出了 SWE ‑ CI 评测基准。这是全球首个专门评估 AI 智能体在长期代码维护表现的评测系统，它不再满足于考察 AI 编程的 " 一次性正确 "，而是评估 AI 是否像真正的软件工程师一样，在数月甚至数年的开发过程中持续保持代码质量。

SWE ‑ CI 基准测试的构建经过四层严格筛选，最终形成高质量评测集。

研究团队先从 GitHub 全网的 Pytho 代码库中筛选出维护三年以上、星标超 500、包含依赖文件和完整单元测试套件，以及采用 MIT/Apache ‑ 2.0 等宽松协议的 4923 个代码库；再提取依赖稳定、代码修改量超 1000 行的提交对，得到 8311 个候选样本；通过自动构建 Docker 环境与自修复依赖机制，保留 1458 组可运行候选对；最后经测试启动校验、通过率差异筛选、时间跨度与提交量排序，确定 100 项最终任务。

研究团队精心构建的 100 项任务中，每项任务都对应着真实世界中一个软件项目的完整进化历程。这些项目平均跨越 233 天的开发时间，包含 71 次连续的代码提交记录。团队还设计了一个精巧的 " 架构师 - 程序员 " 双智能体协作机制。设计的灵感来自真实软件团队中常见的分工模式：架构师负责分析需求和制定技术方案，程序员负责具体的代码开发。

为适配长期迭代评测，SWE ‑ CI 提出了 " 归一化变化 " 与 "EvoScore（进化得分）" 两大核心指标。

" 归一化变化 " 以测试用例通过数为基础，将代码状态映射到 [ -1，1 ] 区间，正向表示功能提升，负向表示出现功能退化。

EvoScore 更侧重衡量 AI 大模型在未来修改任务中的表现。

实测结果：Claude Opus 断层领跑，大多数大模型在 75% 的任务中会破坏原有代码

研究团队对 8 家公司——月之暗面、Anthropic、智谱、千问、MiniMax、DeepSeek、OpenAI 和豆包——的 18 个主流 AI 大模型进行了系统性测试，累计消耗了超过 100 亿 Token 的测试数据。这一实验规模在 AI 编程评估领域堪称史无前例。

研究结果显示，从时间维度来看，AI 大模型在代码维护能力上的进化呈现出明显的加速曲线。

从下图可以发现，同一厂商的大模型新版本普遍稳定高于前一代，且 2026 年后的跃升幅度显著扩大，EvoScore 更高。这表明，当前大模型的代码能力正从静态缺陷修复，快速向持续、长期的代码维护演进。

8 家厂商的主流大模型在 SWE ‑ CI 测试中的 EvoScore 变化情况。图片来源：论文截图

在所有参评大模型中，Claude Opus 系列表现最为突出，从 Claude-opus-4.5 到 Claude-opus-4.6，其 EvoScore 跃升至约 0.9 的高位，明显拉开了与所有竞争对手的差距。

中国的 AI 大模型中，智谱 GLM 系列进步显著，成为第二梯队中最具竞争力的选手。紧随其后的是 Qwen 和 MiniMax，整体趋势向好。而 Kimi 和豆包虽有提升，但缺乏突破。

研究还发现，不同厂商在大模型训练策略上偏好存在明显分化。

具体而言，MiniMax、DeepSeek 以及 OpenAI 的 GPT 系列大模型更偏好长期效益，显示出其在长期代码维护任务中的优势。这意味着，这类大模型在生成代码时，更倾向于采用有利于长期演进与稳定性的策略，而非追求短期修复的最优解。

相比之下，Kimi 与智谱 GLM 系列更偏向于短期见效的优化路径。

而千问、豆包以及 Claude 系列大模型则呈现出另一种特征：其训练策略在短期效果与长期维护之间取得了一定平衡。

随着权重参数 γ 的变化，各个大模型的排名也随之发生显著调整。当 γ>1 时，大模型排名越高，其代码库维护能力越强。图片来源：论文截图

另外，研究还有一项关键发现：在长期代码维护中，所有大模型在有效控制性能退化（Regression）方面都表现不佳。

性能退化是衡量软件质量稳定性的核心指标。如果某个单元测试在代码更新前已经通过，而更新后失败了，则判定该变更触发了性能退化。一旦出现性能退化，不仅会直接影响用户体验，在长期维护过程中，随着修改次数累积，还可能导致系统质量系统性退化。

研究团队测量了 " 零退化率 " ——即在整个维护过程中完全没有破坏原有功能的任务比例。零退化率越高，维护的系统越稳定。

研究结果表明，在所有参与测试的 18 个大模型中，只有 Anthropic 的 Claude Opus 大模型保持了 50% 以上的零退化率，大多数大模型的零退化率都低于 25%。

18 个大模型的零退化率（从低到高排序）。图片来源：论文截图

具体而言，Claude-opus-4.6 以 76% 的零退化率遥遥领先。这意味着在绝大多数测试场景中，其性能能够保持稳定。Claude-opus-4.5 以 51% 位列第二。相比之下，Kimi-K2.5（37%）与 GLM-5（36%）表现接近，构成第二梯队，虽具备一定稳定性，但与头部大模型仍存在显著差距。

包括 GPT-5.2、Qwen3.5-plus、MiniMax-M2.5 和 DeepSeek-V3.2 在内的其余 14 个 AI 大模型的零退化率都在 25% 以下，这意味着在长期代码维护过程中，大模型在超过 75% 的任务中会破坏原本正常的代码功能，引发性能退化问题。

但从版本迭代的角度看，头部厂商的 AI 大模型正快速进步。例如，Claude-opus 系列的 " 零退化率 " 从 4.5 版本的 51% 提升至 4.6 版本的 76%，智谱 GLM 系列从 GLM-4.6 和 GLM-4.7 的 14% 跃升至 GLM-5 的 36%。

但即便如此，绝大多数大模型仍难以在长期代码维护中杜绝性能退化问题，距离可靠的自动化长期开发仍有明显差距。

SWECI 基准测试结果的发布，让行业意识到，" 写代码 " 和 " 维护代码 " 是两种截然不同的能力。对于大模型厂商而言，持续优化可维护性、性能退化控制、架构设计能力，或许将是赢得下半场竞争的关键。

免责声明：本文内容与数据仅供参考，不构成投资建议，使用前核实。据此操作，风险自担。

每日经济新闻