> 它正在制造一种新的屎山：从来没有人理解过的那种。

一、先说结论

用 Vibe Coding 大半年，我的体感是：它确实极大提升了产出速度，同时在史无前例地制造一种新的技术债。

但我想先排除一个误解——问题不在于"AI 写的代码质量差"。这个说法不准确，AI 写出来的代码往往相当体面，比很多人手写的还整齐。

真正的问题是成本结构变了：

生产代码的成本降到了接近零，理解代码的成本一分没降。

任何系统里某个环节的成本骤降，瓶颈都会转移。现在瓶颈全部压在了"人的理解带宽"上，而这个东西没法靠加钱、加人、加显卡扩容。

更麻烦的是，这个失衡不是靠个人自觉能纠正的。它已经变成了一道结构性的选择题，而且大多数人在这道题上的最优解，恰好是让系统持续恶化的那个选项。

二、那道没人愿意明说的选择题

很多人把"没人 review AI 生成的代码"归结为工程师不负责任。我认为完全不是。

摆在每个人面前的其实是这样一道题：

选项 A：不用 AI。 产出是同事的三分之一，考核垫底，年底不好看。在今天的环境里，这基本等于主动退出竞争。

选项 B：用 AI，但认真 review。 AI 三分钟生成六百行，你花两小时读完、改完、想明白。总耗时可能比手写还长——你付出了 AI 的所有成本，却没拿到 AI 的任何收益。

选项 C：用 AI，不 review。 产出爆炸，交付飞快，绩效漂亮。代价在六到十八个月后出现，而那时候你可能已经换组，或者跳槽了。

在只考核交付速度的记分牌下，C 是严格占优策略——不管别人怎么选，你选 C 都不亏。

这就是我说"囚徒困境"的意思。每个人都在做局部理性的选择，合起来把整个系统推向一个所有人都不想要的状态。指望靠"提升职业操守"解决，等于指望囚徒困境里的两个人凭良心不招供。

而且这个困境有两个特别恶劣的性质。

第一，收益即时可见，成本延迟且弥散。 快，是本周就能看到的三个需求；债，是一年半后交付周期从两周变成两个月，而且没人说得清是哪一行代码造成的。在这种反馈延迟下，组织根本不具备学习能力。

第二，它会自我强化。 团队里只要有人选了 C，交付基线就被抬高了。剩下的人要么跟进，要么显得很慢。所以这不是"有些人偷懒"，是慢下来的人会被系统淘汰。

标题里那句"没人敢慢下来"，说的就是这件事。不是不想，是不敢。

三、屎山的性质变了

屎山一直都有。但过去的屎山，是曾经有人懂过的屎山。

写它的人脑子里有一套心智模型：为什么这里要绕一下、为什么这个字段不能删、为什么这段逻辑看起来蠢但删了就出事。这套模型可能没写进任何文档，写它的人可能三年前就离职了，但代码里残留着模型的痕迹——命名的习惯、结构的规律、绕过某个坑的怪异写法。所以考古是可能的：你盯着看半天，能还原出当时那个人在想什么。

现在的屎山不一样。它是从来没有人懂过的屎山。

Peter Naur 在 1985 年写过一篇文章，Programming as Theory Building。核心观点是：编程真正的产物不是代码，而是程序员脑子里那套关于"为什么这样设计"的理论；代码只是这套理论的一个不完整投影。团队解散、理论失传，即使代码完好无损，项目实际上也已经死了。

按这个框架看，Vibe Coding 干的事情是：批量生产投影，但理论只短暂存在于模型的上下文窗口里，会话一结束就蒸发。

你手上剩下的，是一堆没有原像的影子。

四、不是"低质量"，是"高复杂度"

传统的烂代码是显性的。三百行的 if-else 嵌套，一个函数干八件事，变量名叫 tmp2。经验丰富的人扫一眼就知道有问题，看着难受，会想改。

AI 生成的代码通常长这样：

PaymentOrchestrationEngine
TransactionLifecycleManager
RiskEvaluationPipeline
SettlementStateResolver
RetryStrategyFactory

