我们该如何停止"氛围编程"(Vibe Coding)?

#ai#coding
目录

本文是 《How Do We Stop Vibe Coding?》 的中文翻译,原文作者为 Alex Klos(发布于 2026 年 7 月 24 日)。

意图高于代码

Claude Code 在 2025 年 12 月底爆发式流行起来之后,一大批软件开发者很快就把编码智能体(Coding Agent)纳入了他们的核心开发工作流。

发明”氛围编程”(vibe coding)这个说法的 Andrej Karpathy,在 2026 年 3 月的 No Priors 播客上说过:

大概从 12 月起,我基本上就没有敲过一行代码,这是一个极其巨大的变化。我觉得普通人根本意识不到这件事已经发生,以及它的影响有多剧烈。

我相信他。很多人说这只是营销或者炒作,但作为一个同样自去年起一行代码也没写过的人,我认为他说的是实话。至于这是好事还是坏事,取决于你的立场,但毫无疑问,我们已经进入了一个软件工程的新时代。

尽管智能体的采用速度很快,但从业者和那些看着他们产出的人之间,正在滋生出普遍的焦虑:这一波”垃圾产出”(slop)的浪潮什么时候才能结束?我们是不是为了图方便而自毁前程?我们该怎么停下这一切?

意图高于代码

UML 的联合创始人 Grady Booch 实际上论证过,我们正处于软件工程的第三个黄金时代:

Booch 谨慎地指出,这第三个时代并不是由 AI 开启的,只是被 AI 加速了。但他还把 AI 编码智能体比作 Grace Hopper 时代编译器的到来,而正是这个比较才关键。编译器抽象掉了机器,智能体则抽象掉了代码本身。

我们第一次可以做到直接从意图生成代码。正是缺乏这种能力,才在当年扼杀了模型驱动开发(MDD)(对 UML 你尽可以有自己的看法,但也许是时候考虑以某种形式把 MDD 带回来了)。

实际上,当我们沿着抽象层次上移到”意图”层面时,我们会失去很多曾经让编写代码变成一项可靠工程的那些工具和方法。如果我们能适应这种转变,我相信这不仅能加速开发,还可能极大地提升软件解决方案的质量。

但目前,我们被困在了”氛围编程的赌场”里。人人都像世界末日一样拼命产出代码,拉动拉杆,指望运气好。

问题所在

氛围编程几乎被一致地描述为:(a) 损害个人对解决方案和架构的理解;(b) 不可靠,因为提示词缺乏明确的规格、自然语言接口有损耗、以及代码生成是非确定性的。

当你在氛围编程时:

这就是”黑盒效应”,它会慢慢吞噬你的工作流,让你作为软件工程师变得越来越不严谨,直到最后你闭着眼睛推送 commit,把生产环境搞挂。

即便你不这样滥用编码智能体,而是更愿意手动编程,也很难否认这很可能就是整个软件工程的未来。我们可以看到有多少工程师把编码智能体当作核心工作流的一部分,有多少”100 倍开发者”已经在尝试用它搭建自主循环,仿佛控制和决策只是通往真正目标——token 最大化(tokenmaxxing)——的干扰。

无论如何,这一切归结为信任问题:你既无法信任自己对代码库的理解,也无法信任智能体真的做了你想让它做的事。

现有方案都还不成熟

我们都明白这是坏事——但解决方案呢?关于这个话题的讨论很多,但我要说,到目前为止提出的东西还没有一个真正令人信服。

首先,我们要先就”我们到底想干什么”达成一致:我们想要的是尽可能减少对编码智能体产出的信任依赖。

为此,我们需要:

  1. 智能体可靠地做我们让它做的事。 理想情况下是确定性的——这可能做不到,但这是一个好的目标。
  2. 能够审计和追踪它对我们的代码库做了什么。 理想情况下,不必非得去读代码。
  3. 把摩擦降到最低。 氛围编程之所以胜出,是因为它是最省力的路径,我们必须接受这一点,然后把”有纪律的路径”变成”轻松的路径”。

而现有的解决方案没有一个能充分解决以上三点。它们大多依赖——或者说本质上就是——某种提示词工程(prompt engineering),而这跟意图蒸馏(intent distillation,即第 1 点)不是一回事。

Markdown 规范文档

很多和我聊过的工程师都会这样打开话匣子:

呃,我用 markdown 规范文档,并协调一个智能体流水线:让它们评审规范、把它们实现成代码,然后管理和更新它们;它还会检查一致性,对照现有代码库做校验,标记出任何冲突,然后交接给实现环节,一旦完成就再循环回来更新规范,这样文档和代码永远不会脱节,所以实际上 markdown 才是事实来源,其他一切都围绕它转、保持同步……

