Vibe Coding：当"写代码"变成"说需求"，你的技术判断力才是最后防线

做一个思想实验。

假设从今天开始，你写的每一行代码都不是你"写"的——你只需要用一句话描述你想要什么，AI 生成代码，你点 Accept All，运行，看效果。如果报错，把错误信息粘贴回去，AI 再改一版。

整个过程中，你没有读过一行代码。

如果你的反应是"这不就是我现在的工作方式吗？"——恭喜，你已经在 Vibe Coding 了。如果你的反应是"这也太不靠谱了吧"——那你可能低估了这件事的普及速度。

截至 2026 年 4 月，72% 的开发者每天都在使用 AI 编程工具，全球 41% 的代码由 AI 生成。一个叫 Cursor 的 IDE 用不到两年做到了 20 亿美元年化收入。一个叫 Lovable 的 Vibe Coding 平台八个月做到了 1 亿美元 ARR。

但与此同时，96% 的开发者说他们不完全信任 AI 生成的代码。

所有人都在用，没有人完全信任。这个悖论背后到底发生了什么？答案比你想的更复杂。

---

它到底是什么？

2025 年 2 月 2 日，OpenAI 联合创始人、前特斯拉 AI 负责人 Andrej Karpathy 在 X 上发了一条帖子：

There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.
—— Andrej Karpathy, 2025.02.02

"完全交给感觉，拥抱指数级增长，忘记代码的存在。"

他还补充了自己的具体做法：永远点 "Accept All"，不看 diff；遇到报错就把错误信息复制粘贴回去，不加任何评论；有时候让 AI 随机改改，直到 bug 消失。

这条推文在技术圈炸了锅。到 2025 年底，"Vibe Coding"被《柯林斯词典》选为年度词汇。

但很多人对这个概念有一个根本性的误解。

打个比方。传统编程像开手动挡：你踩离合、挂档、控制每一个动作。AI 辅助编程像开自动挡：变速箱帮你换档，但你还是在看路、打方向盘。

Vibe Coding？那是你坐上了一辆自动驾驶出租车，你只说目的地，完全不看路。

车到了，你下车。至于中间走了哪条路、有没有闯红灯、发动机有没有异响——你一概不知。

听起来很疯狂？但 Karpathy 最初确实说过，这只适合"原型"和"周末项目"。问题是，人性不听这种警告。

Vibe Coding 的本质不是"AI 帮你写代码"，而是"你放弃了阅读代码"。这一字之差，区分了工具和赌博。

---

为什么所有人都在用？

因为速度太诱人了。

独立开发者 Pieter Levels 用 Cursor + Grok 3，从零开始做了一个多人在线游戏，17 天做到了 100 万美元年化收入。不是大团队，不是有融资，就是一个人加一个 AI。

开发者 Ben Marshall 用 Vibe Coding 的方式构建了 ForexFlow——一个 20 万行 TypeScript 代码的外汇交易平台，840 个文件，195 次提交。一个人完成。

Y Combinator 2025 年冬季批次中，25% 的创业公司运行在 95% AI 生成的代码上。

这些不是实验。这些是真金白银的产品。

工具端的军备竞赛同样疯狂。Cursor 做到了 10 亿美元 ARR，Windsurf 被 Cognition 以 2.5 亿美元收购，GitHub Copilot 拥有 470 万付费用户覆盖 90% 的财富 100 强企业。每个工具都在往"更自主"的方向冲——Cursor 推出了后台 Agent，Copilot 能直接认领 GitHub Issue 然后自己写代码提 PR。

这就像一条高速公路上所有车都在加速。你不加速，就会被挤到应急车道上。

但问题来了：这条高速公路上有没有收费站？有没有测速？有没有悬崖？

速度是毒药，尝过一次就回不去了。但毒药之所以叫毒药，是因为它在让你爽的同时悄悄侵蚀着什么。

---

45% 的代码有漏洞，然后呢？

让我给你讲一个真实的故事。

2025 年，安全公司审计了一个叫 Moltbook 的生态系统。这个项目是用 Vibe Coding 方式构建的——快速、高效、按时上线。然后安全人员发现：一个配置错误的 Supabase 数据库暴露了 150 万个 API 密钥和 3.5 万个用户邮箱。

开发者不是不小心。他们根本没看那段代码。AI 生成的数据库配置"看起来完全正确"，跑起来也没有任何错误提示。但它就是漏了关键的权限设置。

这不是个例。Veracode 的报告显示，近 45% 的 AI 生成代码包含安全缺陷。更可怕的是，当 AI 面对一个安全方案和一个不安全方案时，它选择不安全方案的概率接近 50%。

为什么？因为 AI 优化的目标是"让代码跑起来"，不是"让代码安全"。它生成了一个 500 行的 React 组件，通过了所有 happy path 测试，但没有做输入验证、没有做 XSS 防护、没有做权限检查。

安全漏洞还只是冰山一角。更隐蔽的问题是技术债务。

传统代码的技术债，你至少看得见——命名混乱、函数太长、缺少注释。AI 生成代码的技术债要阴险得多：代码语法完美、格式整洁、单元测试全过，但内部逻辑微妙地不对。一个文件用 camelCase，另一个文件用 snake_case；一个模块做了错误处理，另一个模块静默失败。

行业里管这叫"六个月墙"——项目上线后大约六个月，累积的安全债务和逻辑不一致会达到一个临界点，整个应用变得无法维护、无法修复。