架构完整、分层清晰、设计模式齐全、注释详尽、接口漂亮。

然后你花两小时读完，发现这十几个类干的事情，本质上是：查一下订单状态，失败了重试三次。

这种代码的危险之处在于，它不难看，所以你不会想改它。它看起来很专业，所以 review 的时候你会倾向于放行。它的复杂度是装饰性的——不解决任何真实问题，纯粹是成本。

而且它有传染性。下一个人要加功能，会顺着现有的抽象继续加，因为看起来这是"规范做法"。三个月后，那个"重试三次"的逻辑分散在六个文件里。

再举个具体的。需求是"提升支付失败后的恢复能力"，AI 会给你：自动重试、状态同步、熔断、事件总线、多策略恢复引擎。技术上完全正确。但业务上你知道，这个场景一年发生四十次，运营手动处理一次五分钟。

AI 优化的是"技术完备性"，而不是"这件事值不值得做"。它没有成本概念，因为它不承担成本。

五、能不能靠 AI review AI 破局

这是我一开始觉得死路一条的地方：既然人没时间 review，那就让 AI review AI 好了——但 AI 的错由 AI 来查，不等于没查吗？

后来我认为这个推论是错的，关键变量是误差相关性。

"用 AI 检查 AI 等于没检查"这个直觉，隐含的假设是：检查者和生成者会犯同样的错。这个假设在某些配置下成立，在另一些配置下完全不成立。

同一个模型、同一段上下文、同一个会话，你问它"你刚才写的对吗"——它的盲点和它写代码时的盲点是同一个盲点。这时候确实是自我安慰。

但换一种机制，相关性就断了：

让它写测试，而不是让它"检查"。 写测试时它面对的是行为规格，不是实现细节，思考路径不同，暴露的错误也不同。而且读 100 行测试比读 1000 行实现，信息密度高一个数量级。

property-based testing 和 fuzzing。 这里的检查者根本不是 AI，是随机数和不变量。它不需要理解你的业务，只需要知道"任何情况下账户余额不能为负""任何路径下资金总额守恒"。

类型系统、契约、断言、编译期约束。 编译器不懂业务，但它绝不撒谎，也绝不会因为代码看起来很专业就放行。

让它解释，而不是让它判断。 "这段代码在并发下会怎样"比"这段代码对吗"有用得多。前者产出的信息你能自己判断，后者你只能选择信或不信。

而最强的验证者根本不是任何 AI，是现实：跑起来了吗，压测过了吗，灰度那 1% 的流量炸了吗，监控曲线动了吗。现实的误差和模型的误差之间，相关性为零。

所以这不是死循环，是个降噪问题。你不需要一个完美的检查者，你需要若干个失败模式互相独立的弱检查者。冗余、多样性、纵深防御——工程上的老套路，不是新发明。

这里还有个反转：过去测试是奢侈品，因为写测试也要花人的时间，所以永远排在需求后面。现在生成成本塌了，测试反而成了性价比最高的东西。

从"审查代码"转向"审查规格和测试"，可能是这一轮里唯一现实的出路。

值得注意的是，这条路之所以可能走通，恰恰因为它不要求你慢下来。它没有试图让你退回选项 B，而是在困境内部造了个新选项：产出速度不变，但验证由机器承担。这是个人能单方面做的事，不需要任何人批准。

六、真正该守的是边界，不是可读性

代码量超出人类理解范畴，其实早就发生了。Linux 内核三千万行，没有任何一个活人理解它；你手机里从硅到 UI 的整个栈，也没有任何人能完整解释。

我们从来不是靠"理解全部"活下来的，是靠局部理解 + 边界隔离。我不知道 TCP 栈里发生了什么，但我知道 socket 的契约；我不理解数据库内部，但我依赖它的事务语义。

所以"AI 写了我看不懂的代码"本身不是新问题。真正的问题被压缩成一句话：

那些代码，有没有被关在足够小、足够严的盒子里。

技术债的代价主要来自耦合，而不是行数。一万行没人懂但被三个清晰接口包住的代码，可以随时整体删掉重写；三百行渗透到全系统各处的没人懂的代码，才是真正会要命的东西。

