「代码大全 × Vibe Coding」系列 · 第 01 篇

最近有一个词非常流行：Vibe Coding。

大意是：你只需要有想法，剩下的交给 AI 就好了。打几行 Prompt，一个 App 的骨架就出来了。那种感觉，真的很爽。

我身边有越来越多的人开始这样做。产品经理、设计师、甚至完全不懂代码的创业者，都开始”做软件”了。

初期的反馈往往非常正向——

“它跑起来了！”

但几个月后，我听到最多的另一句话是——

“这代码我自己都看不懂，有问题怎么改啊？”

这让我想重新翻开一本老书：《代码大全》。

这本书出版于1993年，距今已经超过30年。但我最近重读第一章，发现有一段话像是专门写给今天的我们的：

如果你是自学编程员或是主要从事非正规研制工作，你很可能还没有意识到这些在生产软件中所需要的工作步骤。在潜意识中，你把这些工作统统称为编程……

在许多项目中，程序员可得到的唯一文件便是代码本身。需求说明和设计文档可能会过时，但源代码却总是最新的。因此，源代码必须具有最好的质量。

30年前的话，说的就是今天的事。

我们到底误解了什么？

大多数人眼中的软件开发，是这样的：

有想法 → 写代码（or Prompt）→ 完成

但实际上，软件开发是这样的：

有想法 → 需求分析 → 架构设计 → 编码 → 测试 → 维护 → 持续演进

编码，只是中间的一个环节。

而 Vibe Coding 做的事情，是把这条路径压缩到了极致——让”有想法”和”跑起来”之间的距离，缩短到了几分钟。

这本来是一件好事。

但问题在于，路径缩短了，思考却没有跟上。

Vibe Coding 的”甜蜜陷阱”

我把它叫做”甜蜜陷阱”，因为它的开头真的很甜。

初期，AI 帮你快速搭出骨架，演示效果惊艳，验证想法的成本极低。你会觉得：做软件原来这么简单！

但随着时间推移，问题开始浮现——

每次跟 AI 对话都是局部视角，整体架构没有人在把控

需求没说清楚，AI 就用”它认为合理的方式”帮你填空

代码是一块一块”拼”出来的，而不是”设计”出来的

三个月后，连你自己都不知道某段代码是干什么的

这不是 AI 的问题。这是我们跳过了思考的问题。

那我们应该回到”写需求文档”的老路吗？

不是的。

我不是在说要回到那种动辄几十页需求文档、几个月才开始写代码的老方式。那个时代确实回不去了，也没必要回去。

我想说的是一个更小的动作：

在开始 Prompt 之前，先花半小时把这几个问题想清楚，写下来。

这个软件要解决什么具体的问题？它”不做什么”？边界在哪？核心的数据是什么？它们之间是什么关系？什么情况下，我认为这个版本”完成了”？

就这四个问题。半小时。

你会发现，当你能清晰地回答这四个问题时，你给 AI 的 Prompt 质量会提升一个数量级。

因为 AI 是你意图的放大器。你的意图越清晰，它放大出来的结果就越准确。你的意图越模糊，它放大出来的，只是你的混乱。

“源代码是唯一永远最新的文档”

《代码大全》里这句话，在 AI 时代有了新的重量。

AI 生成的代码，你依然要为它负责。

你是这段代码的作者，不是接收者。

没有人会因为”这是 AI 写的”就原谅糟糕的可读性和可维护性。项目是你的，锅也是你的。

所以，Vibe Coding 可以是你的工具，但不能替代你的思考。

写在最后

我开始了这个系列，想做一件事：

用今天 Vibe Coding 的视角，重新读一遍《代码大全》。

这本书里有很多东西，放在今天依然成立。也有一些东西，值得我们重新审视和更新。

如果你也在用 AI 做软件，如果你也曾经历过那种”初期很爽、后来很痛”的循环，欢迎跟着这个系列一起读。

不是为了复古，是为了在工具飞速进化的时代，守住那些真正重要的东西。

下一篇：第二章——用隐喻理解软件开发

觉得有共鸣，欢迎转发给同样在 Vibe Coding 的朋友 🙌