夜雨聆风Vibe Coding 一年，是时候让我们回顾一下得失了。
"Vibe Coding"是什么
Vibe Coding 这个词是今年年初 Andrej Karpathy 提出来的，意思大概是：你不用精确地写代码，只需要描述你想要什么，让 AI 来实现，出了问题也交给 AI 修，你自己只负责"感觉上对不对"。
很多人觉得这是一种很不严肃的开发方式，有点像是在瞎搞。
但现实是，它在过去一年真的跑起来了，而且跑起来的规模远超大多数工程师的预期。GitHub 有数据显示，现在平台上超过 40% 的代码是 AI 生成或参与生成的。Cursor、Windsurf 的用户量在快速增长，不只是爱折腾的独立开发者，连大厂团队也在用。
于是这个问题开始变得真实：这么搞出来的代码，质量怎么样？
两种声音
围绕这个问题，网上有两种声音，都很响亮。
一种是：AI 写的代码质量太差，全是能跑但不能维护的垃圾，长期下去是巨大的技术债。
另一种是：AI 生成代码的质量已经超过了大多数中级工程师，人类已经不如机器了。
这两种声音有一个共同问题：都在谈"代码质量"，但没有说清楚"质量"指的是什么。
代码能不能跑？功能对不对？有没有安全漏洞？性能够不够？可不可以维护？耦合高不高？有没有测试？文档全不全？
这些东西都叫"质量"，但它们是完全不同的维度，AI 在每个维度上的表现，差异极大。
把这些混在一起讨论，得出的结论注定是模糊的。
规模与质量
我的结论是：软件质量在某些维度下降了，但下降的不是大多数人担心的那个。
功能正确性，没有大规模下降。 AI 写的代码能跑、逻辑对、甚至比很多初级工程师手写的代码更少低级错误。在这一层，Vibe Coding 的产出其实是合格的，有时候比合格还高。
真正下降的，是架构层面的判断质量。
这个区别很重要。
一个具体场景：某个创业团队用 AI 快速搭起了一套系统，三个月上线，功能完整，用户反馈也不错。代码质量看起来还行。但六个月后，他们想加一个新功能，发现原来的数据模型根本撑不住，要动就要改一大半，改了又怕影响线上。于是这个功能拖了两个月才上。
问题出在哪？不是代码写错了，是当初设计数据模型的时候，没有人认真想过这套系统三个月后会长成什么样。AI 给了一个"当下合理"的方案，没有人质疑它，也没有人把更长时间维度的判断带进来。
AI 非常善于在给定约束内生成当下最合理的解。但它不会主动问你："你确定这个数据结构六个月后还够用吗？"它不知道你的业务会往哪里走，不知道你们团队的技术能力边界在哪里，不知道你三个月后会不会来一波用户增长。
这些判断，需要人。而 Vibe Coding 的模式，恰恰跳过了这一步。
测试覆盖率
有一件事在安静地发生，但没什么人在说：Vibe Coding 团队的测试覆盖率，普遍不高。
不是 AI 不会写测试。你让它写，它写得很好。
问题是，在 Vibe Coding 的工作节奏里，"写测试"这件事非常容易被跳过。
因为 AI 让"改出错了再改回来"的成本变得极低，迭代速度极快，很多人开始用"快速跑一遍看看对不对"替代"写测试来保证对"。这在短期内没问题，项目小的时候能跑通，反馈也及时。
但当系统长大，这个债就开始要命了。
一个没有测试覆盖的大型系统，每一次修改都是在赌博。不是说改了肯定出问题，而是你永远不知道改了会不会出问题。AI 可以帮你改，但它没有办法告诉你这次改动有没有破坏三个模块之外那个它不知道的隐性依赖。
这不是 AI 的局限，是 Vibe Coding 这种工作方式带来的系统性风险。
质量分布
讲完下降的部分，我想说一个很多人忽视的另一面。
过去一年，软件质量的分布变了，但不是整体下移——是分叉了。
做得好的团队，代码质量在上升。他们把 AI 用来做大量重复性的、容易出错的脏活：生成样板代码、处理边界情况、写测试用例、检查安全漏洞。工程师的时间被释放出来，可以花更多时间在真正需要人判断的事情上：架构设计、接口定义、技术债务的主动管理。
这种用法，产出的质量比纯手写要高。
做得差的团队，是另一种用法：用 AI 替代思考，而不是替代执行。把架构判断也外包给 AI，把设计决策也外包给 AI，把"这个方案是否合理"的问题也交给 AI 回答。AI 不会拒绝，它会给出一个听起来合理的答案，而且每次都很有说服力。
这种用法，生产出来的系统，就是前面那个六个月后动不了的那种。
同样是 Vibe Coding，用法不同，结果天壤之别。所以"软件质量在整体下降"这个说法本身，是一个把两种截然不同的情况混在一起讲的结论。
那为什么感觉到处都是烂代码？
这里有一个认知偏差值得说一下。
Vibe Coding 大幅降低了"把一个东西做出来"的门槛。以前需要一个团队三个月才能做出来的东西，现在一个人一两周能搞出雏形。这意味着，在这一年里，大量原本根本不具备条件开始软件项目的人，真的开始做软件了。
这批人做出来的东西，质量参差不齐，很多确实很烂。
但这不是"Vibe Coding 让软件质量下降了"，而是"Vibe Coding 让更多人能够做软件了，其中包括了以前根本做不了软件的人"。
样本池变大了，而且新进来的样本集中在能力曲线的低端。整体平均值自然会下移。
但这和"原本就在做软件的工程师的产出质量在下降"，是两件事。
我的想法
绕了这么一大圈，给一个直接的回答：
软件质量没有整体下降，但风险在向一个过去不那么突出的地方集中：架构决策和长周期可维护性。
这个风险不是 AI 造成的，是 Vibe Coding 这种工作方式的副作用——它让"快速出东西"变得太容易，以至于"想清楚再出东西"这件事的优先级，在隐性地降低。
AI 能替你写代码，能替你改 bug，能替你生成测试。
但它替不了你问那个最重要的问题："我们现在做的这个决定，两年后会让我们后悔吗？"
这个问题，一直都是工程师最核心的工作之一。只是以前被大量写代码的时间掩盖了，不那么明显。
现在代码写得少了，这个问题变得无处可藏。
如果你觉得这篇文章对你有帮助，欢迎转发点赞收藏。
转载请注明出处，谢谢。