由此得到的姿态不是"退回去手写"，而是：

人守边界，AI 填内部。

你把精力花在定义模块边界、接口契约、数据形状、失败语义上——这些必须由人来定，而且要少、要小、要严。内部实现让 AI 随便造，造烂了整块删掉重来。

在这个模式下，你追求的不是"能读懂"，而是"能丢弃"。可丢弃性在当下是比可读性更实际的目标。只要还能整块重写，屎山就不是死局。

顺着这个逻辑，还有一件事值得区分：哪些代码是资产，哪些是消耗品。 一次性脚本、内部工具、原型、迁移脚本、胶水层——生命周期本来就短，脏就脏，能跑就行，过期删掉，AI 在这个区间是纯赚。灾难只发生在你把消耗品混进了资产里：让 AI 生成的东西沉淀进核心域、成了要长期演化的模块、变成了别人依赖的接口。

写到这里，标题里那个问题可以回答了：

Vibe Coding 和 Trash Coding，用的是同一个模型、同一个 IDE，甚至同样的 prompt。区别不发生在生成的时候，而发生在生成之后——有没有人给它划一条边界，以及这堆东西还能不能被整块扔掉。

七、为什么这个困境不会自己消失

上面所有手段，技术上都不难，也都是已知的。真正难的部分在别处，有两个。

第一，激励结构没有变。

严格边界、验证设施、定期熵回收、控制生成粒度——这些全都是"现在花时间、以后才见效"的事。而记分牌只记录交付速度。

这不是"不知道怎么办"，是"知道了也没人愿意办"。技术问题通常有解，组织问题往往真的没解，只能等撞墙。

还要补一句：成本其实不落在"组织"头上。组织是个抽象概念，它不会痛。痛的是凌晨三点被叫醒的那个人，是接手了一个没人懂的模块的那个人，是被质问"这么小的改动怎么要两周"的那个人。而这些人，通常不是当初图快的那个人。

这不叫短视，叫成本转移：系统性地把代价从决策者转移到执行者、从现在转移到未来、从跳槽的人转移到留下的人。这种结构一旦形成，靠内部说服基本改不动，因为受益方没动力，受损方没话语权。

这也是为什么我说它是囚徒困境而不是简单的认知问题——在现有的收益矩阵下，所有人的选择都是对的，只是加总起来是错的。

第二，人才断层，这个我认为比代码质量严重得多。

高级工程师的判断力，是从"亲手写过、亲手 debug 过、亲手被坑过"里长出来的。你知道哪里会炸，是因为你炸过。

如果新人从入行第一天起就只做 prompt 和验收，那五年后谁来定边界？谁来判断哪个抽象是必要的、哪个是装饰性的？我们现在是在消耗存量经验，而没有生产新的。

这件事的时间常数是十年，等发现的时候已经来不及了，而且它没有技术解法。

八、那这个问题能被"解决"吗

我的判断是：不能解决，但"解决"这个词用错了。

想想 bug。我们解决 bug 了吗？一行没少。但我们让 bug 变得可存活了：版本控制让你能回滚，测试让你早点发现，灰度让爆炸半径可控，监控让你在用户投诉前知道。

今天没有人认为"bug 问题"被解决了，但也没有人觉得它是行业级威胁。

屎山问题的终局大概率是同一种形态：不是消失，而是代价被压到收益之下。判断标准不是"代码干不干净"，而是：

重写一个模块的成本，是不是低于它带来的价值。

只要这个不等式成立，屎山就只是丑，不是致命的。

还有一种更彻底的可能，是问题本身失效。

今天没有人 review 编译器输出的汇编。为什么？因为编译器足够可靠，汇编成了中间产物，丑不丑无所谓。如果有一天代码也变成中间产物——你维护的是 spec 和测试，实现随时可以重新生成——那"AI 写的代码很屎"就跟"编译出来的汇编很难看"一样，不构成问题。你甚至不需要理解它，只需要能扔掉它。

