强者 Vibe，弱者 Wipe
写在前面
2025 年 2 月 6 日，Andrej Karpathy 在 X 上发了一条推文，用了一个新词：Vibe Coding。
他这样描述这种体验：
“完全交给感觉（Vibes），拥抱指数增长，甚至忘记代码的存在。”
他用 SuperWhisper 语音输入指令，让 Cursor 帮他改 UI 边距、调逻辑，根本不看生成的代码——“it just works, and I don’t fully understand why”。
一石激起千层浪。这条推文在技术圈引发了一场至今未平息的争论，争论的核心不是技术本身，而是一个更根本的问题：编程这件事，究竟是什么？
一、布道者眼中的 Vibe Coding：意图平权的曙光
硅谷的创业者和独立开发者群体是 Vibe Coding 最热情的拥趸。
他们的核心叙事是：软件 3.0 时代到来了。编程的重心正在从”语法实现”转向”意图表达”——你不再需要记住 Array.prototype.reduce 的用法，你只需要知道你想干什么。
典型故事是这样的：一个人，一个周末，40 小时，从零上线一个功能完整的 SaaS。没有后端工程师，没有 DevOps，甚至没有太多编程经验。他们管这个叫”消除想法与产品之间的摩擦”。
YC 的某些批次已经出现了整个公司只有一两个人、但代码库有几万行的情况，背后全靠 AI 代理撑着。
这个叙事有其迷人之处。它意味着：那些被传统编程门槛挡在门外的人——设计师、产品经理、领域专家——现在可以直接把脑子里的东西变成软件。这不是小事，这是创造力的民主化。
二、资深工程师眼中的 Vibe Coding：定时炸弹
同样一件事，在有十年以上经验的工程师眼里，画风就完全不同了。
他们的批评集中在几个点：
代码质量：AI 生成的代码往往是”面条代码”，能跑但没有结构，没有对未来维护的考量。重构的时候你才会发现，这堆东西根本不是在解决问题，而是在绕开问题。
安全盲区：Snyk 等安全机构的研究发现，Vibe Coding 特别容易引入安全漏洞——因为开发者根本不看代码逻辑，只看有没有报错。一个真实的案例：某 SaaS 创业者用 Vibe Coding 快速上线，因为 AI 悄悄跳过了认证逻辑，用户数据被轻易拖走了。
“代码清洁工”困境：流传最广的一个说法是，AI 让初级程序员变成了提示词工程师，却让资深程序员变成了”Code Janitors”——整天在收拾 AI 留下的烂摊子，找那些隐蔽的、只有经验才能识别的 Bug。
这批人并不是在反对 AI 辅助编程本身，他们用 Copilot、Cursor，也觉得很好用。他们反对的是”忘记代码存在”这个姿态——不理解就不能拥有，这是他们的核心信念。
三、初学者眼中的 Vibe Coding：学习方式的重构
对于正在学编程的人来说，这件事更复杂，充满了矛盾感。
一部分初学者发现，Vibe Coding 是个神奇的学习工具。与其看视频教程被动接收，不如直接告诉 AI “我想做一个登录页面”，然后观察代码是怎么变化的，遇到不懂的直接问。这种主动探索的方式，对某些人来说比传统教学有效得多。
但另一部分人，尤其是计算机专业的学生，陷入了一种新的焦虑：我到底在学什么？
如果 AI 能帮你写所有的代码，那学数据结构、学算法、啃操作系统原理的意义是什么？如果你只会调用 AI，你是程序员吗？未来市场上要的是什么人？
这种焦虑是真实的，也是合理的。教育体系还没有给出一个清晰的答案。
四、技术领袖眼中的 Vibe Coding：各说各话
Karpathy 本人后来有所补充。他说他其实并不主张所有人都这样做，Vibe Coding 对他有效，是因为他有足够的底子，知道 AI 在说谎的时候能识别出来。到 2026 年初，他又提出了新词”Agentic Engineering”，强调 AI 不再只是辅助写一行代码，而是作为自主代理负责整个系统设计——这是 Vibe Coding 的进化版，但也需要更强的工程判断力。
Sam Altman 的表态颇为微妙。他亲身试验后感叹，这个过程很有趣，但让他有一种”无用感”（feeling a little useless）——AI 给的方案比他自己想的更好更快。他对学生的建议是学会掌握 AI 工具，而不是死磕特定语言。
而大多数 CTO 保持谨慎。一项访谈 18 名 CTO 的研究发现，其中 16 人报告过因过度依赖 AI 生成代码导致的生产事故。他们倾向于把 AI 用在测试和文档上，而不是核心业务逻辑。
五、数据说了什么
有几个数字值得关注：
- 截至 2025 年底，约 41% 的代码由 AI 辅助或自动生成。
- 重度 AI 用户的自我感知生产力提升了约 3 倍。
- 但 METR 2025 年做的一项对照实验显示：使用 AI 的开发者自认为快了 20%，实际测量却比不用 AI 的慢了 19%。
最后那个数据最刺眼。它揭示了一个可能正在大规模发生的认知偏差：我们感觉在飞，实际上可能在原地打转。原因或许是：AI 生成代码快，但理解、调试、验证这些代码花的时间被低估了；再加上错误方向上的快速推进，代价更大。
六、我的思考
我不认为 Vibe Coding 是一个需要站队的问题。它不是”AI 让编程变好了”或”AI 毁了编程”这种二元叙事能概括的。
我更感兴趣的是它暴露出来的一个深层矛盾：
我们对”理解”的要求，和我们对”产出”的要求，正在发生分裂。
传统编程里，理解和产出是绑定的——你写出来的代码，就是你理解的具象化。Vibe Coding 打破了这个绑定：你可以有产出，但不必有理解。
这不是第一次发生类似的事。框架出现的时候，有人说”用了 Spring 的 Java 程序员不算真正的 Java 程序员”；用 Stack Overflow 的时候，有人说”复制粘贴的不是真正的工程师”。每一次，这种担忧都有一定道理，但历史最终走向了接受，因为抽象层的提升解放了更大的创造力。
但这一次有些不同。之前的每一层抽象，都还要求你理解你在干什么；你得看懂 Stack Overflow 的答案，你得理解框架的边界。Vibe Coding 在某种极端形式下，连这个最低要求也放弃了。
这不是抽象，这是外包。
外包没有问题，前提是你知道外包出去的东西后来会发生什么。一个有经验的工程师做 Vibe Coding，他的”感觉”（Vibe）背后有十年的工程直觉在兜底，他知道什么时候该停下来看一眼代码，知道哪里会出问题。一个没有这个底子的人做 Vibe Coding，他的”感觉”就是真的只是感觉——到出问题的那一天，他既不知道哪里错了，也不知道怎么修。
所以我的结论不是”Vibe Coding 好”或”Vibe Coding 坏”，而是：Vibe Coding 是一个放大器，它放大你已经拥有的东西。
有底子的人，它是加速器。没底子的人，它是一个让人感觉良好的幻觉制造机。
本身强才能 Vibe，本身弱 Vibe 会毁了你。
这让我想到一个更有意思的问题：在 AI 无处不在的时代，”底子”的定义是不是也在改变？如果连 Karpathy 都说”忘记代码存在”，那未来的工程师底子应该是什么？
也许不再是”能写出来”，而是**”知道什么是对的”**——对系统、对安全、对用户的判断力。这种判断力，目前还没有捷径。
写在最后
Vibe Coding 这个词之所以有趣，是因为它诚实。
它没有说”AI 辅助编程”或”智能代码生成”，它直接说：这就是靠感觉。这种诚实反而让围绕它的讨论更真实——它逼着每个人说清楚自己到底在乎什么，在乎代码本身，在乎产品结果，还是在乎某种职业认同。
不同人眼中的 Vibe Coding，照出来的其实是不同人眼中的”编程是什么”。
而这个问题，可能比 Vibe Coding 本身更值得想清楚。