有人把 Vibe Coding 做生产系统比喻为"用 Windows 画图软件设计跨海大桥"。画出来的图很漂亮，但你不会想开车上去。

AI 生成的代码最危险的地方，不是它不能跑——恰恰是它"看起来完全正确"。你无法对一个看起来完美的东西产生警觉。

---

连 Karpathy 自己都改口了？

2026 年 2 月，距离 Karpathy 发明"Vibe Coding"这个词刚好一年，他自己宣布这个概念已经过时了。

他提出了一个新术语：Agentic Engineering（智能体工程）。

核心思想是："claim the leverage from the use of agents but without any compromise on the quality of the software"——利用 AI 的杠杆，但不在软件质量上做任何妥协。

这个转变非常值得玩味。发明 Vibe Coding 的人，用了一年时间得出了一个结论：纯粹的 Vibe 不够。

说一个有意思的花絮。BitTorrent 的发明者 Bram Cohen 曾经公开批评 Vibe Coding，说它导致"严重的代码冗余和架构混乱"。但他同时承认，AI 在清理技术债务方面非常有用。这个矛盾本身就说明了问题：AI 既是制造问题的人，也是解决问题的人——关键看你怎么用它。

那 Agentic Engineering 和 Vibe Coding 到底有什么区别？

一位研究者把 AI 编程助手比作"初级天才"——才华横溢，但有三个致命缺陷：

• 没有架构直觉：它只看当前的 prompt，不顾系统整体的可维护性
• 盲目自信：还没理解需求就开始重构你的代码
• 失忆症：今天纠正过的错误，明天它会原样再犯

Agentic Engineering 的核心不是"让 AI 更聪明"，而是给这个"初级天才"套上工程约束：意图契约（你要什么，必须写清楚，不能靠"感觉"）、合并就绪包（代码必须通过自动化检查才能合并）、以及人类对关键决策的最终审批权。

不是让 AI 更快地写代码，而是把 AI 关进工程的笼子。

---

你该在哪条线停下来？

说到这里，你可能觉得我要劝你别用 Vibe Coding。

恰恰相反。我认为你必须学会用它。但要学会在正确的地方停下来。

还记得 ForexFlow 那个案例吗？20 万行代码，一个人完成。但这里有个关键细节被很多人忽略了——开发者 Ben Marshall 写了 11 个路径级规则文件和 9 个 Skills 脚本来约束 AI 的行为。他说了一句话：

AI coding works when you build the system around it. Rules constrain. Hooks enforce. Skills keep workflows consistent.
—— Ben Marshall, ForexFlow 开发者

"围绕 AI 构建系统"。不是把 AI 当黑盒用，而是给它画线。

实战中怎么做？METR 的一项研究发现了一个反直觉的事实：AI 工具让资深开发者在复杂任务上慢了 19%——尽管他们自己感觉更轻松了。原因是他们花在与 AI 沟通、审查 AI 输出上的时间，超过了 AI 节省的时间。

这告诉我们一个重要的事：Vibe Coding 的效率增益不是免费的。省掉的写代码时间，要么花在了审查上（好的选择），要么变成了六个月后的技术债务（坏的选择）。

Andrew Ng 说得好："Vibe coding requires structuring your work, refining your prompts, and having a systematic process."——它需要结构化你的工作、打磨你的提示词、建立系统化的流程。

这听起来是不是跟"写代码"一样累？

没错。Vibe Coding 没有消灭复杂性，它只是把复杂性从"写代码"转移到了"判断代码"。以前你需要知道怎么写一个安全的认证模块，现在你需要知道 AI 写的认证模块哪里可能不安全。

门槛变了，但没有消失。

如果你是一个经验丰富的开发者，Vibe Coding 是你的涡轮增压器——你知道什么时候该踩油门，什么时候该踩刹车。如果你是一个完全不懂代码的人，Vibe Coding 是一辆没有刹车的跑车——你能开起来，但不知道怎么停下来。

Vibe Coding 不是编程的未来，而是编程门槛的一次重置。门槛从"会写代码"变成了"能判断代码"。而后者，可能更难。

---

我的三个预测

聊到这里，让我做三个预测，给自己设个 deadline：

预测一：到 2026 年底，"Vibe Coding"这个词会退出主流技术话语。

不是因为这种工作方式消失了，而是因为它会被更精确的术语取代——Agentic Engineering、Context-driven Development 或者别的什么。就像"云计算"这个词已经没人再专门提了，因为一切都是云的。Vibe Coding 会变成默认，不再需要一个名字。

预测二：到 2027 年 Q2，主流 CI/CD 平台会内置 AI 代码安全审计作为默认管道步骤。

当 41% 的代码是 AI 生成的、45% 包含安全缺陷时，这不是"要不要做"的问题，而是"多快上线"的问题。GitHub Actions、GitLab CI 都会把 AI 安全扫描变成新项目的默认配置，就像 lint 一样自然。

预测三：到 2027 年底，"代码审查"会被重新定义。

当大部分代码不是人写的，逐行审查就不再现实。取而代之的是意图审查——审查的不是"这行代码对不对"，而是"AI 理解的需求跟你想要的一样吗"、"这个架构决策合理吗"。Review 的单位从"行"变成"意图"。

一年后回来看看，我说得对不对。

但有一件事我不需要预测，因为它已经在发生：真正稀缺的不再是写代码的能力，而是判断代码该不该存在的能力。

这个能力，目前为止，只有人类有。