这是唯一能让问题真正消失、而不只是被管理的路径。

但它现在还不成立，缺的关键一环是：编译器是确定性的、可验证的，模型不是。 同样的输入两次生成不一样，也没有形式化的正确性保证。在这一环补上之前，代码还不能被当作可丢弃的中间产物，你还得对它负责。

我的猜测是折中：CRUD、胶水层、前端、脚本这些领域会先到达"代码即中间产物"的状态；核心域和高风险系统会长期停留在"人守边界"的模式。至于那一环什么时候补上、会不会补上，我不知道，也没有能力判断——这是全文我最不确定的一句话。

九、如果你也在这个处境里

务实地说，与其纠结怎么改变整个行业的激励结构，不如先做那些不需要任何人批准、也不会拖慢你交付速度的事。

第一，从你真正负责的地方开始。

一个人改变不了整个系统的熵增速度，但可以先守住自己 own 的那部分——边界收窄一点、契约明确一点、可丢弃性保住一点。这不是划地自守，而是这些手段本来就只在你有决策权的范围内才生效：你没法给别人的模块定契约。

第二，改变工作方式，而不是等流程。

这些都属于个人习惯，成本极低，也不占用别人的时间：

• 控制单次生成的粒度。一次 50 行你还能验，一次 500 行你只能祈祷。
• 让 AI 解释它写了什么，而不是只让它写。用它便宜的输出补你的理解。
• 优先让 AI 写测试，而不是让 AI 检查代码。
• 保持可丢弃性：新东西尽量放在能整块删除的边界内。
• 定期做熵回收——专门排时间删代码、合并重复、收紧接口。这件事不主动排期，就永远不会发生。

需要强调的是：这些做法之所以可行，是因为它们不以牺牲交付速度为前提。任何需要你"慢下来"的方案，在前面那个困境里都是活不下来的。这也是我认为它们比"呼吁大家重视代码质量"更现实的原因。

第三，分清什么是你的债，什么不是。

技术债本质上是个金融工具，不是道德问题。一家现金流只剩 18 个月的公司，用可维护性换速度是完全理性的——因为债务到期之前，那笔利息可能永远不用付。

真正的问题从来不是"欠债"，而是没人知道自己在欠债，也不知道利率是多少。所以值得做的事情不是自己一个人扛质量，而是让这笔债变得可见：它有多大、什么时候到期、谁来还。

有一种消耗方式很常见——某个人默默扛下所有质量问题，没人要求、没人知道、也没被计入任何排期，最后自己耗干。这既帮不到团队，也帮不到自己。债务应该被记录和讨论，而不是被某个人偷偷垫付。

结语

Vibe Coding 是真实的生产力跃迁，我不打算唱衰它，我自己每天都在用。

但它把软件工程里一个一直存在的矛盾，从慢性病变成了急性病：我们生产代码的能力，永远快于我们理解代码的能力。 过去这个差距是线性拉开的，现在是指数的。

而囚徒困境的破解方式，从来不是靠说服每个囚徒变得高尚，是靠改变收益矩阵。

好消息是，收益矩阵正在被动改变——因为反馈周期也被压缩了。过去技术债的报应要五年才来，长到没人需要为后果负责，因果链断裂，所以行业永远学不会。现在缩到一年半：会有一批公司在很短时间内、很显眼地撞墙，交付速度断崖式下跌、事故频率上升、小改动要排两周。而且撞得足够快，快到当初拍板的人还在场。

工程实践从来不是靠讲道理推广的，是靠尸体。CI、版本控制、自动化测试、code review，每一样在普及之前都死过一批项目。我猜三到五年内会攒够尸体，"AI 时代的工程纪律"会成型，会有工具、有咨询、有布道师。

在那之前，还有个反直觉的地方值得说：越是大多数人跳过"理解代码"这一步，还保有判断力的人就越稀缺。 定边界、知道该验证什么、能看出哪里会炸——这些能力正在批量失传。

如果你现在也有那种"效率明明上去了，心里却发虚"的感觉，我觉得那不是矫情。

那是你还在练这块肌肉的证据。

---