什么是 Vibe Coding：一个被误解的概念，正在重塑写代码这件事
这是「Vibe Coding」专题的第一篇。整个专题不讲”哪个工具好用、哪个 Prompt 神奇”，而是讲一件更根本的事：当写代码这个动作被 AI 大幅接管后，一个开发者真正要做的工作是什么，以及怎么把它做好。
先说清楚 Vibe Coding 是什么
“Vibe Coding”这个词源自 Andrej Karpathy 在 2025 年初的一条推文，本意相当随意——“完全凭感觉，接受 AI 写的所有代码，出错就把错误粘回去”。
但在过去一年多的工程实践里，十个人嘴里的 Vibe Coding，往往是十件不同的事。有人觉得是”用嘴说话就能让 AI 写代码”，有人觉得是”不用学编程也能做产品”。社交媒体上隔三差五就有人发一条”我用 AI 十分钟做了一个 xxx”，底下评论清一色”Vibe Coding 太强了”。
这个词一开始听起来挺虚。但仔细想，它其实指向了一个真实的变化，只是多数人理解歪了。
跟十年前的低代码平台不一样，Vibe Coding 描述的是一种新的工作节奏：你和 AI 之间形成一个高频循环——提问、生成、审阅、修正、再提问。写代码这个动作本身变轻了，但围绕代码的判断、约束、取舍，反而变得更重了。
一个具体的体感是：以前写代码占工作时间的 70%，现在大概只占 20%。剩下的 80% 花在定义问题、审阅结果、维护结构上。这个比例的变化，才是 Vibe Coding 在说的事。
所以更准确的定义是：你不是在”写代码”，而是在指挥一个或多个 AI Agent 写代码。你的核心工作变成四件具体的事，后面几篇会逐一展开：
- 把意图描述清楚（Spec）——不是”做一个登录功能”，而是”基于现有的
auth/模块，加邮箱+OTP 登录，OTP 用 Redis 存，5 分钟过期” - 给 Agent 正确的上下文（Context）——它不知道你的项目长什么样、约定是什么、之前走过什么弯路
- 审查、引导、修正——这是你 80% 的工作
- 在合适的时机分解任务、压缩上下文、切换 Agent——会”换”、会”停”和会”做”一样重要
十分钟做出贪吃蛇，然后呢？
讲一个几乎每个 Vibe Coding 的人都经历过的场景。
打开 Cursor 或者 Claude Code，输入一句：“帮我写一个贪吃蛇游戏。“不到十分钟，浏览器里就能玩了。蛇在跑，苹果在出现，碰到就加分，该有的都有。第一次看到的时候确实有点震撼。
然后问题来了。
蛇的移动速度跟渲染帧率绑死了——笔记本风扇一转，蛇就忽快忽慢。快速连按方向键的时候，蛇会出现诡异行为：明明在向右走，突然调头向左，当场撞死自己。研究一下才明白：连续按键的间隔比游戏 tick 还短，两次输入在同一帧内被处理了，而代码里根本没有”禁止 180 度转向”这条规则。再后来发现，把浏览器窗口拖一下大小，游戏直接重置了——resize 事件触发 canvas 重绘，状态没保存，重绘完一切归零。
这些 bug 有一个共同点：不是语法错了，不是变量拼错了。是”这个游戏应该怎么运行”这件事，没有人说清楚过。 蛇在什么条件下可以转弯？窗口事件该不该影响游戏状态？速度和帧率应该是什么关系？没人提这些问题，AI 也没问。它根据”贪吃蛇”这三个字，凑出了一个能跑起来的东西。跑起来之后会发生什么，它不管。
我们说 AI “写代码”，但它做的事情更像是”拼装一个看起来像答案的东西”。它不理解”贪吃蛇”是一个有物理直觉、有交互预期、有边界约束的系统，它理解的是”贪吃蛇”这个 token 序列后面大概率跟什么代码。
前十分钟的兴奋感是真的，后面两小时修各种边界问题时的挫败感，也是真的。“看起来能跑”和”靠得住”之间的距离，比想象的远得多。 这个落差，是理解 Vibe Coding 的入口。
多数人觉得 Vibe Coding 的核心是”生成”——AI 帮你把代码写出来，省时省力，完事。但经历过几次”十分钟出原型、两小时修边界”的循环之后，你会越来越觉得生成是最不值钱的那一步。后面那些事才考验人：读懂 AI 写的代码，判断哪些可以留下哪些必须扔掉，找到系统行为的模糊地带并把它钉死，反复重构，为最终结果承担后果。
2026 年了，生成能力谁都有，你在任何工具里输一句话就有。但你有没有能力判断生成结果该不该用，这件事 AI 帮不了你。
效率这个词需要重新理解
AI 把写代码的速度拉高了。过去半天才能搭好的页面，现在十分钟搞定；过去对着文档查两小时的 API 对接，现在一句话丢过去就能拿到初稿。产出量涨了，没什么好争的。
但有一个越来越强的感受：产出量涨了跟系统质量涨了，是两回事。 把这两件事混在一起，会出大问题。
做过项目的人对下面这个过程不会陌生。刚开始推进飞快，模块少，边界清楚，想怎么改就怎么改，很爽。但系统长到一定规模，情况就变了：依赖关系越来越多，命名开始漂移，早期图省事留下的妥协固化成了结构惯性。团队投入没减少，人手可能还多了，但大家开始觉得”改不动了”。一个小改动要摸清它会影响哪些地方，光这件事就够累的，动手改反而是小头。
AI 没有改变这个过程，只是把它调快了。
在传统开发里，人手写代码本身就是一层天然过滤器——你写得慢，草率的依赖、混杂的实现，扩散速度就是有限的。但 AI 协作环境不一样：一个模块里的设计问题，几轮生成之后就成了整个代码库默认的写法。后面的人看到前面这么写，不会多想；AI 也照着这个模式继续补。“不太好的做法”很快就变成了”项目的标准做法”，而且这个过程是静悄悄发生的。等你意识到的时候，已经改不动了。
AI 是一个忠实的放大器。你走对了路，它帮你加速；你走错了路，它也帮你加速，速度一样快，甚至更快——因为走错路的时候你不会停下来仔细想。
所以”效率”这个词现在得更谨慎地看。“单位时间写了多少行代码”这个指标，在 AI 时代没有意义。工程上的效率得看更长的时间窗口：代码未来好不好维护，结构还能不能承受变化，加新东西的时候有没有余地。如果你每次交付都在透支可维护性，那这种效率只是在借未来的债。
开发者当中流传一句话，杀伤力很大：“先这样吧，后面再改。“但回头看，“后面再改”在大多数项目里，没有一次自动发生过。每次都是等到问题大到不得不改，才发现改的成本比当初做对的成本高了好几倍。技术债拖得越久，利息越高。
一个比喻：从”管字符”到”管 Agent 的注意力”
传统编程里，你直接打字，每个分号、每个变量名都是你的手在控制。你的工作粒度是字符。
Vibe Coding 里，字符是 Agent 打的。但 Agent 的”注意力”——也就是它的上下文窗口——是有限的资源。它一次能”想着”的东西就那么多：现在装着哪些文件的内容、记得 20 轮对话前讨论过什么、在意你刚强调的那个约束、意识到这个改动会影响别处。这些东西都在抢同一份”注意力预算”。
于是你的工作变成：
- 决定让 Agent 现在关注什么（给它合适的 spec、合适的文件、合适的任务粒度）
- 避免它的注意力被无关的东西占满（对话太长、读了太多无关文件、目标太散）
- 在它分心走偏的时候拉回来（打断、重启、refocus）
- 在自然的停顿点把注意力清零（完成一个阶段就开新 session）
“管字符 → 管 Agent 的注意力”——不是玄学，就是字面意思。你以前在乎每个分号，现在你在乎”Agent 现在脑子里装着什么、还能装多少、装的对不对、什么时候该清零”。写代码的”手感”还在，但操作对象从字符变成了 Agent 的注意力。
这个专题要讲什么
Vibe Coding 降低了软件开发的门槛，让更多人有机会把想法变成现实。但它也让”写出能跑的代码”和”做出好的软件”之间的差距变得更不容易察觉——AI 生成的东西看起来总是像模像样，很多人分不清”能跑”和”能用”的区别。
它对开发者的要求其实更高了。要求的能力从”手写实现细节”变成了定义规则、审阅结果、维护边界、为系统的长期命运负责。这些事 AI 做不了，至少目前做不了。
接下来的几篇，就是把这套”更高的要求”拆开讲透：
- 第 2 篇 · Spec 与上下文：一切的起点。怎么把意图说清楚，怎么用 AGENTS.md / CLAUDE.md 给 Agent 建立项目认知。
- 第 3 篇 · 提问即设计：你的 Prompt 质量直接决定代码质量。一套可复用的六段式结构。
- 第 4 篇 · Code Review 与复杂性预算：Code Review 正在变成第一基本功；怎么守住系统能承受的复杂度上限。
- 第 5 篇 · 什么时候 Vibe，什么时候收：探索区放开，生产区收紧。一套切换阈值。
- 第 6 篇 · 长任务实战：怎么用反馈闭环让 Agent 自主跑一小时甚至一整天。
- 第 7 篇 · 负责任的 Vibe：协作公约，以及一个关键警醒——AI 不能当你的架构师。
如果你正在 Vibe Coding 的路上，不妨先记住三个问题，后面每一篇都会帮你更好地回答它们：
生成的这段代码，你能向别人解释清楚吗？ 接受的这个实现，你愿意在三个月后维护它吗？ 今天省下的这个重构，明天会以什么代价还回来？
能回答好这几个问题，就够了。
本文为「Vibe Coding」专题开篇，综合整理自社区长文《Vibe Coding 到底是什么》（blog.byebug.cn）与《Vibe Coding 实战教学指南》。“Vibe Coding”一词出自 Andrej Karpathy。观点经二次消化重写，如有疏漏欢迎指正。