在我的眼神逐渐失焦的同时,我忍不住想:

这背后会冒出太多问题,而通常这些问题的答案都非常含糊——到这一步,它看起来就像是一个个人工作流的优化,并没有可验证的影响。无论他们做了什么,都只是”让他们自己感觉严谨”而已。

Addy Osmani 在 2026 年 2 月的文章《如何为 AI 智能体写一份好的规范》(How to Write a Good Spec for AI Agents)就是一个很好的例证。

它并不是含糊——它很”密”。五条原则、一个六节式的格式、一项对 2500 个配置文件的调研、你听过的所有工具都被点名提及。它看起来像个系统。然后你意识到,整篇文章其实只是在描述智能体语境下的提示词工程。

我们不能认真地把这称为”规范驱动开发”,因为规范并不是”事实来源”,而只是一个引导性的提示词。它没有强制执行机制,甚至没有对账机制——除了问智能体”代码是否遵循了规范?”——而这个问题 AI 想怎么解释都可以,因为根本没有共享的语法!

从根本上说,markdown 规范并不能解决我们对智能体的信任缺失,而且它们管理起来简直烦人。它们必须被明确地结构化,并放入一个更大的系统中,才能变得有用。

Skills(技能)

本质上,这些是视任务而有条件注入的上下文/指令。虽然它们可能有用,但依然完全依赖智能体去遵守,而这在需要上,和 markdown 规范失败的方式如出一辙——即使它们实现起来没那么折腾。

有趣的是,它们也往往是让人讨厌的花架子,比如 gstack 里这个巨大的”QA”技能。

我很确定,用提示词”帮我找 bug 并修一下”对大多数智能体来说效果一样(甚至更好?)。

Skills 顶多算一种补充,本质上还是提示词工程。

Spec Kit 与 OpenSpec 等

Spec Kit 是一个 markdown 模板目录,由 CLI 放进你的项目。你要按顺序跑六条命令:specify(定义)→ clarify(澄清)→ plan(计划)→ tasks(任务)→ analyze(分析)→ implement(实现)。

在幕后,智能体被引导着按照模板去定义一切,然后把输出留作后续提示词的上下文。

这几乎是一个开始,因为它试图给氛围编程套上某种流程,并粗略地定义了编码智能体要遵循的结构。关键词是”粗略”,问题在于:整个流程还是由开发者自己驱动——从一条命令变成了六条——却依然无法真正”看到”任何东西。

OpenSpec 是同一个思路的轻量版:explore(探索)→ propose(提议)→ apply(应用)→ archive(归档),代替了那六条命令的流水线;用纯 markdown 的 WHEN/THEN 场景来代替 Kiro 的 EARS。它下了同样的赌注,也用同样的方式失败:你驱动流程,智能体给自己的作业打分,但没有任何机械性的机制去对照规范和代码。

这样的项目有一大堆,而且它们基本上都一样。

Kiro

Kiro 试图通过 hooks,引导智能体使用带 EARS 需求的 markdown 规范,从而把功能开发系统化。

如果你不知道 EARS(Easy Approach to Requirements Syntax,易用需求语法)是什么,下面举两个例子,对比一下自然语言需求和 EARS 需求:

自然语言EARS
出于安全考虑,用户闲置一段时间后应该被登出。当一个用户会话闲置满 15 分钟时,系统应终止该会话,并将用户重定向到登录页。
优雅地处理支付失败。如果一次支付尝试失败,那么系统应保留购物车内容,并显示失败的原因。

这里使用 EARS 很有意思,因为它通过把需求写成比纯散文更结构化的形式,对智能体和开发者都有帮助。当你处理的是”意图”时,使用非结构化的散文很快会让你眼花缭乱;你没法像看代码那样去扫读它。EARS 能帮你解决这个问题。

实现 hooks 也是不错的一步,它迫使智能体对触发器做出反应,并明确地遵循流程的每一步。它不是确定性的,但它是结构。

遗憾的是,Kiro 在两个地方崩掉了:

测试驱动开发(TDD)

测试的名称就是对意图的一种描述;它是代码必须满足的业务或流程需求,用自然语言写成。测试本身是通向真实代码的锚点,希望它能证明代码与所说的意图一致。从这个意义上说,更高级别的测试甚至可以作为功能依赖图。

终于有了一点”确定性强制”的影子。这确实能帮忙!

然而,开发者通常会让智能体去写测试,因为这样更省事,但这又把我们想解决的同样的问题重新引入了。

