文章目录
- 一条推文炸出的新词
- [传统编程与 Vibe Coding 的范式分野](#传统编程与 Vibe Coding 的范式分野)
- [AI 凭什么"听懂"你说话：Token 化机制](#AI 凭什么"听懂"你说话：Token 化机制)
- [上下文窗口与概率生成：AI 的"工作记忆"与"幻觉"](#上下文窗口与概率生成：AI 的"工作记忆"与"幻觉")
- [历史坐标：AI 编程的四阶段演进](#历史坐标：AI 编程的四阶段演进)
- [Vibe Coding 在 2026 年的真实坐标](#Vibe Coding 在 2026 年的真实坐标)
一条推文炸出的新词
Andrei Karpathy 这个名字在 AI 圈具有特殊分量。他是 OpenAI 的联合创始人之一，曾担任 Tesla 的 AI 总监，主导自动驾驶视觉系统的研发，又在 Stanford 开设了广受追捧的深度学习课程 CS231n。这样一位既懂模型底层原理、又亲手做过工业级系统的从业者，他给出的判断天然带有"内行认证"的色彩。当这样身份的人在 2025 年 2 月 3 日于 X 平台抛出一个新名词时，整个开发者社区自然不会等闲视之------一个由顶级研究者命名的概念，往往意味着某种趋势已经积累到需要一个正式称呼的程度。更重要的是，Karpathy 本身就是 AI 编程工具的重度使用者，他的判断不是来自实验室推演，而是来自日复一日的真实编码实践。
那条推文后来被无数次引用与解读，原话大意是："a new kind of coding... you just give in to the vibes, embrace exponentials, and forget that the code even exists"（一种新的编程方式......你只要沉浸在氛围里，拥抱指数增长，然后忘记代码的存在）。中文社区流传的版本是："完全沉浸在氛围中，拥抱指数级增长，忘记代码的存在。"这条推文描述的场景并不复杂：Karpathy 在用 Cursor（一款 AI 原生代码编辑器）写代码时，不再逐行检查生成的内容，而是直接全部接受（Accept All），只要程序能跑起来就继续往下走。他给这种状态起了一个名字------Vibe Coding。推文本身只有寥寥数句，但它抓住的恰恰是一种许多人已经在做、却没人给过名字的工作状态。
把原话拆开，三个关键词各自指向一种态度。第一个是 vibes（氛围/感觉），它借用自音乐和派对场景的俚语，本意是"跟着感觉走"，在这里指开发者不再较真于每一行代码的字面含义，而是凭"整体感觉"判断方向是否对路------就像有经验的厨师不靠菜谱靠手感调味，开发者凭对产品的整体判断来决定是否继续往前。第二个是 embrace exponentials（拥抱指数增长），强调的是 AI 能力的迭代速度------模型每隔几个月就会更新一版，今天的短板下个版本可能就补上了，开发者要学会"乘势"而不是"对抗"这种节奏。这意味着一种新的心态：不必死磕当下模型的某个缺陷，因为那个缺陷可能三个月后就自动消失了。第三个是 forget the code（忘记代码存在），这是最反直觉的一条，意思是把代码视作一种中间产物而非神圣文本，就像开车的人不必懂发动机原理，只要方向盘和刹车听话就行。
这三个关键词合在一起，勾勒出的是一种全新的开发者姿态：人从"和代码较劲"转向"和 AI 协作达成目标"。在传统观念里，优秀的程序员以对代码细节的极致掌控为荣，能背诵冷门 API、能徒手写出复杂算法是专业能力的象征。Karpathy 的推文等于公开宣告：在 AI 够强的前提下，这种掌控不再是唯一的高效路径，放手让 AI 去做实现、自己只管方向和验证，同样可以产出可用软件，而且往往更快。这种宣告之所以引发巨大反响，正是因为它挑战了程序员群体最核心的身份认同------如果代码不再是衡量水平的标尺，那"会编程"这件事该如何重新定义。
这个词的传播速度本身就印证了"指数增长"的说法。Collins 词典将其列为 2025 年度词汇之一，Merriam-Webster 则给出了一个略带锋芒的定义：一种借助 AI 辅助、但相对"careless"（漫不经心/不严谨）的写代码方式。这个"careless"具有明显的双面性：站在传统工程严谨性的角度，它是一种批评------不去核验生成的代码确实不够专业，在严肃项目里甚至算得上失职；但从 Karpathy 的原意来看，它其实是一种诚实的转述------他本就承认自己"不看代码"，只是这种"不看"建立在 AI 已经足够可靠的前提之上。两个词典的收录，意味着这个词已经突破了技术圈的黑话范畴，进入了大众语言库。一个技术俚语在不到一年内完成从个人推文到权威词典词条的跃迁，这种速度本身就在说明它命中的不是一个孤立现象。
更值得思考的是这个词背后的命名时机。在 2025 年初，用 AI 辅助写代码已经是一种普遍现象，但社区里始终没有一个精准的词来描述"我不读代码、直接接受、跑起来就行"这种既真实存在、又略带争议的工作状态。开发者们在实践中早已分化为两派：一派坚持逐行审查 AI 输出，把它当成一个需要监督的实习生，每生成一段都要自己过一遍才放心；另一派已经开始放手，像 Karpathy 那样信任并迭代，用速度换取覆盖率。两派之间缺乏一个共同语言来讨论分歧，争论往往沦为"你这样不安全"对"你那样太慢"的各说各话。Karpathy 的推文等于给一种"已经发生但无人定义"的现象贴上了标签。一旦有了名字，人们就能讨论它、拥护它、反对它，它也从一种个人习惯变成了一种可被研究的范式。这正是 Vibe Coding 这个词的符号意义所在------它不是发明了一种新做法，而是命名了一种早已存在的旧做法，并因此让这种做法获得了被审视、被改进、被系统化的可能。命名的力量，在于让模糊的实践变得可言说、可传授。
传统编程与 Vibe Coding 的范式分野
要理解 Vibe Coding 为何能独立成词，需要先看清它与传统编程在路径上的根本分歧。传统编程的学习曲线是出了名的陡峭，这种陡峭不体现在某一个环节，而是贯穿始终。一个零基础的学习者通常要花几个月掌握一门语言的语法（变量、循环、函数、类），这一步对很多人来说就已经足够劝退------报错信息晦涩、环境配置繁琐、一个分号缺失就能让整个程序崩溃。再花几个月在算法和数据结构上练习，理解排序、查找、树、图这些抽象概念，才能写出不那么低效的代码。还要花几个月做项目来串联知识，把语法和算法拼装成一个能跑的程序。最后才能产出一个"勉强可用"的软件，而且这个"可用"往往伴随着各种边角问题。
整条路径的核心动作是"搬运代码"：开发者把脑子里的逻辑翻译成语法，再把语法拼装成程序，出错时还要一行行调试。调试本身就是一个巨大的时间黑洞------一个空指针异常可能让人花半天排查，最终发现只是一个变量没有初始化。时间成本和学习成本都集中在"把想法变成代码"这一步，而这一步恰恰是最枯燥、淘汰率最高的。大量有产品想法的人，最终不是败在想法不好，而是败在"想法到代码"这段距离太远、太长、太陡。传统编程的门槛，本质上就是这段距离的长度。这也是为什么编程教育长期被视作"筛人"的学科------它筛掉的不是没有想法的人，而是扛不住这段距离的人。
Vibe Coding 把这条路径拦腰截断。它主张的路径是：先学会用清晰的自然语言表达需求，再让 AI 把需求实现成代码，开发者只负责"看效果、提反馈、做迭代"。学习周期从"学语法几个月"被压缩到"学会写需求几小时"。这不是说技术不重要，而是技术从"前置必修课"变成了"边用边学的伴随知识"------在和 AI 协作的过程中，自然会接触到框架、API、数据结构，只是不再需要先通过一场"语法考试"才能上场。这种从"先学后用"到"边用边学"的转变，是范式分野的起点。一个有产品想法但不会写代码的人，现在可以在几小时内看到自己的 idea 变成可运行的界面，这在传统路径下是不可想象的。
下面这张表从多个维度对比两种范式：
| 维度 | 传统编程 | Vibe Coding |
|---|---|---|
| 核心技能 | 语法、算法、调试 | 需求表达、效果判断、迭代 |
| 人的角色 | 代码编写者 | 需求提出者与审查者 |
| 关注点 | 代码怎么写 | 产品好不好用 |
| 学习周期 | 数月至数年 | 数小时至数周 |
| 出错处理 | 逐步调试代码 | 用自然语言描述问题让 AI 修 |
| 协作方式 | 人写代码，机器执行 | 人描述意图，AI 实现并执行 |
| 成本结构 | 时间花在实现 | 时间花在迭代与验证 |
围绕 Vibe Coding 有三个常见误区需要澄清。第一个误区是"Vibe Coding 等于不需要技术"。这是误读。两者的区别是"先学后用"还是"边用边学"，而不是"学不学"。一个完全不懂技术的人面对 AI 给出的报错会束手无策，而懂一点技术的人能看懂错误提示、能判断 AI 的方案是否合理、能在关键时刻给出更精确的指令。技术深度仍然是决定产出质量上限的因素，只是它不再卡在入口------不必先花半年学语法才能开始做东西，但能不能把东西做对、做好，依然和技术理解力正相关。一个理解数据库索引原理的人，能让 AI 生成更优的查询方案；一个理解前端渲染机制的人，能判断 AI 给的组件是否会引发性能问题。技术是放大器，不是门票。
第二个误区是"Vibe Coding 等于不验证"。Karpathy 的"不看代码"是一种个人选择，不等于"不验证结果"。Vibe Coding 的黄金法则是"信任但验证"（trust but verify）------可以信任 AI 生成的代码，但必须验证它跑出来的结果对不对。验证的对象从"代码写得对不对"转移到"行为符不符合预期"，这是验证方式的变化，不是验证本身的取消。一个负责任的 Vibe Coding 实践者，依然会运行测试、检查边界情况、对比预期输出，只是不再逐行审读源码。把"不读代码"等同于"不验证"，是对原意的曲解，也会在实践中付出代价。
第三个误区是"Vibe Coding 只能做玩具"。早期的确有很多"几分钟做个小工具"的演示，给人留下"这只是玩具"的印象。但到 2025-2026 年，已经有团队用它搭建生产级应用。关键在于：项目复杂度上去之后，Vibe Coding 会自然演化为更结构化的 Agent 工程，工具链、规范、测试都会补上。玩具与否取决于工程实践，不取决于编程范式本身。把"早期演示简单"等同于"能力上限低"，是对指数增长曲线的误判------今天看起来像玩具的，可能只是还没长大。
两种思路的差异，用一个具体例子最能说明。假设要做"一个能记账的网页"。传统编程思路会这样推进：先选框架（React 还是 Vue）、再设计数据库表结构（收入表、支出表、分类表）、然后写 ORM（对象关系映射，把数据库表映射成代码对象的层）、接着写后端 API（增删改查接口）、最后写前端页面，每一步都要开发者亲自落地代码，每一步都可能卡在某个语法或配置细节上------光是配好开发环境可能就耗掉半天。Vibe Coding 思路则是：先用一段自然语言描述"我要一个能记账的网页，能添加收入支出、按月统计、用图表展示"→AI 生成初版→在浏览器里看效果→用自然语言告诉 AI"图表颜色太深、加一个分类筛选、支持导出 CSV"→继续迭代。前者的精力花在"怎么写"，后者的精力花在"要什么"。这种关注点的转移，才是范式分野的本质------代码从"主角"变成了"中间产物"，人的注意力得以从实现细节上挪开，投向更重要的产品判断。当一个开发者不再被语法细节困住，他才有余力思考"用户真正需要什么"，而这恰恰是决定产品成败的关键。
这种转移也重新定义了"效率"的含义。在传统语境下，效率高的程序员指的是代码写得快、bug 少、能处理复杂逻辑的人。在 Vibe Coding 语境下，效率高的实践者指的是需求表达精准、迭代方向判断准确、验证及时的人。两者的能力模型截然不同：前者比拼的是"手速和准确度"，后者比拼的是"眼力和判断力"。这不是说后者比前者高级，而是说在 AI 已经接管了大量"手速"工作之后，决定整体产出效率的瓶颈从"写得多快"转移到了"方向走得多对"。一个方向判断准确的人，即使每一轮迭代都要花时间验证，总效率也远高于一个代码写得极快但方向跑偏的人------因为跑偏的返工成本，远大于多验证几轮的成本。
AI 凭什么"听懂"你说话：Token 化机制
Vibe Coding 能成立，前提是 AI 能"听懂"人类用自然语言描述的需求。要理解这种"听懂"的机制，绕不开一个基础概念------Token（令牌/词元）。AI 并不是像人那样逐字逐句地阅读文本，而是先把文本切成一个个小块，每个小块就是一个 Token，再把这些 Token 送入模型处理。比如"Hello World"这句话，会被切成"Hello"和" World"两个 Token；"我喜欢编程"可能被切成"我"、"喜欢"、"编程"三个 Token，也可能被切成不同的组合，具体取决于模型的分词器。可以把 Token 理解为 AI 阅读世界的"最小视觉单元"，就像人读字、计算机读字节一样，Token 是大模型处理语言的基本粒度。
分词背后的核心技术叫 BPE（Byte Pair Encoding，字节对编码），它通过统计训练语料中字符对的出现频率，反复合并最高频的相邻字符对，逐步构建出一个词表。高频出现的组合会被合并成一个单独的 Token，低频组合则被拆成更小的子词甚至单字符。这意味着"经常一起出现的文字"在 Token 层面会被当作一个整体处理，而罕见的词汇会被拆碎。这就是为什么"the"是一个 Token，而"supercalifragilistic"会被切成好几块------词表里没有收录后者的高频组合。
Token 这个概念之所以重要，是因为它直接关系到使用成本和上下文管理。几乎所有的商业大模型都按 Token 计费，输入 Token 和输出 Token 各有单价；同时模型每次能处理的 Token 总数也有上限，超出就要截断或分批。开发者在 Vibe Coding 中描述的每一句话、粘贴的每一段代码，都会被换算成 Token 计入账单和上下文。理解 Token，等于理解了 AI 编程的"计量单位"------就像开车要懂"升"是油的单位、用电要懂"度"是电的单位一样，用 AI 编程要懂 Token 是智能的计量单位。对 Token 没有概念的开发者，很容易在不知不觉中烧掉大量费用，或者在关键对话中超出上下文限制导致 AI"忘记"前面的内容。
一个经验性的换算关系是：1 个 Token 大约对应 4 个英文字符，或者 1 到 2 个中文字符。这意味着同样字数的内容，中文的 Token 消耗通常比英文高。举例来说，一篇 1000 字左右的中文文章，大约会占用 500 到 1000 个 Token；而同样信息量的英文文本，Token 数可能更低。这个差异在短文本里不明显，但在粘贴整个代码库、或者进行长对话时，会累积成可观的成本和上下文压力。这也是为什么在 Vibe Coding 中，"精炼地描述需求"本身就是一项省钱的技能------用更少的 Token 传达同样的意图，既省费用又给上下文留出更多空间放项目代码。
要精确知道一段文本到底消耗多少 Token，不能靠估算，得用工具测。OpenAI 开源的 tiktoken 库是最常用的 Token 计数工具之一。下面这段 Python 代码演示了如何计算一段中英文混合文本的 Token 数：
python
import tiktoken
# 使用 GPT-4o 的分词器
enc = tiktoken.encoding_for_model("gpt-4o")
text = "Hello World，我喜欢用 Vibe Coding 写代码。"
# 编码成 Token id 序列
token_ids = enc.encode(text)
tokens = [enc.decode([tid]) for tid in token_ids]
print(f"原始文本：{text}")
print(f"字符数：{len(text)}")
print(f"Token 数：{len(token_ids)}")
print(f"Token 切分结果：{tokens}")运行结果（以 tiktoken 对 gpt-4o 的编码为准，实际输出可能因库版本略有差异）：
原始文本：Hello World，我喜欢用 Vibe Coding 写代码。
字符数：29
Token 数：18
Token 切分结果：['Hello', ' World', '，', '我', '喜欢', '用', ' V', 'ibe', ' Coding', '写', '代码', '。']从运行结果能看到几个有意思的现象。第一，英文单词"Hello""World"各占一个 Token，符合"1 Token≈4 英文字符"的规律。第二，中文部分"我""喜欢""用""写""代码"各占一个 Token，"代码"作为一个词被切成单个 Token，但整体上中文的 Token 效率低于英文------同样含义的内容要消耗更多 Token。第三，"Vibe"被切成了" V"和"ibe"两块，这是因为分词器在训练语料里没见过这个词的高频组合，只能按子词切分------这也是为什么生僻术语和专有名词会消耗更多 Token。把这些现象连起来看，就能理解为什么"用 AI 看得懂的方式精炼表达"会同时影响效果和成本：表达越精准，Token 消耗越少，AI 理解也越准确。
如果换一段更长的真实代码场景来测试，差异会更明显。假设把一个 200 行的 Python 文件喂给模型，其中注释和字符串包含大量中文，那么 Token 数可能远超行数的某个固定倍数。开发者在做"把整个项目塞进上下文"的决策时，必须先用工具测一下实际 Token 数，而不是想当然地估算------因为分词器的切分方式往往和直觉不符，一段看起来不长的中文注释可能吃掉意想不到的 Token 预算。
不同模型的 Tokenizer（分词器）对中文的切分策略并不一致，这会直接影响中文场景下的成本和效果。Claude、GPT、GLM（智谱）等模型各有自己的词表，对同一个中文句子切出的 Token 数可能相差 20% 甚至更多。一般来说，国产模型对中文的词表优化更好，单位 Token 能承载更多中文信息；而部分海外模型在中文上切得更碎，单次对话的 Token 消耗更高。在做选型时，除了看模型能力，也要把"这个模型处理中文的 Token 效率"纳入考量，尤其是高频调用、长上下文的场景。同一个中文需求描述，在 A 模型上花 500 Token，在 B 模型上可能花 700 Token，长期累积下来成本差距相当可观。（注：各模型分词器细节以官方文档为准，本文核对时间为 2026 年 5 月。）
Token 机制还揭示了一个容易忽视的事实：AI 对代码的"理解"本质上是把代码当成一种特殊文本进行切分和概率建模。它不是真的"读懂"了代码的语义结构，而是根据海量训练数据学会了"这一段 Token 之后，最可能接哪一段 Token"。这就是为什么 AI 能流畅地写出看起来很专业的代码，却不保证逻辑正确------它匹配的是"代码长什么样"的模式，而不是"代码应该怎么运行"的因果。这种理解方式强大，擅长模式匹配和迁移，却不擅长严格的逻辑推理和确定性计算。一个靠概率"接龙"的系统，天然存在接错的可能，这正是下一节要讨论的"幻觉"问题的根源。
在实际的 Vibe Coding 中，Token 意识会直接影响协作效率。一个常见的失误是：开发者在对话里反复粘贴大段代码，却不清理前面的历史消息，导致上下文里堆积了大量已经无关紧要的旧代码，Token 被白白浪费在"过时内容"上。有经验的实践者会定期开新对话、只保留当前任务必需的上下文、用"精炼摘要"代替整段代码粘贴。这些操作本质上都是在做 Token 预算管理------把有限的 Token 预算花在刀刃上，而非撒在噪音上。
上下文窗口与概率生成：AI 的"工作记忆"与"幻觉"
理解了 Token，就能理解另一个决定 AI 编程能力上限的概念------上下文窗口（Context Window）。上下文窗口指的是模型在一次推理中能"看到并记住"的 Token 总量，可以类比为开发者办公桌的大小：桌子越大，能同时摊开的资料越多；桌子越小，就只能放最新的几份，旧资料必须收起来。AI 在一次对话里能参考的所有内容------系统提示、历史对话、粘贴的代码、文档------都要塞进这个"窗口"，超出就会被截断或遗忘。窗口大小直接决定了 AI 能在多大范围内保持"记忆连贯"，也决定了它能处理的项目规模上限。
上下文窗口的演进速度本身就是"指数增长"的一个缩影。早期模型只有 4K 左右的窗口，大约相当于一篇短文；后来扩展到 128K，约等于一本中等长度的小说；再往后 200K，已经能放下一本厚书；到 2025-2026 年，Claude 等模型已经支持 1M（一百万）Token 的上下文，相当于能塞进一个中小型项目的全部代码。下面的对照表给出一个直观感受：
| 上下文窗口 | 大致容量 | 典型对应物 |
|---|---|---|
| 4K | 约 3000 字 | 一篇短文 / 几页文档 |
| 128K | 约 10 万字 | 一本中等小说 |
| 200K | 约 15 万字 | 一本厚书 / 小项目全部代码 |
| 1M | 约 70 万字 | 一个中型项目的代码库 |
（注：以上容量为粗略换算，2026 年各模型的实际上下文窗口以官方文档为准，本文数据核对时间为 2026 年 5 月。）
上下文窗口越大，AI 编程能力越强，原因在于它能同时"看到"更多项目代码。在 4K 时代，开发者只能把当前要改的函数贴给 AI，AI 对项目全貌一无所知，给出的建议常常和现有代码风格冲突、或者重复造轮子------它不知道你已经有一个现成的工具函数，又给你写了一个功能重复的。到了 1M 时代，整个仓库都能塞进上下文，AI 可以同时参考配置文件、数据库模型、路由定义、前端组件，给出的修改建议能和既有架构对齐。这种"全局视野"是 Agent 能"自主完成任务"的前提之一------没有大窗口，Agent 就没法在一次任务里连贯地改完涉及多个文件的复杂需求，它会在改 A 文件时忘记 B 文件的约束。
需要澄清的是，"窗口大"不等于"记得牢"。即使上下文窗口支持 1M Token，模型对窗口内不同位置内容的注意力也并非均匀分布------大量实验表明，模型对开头和结尾的内容记忆更牢，对中间部分容易"走神"，这被称为"lost in the middle"现象。这意味着在 Vibe Coding 中，把最重要的约束和上下文放在对话的开头或结尾，效果往往好于埋在中间。理解窗口的"形状"比只看"大小"更重要。
但上下文窗口再大，也改变不了一个本质事实：大模型是概率生成系统。它的核心机制是"预测下一个 Token"------给定前面的所有 Token，计算下一个 Token 的概率分布，然后采样输出。这个过程很像一个极其博学但偶尔"走神"的助手：大多数时候它顺着上下文给出合理接续，但因为没有真正的"事实核查"机制，它也可能一本正经地输出一个看似合理、实则不存在的答案。这就是所谓"幻觉"（Hallucination），中文圈形象地称之为"一本正经地胡说八道"。
在编程场景里，幻觉的典型表现包括：编造一个并不存在的函数或 API、给出语法正确但调用参数错误的示例、引用一个版本号对不上的库用法。比如 AI 可能自信地告诉开发者"使用 foo-bar 库的 quickSort(arr) 函数即可排序"，但这个库或这个函数根本不存在；又或者它给出的某 API 调用方式在最新版本里已经被废弃，参数签名已经变了，但 AI 仍然按照旧版本的样子来写。这类问题对初学者尤其危险，因为 AI 的回答看起来非常专业、非常笃定，语气上没有任何"我不确定"的提示，缺乏经验的人很难第一时间辨别真伪。幻觉不是 bug，而是概率生成的结构性特征------只要模型是靠"猜下一个词"工作，就永远存在猜错的可能。这也是为什么 Vibe Coding 的"忘记代码"是有条件的：你可以在大部分时候不读代码，但在涉及正确性的关键节点，必须有验证机制兜底。
应对幻觉的核心策略是"信任但验证"。对于 UI 样式、文案、纯展示逻辑这类出错了影响有限的场景，可以容忍较高的信任度，错了也只是一次迭代的事；但对于数据库操作、用户认证、支付逻辑这类"出错就要命"的环节，AI 给出的每一行涉及外部接口的代码都应该查官方文档核对。具体做法是：让 AI 给出方案的同时标注依据（来自哪个库的哪个版本）、对关键调用去官方文档原文比对、对涉及权限和数据的操作加测试用例。比如 AI 说"用 bcrypt.hash(password, 10)"，开发者应该去 bcrypt 的官方文档确认这个函数签名和参数含义是否正确，而不是想当然地接受。这条"信任但验证"的黄金法则，是 Vibe Coding 能从"玩具"走向"可用"的底线------它不要求人读懂每一行代码，但要求人能判断每一行代码的后果。验证的本质，是把概率系统的"可能出错"转化为"出错能被发现"。
把幻觉问题放到 Vibe Coding 的语境里看，会发现一个有趣的张力：Vibe Coding 鼓励"忘记代码"，而幻觉恰恰在代码层面最危险。化解这个张力的方法不是回到逐行审查，而是建立分层信任机制------根据出错的后果严重程度，给不同模块分配不同的信任等级。展示层可以高信任、快速迭代；业务逻辑层中等信任、看关键逻辑；基础设施层（数据库、认证、支付）低信任、逐项验证。这种分层不是额外负担，而是任何严肃项目都应有的工程纪律，Vibe Coding 只是让它变得更显性。
历史坐标：AI 编程的四阶段演进
把 Vibe Coding 放回时间轴上，会发现它并非凭空出现，而是 AI 编程能力演进到特定阶段的产物。整个过程大致可以划分为四个阶段，每个阶段的标志性变化都对应着开发者与 AI 协作方式的根本改变。理解这条演进线，才能理解为什么 Vibe Coding 恰恰在 2025 年这个时间点被命名------它不是某个天才的灵光一现，而是技术积累到临界点后的自然涌现。
第一阶段是智能补全，时间大约在 2020 到 2022 年，代表产品是 GitHub Copilot 的早期版本和 TabNine。这一阶段 AI 的能力边界是"行级联想"------开发者敲出几个字符，AI 猜测整行或接下来几行应该是什么，类似输入法的联想输入，只是联想的对象从词语变成了代码。Copilot 基于 Codex 模型（OpenAI 基于 GPT-3 微调的代码模型），能在开发者写代码时实时给出补全建议，按 Tab 键即可接受。开发者的角色没有变化，依然是亲手写每一行，AI 只是省去了打字的时间。这一阶段谈不上 Vibe Coding，因为人必须全程在场，AI 连一个完整函数都很难独立生成，更别说理解项目意图。它的价值更多在于"省键盘"，而非"省脑力"------每分钟多打几十个字符，但思考的重担依然全在人肩上。
第二阶段是对话式编程，时间在 2023 到 2024 年，代表是 ChatGPT、Claude.ai 等通用对话产品的编程应用。开发者可以把需求描述给 AI，AI 生成一段代码块作为回答，但这段代码不会自动进入项目，需要人手动复制粘贴、手动调整依赖、手动修错。这一阶段 AI 的能力边界是"问答式生成"------它不了解项目全貌，只看得到这次对话里粘贴的内容，给出的代码常常和项目既有结构对不上。一个典型场景是：开发者把报错信息贴给 ChatGPT，得到一段修复代码，然后手动粘贴回编辑器，发现 import 路径不对、变量名不匹配，再回去追问。开发者依然是"搬运工"，只是搬运的对象从"脑子里的逻辑"变成了"AI 生成的代码块"，谈不上"忘记代码"。这一阶段最大的贡献是让开发者意识到 AI 能写代码，但协作方式仍然是人主导、AI 辅助。
第三阶段是智能体编程（Agent Coding），从 2024 年至今，代表产品是 Claude Code、Cursor 的 Agent 模式、OpenAI Codex 等。这一阶段的关键突破是 AI 从"回答问题"升级为"完成任务"------它能直接读写本地文件、执行命令、调用工具（如搜索、运行测试、查文档），在最小化人工介入的情况下推进一个任务到完成。开发者可以描述"给这个项目加一个登录功能"，Agent 会自己去读现有结构、设计实现、写代码、跑测试、改 bug，整个过程中人只需要在关键节点做判断。只有在第三阶段，Vibe Coding 才真正成为可能：因为只有 Agent 能"自主执行"，人才能从"搬运代码"中解放出来，真正去"忘记代码"。这一阶段和前两阶段的根本区别在于"落地动作"的归属------前两阶段落地靠人手，第三阶段落地靠 Agent 自己。
第四阶段是协作工程（Collaborative Engineering），目前还在形成中。它的特征是多 Agent 协同------一个负责写代码、一个负责测试、一个负责审查、一个负责文档，人类开发者的角色从"执行者"上升为"项目总监"，负责拆解任务、定义标准、做关键决策。这一阶段还在演进，标准工具链和工作流尚未稳定，但方向已经清晰：人越来越少地碰代码细节，越来越多地管"做什么"和"做得对不对"。当多个 Agent 各司其职、互相校验时，单个 Agent 的幻觉风险也能被系统性降低------写代码的 Agent 犯的错，审查的 Agent 可能会揪出来。
下面的表格把四个阶段的核心特征并置，便于对照：
| 阶段 | 时期 | 代表产品 | AI 能力边界 | 人的角色 |
|---|---|---|---|---|
| 智能补全 | 2020-2022 | Copilot 早期 / TabNine | 行级联想 | 亲手写每一行 |
| 对话式编程 | 2023-2024 | ChatGPT / Claude.ai | 问答式生成代码块 | 复制粘贴 + 调试 |
| 智能体编程 | 2024 至今 | Claude Code / Cursor Agent / Codex | 自主完成任务 | 提需求 + 审查 |
| 协作工程 | 形成中 | 多 Agent 协同 | 多角色协同 | 项目总监 |
核心论点在这里很明确：Vibe Coding 只在第三阶段才可能。前两个阶段，人必须亲自搬运代码------无论 AI 多聪明，最终的"落地"动作都靠人手完成，人无法"忘记代码"。只有当 Agent 能自己读写文件、运行命令、调用工具，把"落地"这一步也接管过去，人才能真正"沉浸到氛围里"。换句话说，Vibe Coding 不是一种态度的转变，而是一种能力门槛被跨过之后的自然结果。从第二阶段到第三阶段的跨越，是整个演进中最关键的一跳：它把人从"代码搬运工"变成了"任务指挥官"，这一跳之后，"忘记代码"才从一句口号变成了可操作的实践。Karpathy 在 2025 年初命名它，正是因为第三阶段的能力在那时刚刚达到"可用"的临界点------再早一点，Agent 还没强到能让人放心不看代码；再晚一点，这个现象又会被淹没在更多新概念里。命名发生在临界点刚刚跨过的时刻，既不超前也不滞后，这本身就是技术演进规律的一个注脚。
Vibe Coding 在 2026 年的真实坐标
站在 2026 年中回看，Vibe Coding 这个词的命运本身就折射出 AI 编程范式的转移速度。一个由个人推文创造的技术俚语，不到一年就被 Collins 和 Merriam-Webster 两大权威词典收录，这种从"圈内黑话"到"大众词条"的跃迁，在技术史上并不多见。它说明 Vibe Coding 命中的不是某个小众工具的用法，而是一种已经触达大众编程认知的范式转移------当普通用户也能用 AI"造软件"时，词典必须给这种新现象一个名字。一个词进词典的速度，往往就是它所代表的现象普及的速度。对比之下，"云计算"从概念提出到进入大众词典花了数年，而 Vibe Coding 只用了不到一年，这种压缩本身就是"指数增长"在文化层面的体现。
"指数增长"在 2026 年有了更具体的可量化指标。模型能力方面，以 SWE-bench（一个评估模型自主解决真实软件工程问题的基准测试）为例，主流模型的得分从早期 50% 量级一路攀升，Claude 系列在 2026 年的某些配置下已达到 80% 以上（注：具体数值以官方基准为准，本文核对时间为 2026 年 5 月）。SWE-bench 的题目来自真实开源项目的 issue，要求模型理解问题、定位代码、给出修复并验证，80% 的通过率意味着模型在"自主解决工程问题"这件事上已经接近资深开发者的水平。工具生态方面，Agent 化的代码编辑器、命令行工具、CI/CD 集成在一年内快速成熟，开发者已经能在主流 IDE 里直接唤起 Agent 完成跨文件改动，而不需要切换到单独的对话窗口。社区采用度方面，从独立开发者到企业团队，"用 AI 写代码"从尝鲜变成默认选项。三者同步爆发，共同把 Vibe Coding 从"少数人的炫技"推向"多数人的日常"。
不过，Karpathy 本人在 2025 年中后期的公开内容里出现了一个值得关注的转向。他开始更多讨论"Harness Engineering"（驾驭工程/管控工程），即如何为越来越强的 AI 搭建可控的工程框架，而不是单纯"沉浸氛围"。这被不少观察者解读为：Vibe Coding 作为一个"阶段"正在落幕，但作为一种"心法"------把注意力从代码细节转向意图表达和结果验证------会延续到下一个阶段。当模型强到几乎不需要人去"vibe"时，剩下的核心工作就是如何更好地"驾驭"它：拆解任务、定义验收标准、设计防护栏、搭建反馈回路。Karpathy 的转向，恰恰印证了"指数增长"的另一面------能力涨得快，人对能力的管控方式也得跟着涨。一个只会"沉浸氛围"而不会"搭建框架"的实践者，在模型越来越强的趋势下反而会越来越被动，因为强大的能力如果没有约束，破坏力和创造力一样大。
这个转向也提示了一个更深层的判断：Vibe Coding 的历史意义，可能不在于它是一种长久的编程方式，而在于它是一个过渡阶段的命名。它标记了"人从写代码到管 AI"这段过渡的起点。在过渡期内，"沉浸氛围"是可行甚至高效的，因为模型还不够强到完全自治，但已经强到可以让人放手大部分实现细节。当模型继续变强，过渡期结束，"沉浸"就会被"驾驭"取代------不是回到亲手写代码，而是上升到更高的抽象层去指挥和监督 AI。理解这一点，有助于把 Vibe Coding 放在正确的期望值上：它是当下的实用策略，不是终点。把一个过渡阶段的策略当成永恒不变的法则，或者在它该进化时还固守"沉浸氛围"，都会让实践者在下一波能力跃迁中掉队。
从更宏观的视角看，Vibe Coding 的出现也折射出软件开发行业的一个结构性变化：编程能力的获取门槛正在急剧降低，而判断力的价值正在急剧上升。过去，能写代码本身就是一种稀缺技能，掌握它的人天然拥有竞争优势。当 AI 把"写代码"这一步的成本压到接近零，稀缺性就转移到了上游------能不能想清楚要做什么、能不能判断 AI 给的东西对不对、能不能在模糊需求中找到清晰路径。这种变化对从业者的影响是双面的：对只会写代码但缺乏产品判断的人是冲击，对有想法但被代码门槛挡住的人是机会。
本系列后续 4 篇将沿着这条线索继续展开。第二篇聚焦"怎么用"，拆解 Vibe Coding 的标准工作流与典型陷阱，给出从需求描述到迭代验证的可操作步骤；第三篇聚焦"用什么"，盘点 2026 年主流工具链的选型与组合，对比不同 Agent 化工具的适用场景；第四篇聚焦"何时用"，讨论 Vibe Coding 适用的场景边界与不适用的高风险领域，帮开发者在效率和安全之间找到平衡点；第五篇聚焦"向何处去"，从协作工程出发展望 AI 编程的下一个范式。理解了起源与本质，后续的实践讨论才有共同的坐标系------知道 Vibe Coding 从哪来、为什么在这个时间点出现、它的能力边界由什么决定，才能在"怎么用"的层面做出清醒而不是盲从的选择。