如何阻止 Vibe Coding？

# 我们如何停止“氛围编码”？ 来源：https://alexklos.ca/blog/how-do-we-stop-vibe-coding 2025 年 12 月底，Claude Code 迅速爆红，大量软件开发者纷纷将编码代理纳入其主要开发工作流。 安德烈·卡帕西（Andrej Karpathy）创造了“氛围编码”（vibe coding）一词。他在 2026 年 3 月的 *No Priors* 播客中表示： > 我基本上从去年 12 月起就没写过一行代码了，这真是一个巨大的变化。我觉得普通人根本没意识到这件事发生了，也不知道它有多戏剧性。 我信他。很多人说这只是营销或炒作，但作为一个去年以来同样没写过一行代码的人，我觉得他说的是实话。至于这是好是坏，取决于你的视角，但毫无疑问，我们已经进入了软件工程的新纪元。 尽管代理迅速被采用，但从业者以及关注其产出的人们中，一种普遍的焦虑正在滋长：这波“劣质产出”的浪潮何时才能结束？我们是不是为了便利而在自我毁灭？我们该如何阻止这一切？ ## 意图高于代码 UML 联合创建者 Grady Booch 实际上[认为](https://www.youtube.com/watch?v=OfMAtaocvJw)我们正处于软件工程的第三个黄金时代： - 第一个时代，从 1940 年代末到 1970 年代，是算法的时代。高级语言和编译器抽象掉了机器。 - 第二个时代，从 1970 年代到 2000 年代，是面向对象抽象的时代。 - 第三个时代，大约从 2000 年开始，是系统的时代：库、平台和 API 抽象掉了整个子系统。 Booch 谨慎地指出，这第三个时代并非由 AI 开启，只是被 AI 加速了。但他也将 AI 编码代理与 Grace Hopper 时代编译器的出现相提并论，而这正是关键所在。编译器抽象掉了机器。代理则抽象掉了代码本身。 现在，我们有史以来第一次能够直接从意图生成代码。过去，正是缺乏这种能力扼杀了模型驱动开发（你怎么看 UML 都行，但也许我们该考虑以某种形式重拾 MDD 了。） 实际上，当我们沿着抽象层次向上，逼近意图时，我们失去了许多曾让代码工作变得可靠的工具和方法。如果能够适应，我相信这种转变不仅可能加速开发，还可能大幅提升软件解决方案的质量。 然而，目前我们仍困在“氛围编码赌场”里。张三李四都在疯狂地生成代码，拉动杠杆，祈祷最好结果。 ## 问题所在 “氛围编码”几乎被普遍描述为：（a）损害个人对解决方案和架构的理解，（b）因提示词过于笼统、自然语言界面有损、以及非确定性的代码生成而不可靠。 当你进行氛围编码时： - 你不再理解你正在处理的代码库。你构建的心理模型是模糊的，主要依赖你自己作为程序员的过往经验。 - 你会失去对死代码、冗余代码以及桩代码的感知。 - 你会搞不清哪些东西已经实现，以及为什么实现。 - 你无法向他人解释架构，也无法推理潜在问题。 - 在你批准一个计划之前，你几乎看不到会有什么变化。是的，代理通常会写一小段说明，解释它将做什么，但这很有限。 - 它不会展示影响范围。 - 它不会告诉你它只是部分实现了某个功能，或者遗漏了你认为显而易见的关键内容。 - 即使它说了，你可能也抓不住，因为计划没有可学习的结构。 这就是黑箱效应，它会慢慢吞噬你的工作流，让你作为软件工程师越来越不严谨，直到你最终盲目地推送提交，导致生产环境崩溃。 即使你不这样滥用编码代理，而是更倾向于手动编程，也很难否认这很可能就是软件工程未来的大趋势。我们可以看到有多少工程师正在将编码代理作为其核心工作流的一部分，以及有多少 100 倍效率的开发者已经在尝试用它们创建自主循环，仿佛控制和决策只是实现真正目标——代币最大化——的干扰。 无论如何，这归根结底是信任问题：你既无法信任自己对代码库的理解，也无法信任代理按照你的意愿完成了工作。 ## 现有解决方案尚不成熟 我们都明白这很糟糕——但潜在的解决方案呢？关于这个话题有很多讨论，然而我认为迄今为止提出的方案都远谈不上有说服力。 首先，我们需要就我们试图达成的目标达成一致：我们希望尽可能减少对编码代理输出的依赖，即减少需要信任的程度。 为此，我们希望： 1. **代理能可靠地执行我们的要求。**理想情况下是确定性的——这可能无法实现，但这是一个好的目标。 2. **能够审计和追踪代理对代码库所做的更改。**理想情况下，不必非得阅读代码。 3. **将流程阻力降至最低。**氛围编码之所以胜出，是因为它是阻力最小的路径，我们需要接受这一点，并让原则性强的路径变得容易。 而目前的解决方案没有充分满足上述三点。大多数方案都依赖于（或干脆就是）某种形式的提示工程，这与“意图精炼”（目标 #1）**不是一回事**。 ### Markdown 规范 我交谈过的许多工程师都会这样开始： > 嗯，我使用 markdown 规范，并协调一个代理流程：先审查规范，将其实现为代码，然后管理和更新它们。代理会检查一致性，对照现有代码库，标记任何冲突，然后交给实现步骤。完成后，它会循环回来更新规范，这样文档和代码永远不会脱节。因此，markdown 是真理之源，其他一切都围绕着保持同步运转…… 当我听得目光呆滞时，我忍不住思考： - 这些规范有系统或结构化格式吗？ - 你怎么知道规范的哪些部分已经实现？ - 你怎么知道代码除了规范指定的内容之外，没有做其他事情？ - 什么代理流程？你需要提醒它你的规范存在吗？ - 我为什么不直接提示代理？ 由此衍生出许多问题，而答案通常极为模糊——至此，这看起来只是一种个人工作流优化，并没有可验证的影响。无论他们在做什么，都只是让他们自己感觉“严谨”而已。 Addy Osmani 在 2026 年 2 月发表的文章“[如何为 AI 代理编写良好的规范](https://www.oreilly.com/radar/how-to-write-a-good-spec-for-ai-agents/)”很好地体现了这一点。 它并不含糊——恰恰相反，它内容密集。五个原则，一个六节格式，一项对 2500 个配置文件的研究，所有你听过的工具都提及了。它看起来像是一个系统。然后你意识到整篇文章只是在描述代理上下文中的提示工程。 我们不能认真地称此为规范驱动开发，因为规范不是“真理之源”，而是一个指导性提示。没有强制机制，甚至没有比要求代理“代码是否遵循规范？”更复杂的协调机制——而 AI 可以随意解释，因为没有共享的语法！ 从根本上说，markdown 规范并没有解决我们对代理缺乏信任的问题，而且管理起来非常烦人。它们必须变得清晰结构化，并置于更大的系统中才能有用。 ### 技能 这本质上是你根据任务有条件地注入的上下文/指令。虽然它们可能有用，但它们仍然完全依赖代理去遵循，这与 markdown 规范失效的方式完全相同——即使它们实现起来远没有那么麻烦。 有趣的是，它们往往也是令人讨厌的废话，比如来自 gstack 的这个巨大的“[QA 技能](https://github.com/garrytan/gstack/blob/main/qa/SKILL.md)”。 我很确信，对大多数代理来说，提示“查找并修复错误，谢谢”也能完成同样的工作（甚至可能更好？）。 技能充其量只是补充，本质上是提示工程。 ### Spec Kit (https://github.com/github/spec-kit) 与 OpenSpec (https://github.com/Fission-AI/openspec) 等 Spec Kit 是一个 markdown 模板目录，通过 CLI 放入你的项目。你需要按顺序运行六个命令：specify → clarify → plan → tasks → analyze → implement。 在幕后，代理被引导根据模板定义所有内容，然后将输出作为后续提示的上下文保留。 这**几乎**是个开始，因为它试图对氛围编码应用某种流程，并为编码代理松散地定义了一个结构。关键词是“松散”，问题在于开发人员是驱动整个流程的人——六个命令代替了一个——而且仍然无法真正**看到**任何东西。 OpenSpec 是同一个想法的轻量级版本：explore → propose → apply → archive 代替了六个命令的流程，以及纯 markdown 的 WHEN/THEN 场景代替了 Kiro 的 EARS。它下了同样的赌注，并以同样的方式失败：你驱动流程，代理给自己评分，但没有机械性的检查来对照代码验证规范。 这类项目有几十个，基本上都一样。 ### Kiro (https://kiro.dev/) 试图通过 hook 引导代理使用带有 EARS 需求的 markdown 规范，从而将功能开发系统化。 如果你不熟悉 EARS（需求语法简易方法），这里有几个例子展示自然语言需求与 EARS 需求的对比： | 自然语言 | EARS | | --- | --- | | 为了安全，用户若长时间不活跃应被登出。 | 当用户会话不活跃达到 15 分钟时，系统**应该**终止会话并将用户重定向至登录页面。 | | 优雅地处理失败的支付。 | 如果支付尝试失败，那么系统**应该**保留购物车内容并显示失败原因。 | 这里使用 EARS 很有意思，因为它通过比纯散文更结构化的方式制定需求，对代理和开发者都有帮助。当处理意图时，使用非结构化的散文会让你很快眼花缭乱；你无法像扫描代码那样扫描它。EARS 在这方面有帮助。 实现 hook 也是一个好举措，迫使代理对触发器作出反应，并明确遵循其流程步骤。这不是确定性的，但它是结构化的。 遗憾的是，Kiro 在两个地方失败了： - 功能规范会积累，但不会组合；因此没有可审计的图。 - 需求与已发布的代码之间从未进行过对账；它建好了法庭，却从不开庭审判。 ### 测试驱动开发 测试的名称是意图的描述；一个必须由代码满足的业务或流程需求，用自然语言编写。测试本身是真实代码的一个锚点，希望能证明代码与该意图一致。从这个意义上说，更高级别的测试甚至可以充当功能依赖图。 终于有了一些确定性强制力的迹象。这确实能有所帮助！ 然而，开发人员通常让代理编写测试，因为这更简单，但这再次引入了我们试图修复的相同问题。 另一种方法是手动编写测试，但那样你就必须知道代码的实现——而且你必须编写代码，我认为如果我们要讨论抽象掉代码，这本身就是一个问题。我并不是说你编写自己的测试是错误的，但这篇文章具体是关于如何修复氛围编码的。作为编码代理的爱好者，我们更愿意尽可能停留在意图层面，而不是实现层面。 > *附注：*CodeSpeak——下面会详细介绍——最近正好遇到了这个问题：最初的设想是开发人员手动编写规范文件，但大多数 Alpha 测试者却让他们的代理来做。他们后来转向从自然语言提示中自动提取结构化的意图。 所以，我们又回到了原点：TDD 解决了部分问题，但前提是我们能约束代理编写测试的方式，或者能确定性地生成测试。 ## 拼图开始就位 之前的方案之所以不充分，是因为它们没有解决核心问题：信任。 是的，它们试图让代理更好地对齐我们的意图。它们试图给代理一套操作流程。它们甚至有一些基本的概念来保存更改历史，或者收紧约束（例如使用 hook）。 但这仍然是一个提示接口——加上作为纪律的附加仪式——以及阅读散文或代码。它们没有展示你正在处理的事情的全貌。它们没有强制要求代理实现你所定义的内容，甚至不强制实现代理声称已实现的内容。它们没有提供一个开发者和代理都认同的共享表面。 而解决这个问题真的很难。值得注意的是，[Tessl](https://tessl.io/)——曾以规范驱动开发的承诺筹集了 1.25 亿美元——已经悄悄地从向开发者销售 SDD 转向了“技能即新代码”。哦，是吗？ 幸运的是，这个领域还很年轻，正在积极探索，有几种方法开始收敛于真正有效的东西。 以下两个项目（免责声明：其中一个是我的）我认为正朝着正确的方向前进。 **顺便说一句，这是我所知道的唯二专注于信任问题的项目。如果有其他的，我很乐意了解。** * ### CodeSpeak (https://codespeak.dev/) 由 Kotlin 的创建者 Andrey Breslav 创立。 CodeSpeak 押注信任可以通过编译来消除：你编写简洁的 markdown 规范，组织成相互导入的模块，然后 `codespeak build` 将它们编译成可工作的代码——Python、Go 或 TypeScript，你其实不需要审查。这个工具链认真对待“编译器”的比喻：构建前验证规范的一致性，构建后运行测试，`codespeak takeover` 甚至可以反向从现有代码库生成规范。 自从我前面提到的转变之后，他们还在其之上构建了一个需求层：与代理的对话被精炼成结构化的需求，映射到实现它们的代码文件，当变更出现偏差时标记出漂移。他们仍在致力于规范语言本身的形式化，目标是实现确定性（或接近确定性）的构建。 ### Scryer (https://github.com/aklos/scryer) 在过去的六个月里，我一直在开发这个工具，根据我自己的开发工作流进行迭代。 Scryer 押注相反的方向：对代理的信任是不可削减的，因此应该尽可能廉价地消耗它。这是面向编码代理的模型驱动开发。你和你的代理共享一个系统模型：一个 C4 风格的分层结构，每个节点用简短、与语言无关的声明说明其职责，并映射到实现这些职责的源代码行和验证它们的测试。代理通过 MCP 读写模型；你以维基风格的页面和图表来浏览模型，而不是阅读代码。 模型先行；代码跟随。你计划一个变更，计划会显示为整个模型的 git 风格 diff。这就是你的影响范围。底层是一个确定性的可观测性层，报告已构建的内容与计划内容的对比，以及哪些声明是……（原文截断）