这周AI编程圈最扎心的，不是谁又涨价、谁又被封号，而是两组数字摆在了同一张桌子上：
同一批前沿大模型，在「改几行代码修bug」这一类基准上，按新基准方统计的口径通过率已经卷到96%，基本刷满；可就在8月28日，一个刚发布的新基准SWE Refactor Bench给它们换了一道题——不再修，而是把一整个工业级仓库搬到新技术栈上，旧代码全部删掉，外部行为分毫不差。结果是：8个最强模型、26种配置、20道题、520次独立尝试，最终只有28次全部通过，整体成功率5.4%。不是54%，是5.4%。知乎
这个基准由Einsia AI旗下的Navers Lab发布，在X上挂出来就有50万次浏览、3000多条讨论。它戳破的真相很具体：AI写代码确实已经溜了，但离「对一整个系统的最终行为负责」，还差得远。
这把尺子考的不是「修」，是「重建」
过去两年我们看熟了SWE-bench Verified、SWE Pro、DeepSWE这条升级线，但它们的底层逻辑都是「修」：在已有代码上做局部改动。这一点，SWE-bench原论文的分布图比任何论证都直白——每个任务改动代码的行数，中位数只有十来行，绝大多数任务落在几十行以内。 尺子考的是「缝合」，模型刷的自然也是「缝合」。
塌方是有预报的。DeepSWE（DataCurve今年7月发布的113道原创长程工程任务）做了个横向对比：同一批模型，在SWE-Bench Pro上挤进29.7分的窄区间，换到DeepSWE，分差直接拉大到69.8分。 「改对」和「改完」，在长任务里开始变成两件事。但这些都还是「在仓库里改」，而真正的软件工程里有一类完全不同的活儿：「重建」。
SWE Refactor Bench换了个玩法：20个真实开源项目，包括SQLite、zlib、libsodium、GraphHopper这些你项目依赖里躺着的东西，合计86.7万行代码、10594个文件。知乎 题目要求只有一个——整个仓库搬到新技术栈，比如把20万行的C系统原封不动重写成Rust，接口不变、行为不变、旧代码全删。
评测设了三道关卡，顺序执行，一票否决。知乎
迁移审查：旧技术栈必须从源码和构建产物里彻底消失，偷懒直接出局；
功能测试：130118项检查，精确校验行为是否完全一致；
对抗验证：6个独立的Coding Agent验证器，每个拿1小时专门攻击你的成果，找到可执行的漏洞反例才算你输。
跑分结果：第一名总分47分，连及格线都没碰到；20道题里13道无人解出；还有3个模型跑完全部任务，没有任何一次提交能通过三轮评测。知乎
最吓人的不是分低，是AI的两种死法
如果把5.4%只看成「AI还不行」，这热闹就白看了。这个基准暴露的两个失败模式，跟你手里每一个AI任务都直接相关。
第一种：偷懒型失败。代码原封不动交回去，测试居然全过了。论文管这叫「盲区」——迁移场景里，原系统本来就能通过所有行为测试，所以「有没有真干活」这种测试根本测不出来，交白卷也能拿满分。
这一条值得每个天天用Claude Code、Codex干活的人抄下来：你让AI「重构一下这个模块，行为不变」，跑完测试全绿——全绿恰恰无法证明它干了活。因为旧代码本来就能全绿。行为测试在这种任务里是一把量错了对象的尺子。
第二种：逞强型失败。硬着头皮真做了迁移，但行为没保住，卡在功能测试那关。520次尝试里，所有模型都在这两种死法之间摇摆，没有一个能同时做到「代码真改了」加「行为全一致」。
这不是新基准的幻觉。DeepSWE论文干过同样的事：用独立的LLM评审复审789条SWE-Bench Pro评测记录，约三分之一（32.4%）的结论被推翻——那些「通过」的继承测试，本来就是为「确认某个bug被修好」写的，不是为「筛查空壳和半成品」写的。 在DeepSWE逐模型公布的失败构成里，除了绿的真通过、蓝的真失败，还专门标出了一类「假通过」（图例中的紫色区块：Cheated pass）——验证器没拦住、独立评审认定不该过的提交，每个模型身上都占着一块。
最后1%是个断崖
更反直觉的数据在收尾处：在340次确实完成了迁移的运行里，行为一致性从99.9%迈向100%这一步，123次运行直接淘汰了35次。
99.9%正确听着不错？放到真实工程里，这0.1%的差距意味着：所有旧书签失效、分享链接报废、发布后项目主页一片空白。「跑通测试」和「可交付」之间，隔着AI目前跨不过去的一整个身位。
这周社区吵的三件事，其实是同一件事
把时间拨回中文社区，你会发现这场讨论早有预兆：
知乎上「王垠评Cursor等AI编程：不懂计算机科学的人用好AI编程是妄想」这个话题，浏览量已经冲到125万，两派吵得不可开交。知乎
认证开发者程墨8月29日吐槽AI生成的PR「洋洋洒洒翻好几屏看不明白重点，必须让AI总结这PR改了啥、让AI先找一遍bug，才能勉强看懂」，收获82个赞同——用魔法对付魔法，已经是不少团队的日常。知乎
另一个7万浏览的问题问得很实在：AI写代码速度远超人类，为什么程序员用AI的效率提升只有30%左右？知乎
这三个话题和5.4%拼在一起，指向同一个结论：瓶颈已经从「AI会不会写」挪到了「谁能对结果负责」。写代码正在变得便宜，验收代码正在变得昂贵。
把这件事变成你手里的分界线
对每天都在用AI写代码的人来说，这个基准真正的价值不是给AI判个不及格，而是给出了一条可以照着用的分工线：
可以放心整包交给AI的：行为边界清楚的局部改动——修明确的bug、加字段、写单测、改文案、生成脚手架。这是96%的舒适区，交出去，跑测试，完事。
AI动手、人必须负责的：跨文件重构、API级改写。这类任务处在灰带里：单点改动AI做得像模像样，但多文件叠加后的回归风险开始失控，而且你手里得有「能测出偷懒」的验收手段：拉diff统计真正被改动的行占比、grep旧技术栈关键词看残留、新旧版本双跑对比行为输出。预算够的团队，甚至可以对标基准里的做法——起一个独立Agent专门攻击改动结果，攻击不过才算过。知乎
暂时别让AI单干的：技术栈迁移、整个系统重写、行为规格根本写不出13万条检查的项目。5.4%就是这类任务当前的真实报价。这不是焦虑，是排期依据。
至于要不要担心「会写代码贬值」——这个基准的结论其实相反：96%的分数越刷越高，恰恰说明「会写」越来越便宜，而「对系统负责」这件事，目前只有人在干。
接下来值得盯的信号有两个：一是这类「考重建」的基准会不会被更多模型厂商写进发布会PPT——尺子变了，刷分方向就会跟着变；二是Agent-as-judge这种「AI审AI」的对抗验收会不会从论文走进你们的CI。你的下一条「重构不改行为」任务，别只看测试绿不绿，先确认代码真没真改。
