MirrorCode逼问AI编程上限

AI 编程基准开始从“修一个 Bug”走向“重建一个项目”

MirrorCode 正在把 AI 编程能力的考题，从完成局部修改升级为独立复刻完整软件。 Epoch AI 与 METR 在 6 月 26 日公布了这一基准的首批结果；截至 2026 年 8 月 3 日，它引发的核心争论已经不再是模型会不会写代码，而是模型在没有持续人工接管的情况下，究竟能完成多大、运行多久、价值多少的软件工程任务。

MirrorCode 是一个测试 AI 能否在无法查看目标源代码的前提下，根据外部规格和可观察行为重新实现完整程序的基准。 模型不是在现有仓库里补全函数，也不是接收一个明确标注位置的缺陷，而是要从零搭建项目结构、选择实现路径、调试失败结果，并最终通过隐藏测试。

这一区别很关键。

过去两年最常见的 AI 编程评测，例如围绕 GitHub issue 展开的真实仓库修复任务，通常已经把软件主体交给模型。模型要做的是在几十万行代码中找到问题，再修改其中几十行或几百行。MirrorCode 则直接拿走原始代码，相当于只给工程师产品说明、外部行为和验收标准，然后要求他重新造出一个兼容实现。

MirrorCode 衡量的不是代码生成速度，而是长时间维持工程目标的能力。 一个代理需要连续处理需求理解、模块拆分、依赖选择、接口兼容、测试反馈和错误修复，任何一步积累的小偏差，都可能在数小时甚至数天后变成无法收敛的系统性错误。

56%是领先成绩，也是一条清晰的警戒线

Claude Opus 4.7 在最严格设置下取得了 56% 的任务解决率，是首批结果中表现最好的模型。 这里的 56% 指任务实例通过，而不是某个项目完成了 56% 的代码，也不意味着生成代码有 56% 可以直接进入生产环境。

最具冲击力的成功案例，是 Claude Opus 4.7 在约 14 小时内重建了一个约 16,000 行代码的生物信息学工具包。 如果只看规模，这已经超过大量内部工具、命令行应用和垂直领域组件；按照传统开发方式，一个不熟悉项目背景的团队可能需要数周才能完成需求梳理、实现和兼容性验证。

最具警示意义的失败案例，则是一项持续运行 19 天、产生约 2,600 美元推理成本的任务。 模型最终仍未给出通过验收的实现，这说明增加运行时间和 token 预算，并不会自动把失败任务“熬”成成功任务。

首批结果可以概括为下表：

| 观察维度 | 已公布结果 | 应该如何理解 | |---|---:|---| | 领先模型 | Claude Opus 4.7 | 领先不等于大型项目已被解决 | | 严格设置解决率 | 56% | 接近一半任务仍需要人工介入或最终失败 | | 代表性成功项目 | 约 16,000 行代码 | 14 小时完成，说明中等规模工具已进入实用区间 | | 最长失败任务 | 19 天 | 长时间自主运行不保证收敛 | | 该失败任务成本 | 约 2,600 美元 | 算力投入可能高于人工先做架构判断的成本 | | 最大型任务 | 所有参测模型均未通过 | 当前前沿模型仍存在明确工程规模上限 | | 基准规模 | 25 个目标程序、132 个任务实例 | 其中 22 个程序相关材料已开放，3 个保留用于测试 | | 覆盖语言 | 6 种编程语言 | 结果比单一语言评测更有参考价值，但仍不能代表全部技术栈 |

56% 的价值在于证明 AI 已经能独立完成一部分中等复杂度工程，而不是证明 AI 可以替代一支软件团队。 在 benchmark 中，失败一次只是丢掉一个样本；在生产环境里，失败可能意味着迁移延期、接口不兼容、数据损坏，或者团队在数天后才发现代理一直走在错误方向上。

换句话说，56% 在研究图表上是一个不错的分数，在企业交付里却可能是不可接受的成功率。

大项目为什么不能靠“多跑几天”解决

大型软件任务的难点不是代码行数本身，而是约束数量会随着模块、接口和运行时间快速增长。 1.6 万行代码并不必然比 5,000 行代码难：结构清晰、行为容易观察、模块边界稳定的工具，可能比一个代码更少但状态复杂、兼容负担沉重的系统更适合 AI 重建。

