Vibe Coding 只靠直觉驱动，最终一定会翻车

把 Prompt 交给 AI，生成代码后直接运行，只要眼前结果看起来没问题，便将任务视为完成，这就是当下流行的 Vibe Coding。这种方式速度极快，但若把它直接等同于软件工程，只会浪费这个概念的专业含义。自娱自乐或制作 Demo 时或许可以随意 Vibe，一旦涉及资金、用户数据或生产环境，不经过 Review 就让代码上线，结果必然是灾难。

Vibe Coding 不等于 AI 协作

把所有借助 AI 编码的行为混为一谈，会忽略它们之间本质的区别。

• 纯 Vibe Coding： 整个过程只是「写 Prompt → 生成 → 运行 → 结果不对 → 改 Prompt → 再次生成」。开发者既不阅读代码，也不亲手编辑，门槛很低，风险却极高。
• AI 辅助评审： 代码由 AI 产出，人负责把关。这要求开发者具备识别烂代码与优雅实现的能力。
• AI 结对编程： 方向由人掌控，AI 提供辅助。核心逻辑由人主导，AI 负责补全代码、处理边界情况或编写高重复度的样板代码。

三者真正的分界点，在于开发者是否为最终交付的每一行代码承担责任。

不能完全相信 Vibe Coding 的原因

如果开发的是处理敏感数据的金融 App 或医疗健康工具，完全依靠 Vibe 堆出代码，错误很容易直接出现。AI 常在安全漏洞、内存泄漏以及复杂竞态条件上失手，这些问题并不会因为程序暂时跑通就消失。

身为工程师却长期固守 Vibe Coding，通常会暴露出三种心态：不愿花两周时间夯实编程与安全基础；漠视产品质量和用户数据安全；或者对技术底层缺乏好奇心。

保持工程掌控的固定流程

拥有十年编码经验的我使用 Cursor 或 Claude 3.5 Sonnet 时，效率确有一倍提升，但绝不会点下 Apply 后便撒手不管。即便面对 Rust 这样的陌生语言，也可以遵循固定的协作步骤。

先留出一两天研读相关文档与 Language Reference，理解基本的内存模型和容易踩中的语法陷阱。让 AI 完成代码生成后，以审稿人的姿态逐行 Review，不放过任何不明片段。

遇到看不懂的部分，就要继续追问：为什么选择这个库？是否存在性能瓶颈？在并发场景下是否安全？

坦白说，用于审查代码的 Token 往往比生成阶段消耗得更多。只有亲自理解代码，Bug 出现时才可能精准定位，而不是对着 AI 喊「它又崩了，快修修」。

什么时候必须停止 Vibe

如果开发过程已经陷入「改 Prompt → 运行 → 报错 → 再改 Prompt」的死循环，并且连续 5 次仍未成功，就应立刻停止 Vibe，强制自己阅读代码。

判断标准很简单：如果无法在 30 秒内向别人讲清这段 AI 代码的运行机制，说明自己仍处于 Vibe 状态，而不是 Engineering 状态。

在 AI 尚未 100% 闭环处理所有逻辑之前，方向盘必须握在人手中，不能在高速公路上闭眼狂奔。