代码腐化，比想象中更快：盲目Vibe Coding的副作用正在悄然发生

Vibe Coding 概念的推出，以及某公司宣称自己软件代码100%由AI生成，让一些公司像发现了软件开发提效的银弹，甚至制定了极具冲击力的目标：90% 的代码通过 AI 生成，仿佛慢一步就要被时代抛弃。

这股热潮可以理解，我本人也是AI开发的实践者。在使用AI开发的过程中，我意识到如何保障质量至关重要。在实际项目中，我发现代码质量代码腐化的速度，比我想象中快得多。

AI Review：它能看代码，却看不懂“意图”

在 Vibe Coding 之前，部门已落地 AI 代码审查，目标是让 AI Review 替代人工 review。听起来完美，但实践中效果有限。

AI 的判断完全依赖模型能力，对于复杂的业务逻辑，即使是最强的大模型，也很难识别业务逻辑问题。在满是历史债务的系统里，很多需求、设计决策早已模糊不清。AI往往看得懂代码，看不懂业务。如果一味的追求数字目标，结果可想而知。

在实际项目里，我依然会人工review代码，也观察到一些 Vibe Coding 推广后的现象。

能跑，但要命的改动

A 同学修复了一个 Bug。AI 改的代码确实能跑，但设计很糟糕，在父组件里直接读取子组件状态，直接通过实例去调用子组件的子组件内部的方法。这种代码一多，维护成本立刻飙升。

我问他为什么这么写，他答：“AI 写的”。那一刻我意识到，AI 不是让人更自由，而可能让人更懒。

无意义的注释与语义不符的命名

B 同学的提交里，一堆 AI 写的注释，类似“将变量 a 与 b 相加得到 c”，这种注释的意义在哪里。

类似的，还有随机字符串命名的 css class，以及不明所以的js变量名。明显是AI的杰作，但是作为开发人员，这就是你输出的代码，代表个人的水平。

AI 修 Bug，不复用原逻辑

我自己用使用 AI 修复 Bug。AI 修改是对的，但完全没复用原逻辑，即使原代码里有现成的分支，AI却另起炉灶。无独有偶，也有开发同学出现了相同的情况。

迁移项目中的“复制思维”

某个需求需要把旧平台的模块迁移到新平台，我们很自豪地说整个模块100%的编码是100%生成的，提升了75%以上的效率。结果代码走读，迁移后代码里存在大量代码规范、冗余逻辑、无效逻辑、以及仍不确定的场景等问题。

当指出这些问题时，开发同学的回答往往是两句经典台词：“AI 写的”，或者“原来代码就是这样”。看似无辜，却折射出一个更深层的问题——当责任可以推给 AI，人类的判断力也在被消解。

开发者变成了搬运工，不再关注代码设计和质量。这种“复制式迁移”看似省事和提效，实际在无形中制造了更多技术债务。

这些现象让我越来越清楚，Vibe Coding 真正的风险不是AI 写错代码，而是开发者放弃了思考的主动权。

很多人现在习惯于“AI 生成、自己点确认”，不再去推敲设计、也不主动 review 自己的代码，不为自己提交的代码负责。久而久之，代码腐化速度反而更快。它不是十年后的老项目才会烂，而是“刚写完就开始老化”。

AI 给了我们提效的能力，也在削弱我们对质量的敏感度。当设计意识下降、代码审查依赖模型、团队节奏追求更快交付时，腐化几乎是必然的结果。

我不反对 Vibe Coding，相反我是实践者。去年我用 AI 开发了环境管理平台，90% 的代码由 AI 完成，开发速度惊人。作为个人原型项目，我基本上放弃了审核，任由AI生成代码、AI解决问题，只有AI解决不了的才人工处理。实际查看生成的代码，远达不到正式产品的质量，也无法实长期维护。

AI 的价值在于“放大”，它能放大一个人的能力，也能放大他的短板。对思考敏锐的开发者，它是倍增器；对缺乏设计意识的人，它是烂代码产生的加速器。

幸运的是，越来越多的团队开始意识到这些问题。比如业界提出的“规范驱动开发”，用明确的约束和规则让 AI 编程更稳健。而开发者的角色也会有很大的转变，开发者的责任不再是“写代码”，也不是只会点击接受代码的机器，而是指挥AI的“管理者”。