Vibe Coding on lategege 的技术博客

Vibe Coding —— 当编程从写代码变成"摇人"

Tue, 07 Jul 2026 01:10:00 +0000

Vibe Coding 这个词是 Andrej Karpathy 在去年年初发明的，现在已经变成 AI 编程领域最火的词了。他用了一段非常直白的话来描述：

“It’s not really coding — I just see stuff, say stuff, run stuff, and copy-paste stuff, and it mostly works.”

翻译过来就是：我不写代码了，我只看、只说、只跑、只复制粘贴，而且大部分情况下它能跑。

这话从一个前 Tesla AI 总监、OpenAI 创始成员嘴里说出来，确实挺冲击的。但你要是实际用过现在这波 AI 编程工具，你会知道他说的是真的。

重点不是工具，是角色换了

很多人以为 Vibe Coding 就是"用 Copilot 写代码"，觉得没什么大不了的。我以前也这么想。

直到我开始用 Cursor 写了一个小项目。我发现整个工作流变了。以前是：我想好逻辑 → 敲代码 → 调试。现在是：我开口说 → AI 写 → 我跑起来看看 → 不对再说一遍。这个转变其实挺本质的。你不是在写代码了，你是在提需求。

打个比方。以前写代码你是施工队，现在你是甲方。你说"我要一个 RSS 阅读器，左边列表右边内容"，AI 哐哐哐给你干出来。你说"列表太宽了缩到 300px"，它又改了。你说"加个暗色模式"，它又改了。

你全程没写过一行代码。但你确实"做"了一个项目。

这种感觉很奇妙。有时候我盯着屏幕发呆——这活是我干的吗？好像不是。但东西确实做出来了。

爽是真爽，但有几个问题

我说说我实际用了几个月之后的感受。

最爽的是做原型。上个月我有个内部工具要做，前端后端数据库全上。按以前的工作流，光搭架子配路由写 API 再联调，一天估计打不住。但那次我跟 Cursor 聊了一下午的天，两小时 MVP 就出来了。这个效率提升是碾压级的，没什么好争议的。

但问题也不少。

一个是代码质量飘忽不定。 AI 有时候会在特别奇怪的地方偷懒。我跟它说配置项走环境变量，它给我硬编码塞在代码里。我跟它说用某个 API，它给我写了个已经被弃用的版本。你要是没看出来，它就这么上线了。

第二个问题更隐蔽——你对代码的理解在慢慢退化。 项目越大，你越不敢改。因为你没写过那些代码，你不知道动了这里会不会把那边搞炸。以前写代码积累的是肌肉记忆，哪块逻辑在哪、怎么写最稳妥，心里都有数。现在积累的是"提示词记忆"——怎么描述需求才能让 AI 写对。前者让你越来越强，后者让你越来越依赖。

还有一个就是调试特别累。 以前出 bug，是你自己引入的，看一下逻辑链就能找到。现在出 bug，是 AI 引入的，你得花时间教它理解哪里错了。有时候你说半天它改不对，你一气之下自己动手改了——然后发现还不如一开始就自己写。

我觉得适合这么用

我自己实践下来，Vibe Coding 最适合两件事。

一个是快速验证想法。 你想试个东西，不确定能不能行，不用花一整天搭工程。直接跟 AI 说，半小时跑起来看看效果，不行就扔。这个成本太低了。

另一个是你懂但懒得写的东西。 你知道那个逻辑怎么写，但你不想去查语法、不想去翻文档。告诉 AI，它帮你糊上去，你检查一下没什么问题就合。这是效率最大化。

不适合什么也很清楚：

复杂架构就别让 AI 搞了，它没有大局观，做着做着就偏离了
性能敏感的底层代码也别用它，AI 对性能的直觉还很差
还有就是你自己完全不懂的东西——你不懂的话连验收的能力都没有，AI 写出来是好是坏你完全没概念，这就危险了

我的态度

说到底，Vibe Coding 的本质是在"人写代码给机器执行"这个链条中间插了一个 AI 翻译官。

你信它，你就快。你不信它，你就得逐行审，那就更慢。

我的态度是：用，但别信太多。

就像招了一个特别勤奋但经验一般的实习生。他干活快，什么都能干一点，但你不能全信他。每次提交都得 review，每个边缘情况都得自己想一遍。

你把它当成一个能说人话的搜索引擎 + 补全工具，它无敌。你把它当成一个能独立交付的程序员，你会失望的。

不过这波工具迭代的速度确实快。Cursor、Copilot、Claude Code、Codex……一个比一个猛。我身边做开发的朋友分成了两拨，一拨拼命拥抱，能用 AI 写的绝不自己动手，一个人干三个人的活。另一拨打死不用，信不过 AI 写的代码，坚持手写，保持对代码的掌控。

我觉得两派都有道理。但有一件事越来越清晰——以后不会被淘汰的，不是代码写得最好的人，而是最能跟 AI 协作的人。

学会摇人，也学会验货。就这么简单。

Vibe Coding：编程从「写代码」变成「聊需求」

Tue, 07 Jul 2026 00:00:00 +0800

今年年初，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 了吧 🎧