长程代理最常见的问题是错误会复利，而不是错误会平均分布。 模型在开始阶段误解一个接口语义，随后可能基于这个错误设计数据结构、编写适配层并补上测试；等隐藏测试暴露问题时，已经有数十个模块依赖错误假设。此时继续生成代码，往往只是给错误架构增加更多补丁。

上下文压缩也可能让代理逐渐忘记最初的工程约束。 一个持续数天的任务会产生海量终端输出、测试日志、代码差异和中间计划，即使模型支持很长的上下文窗口，代理系统也必须对历史信息进行摘要和取舍。压缩一旦遗漏关键失败原因，模型就可能反复尝试已经被证明无效的路线。

隐藏测试让“看起来完成”与“真正兼容”之间出现了巨大差距。 一个复刻项目可以正常启动、通过公开样例，甚至覆盖主要功能，但只要边界条件、错误处理、文件格式或性能特征不兼容，就仍然无法算作成功。

这也是 MirrorCode 比常规演示更有意义的地方。屏幕录制通常展示代理如何不断创建文件、运行命令和修复报错，过程很热闹，却不容易回答最终软件是否真的可用。隐藏测试把判断重新拉回结果：不是看模型工作得像不像工程师，而是看产物能不能通过验收。

MirrorCode 与 SWE-bench 测的不是同一件事

SWE-bench 是让模型根据真实软件仓库中的 issue 修改已有代码，并用测试判断补丁是否正确的基准。 它更接近维护、修 Bug 和处理增量需求，是目前代码代理厂商最常引用的能力指标之一。

MirrorCode 则更接近黑盒重建、兼容实现和遗留系统迁移。 它要求模型自己建立代码骨架，并在缺少原始实现的情况下恢复外部行为，因此更强调架构规划、行为推断和长时间自主执行。

| 对比项 | MirrorCode | SWE-bench 类评测 | 常见代码生成题 | |---|---|---|---| | 核心目标 | 从零复刻完整程序 | 在已有仓库中修复问题 | 完成函数或算法 | | 是否提供原始项目代码 | 不提供目标源代码 | 提供完整仓库 | 通常只提供题目与函数签名 | | 典型任务时长 | 数小时至数天，极端案例达 19 天 | 通常更短 | 分钟级 | | 主要难点 | 架构、兼容性、长程规划 | 定位问题、理解现有代码、生成补丁 | 局部逻辑正确性 | | 更接近的现实场景 | 软件重建、替代实现、遗留迁移 | 日常维护、Bug 修复、需求迭代 | 面试题、局部代码生成 | | 能否代表完整软件交付 | 相对更接近，但仍不完整 | 不能直接代表 | 基本不能代表 |

MirrorCode 不会取代现有代码基准，但它补上了“项目级自主性”这一块长期缺失的拼图。 一个模型可能很擅长在现有仓库中修补问题，却未必能从零设计出稳定架构；反过来，一个能快速搭建新项目的模型，也可能不擅长理解十年历史包袱下的旧代码。

成本数据说明，模型能力排名不能代替ROI评估

MirrorCode 首批实验没有呈现“模型越新，完成同一任务就一定越便宜”的简单规律。 根据研究团队披露的同任务观测，GPT-5.5 的成本约为 GPT-5 的 3 倍，而 Claude Opus 4.7 的成本约为 Claude Opus 4.1 的三分之一。

推理单价只是成本的一部分，能否快速收敛往往更加重要。 一个价格更高但在 4 小时内完成任务的模型，可能比一个单价更低却循环调试 3 天的模型便宜；一个能够及时识别错误路线并重新规划的代理，也可能比“每秒输出更多 token”的模型更有经济价值。

因此，企业评估代码代理时至少要同时记录五项数据：

1. 最终通过率：产物是否通过完整验收，而不是是否生成了大量代码。
2. 端到端时长：从接收任务到形成可交付结果用了多久。
3. 总推理成本：包括反复调试、上下文处理和失败尝试。
4. 人工接管时间：工程师花了多少时间纠偏、审查和补测试。
5. 失败发现时间：系统是在 20 分钟后暴露路线错误，还是在运行 10 天后才失败。

