Vibe Coding 不是「让 AI 写代码」 - Martin Fowler 为什么要拆开这个词

现在打开任何一个技术社区，“vibe coding”几乎成了“用 AI 写代码”的同义词。有人用它指 Cursor 里按 Tab 补全，有人用它指 Claude Code 跑一整晚，有人用它指自己干脆不写代码了。一个词，把所有人都装了进去。

Martin Fowler 不太同意这种用法。5 月 21 号，他在自己的 bliki 上一口气发了两篇短文 - Vibe Coding 和 Agentic Programming。同一天、同一个大主题，他没有合成一篇，而是拆成两个独立词条。这是一次刻意的「拆词」。

这篇我想聊聊 Fowler 为什么要在一个已经被用烂的词上较真，以及这条被他重新划清楚的分界线 - 你到底看不看 LLM 写的代码 - 对每天用 AI 编程的人意味着什么。

Karpathy 当初说的 vibe coding 是什么

“vibe coding”这个词不是新的。Fowler 在词条里把出处追得很清楚：2025 年 2 月，由经验丰富的程序员 Andrej Karpathy 在 X 上提出。Karpathy 的原话是这样的：

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. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper so I barely even touch the keyboard. I ask for the dumbest things like “decrease the padding on the sidebar by half” because I'm too lazy to find it. I “Accept All” always, I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension, I'd have to really read through it for a while. Sometimes the LLMs can't fix a bug so I just work around it or ask for random changes until it goes away. It's not too bad for throwaway weekend projects, but still quite amusing. I'm building a project or webapp, but it's not really coding - I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.

-- Andrej Karpathy

通读这一段，没有一句在谈代码质量。“I 'Accept All' always, I don't read the diffs anymore”、“The code grows beyond my usual comprehension”、“ask for random changes until it goes away” - Karpathy 描述的是一种主动放弃对代码掌控的状态。而且他自己框定了边界：“throwaway weekend projects”，一次性的周末项目。

Fowler 把这段话里最要紧的一点单独拎出来，当成整个定义的锚：

The key point about vibe coding is “forget that the code even exists”. This is what gives it much of its usefulness, but also its limitations.

“忘掉代码的存在” - 这几个字既是 vibe coding 全部价值的来源，也是它全部局限的来源。能不看代码，所以不需要编程能力，所以人人可用；但也正因为不看代码，后面那些问题才一个都躲不掉。

真正的分界线，是你看不看代码

Fowler 观察到一个现象：很多程序员现在让 LLM 写掉自己几乎全部的代码，有人甚至说自己可能再也不会亲手写一行了。这听上去很像 vibe coding。但 Fowler 说，不是 - 因为这些程序员在乎这些代码。他们 review 它，关注它的内部结构。

Since the November Inflection many programmers are getting LLMs to write all their code ... However they do care about this code, reviewing it, paying attention to its internal structure. In that case, they aren't forgetting the code exists, so it's really a different thing that I call Agentic Programming.

这就是另一篇词条的由来。Fowler 给这种工作方式起名 agentic programming，并且把它和 vibe coding 的区别说得不能再直白：

With vibe coding humans don't look at the code, indeed they forget that it even exists, while with agentic programming they are concerned with the code, often giving it detailed review.

两边用 LLM 写代码的程度可能一模一样 - 都可能是 100% 的代码由 LLM 生成。区别不在“谁敲的键盘”，而在“事后谁的眼睛扫过了这些代码，谁为它的结构负责”。

把两边摊开对比：

	Vibe Coding	Agentic Programming
看不看代码	不看，忘掉它的存在	看，常常逐行 review
谁为代码负责	没有人	人 - 对软件的行为和结构负责
需要编程能力吗	不需要	需要
适合的场景	一次性软件、原型、个人小工具	生产软件
出了 bug 怎么办	让 LLM 再改、绕过去、或随机改到不报错为止	人来 review、读测试结果、看各种 sensor 输出
核心技能	把需求描述清楚	harness engineering 加上对业务领域的理解

Fowler 还顺手划清了第三种东西：agentic programming 也不等于“把 LLM 当一个高级的代码补全”。在 IDE 里靠 LLM 补全，人始终主导着每一行；agentic programming 是人退到监督位，LLM 成段成段地干。三者是同一条光谱上的三个点。

那么具体到自己手上的活，该往哪边靠？Fowler 给的判断标准，其实可以画成一张图：

flowchart TD
    A["要用 LLM 做一个软件"] --> B{"它是一次性的吗？<br/>用户只有你或少数知情的人？"}
    B -->|"不是，会被广泛使用"| D["Agentic Programming<br/>必须 review 代码，对结构负责"]
    B -->|"是"| C{"会接触敏感数据或凭证吗？<br/>出错的后果严重吗？"}
    C -->|"否"| E["Vibe Coding<br/>忘掉代码，尽情迭代"]
    C -->|"是"| D

Fowler 为什么非要把这两个词分开

如果只是术语洁癖，Fowler 不至于专门发两篇。他在 Vibe Coding 词条里写了一句话，把动机说得很明白：

Sadly the term “vibe coding” really caught on, so many people use it to mean agentic programming. However I feel that despite this rapid Semantic Diffusion, it's worth trying to keep the concepts ... separate.

这里的 Semantic Diffusion（语义扩散）又是 Fowler 自己造的词 - 而且是 2006 年造的。他当时的定义是：

Semantic diffusion occurs when you have a word that is coined by a person or group, often with a pretty good definition, but then gets spread through the wider community in a way that weakens that definition.

