停止过分追求单次任务的成功率吧，现在是时候思考如何让人工智能学会为长远考虑编写程序了。
夜深人静的工位上，程序员小李面对Claude刚完成的第三版代码感到十分沮丧：
最初他的需求很简单：创建一个用户登录接口。AI在十分钟内完成了这项工作，并且运行正常。然而，在增加了验证码、三方登录、权限系统和多租户支持等功能后，到第五轮修改时，AI生成的代码已经变得混乱不堪。
小李忍无可忍地重写了整个模块，边写边抱怨：那些声称人工智能能够替代程序员的说法根本站不住脚。每次迭代后的代码质量都会下降，最终还是得由人类来收拾残局。
如果你也有类似的经历，那么恭喜——最近威斯康星麦迪逊大学和麻省理工学院的研究团队已经将这种痛点转化为行业标准，并证实了当前所有AI编程代理的致命缺陷：虽然它们在初次编写代码时表现出色，但在长期迭代需求的过程中，这些程序逐渐变得低效甚至无法使用。
他们还开发了一个名为「SlopCodeBench」的评测基准，直截了当地测试AI生成的糟糕代码到底有多退化。
我们被误导了吗？
首先，你是否经常看到这样的报道：
«GPT-5在编程测试中的正确率超过了SWE-Bench！»
«Claude Opus编写代码的成功率为90%以上！»
«新模型击败了80%的程序员！»
......
每一项测试都要求AI一次性完成一个固定需求，确保它能够通过所有测试用例。
然而，在现实开发中，哪位产品经理会在一开始就将全部需求提供给你？哪个项目不会在中途添加新功能或修改逻辑？
本质上来说，现在的AI编程评测就像是一场开卷考试，只要一次性考满分就行。但真正的软件开发更像是每天增加一门课程，并且课本内容不断变化，你需要根据旧笔记不断补充新的知识。
这种测评与实际情况的脱节直接造成了「AI编写代码比人类更优秀」这一虚假繁荣的局面。
SlopCodeBench的研究揭示了一个重要的事实：目前的人工智能离完全替代程序员还相差甚远。它们更像是能够快速完成短期任务的学生，但在长期项目迭代中却力不从心。
给非技术背景的读者一个建议
请不要被「AI可以在几分钟内创建系统」这样的说法所迷惑。软件开发的核心成本在于后续几年中的修改和维护工作。尽管人工智能可能能够迅速完成初始版本，但每次改动的成本都会翻倍增加，最终总成本比人类编写代码要高出很多。
1. 不用担心你的饭碗会被AI抢走，至少目前而言，那些有能力把控长期架构并能有效管理项目迭代的开发者仍然非常珍贵。
2. 在使用人工智能编写代码时，不要直接让其修改现有的复杂核心逻辑。最好先让它提供设计方案参考，然后自己来控制架构设计，再由它完成具体的实现工作，并且要进行严格的代码审查流程。
3. 别在如何通过提示词指导AI创建优质架构上耗费太多时间，因为目前这方面的技术还远未成熟。重要的部分还是需要你自己来进行设计。
4. 可以多关注一些专门用于检测和优化AI代码质量的工具，未来你可能经常要做的是为这些程序生成的低效代码进行清理和修复工作。
至于人工智能编程技术未来的方向，本次研究已经指出了一个明确的方向：不要再专注于单一任务的成功率了，而是应该考虑如何让它们学会像人类一样关注长期维护和发展，即具备设计纪律性，了解编写高质量软件不仅仅是完成一次性的编码任务。
......
总而言之，软件工程的核心在于创建能够随着时间推移而不断改进和扩展的代码库。如果AI无法跨越这一关键障碍，那么它将永远只能作为一个一次性工具存在。
最狠的是这三条规则，完全不给AI开外挂：
1. 不预设任何内部接口：只告诉你外部要做成啥样，代码架构怎么设计、函数怎么拆，全靠AI自己定，相当于产品只说「我要个能聊天的APP」，技术方案全靠你想。
2. 不暴露测试用例：AI只能像人类开发者一样，对着需求文档自己想边界情况，写完了才知道哪里错了，不会给你把所有测试用例列出来让你对着改。
3. 必须在上一轮的代码基础上改：不能每次都重写，就像你接了前任的烂摊子也得接着维护，不能上来就说我要重构。
两个指标直击「烂代码」本质
这次研究者没搞虚的「通过率」，而是直接抓了两个所有程序员都深恶痛绝的烂代码特征：
1. 结构侵蚀（Structural Erosion）
说白了就是代码逻辑全堆在少数几个「超级函数」里。比如你最开始写登录逻辑是个20行的小函数，后来加了七八个需求，AI懒得拆新函数，直接往里面堆代码，最后一个函数塞了上千行，圈复杂度（简单理解就是逻辑分支的数量，越高越难改）飙到几百，改一行崩十行。
研究者的计算方式也很直观：先算每个函数的「复杂度权重」= 圈复杂度 x 代码行数的平方根，再看圈复杂度超过10的高风险函数，占了整个项目总权重的多少，比例越高代码越烂。
2. 冗余度（Verbosity）
就是代码里重复的、可以简化的垃圾内容占比。比如同样的参数解析逻辑，AI在8个地方抄了8遍；明明可以用循环实现的逻辑，AI写了十几行重复的if-else。研究者用137条规则扫描常见的冗余模式，再加上克隆代码检测，直接算出你写的代码里有多少是没用的废料。
测试结果扎心了：所有AI全败，没有一个能打
研究者测了当前市面上最能打的11个模型，包括Claude Opus 4.5/4.6、GPT 5.1-5.4、GLM 4.7，结果没有一个能打的，直接把AI编程的底裤都扒了：
连一个完整项目都做不下来
没有一个AI Agent能从头到尾完成任何一个问题的所有检查点，哪怕是当前最强的Claude Opus 4.6，严格通过率也只有17.2%——相当于做10个项目，8个半都是烂尾的。
更吓人的是退化速度：
80%的项目里，AI代码的结构侵蚀随着迭代持续上升
89.8%的项目里，冗余度一路走高，根本停不下来
最开始核心功能测试和全量测试的通过率只差1.4倍，到后期直接差到13.3倍——也就是说，表面上核心功能好像还能跑，实际上边角的逻辑已经烂透了，一碰就崩
研究者给大家举了个真实案例：在 circuit_eval（电路模拟器）这个问题里，Claude Opus 4.6最开始的 main() 函数只有84行，圈复杂度29，还算是个正常的代码。经过8轮需求迭代之后，这个函数直接膨胀到了1099行，圈复杂度飙到285，9个命令分支抄了9遍完全一样的参数解析逻辑，你想加个新命令，得先把这9遍逻辑全改对，少改一个就报错。
这像不像你做项目的时候，前两期跑得挺顺，到第三期加需求的时候发现之前的代码写死了，只能加班重写？AI跟你犯的错一模一样，甚至更离谱。
AI写的代码，比人类屎山还烂2倍
研究者还专门找了48个不同Star量级的Python开源仓库做对比，从几千Star的小工具到scikit-learn、scipy这种明星级项目，结果AI的脸被打得啪啪响：
直观对比就是：
冗余度：AI Agent代码是人类代码的2.2倍！
结构侵蚀：AI Agent代码是人类代码的2.2倍！
违反率：AI Agent代码是人类代码的2.9倍！
更扎心的是：连以复杂度高著称的scikit-learn（0.411）和scipy（0.457），都比AI写的代码健康得多。
研究者追踪了20个开源仓库好几年的提交记录，发现人类写代码，只要是正经维护的项目，质量基本保持平稳，甚至会越重构越好。但AI写的代码，每迭代一次质量就掉一截，根本没有停下来的意思。
说句不好听的：你吐槽了一万遍的公司祖传屎山，都比AI迭代几轮写出来的代码质量高。
提示词也救不了！越改越贵，还越改越烂
看到这里肯定有程序员会问：是不是我提示词写得不够好？我让AI先写设计文档、让AI不要写冗余代码、让AI注意架构，是不是就能解决问题？
研究者专门做了提示词干预实验，测试了两种程序员最爱用的「魔法提示」：
1.「反slop提示」：明确告诉AI不要写重复代码、不要过度工程化、要拆函数、要避免冗余模式。
2.「先规划提示」：要求AI先写详细的设计方案，确认没问题再写代码。
结果怎么样？确实，初始质量有改善：冗余度降低了33%~34%，前两轮的代码看起来确实干净多了。
但重点来了：退化速率一点没变——两条退化曲线几乎是平行的，无非是一个起点低一点，一个起点高一点，到最后都会烂到没法看。正确率更是没有一丁点提升，统计检验直接显示没有显著差异（Wilcoxon检验，p > 0.05）。
更讽刺的还在后面：干净的代码反而更贵！GPT 5.4用了「反slop」提示之后，完成项目的花费从304美元涨到了450美元，涨了快一半，但通过率反而从37.2%掉到了27.1%——钱花得更多了，活干得更烂了。
为什么会这样？因为AI为了写更干净的代码，会花更多token去思考架构、去拆函数，但它本质上还是没有长期架构设计的能力，后面改需求的时候，该乱堆还是乱堆，该重复还是重复，前面花的那些设计的钱，全打了水漂。
根本问题：AI根本不懂「设计纪律」
为什么AI单次写代码那么厉害，迭代起来就这么拉？核心原因其实很简单：当前的AI编程Agent，根本没有迭代式软件开发需要的「设计纪律」（设计规则）。
人类开发者写代码的时候，脑子里是有「长期规划」的：
我现在写这个函数，后面可能要加三个功能，所以得预留好扩展点
这个逻辑后面好几个地方要用，得抽成公共函数
现在为了快写死的地方，得留个TODO注释，后面有空了重构
加新功能的时候，会想怎么改不影响之前的逻辑，实在不行就提前重构打基础
但AI没有这个意识，它所有的决策都是「短期最优」：当前这一轮需求我要最快跑通，怎么简单怎么来。
要加新功能？直接往已有函数里堆代码，反正这次能跑就行
逻辑重复？复制粘贴八遍最快，我才懒得抽公共函数
之前的架构不适合新需求？不管，硬塞进去就行，只要这次测试能过，后面崩了再说
你看AI写的代码，每一轮单独看好像都没问题，合到一起就是个随时会炸的火药桶。这不是能力问题，是「思维模式」的问题：人类写代码是给未来的自己和同事写的，会考虑长期维护成本；AI写代码是给当前这轮prompt写的，根本不管后面怎么改。
现在的所有评测，都在奖励AI的「短期行为」：只要这次能过测试，你代码写得再烂都算对。但真实的软件工程，要的是「长期可维护」，这恰恰是当前AI最缺的东西。
最后说两句
这次SlopCodeBench的研究，本质上是给现在热得发烫的AI编程浇了一盆冷水：我们离「AI替代程序员」，还差了十万八千里。现在的AI更像个能干的实习生，给你写个小工具、做个一次性的脚本、帮你查个API用法都没问题，真要让它负责一个长期迭代的项目，最后擦屁股的还是你自己。
给非技术读者说句实在话
不要被「AI几分钟写一个系统」的噱头骗了，软件的核心成本从来不是第一版怎么写，而是后面几年怎么改、怎么维护。AI写的第一版确实快，但后面每改一次成本翻倍，最后总成本比人类写的高好几倍，这账算下来一点都不划算。
给程序员朋友的建议
1.不要怕AI抢你饭碗，至少现在，能把控长期架构、能维护迭代项目的开发者，比任何AI都值钱。
2.用AI写代码的时候，不要直接让它改旧代码，尤其是复杂的核心逻辑。最好让它给你写方案参考，你自己来控制架构，再让它写具体的实现，写完了你要做Code Review，别什么代码都往仓库里提。
3. 别在「怎么写提示词让AI写出好架构」上浪费太多时间，这玩意儿目前真的救不了，该你做的设计你得自己做，甩锅给AI最后背锅的还是你。
4.反而可以多关注「AI代码质量检测」相关的工具，以后你大概率会经常干「给AI擦屁股，改它写的烂代码」的活，有工具能省不少事。
至于AI编程未来怎么走？这次的研究其实已经指了个很明确的方向：别再卷单次任务的通过率了，是时候想想怎么让AI学会「为未来写代码」，学会像人类一样有设计纪律，知道写代码不是一锤子买卖。
毕竟，软件工程的本质，从来都不是写能跑的代码，而是写能改、能维护、能活好几年的代码。这个坎，AI要是跨不过去，就永远只是个写一次性代码的工具而已。