失败发现时间可能是最容易被低估的指标。 如果一个任务本来就不适合当前模型，最好的代理未必是坚持最久的代理，而是能够尽早说明信息不足、架构不可行或预算不够的代理。

结果仍要防范训练数据污染

MirrorCode 使用真实开源程序作为目标，因此无法完全排除模型在训练阶段见过原始代码。 Epoch AI 与 METR 的初步测试认为，首批成绩并非主要由记忆驱动，但研究团队也明确承认，不能排除训练数据记忆对结果产生贡献。

保留未公开程序和使用隐藏测试，可以降低针对 benchmark 优化的风险，却不能彻底解决污染问题。 模型即便没有逐字记住整个仓库，也可能见过文档、代码片段、接口讨论或相似实现，从而降低重建难度。

MirrorCode 的成绩更适合被看作能力上界，而不是对陌生私有系统的直接承诺。 企业内部遗留软件通常文档更少、环境更旧、业务规则更隐蔽，还可能依赖不可复现的数据与基础设施，其实际难度往往高于结构清晰的开源项目。

对开发团队真正有用的，不是“替代程序员”这个结论

MirrorCode 最现实的用途，是帮助团队判断哪些项目可以交给代理端到端执行。 小型命令行工具、格式转换器、内部自动化组件和接口明确的垂直软件，已经适合进入封闭环境试验；支付、权限、数据迁移和核心交易系统，则仍然需要更细粒度的检查点与人工审批。

企业不应该直接拿 56% 的总成绩决定采购，而应该建立自己的 MirrorCode 式测试。 具体做法不是准备几十道算法题，而是从内部历史项目中抽取已知结果的任务，隐藏原实现，只提供当时能够获得的需求、文档、样例和测试，再观察代理能否在固定预算内交付。

一个更可靠的内部评估可以分为三档：

• 可自主完成：模型能够在预算内通过测试，人工只做最终审查。
• 适合协作完成：模型能搭建主体，但需要工程师处理架构、边界条件或关键模块。
• 不适合当前模型：任务长时间不收敛，或人工纠偏成本接近直接开发。

Junior 工程师的价值也不会因为中等任务被自动化而消失，但培养方式必须改变。 当模型能够快速产出一万行代码时，新人的核心训练不能只剩下“写得更多”，而要转向验收设计、故障定位、架构判断、安全审查和理解业务约束。

高级工程师的瓶颈则会从实现速度转向任务定义质量。 需求写得含糊、验收标准不完整、接口边界不稳定时，更强的模型只会更快地产生一套看似完整但方向错误的系统。

MirrorCode给出的答案：中型项目能做，大型项目还不能放手

截至 8 月 3 日，MirrorCode 对“AI 能独立完成多大的软件项目”给出了一个暂时但清晰的回答：结构明确的中等规模程序已经进入可用区，最复杂的大型任务仍超出所有参测模型的稳定能力。 14 小时重建约 16,000 行代码证明项目级自主编程不再只是演示，19 天和 2,600 美元仍然失败则证明规模扩展远非线性。

MirrorCode 最重要的贡献不是给 Claude Opus 4.7 戴上一顶 56% 的冠军帽子，而是给“自主完成软件”建立了更严格的衡量方式。 未来模型发布时，开发者需要关注的不只是补丁通过率和编程竞赛分数，还要看它能连续工作多久、在什么规模开始失控、失败要花多少钱，以及能否在走错路线时及时停下。

这比“AI 会不会取代程序员”更具体，也更接近软件团队今天真正要做的决策。

参考来源

• GitHub：检索 MirrorCode 相关仓库与公开实现——用于查找研究团队公开的脚手架、任务材料及社区复现项目。
• Reddit：MirrorCode 相关社区讨论——用于了解开发者对项目规模、训练数据污染和推理成本的讨论。

主要数据来自 Epoch AI 的 MirrorCode 项目说明及 Epoch AI、METR 公布的首批评测结果；受文末链接域名范围限制，此处不附其站外链接。