今年年初，Andrej Karpathy 提了一个词叫 Vibe Coding，在开发者圈子里炸了一波。
我看了下讨论，有人嗨得不行，说这是编程民主化的开端；也有人嗤之以鼻，觉得不就是换了个马甲的「低代码」么。
我自己试了小半年，聊点真实的感受。
啥是 Vibe Coding
Karpathy 原话大概意思是：你整个人沉浸在氛围里，放弃写代码，开始描述需求。你几乎不再跟代码本身打交道，而是像跟一个人聊天一样说你要什么，它帮你搞定。
说白了就是——你张嘴，AI 动手。
比如你想写个 Python 脚本处理 CSV：
- 以前：打开编辑器，import csv，写循环，调试，累得半死。
- Vibe Coding 状态：开个对话窗，「帮我写个脚本，读这个 CSV，把第二列大于 100 的行挑出来，输出到新的文件」，几秒钟活干完了。
这种感觉很奇妙。你不再是那个「吭哧吭哧敲代码的人」，变成了「提需求的那个甲方」。
说实话，刚开始我有点不适应
用了几天 Cursor 和 Copilot 之后，最强烈的感受是——空虚。
对，你没看错，是空虚。
以前写一个功能，从构思到实现到调试，整个过程是有「手感」的。你知道每一行代码怎么来的，知道哪里容易出坑。现在呢？你跟 AI 说「帮我做个用户登录」，它噼里啪啦一顿输出，代码就摆在那了。你看了看，好像没什么问题，合进去了。
但心里总有点发毛——这玩意儿真没问题吗？万一有个边界情况它没处理呢？
后来我想通了。这种不安全感，本质上是对未知代码的不信任。 就好像你让别人替你写了一段代码，你没亲自 review 每一行，心里就不踏实。
但问题是，以前你 review 第三方库的代码吗？不 review 吧。你信它是因为它经过很多人用过、踩过坑。AI 生成的代码也一样——你需要的是验证手段，而不是放弃使用。
什么场景下 Vibe Coding 是真香
我用了几个月，总结了几个「真香时刻」：
写胶水代码——连两个 API、做个数据转换、写个简单的 CRUD。这种活 AI 干的又快又好，我完全不想自己写了。
不熟悉的领域——比如我对前端不太熟，但有次要写个简单的 React 组件。放以前我得先学半天 React 基础，现在直接跟 AI 描述我要什么效果，它生成，我微调，半小时搞定。
写测试——我讨厌写测试，AI 不讨厌。让它写，我来 review，舒服。
修 Bug——以前遇到奇怪的报错，第一反应是 Google 或者 Stack Overflow。现在直接把报错信息扔给 AI，很多时候它直接看出问题在哪。
但这些场景有个共同点：我知道我想要什么，而且我能判断 AI 给出的东西对不对。 这才是关键。
哪些场景它不行
聊完好的，也得说说坑。
复杂架构决策——AI 给不出好的架构设计。你跟它说「帮我设计这个系统的模块划分」，它给你一个教科书式的答案。但真实项目的架构决策往往掺杂了各种业务约束、团队习惯、历史包袱，这些东西 AI 不知道。
调试深渊——当 AI 生成了你看不懂的代码，然后它出了问题，你就尴尬了。看不懂就很难描述清楚问题，AI 就瞎修，越修越乱。最后你还是要自己读懂那坨代码。
安全敏感场景——AI 生成的代码看起来对，但可能漏了权限校验、输入过滤、SQL 注入防护。如果你自己没有安全意识，AI 写出来的东西很可能有洞。
长期维护——AI 倾向于写「能跑就行」的代码，不太在意代码质量。变量名乱起、函数太长、逻辑耦合——这些 AI 不 care。如果长期放任不管，项目会变成一坨屎山。
那我的态度是啥
我现在的做法是：把它当工具，别当神。
具体来说：
- 写东西快，但 review 不能省。AI 写完的代码，至少扫一遍，理解它在干什么。
- 不懂的地方让 AI 解释。看不懂的代码不要直接合进去。
- 适合用 AI 写的就去写，不适合的别硬上。比如核心的业务逻辑，我自己写更放心。
- 用 AI 填补自己的短板，而不是替代自己的思考。
Karpathy 自己说过一句话我挺认同的：“I still need to be able to read code, even if I don’t write it.”
编程的未来，不会是谁写代码更快，而是谁能更清楚地描述问题、更好地判断结果质量。Vibe Coding 改变的是实现方式，不是思维方式。
反正我现在已经回不去了——遇到写代码的任务，第一反应已经不再是「打开编辑器」，而是「跟 AI 说说看」。这大概就是 Vibe 了吧 🎧