用 AI 堆代码不能叫工程，纯靠感觉写代码迟早得翻车

把 Prompt 扔给 AI，然后直接运行，只要结果看着对就觉得搞定了，这就是现在很火的 Vibe Coding。这种方式快到离谱，但如果你管这叫“软件工程”，那纯粹是给这个词抹黑。结论很简单：自己玩玩、做个 Demo 随便 Vibe，但只要涉及钱、用户数据、生产环境，不 Review 代码就上线简直是灾难。

怎么定义 Vibe Coding 和真正的 AI 协作

很多人把所有用 AI 写代码的行为都混在一起，其实差别极大。

• 纯 Vibe Coding： 流程是「写 Prompt → 生成 → 运行 → 不对 → 修改 Prompt → 再次生成」。在这个过程中，开发者完全不看代码，也不编辑代码。这种方式对门槛要求最低，但风险最高。
• AI 辅助评审： AI 写，人审。这要求你得有能力分辨什么是烂代码，什么是优雅实现。
• AI 结对编程： 你在开车，AI 在导航。你主导逻辑，AI 帮你补全、处理边缘 case 或写重复性强的样板代码。

这两者和 Vibe Coding 的核心区别在于：你是否对最终交付的每一行代码负责。

为什么现在不能完全信任 Vibe Coding

如果你在做一个处理敏感数据的金融 App，或者一个医疗健康工具，完全靠 Vibe 出来的代码大概率会出问题。因为 AI 经常在安全漏洞、内存泄漏或复杂的竞态条件上掉链子。

如果你自称是工程师却坚持 Vibe Coding，通常意味着这三种情况之一：要么你懒得花两周时间去补最基础的编程和安全知识；要么你根本不在乎产品的质量和用户数据的安全；要么你对技术底层逻辑毫无好奇心。

我在实操中是怎么用 AI 的

我写了十年代码，现在用 Cursor 或 Claude 3.5 Sonnet 效率确实翻倍了，但我绝不会直接点击 Apply 然后就完事。

每当我尝试用一个不熟悉的语言（比如最近折腾 Rust）写东西时，我的标准流程是：
1. 先花一两天刷官方文档和 Language Reference，确保我知道这个语言的基本内存模型和语法陷阱。
2. 让 AI 生成代码，但我会像审稿人一样逐行 Review。
3. 针对不理解的片段，我会疯狂追问 AI：为什么这里用这个库？有没有潜在的性能瓶颈？这种写法在并发环境下安全吗？

说实话，我为了审代码而消耗的 Token，往往比生成代码时消耗的还要多。只有这样，我才能在出 Bug 时迅速定位，而不是对着 AI 说「它又崩了，你快帮我修修」。

避坑建议：什么时候该停止 Vibe

如果你发现自己陷入了「改 Prompt → 运行 → 报错 → 再改 Prompt」的死循环，且连续尝试 5 次都没解决，这时候请立刻停止 Vibe，强迫自己去看代码。

一个简单的判断标准：如果你无法在 30 秒内向别人解释清楚这段 AI 生成的代码是怎么跑通的，那么你目前处于 Vibe 状态，而不是 Engineering 状态。

在 AI 真正能 100% 闭环处理所有逻辑之前，请务必握紧方向盘，别在高速公路上闭眼开车。