在 Vibe Coding 与 Spec Driven Development 之间有折中方案吗？

Source: Dev.to

请提供您希望翻译的完整文本内容（除代码块、URL 以及上述来源链接外），我将为您翻译成简体中文并保持原有的 Markdown 格式。

Source: …

规范驱动开发 vs. 气氛编码

规范驱动开发（Spec‑Driven Development）在使用 AI 编码代理时越来越受欢迎——尤其是针对技术和用户需求细致的复杂应用。

而 气氛编码（vibe coding）则追求速度：一次提示，立即反馈，迭代直到可用。

但如果你在构建某个东西时真的不知道它会变得多复杂怎么办？

在气氛编码和规范驱动开发之间有没有折中的办法？

• 不要太被动。
• 不要太正式。
• 不要太沉重。

我最近正好遇到了这个问题。

你可以在我的 YouTube 频道（CodeLess Developer）观看完整视频

场景：构建一个 AI 生成的游戏街机

我想让 AI 构建一个基于浏览器的经典游戏街机：

• 俄罗斯方块
• 吃豆人
• 太空入侵者
• 第四款经典游戏

之前，我使用 GitHub Copilot 在 Visual Studio 2026 中完成了这个挑战，模型是 Claude Sonnet 4.5。当时 Sonnet 4.5 是该工作流中最好的 AI 编码模型。

这一次我尝试了不同的做法：

• 👉 在 VS Code 中使用 GPT‑5.3 Codex
• 👉 避免纯气氛编码
• 👉 避免沉重的规范驱动开发

我没有交互式提示，而是从一个 instructions.md 文件开始。指令很简单：

1. 创建 4 个游戏。
2. 每个游戏放在自己的 feature 文件夹中。
3. 使用 .NET 10。
4. 使用 C# Blazor。
5. 应用最佳实践（关注点分离、模块化结构）。

这本应该很直接，却并非如此。

当“简单”并不简单

甚至第一步——创建 .NET 解决方案和项目——就花了 13–15 分钟。GPT‑5.3 Codex 在正确搭建解决方案时表现吃力。

这让我感到惊讶；我本以为自动化创建 .NET 解决方案是足够常见的任务，现代 AI 编码代理应该能轻松完成。

最终生成了俄罗斯方块，但当我在 Visual Studio 中运行解决方案时：

• ❌ 游戏无法玩。
• ❌ 实现失败。

第一次尝试彻底失败。

气氛编码本可以赢的地方

讽刺的是，如果我直接气氛编码——“用 JavaScript 和 HTML 创建俄罗斯方块”——我几乎可以立刻得到一个可玩的版本。

因为我明确选择了 Blazor 和 C#，把 AI 推向了一个较弱的执行路径。这正是事情变得有趣的地方。

我没有通过一次次被动提示来强迫修复，而是尝试了不同的做法。

后退一步：先让 AI 思考

我问 GPT‑5.3：

构建基于浏览器的街机游戏，哪种技术栈最合适？

这改变了一切。与其把它硬塞进我最初的假设（.NET Blazor），我让模型去推理：

• 渲染性能
• 游戏循环
• Canvas 处理
• 浏览器原生能力
• 框架适配性

随后我进一步让它：

• 提出高层规格
• 定义架构
• 创建包含规划上下文的 docs 文件夹
• 在编写代码前先勾勒编排

这样我们既不再是气氛编码，也没有进行沉重的规范驱动开发。感觉像是两者之间的折中。

定义中间地带

以下是我迄今为止的观察。

❌ 这不是气氛编码

• 我们生成结构化的规划文档。
• 我们在实现前定义架构。
• 我们在执行前增加上下文。
• 我们降低随机性。

❌ 这也不是完整的规范驱动开发

• 我们并未对每一次更改进行正式的规格审查。
• 我们不强制变更提案流程。
• 我们不使用严格的结构化规范文档。

（未完，待续）

• 我们并未锁定在治理工作流中。
• 我们也不锁定在像 OpenSpec 或 SpecKit 这样的规范框架中。

那它是什么？

以上下文为先的开发

如果现在必须给它命名，我会称之为 以上下文为先的 AI 开发。

核心理念

1. 在编写代码之前，生成结构化思考。
2. 让 AI 提出架构方案。
3. 明确技术栈决策。
4. 设定执行边界。
5. 然后开始构建。

没有繁重的流程。没有正式的规格审查周期。没有被动的混乱。只提供足够的结构以防止昂贵的误导。

真正的紧张点

当需要进行更改时会发生什么？

一旦你引入：

• 更新
• 功能添加
• 重构
• 修正

你就会开始偏向变更提案、随后是版本化规格、再到审查周期。突然之间，你的“中间地带”变成了完整的规格驱动开发。

如果你不使用像 OpenSpec 或 SpecKit 这样的正式框架，你最终会自行发明一个轻量版的框架。这就是悖论所在。

要点

• 从上下文开始。 在 AI 编码前给它思考的空间。
• 保持过程轻量化。 除非项目确实需要，否则避免使用正式的规范框架。
• 做好转向准备。 如果范围扩大，可能需要采用更严格的规范实践。

在纯粹的氛围编码与重量级规范驱动流程之间找到最佳平衡点，可显著提升生产力，同时保持 AI 生成代码的可靠性。

![Diagram](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/boob0pahykfw5c2fgb8a.png)

为什么这很重要

大多数非技术用户：

• 不想要正式的规范工作流。
• 不理解架构建模。
• 更喜欢“氛围编码”，因为它感觉更即时。

但氛围编码在以下情况下会变得低效：

• 应用规模扩大。
• 状态管理变得复杂。
• 模块之间相互作用。
• 错误累积。

规范驱动开发可以解决这些问题——但代价是额外的开销。

所以真正的问题不是：

哪种方法更好？

真正的问题是：

在什么阶段结构变得必要？

工作假设

目前，我的工作模型如下：

第1阶段 — 探索

使用 vibe 编码来发现方向。

第2阶段 — 背景形成

生成架构、技术栈决策以及高层规范。

第3阶段 — 可控执行

在定义的边界内构建，无需繁重的治理。

第4阶段 — 正式化（可选）

仅在复杂度需要时引入结构化规范工作流。

那可能是最干净的折中方案。

持续的实验

在本实验的下一阶段，我将根据 GPT‑5.3 Codex 生成的规划文档重建街机。

真正的考验并不是它是否能构建《俄罗斯方块》。

真正的考验是：

• 这是否能减少迭代循环？
• 这是否能降低误导？
• 这是否优于纯粹的氛围编码？
• 这是否能避免正式的规范驱动开发的开销？

我仍在寻找这种方法论的清晰定义，但我确信一件事：

AI 辅助开发的未来并非二元对立。
它不是“氛围编码 vs. 规范驱动开发”。
存在一个中间地带——我们只需要对其进行定义。