Vibe Coding 不是工程：为什么 AI 生成的代码无法替代系统设计

背景

在生成式 AI 迅速普及的当下，“Vibe Coding”（氛围编程/直觉编程）成为一种流行的开发范式。开发者只需通过自然语言描述需求，AI 模型（如 LLM）便能迅速生成可运行的代码片段。这种模式极大地降低了编码门槛，提升了原型开发的效率，但也引发了一种错觉：既然 AI 能瞬间写出代码，那么软件工程的核心工作似乎也变得微不足道了。

然而，Hacker News 上的一篇深度文章《Vibe Coding Is Not Engineering》（氛围编程不是工程）对此提出了严厉警告。文章指出，Vibe Coding 产生的只是“代码”，而工程产生的是“系统”。这两者之间的巨大鸿沟，正是生产环境中故障频发的根源。这并非是对 AI 技术的否定，而是对“工程思维”缺失的警示。

核心内容

文章的核心论点在于区分“代码生成”与“系统工程”的本质差异。LLM 擅长的是模式匹配和文本续写，能够根据提示词（Prompt）生成看似正确的代码，但它缺乏对系统整体性、约束条件和业务逻辑的深层理解。

1. Vibe Coding 的局限性：有输出，无连贯性 Vibe Coding 提供了代码、输出和开发 momentum（势头/节奏感），但它无法提供系统的“连贯性”（Coherence）。在代码编写之前，工程师所做的关键决策——如解决歧义、定义边界、建模行为、决定系统在压力下的表现——是维持系统稳定的基石。LLM 跳过了这些工程环节，直接生成代码文本。

2. 系统不仅仅是代码文本 一个健壮的系统依赖于：

• 不变量（Invariants）：必须始终为真的条件。
• 约束（Constraints）：不可违反的规则。
• 耦合与序列规则：塑造业务逻辑和用户行为的关系。 这些要素存在于模型的“内部世界”之外。LLM 无法看到那些“需要被问出的问题”的类别。

3. 缺失工程决策导致的脆弱性 当 AI 生成的代码缺乏前置的工程决策时，系统会出现以下症状：

• 功能相互冲突并导致崩溃。
• 系统状态变得不可预测。
• 部署变得脆弱且缓慢。
• 错误信息失去意义。
• 简单功能的扩展变得极其困难。 这种脆弱性会导致信心在系统实际崩溃前就瓦解。

4. 案例解析：登录系统的陷阱 文章通过一个具体的例子说明了这一风险。如果提示词是：“写 Python 代码，为网站添加用户账户功能，让人们可以登录。” LLM 可能会生成一个基于 Flask 和 SQLite 的最小可行示例。这对演示（Demo）来说是可以接受的，但它没有询问以下五个关键工程问题：

• 邮箱地址是否必须唯一？
• 账户是否需要验证？
• 用户是否应该能够重置密码？
• 是否存在角色（Roles）权限体系？
• 安全模型是什么？

5. 后果推演：唯一性缺失的灾难 如果未考虑“邮箱唯一性”这一约束，将导致严重后果：

• 两个不同用户可以注册相同的邮箱。
• 当这两个用户同时登录时，系统无法区分用户身份，导致身份混淆。
• 数据库查询返回多个结果，任何假设“用户唯一”的代码逻辑都会出错。
• 致命缺陷：如果其中一个用户重置密码，系统可能会重置所有共享该邮箱用户的密码；如果其中一个用户删除账户，所有共享该邮箱的账户都会被删除。 这种系统在现实中是“不可存活”（Not Survivable）的，生产环境绝不容忍此类逻辑。

6. 对 AI “智能”的误解 Vibe Coding 的误区在于假设 AI 拥有像工程师一样的“智能”。如果 AI 真的智能，它会自动捕捉缺失的需求、模糊的规则和隐藏约束。但事实是，LLM 不进行推理，不构建领域模型，不追踪后果，也不保护不变量。它生成的只是看起来像答案的文本。人们因为代码能运行，就误以为必要的思考已经完成，将“模式续写”误认为是“工程智能”。

关键要点

• 代码 $\neq$ 系统：Vibe Coding 产出的是代码片段，而工程产出的是能在现实压力下生存的系统。生产环境的故障往往源于两者之间的差距。
• 工程的核心是决策：在写第一行代码之前，工程师通过解决歧义、定义边界和建模行为来确保系统连贯性。LLM 无法执行这些前置决策。
• LLM 缺乏系统视角：模型内部没有“不变量”、“约束”或“业务耦合”的概念。它只生成文本，不思考后果。
• 隐性需求决定系统生死：如“邮箱唯一性”这类看似简单的需求，若未被显式定义，会导致数据一致性崩溃和严重的业务逻辑错误（如误删账户、密码泄露）。
• 演示成功不等于生产可用：AI 生成的代码容易通过简单的功能演示，但在面对并发、异常状态和复杂交互时，会迅速暴露出脆弱性和不可预测性。
• 正确的做法：在生成代码前，人类必须明确：
  • 什么必须始终为真（不变量）？
  • 什么定义了实体的“同一性”（身份规则）？
  • 系统绝不允许什么（约束）？
  • 系统出错时如何表现（故障模式）？

意义与影响

这篇文章对当前的 AI 辅助开发浪潮具有重要的纠偏意义。它提醒开发者和技术领导者，AI 是强大的代码生成工具，但绝非工程决策的替代品。

1. 重新定义工程师的价值：随着 AI 接管了基础的编码工作，工程师的核心竞争力将从“编写语法正确的代码”转移到“定义系统边界、处理复杂约束和进行架构决策”上。那些能提出正确问题、定义不变量的人，比单纯依赖 AI 生成代码的人更具价值。
2. 警惕“虚假的安全感”：Vibe Coding 带来的快速反馈循环容易让人产生系统已经完善的错觉。团队需要建立更严格的测试、代码审查和架构评审机制，以弥补 AI 在逻辑完整性上的缺失。
3. 生产环境的韧性优先：在构建面向生产环境的产品时，不能仅满足于“功能可用”，必须深入考虑数据一致性、安全性、异常处理和扩展性。这些非功能性需求是 LLM 难以自动推导的，必须依靠人类工程师的深思熟虑。
4. 从个体效率到团队能力：正如文章末尾提到的，AI 确实提升了个体的速度，但真正的系统级增益来自于团队协作和清晰的工程纪律。只有将 AI 作为辅助工具，嵌入到严谨的工程流程中，才能构建出真正稳健的软件系统。

总之，Vibe Coding 适合原型验证和快速探索，但在构建生产级系统时，必须回归工程本质。没有工程决策支撑的代码，无论生成得多快，都是建立在沙堆上的城堡。