另一种做法是手动写测试,但那样你就得了解代码的实现——而且你得写代码,而如果我们的目标是”把代码抽象掉”,这恐怕就是个问题。我不是说亲手写测试是错的,但本文的重点是如何修复氛围编程。作为编码智能体的爱好者,我们希望能尽可能停留在”意图”这一层,而不是”实现”那一层。

附注: CodeSpeak——下文会讲到——最近就撞上了这个确切的问题:最初的想法是让开发者手动写规范文件,但大多数 alpha 测试者反而让他们的智能体去写。他们后来转向了从自然语言提示词中自动提取结构化意图。

所以,我们又绕回来了:TDD 能解决部分问题,但前提是我们能约束智能体怎么写测试,或者能确定性地生成测试。

拼图正在各就各位

前面那些方案之所以不合格,是因为它们没有触及核心问题:信任。

没错,它们确实试图让智能体更好地对齐我们的意图。它们试图给智能体一份操作规程。它们甚至有一些基本的”保留变更历史”或”收紧缰绳”(比如使用 hooks)的概念。

但本质上它仍然是一个提示词接口——只不过多加了点仪式当纪律——外加阅读散文或代码。它们没有揭示你正在处理的完整图景。它们没有强制执行”智能体必须实现你定义的东西”,甚至不强制”智能体必须实现它自己声称实现的东西”。它们没有提供一个开发者与智能体都能同意的共享表面。

而要解决这个问题真的很难。颇具意味的是,Tessl——曾以”规范驱动开发”的愿景融了 1.25 亿美元——已经悄悄从”把 SDD 卖给开发者”转向了”skills 是新的代码”。呃哦?

幸运的是,这个领域还很年轻,正在积极试验,而且已经有几种方法开始收敛到某种真正管用的东西上了。

下面这两个项目(声明:其中一个是我的)在我看来,是走对了方向的那两个。

顺便说一句:这也是我实际知道的、唯一把重心放在”信任问题”上的项目;如果还有其他的,我很乐意听听。

CodeSpeak

由 Kotlin 之父 Andrey Breslav 创办。

CodeSpeak 的赌注是:信任可以被”编译”掉。你写简洁的 markdown 规范,组织成可以互相 import 的模块,然后 codespeak build 会把它们编译成可工作的代码——Python、Go 或 TypeScript,而这些代码本来就不是给你审查的。这套工具链很认真地对待”编译器”这个框架:构建前校验规范的一致性,构建后运行测试;codespeak takeover 甚至可以从现有代码库反向生成规范。

自从我前面提到的转向之后,他们还在其上加了一个需求层:与你的智能体的对话会被蒸馏成结构化的需求,映射到实现它们的代码文件,当某个变更发生偏离时会标记出漂移(drift)。而且他们还在继续形式化规范语言本身,目标是让构建变得确定,或者接近确定。

Scryer

过去六个月我一直在做这个工具,让它贴合我自己的开发工作流反复迭代。

Scryer 押的是相反的赌注:对智能体的信任不可消减,所以应该让”消耗信任”尽可能便宜。这是面向编码智能体的模型驱动开发。你和你的智能体共享同一个系统模型:一个 C4 风格的层级结构,每个节点都用简短、与语言无关的陈述声明它负责什么,并映射到实现它们的源码行,以及证明它们的测试。智能体通过 MCP 读写这个模型;你则以 wiki 风格的页面和图表来浏览它,而不是去读代码。

模型领路,代码跟随。你规划一个变更,计划会以”git 式 diff”的形式呈现在整个模型之上。这就是你的爆炸半径。底层是一个确定性的可观测性层,报告”已构建”与”已计划”的差异、哪些声明有锚点并有测试支撑,以及自上轮对账以来代码与模型之间的漂移。

没有退路

现代软件开发,很大程度上就是一遍又一遍地重新实现同样的模式,使用标准方案,再混搭各种算法。这正是 LLM 擅长的事——它们比我们做得更好,而且说实话,我们又何苦要手动做这些?它带来的只有过劳和犬儒主义。

手写代码将永远存在于那些定制化、新奇的复杂工作中。希望很多开发者能慢慢重新找回对编程的热爱——当他们能把它用在真正让他们感兴趣、有挑战的问题上时。至于其余的一切,我们应该尽力让编码智能体尽可能可靠。

或许,我们会一直做智能体的”飞行员”,又或许不久之后自主智能体就会包揽大部分工作。无论哪种情况,它们都需要一份规范——而”披着流程外衣的提示词仪式”是撑不住的。我们需要走出当下这一批”半吊子方案”,转向真正为此而造的工具:把意图当作一等公民,并让代码接受它的检验。

我们回不去一个没有编码智能体和氛围编程的世界,但我们能把老虎机作弊,然后离开赌场。

评论区