AI 写代码正在变“水”，但烂代码未必会赢
AI 把代码产量拉满，也把焦虑一起拉满
这两年，AI 生成内容有了一个不太体面的流行词：slop。中文很难找到完全对应的词，大概介于“机器灌水”“低质堆料”“看起来像那么回事、其实经不起推敲”之间。最早大家用它来吐槽互联网上泛滥的 AI 图片、营销文案和垃圾信息，现在，这个词已经顺着网线爬进了软件行业——变成了“AI 写出来的一坨代码”。
Greptile 在 3 月底发了一篇博客，标题很直接：《Slop Is Not Necessarily The Future》，翻成大白话就是：“代码垃圾不一定就是未来。” 这篇文章之所以值得看，不是因为它喊了句政治正确的口号，而是因为它试图回答一个如今所有工程团队都绕不开的问题：当 AI 编程助手越来越能写、越来越敢写，程序员是不是正在把“先跑起来再说”升级成“先生成再说”？
Greptile 给出了一组很有冲击力的数据。在它们的 2025 年 AI 编程现状报告里，单个开发者产出的代码行数，从 4450 行增加到 7839 行；PR 的中位改动规模，从 57 行涨到 76 行；文件变更也更大、更密。说得直白些，开发者正在借助 AI 更快地往生产环境里“倾倒”代码。这当然很爽，谁不喜欢效率暴涨的感觉？但另一面也很清楚：代码写得越快，团队就越容易把本该在设计阶段解决的问题，延迟到测试、上线、报警和深夜回滚里去解决。
这也是为什么很多工程师最近有一种很微妙的心情：白天觉得 AI 像外挂，晚上又担心自己是不是在给未来埋雷。Node.js 之父 Ryan Dahl 那句“人类写代码的时代结束了”，听上去像宣言，也像叹气。Karpathy 对 agent 生成代码的评价更接地气：抽象膨胀、代码美感差、特别爱复制粘贴，一团乱麻。你看，连最懂模型的人，说到这里时都没什么赛博浪漫，只剩工程现实主义。
真正的问题不是 AI 会不会写，而是写出来的东西贵不贵
Greptile 文章最有价值的地方，在于它没有停留在“我们都希望代码更优雅”这种空话上，而是把问题拽回到一个更硬核也更残酷的维度：经济性。
软件行业一直有个老道理，John Ousterhout 在《A Philosophy of Software Design》里讲得很透：复杂度是软件设计的头号敌人。所谓好代码，未必是最炫技的代码，而是简单、易懂、易改。坏代码则正相反，它需要大量上下文才能理解，一改就牵一发而动全身。过去这是团队协作成本问题，到了 AI 编程时代，它突然又多了一层新含义：上下文越复杂，模型理解和修改代码所需的 token 就越多，算力和费用也就越高。
这件事特别像搬家。一个收纳良好的房间，打包和整理都很快；一个堆满杂物的房间，光是决定什么该扔什么该留，就能把人折腾半天。AI 改代码也是这样。代码库越臃肿、依赖越混乱、抽象越套娃，模型每次“动刀”前就越需要吞下更多上下文。今天你也许觉得“让 AI 多看一点没关系”，但当项目规模从几千行长到几百万行，当团队开始频繁依赖 agent 自动修 bug、写测试、做重构，这些 token 成本会像云账单一样，月底突然让你心脏一紧。
所以 Greptile 的判断是：长期来看，市场不会奖励 slop。 原因不是道德觉醒，而是烂代码太贵了。它贵在生成时需要更多上下文，贵在修改时容易牵连更多模块，贵在维护时容易引发更多事故，也贵在系统越长越大之后，复杂度会近乎失控地放大。这是一个很典型的技术行业结论：短期内，混乱能换来速度；长期看，只有结构化的秩序才配得上规模化增长。
为什么这个时间点特别关键：行业正处在“先能用，再谈优化”的混乱窗口
如果把 AI 编程的发展比作造路，现在其实还处在“先让车能开上去”的阶段。很多公司部署 AI coding assistant，并不是因为它已经完美，而是因为大家都怕错过下一轮生产力红利。于是行业的普遍心态就变成了：先把生成能力接进开发流程，后面再谈规范、质量和治理。
这也解释了为什么今天的 AI 编程世界，呈现出一种很奇特的双重景象。一边是 GitHub Copilot、Cursor、Codeium、Devin、各种 agent 框架和代码审查工具层出不穷，仿佛软件开发正在进入自动化黄金时代；另一边则是越来越多团队在抱怨，AI 确实写得快，但写出来的东西并不总是适合进入一个真实、长期维护的代码库。你会看到重复函数、表面正确的抽象、不必要的封装，以及“能跑但说不清为什么这么写”的实现细节。
这不是哪个产品单独的问题，而是整个行业在高速冲刺时的共同副作用。模型厂商现在最关心的是 benchmark、响应速度、工具调用能力、多文件编辑能力，至于“代码审美”——或者说软件工程纪律——很多时候还排不上优先级。因为市场的早期买单逻辑也很现实：先证明能提效，再证明提得稳，最后才轮到提得优雅。
我个人觉得，Greptile 对这一阶段的描述是准确的：我们正在经历一个脏、乱、快的创新窗口。 它像互联网早期的内容农场时代，也像移动互联网初期那种“先发版、后修 bug”的蛮荒增长。区别只在于，这次被批量生产的不是页面和 App，而是构成数字世界骨架的代码本身。换句话说，这场混乱比看上去更深，因为它会直接影响未来软件基础设施的可靠性。
“好代码会赢”并不自动发生，它还需要工具、流程和文化一起补课
Greptile 的乐观判断有道理，但我不完全认为“经济规律”会自动把行业拉回正轨。市场确实会惩罚昂贵、脆弱、难维护的系统，可问题是，很多代价往往不是立刻体现，而是以 outage、技术债、招聘困难、迭代变慢这些形式慢慢积累。等你真正感受到痛，可能已经晚了。
这意味着，“好代码会赢”并不是一个自然掉落的结局，而更像一场需要多方配合的工程治理。模型需要更擅长理解大型代码库，而不是只会局部续写；代码评审工具需要从“找语法和逻辑错误”升级到“识别结构性复杂度”；企业内部也要重新定义什么叫高质量交付——不能只看提交量、关闭工单数和发版速度，还要看可维护性、回归成本和事故率。
这也是 Greptile 这类 AI Code Review 产品想切入的位置。它们赌的是下一个阶段：当大家都能生成代码之后，谁来约束、筛选、纠偏这些代码，会变得比“谁能多生成一点”更重要。某种意义上，软件开发正在从“人写机器审”转向“机器写机器审，人负责兜底和裁决”。这是个颇有戏剧性的变化：程序员不会消失，但会越来越像建筑工地上的总包经理，真正下手搬砖的，可能是一群高效但偶尔冒失的 AI 工人。
这里还有一个值得深想的问题：如果未来 AI 生成的“好代码”只是因为更省 token、更容易被下一个 AI 理解，那它究竟是在为人类优化，还是在为机器优化？理想状态当然是两者一致——简单、可读、可维护，本来就是人和机器都喜欢的品质。但如果某一天，模型开始偏爱某种“对模型友好、对人类别扭”的写法，软件工程会不会出现新的审美分裂？这可能是下一轮争议的起点。
软件行业终究会回到一个朴素结论：简单不是保守，而是竞争力
过去十几年，软件工程圈一直在反复重申一件听起来很无聊、但总能被现实验证的事：简单比聪明更值钱。 只是以前，这个道理主要靠资深工程师口耳相传；现在，AI 把它变成了一笔可以被量化的账。
你可以让模型在一天里给你生成十个功能，也可以让它把一段逻辑拆得花里胡哨、封装得像俄罗斯套娃，短期看交付速度可能都很漂亮。但真正决定一家团队会不会被技术债拖垮的，从来不是今天多写了多少行代码，而是半年后谁还敢改、谁还能看懂、谁改完不会出事故。代码量上升不等于软件质量提升，正如一篇作文写到五千字，也不自动意味着它更有思想。
所以我赞同 Greptile 的核心结论：AI 编程的未来，不会永远停留在“先生成一坨再说”的阶段。只是这个拐点不会靠善意自动到来，它会靠成本压力、生产事故、团队治理和市场竞争，一点点把行业逼回“写清楚、写简单、写能维护”的老路上。讽刺的是，AI 越强，软件行业也许越会重新发现那些最传统的工程原则。
说到底，代码这门手艺并没有过时。它只是从“亲手写每一行”变成了“决定哪些行值得存在”。在这个意义上，程序员的工作不是消失了，而是变得更像编辑、设计师和守门人。AI 可以写很多，但真正稀缺的，依然是判断力。