一个词被人精心定义出来，然后在大范围传播的过程里，定义被一点点冲淡，最后稀释到这个词什么都指、因而什么都不指。Fowler 2006 年举的例子是 agile 和 Web 2.0 - 他见过有人以为敏捷就是“不做任何计划”。二十年后，同样的事正发生在 vibe coding 身上。

为什么这件事值得管？因为词一旦混了，边界就没了。“vibe coding”和“agentic programming”如果塌缩成同一个词，你就没办法讨论那个真正要紧的问题 - 这次该不该 review 代码。一个完全不懂编程的人用 vibe coding 给自己拼个小工具，挺好；但一个团队带着“反正是 vibe coding”的心态去做生产系统，那是另一回事。Fowler 想保住的不是词，是词背后那条能让你做出正确判断的界线。

越过边界会踩到什么

Fowler 给 vibe coding 圈定的安全区很小：

... disposable software that's only used by its author or a close group of collaborators who understand and accept the risks involved.

一次性的、用户只有作者本人或少数知情同伴的软件。出了这个圈，三类风险会逐个找上来，Fowler 在词条里逐条点了名。

第一是安全，他认为这是最严重的一个。 LLM 本身就是一个巨大的攻击面。vibe coding 产出的应用经常会暴露敏感信息，甚至把凭证暴露出去，让攻击者顺着往组织系统更深处渗透。Fowler 在这里特意点名，说即使是非程序员也得知道 Lethal Trifecta - 这是 Simon Willison 提出的概念：当一个 AI agent 同时具备三件事 - 能访问私有数据、会接触不可信内容、有对外通信的能力 - 数据被悄悄外泄的通道就成立了。问题在于，做 vibe coding 的人根本不看代码，他无从知道自己拼出来的东西有没有恰好凑齐这三条。

第二是可维护性。 不盯代码，vibe coding 会飞快产出大量低质量代码。Fowler 的原话是，这种代码会变得连 LLM 自己都难以修改和增强。他补了一句很值得琢磨的话：

... well-structured software makes life easier for LLMs too.

结构良好的代码，对 LLM 也更友好。换句话说，“忘掉代码”在短期是 vibe coding 的卖点，在长期却是它的自我拆台 - 你越不管结构，往后你和 LLM 就越改不动它。

第三是正确性。 LLM 会一本正经地编造错误的事实，这个毛病也会让它写出行为错误的软件，而这些错误用户不一定看得出来。更麻烦的是非确定性：你让 LLM 去改一个小功能，它完全可能在本来不该动的地方引入新的错误。Fowler 给的态度是：对 LLM 生成的软件保持怀疑 - 它仍然有用，但你得清楚风险在哪。

三条叠起来，Fowler 的结论很克制也很清楚：更复杂、用得更广、出错后果更大的代码，不应该被“忘掉”。

分界线的另一边，是专业开发者的主场

回到 agentic programming 这一侧。Fowler 给了它一个时间锚点，写在另一篇词条 November Inflection 里（发表于 5 月 1 号）：2025 年 11 月。那个月 Anthropic 发布了 Opus 4.5，OpenAI 发布了 GPT-5.2。Fowler 说，尤其是 Opus 4.5 加上 Claude Code 这个 harness，构成了 AI 用于编程的一个关键转折。他引了两个人的话：

one of those moments where the models get incrementally better in a way that tips across an invisible capability line where suddenly a whole bunch of much harder coding problems open up

-- Simon Willison

Sometime in late 2025, I wrote my final lines of code. ... that code wasn't written by hand. It was written by AI agents that I directed.

-- Adam Tornhill

注意 Tornhill 的措辞：“AI agents that I directed” - 他没说自己忘了代码，他说自己在指挥。这正好落在 agentic programming 这一边，不是 vibe coding。

那么 agentic programming 具体长什么样？Fowler 在词条里描述得很细：现在的 agentic 工具跑在终端环境里，程序员发出 prompt - 这些 prompt 常常会带上事先写好的、说明 LLM 该遵守哪些规范的文档；LLM 随后直接操作源码树，建文件、改文件、跑代码、看测试结果，然后持续往下做，常常一干就是很长一段时间。等它干完，人再来评估 - 做 code review、检查测试结果、查看其他各种 sensor 的输出。

这套工作方式把一个新技能推到了中心，Fowler 给它起名 harness engineering。当编程的本质变成“人监督 LLM agent 干活”，最值钱的能力就不再是敲代码的手速，而是打磨 LLM 周围那一圈 guide 和 sensor - 你喂给它什么指令文档、你靠什么信号判断它干得对不对。Fowler 还加了一条：程序员对自己所做领域的理解会变得更重要，因为他要和用户、客户一起，把产品一步步迭代地定义出来。

review、harness、领域理解 - 这些全都建立在一个前提上：代码还在，你也还在看它。而这恰恰是 vibe coding 主动放弃掉的那部分。

下次开工前，先问自己一个问题

所以下次你打开 Cursor 或者 Claude Code，可以先问自己一句：这一次，我会去看它写出来的代码吗？

如果答案是“不会，也不需要” - 你在 vibe coding。前提是这东西确实是一次性的，用户只有你自己或几个知道风险的人。周末搭个小工具、快速验证一个想法，尽管放心地 vibe，这正是它存在的意义。

如果答案是“会，我得对这些代码负责” - 那你做的是 agentic programming。它不会因为你全程没碰键盘，就自动降级成 vibe coding。代码还在，责任还在，review 那一步省不掉。

Fowler 这次拆的不是用词习惯，是这两件事背后截然不同的后果。把它们叫成同一个名字，最大的代价不是名称混乱，而是 - 你会在本该 review 的时候，以为自己可以“忘掉代码”。