Spec-Driven Development：当 AI Agent 让我们「重回瀑布」——Vibe Coding 之后的工程化反思

当 Andrej Karpathy 在 2025 年初提出「Vibe Coding」概念时，开发者们兴奋于一种全新的编程范式：用自然语言描述需求，让 AI 生成代码，完全拥抱不确定性。然而一年后，一个有趣的反转正在发生——开发者们发现自己在做一件「复古」的事情：写详细的需求规格文档。

📌 核心问题：为什么 AI Agent 让我们重回「瀑布」？

当你给一个 Coding Agent 模糊的指令时，你得到的是模糊的输出——或者更糟，是看似正确但实际错误的输出。Agent 会用它的统计猜测填补规格中的每一个空白，而这些猜测会不断累积。

于是你很快学会了精确。你描述数据模型、用户流程、错误状态、依赖关系。你写的本质上是一份详细的设计文档——这和 2004 年瀑布式项目管理者写的文档如出一辙。

🔥 关键数据：开发者行为的转变

• 一位工程负责人描述为「敏捷规划，瀑布执行」——团队在前期设计上花费 3 倍时间，以便 Agent 可以在执行阶段无需频繁纠正
• Claude Code 的 CLAUDE.md 机制：开发者可以教 Agent 项目约定、架构决策和编码标准，每次会话自动加载
• Claude-Mem 插件（捕获编码会话中的上下文并注入未来会话）在 2026 年 2 月初登顶 GitHub 热榜
• Claude Code v2.1.32 新增自动记忆录制与召回，v2.1.33 新增跨 Agent 持久化记忆作用域

🧠 技术架构：Vibe Coding → Spec-Driven → Context Engineering

这个演进路径清晰地描绘了 AI Coding 的成熟过程：

第一阶段：Vibe Coding（对话式、探索式）

开发者用自然语言和 AI 对话，快速生成原型。优势是速度快、门槛低；劣势是产出质量不稳定，难以维护。

第二阶段：Spec-Driven Development（规格驱动、自主执行）

开发者先写详细的规格文档，然后让 Agent 按规格执行。优势是产出可预测、质量可控；劣势是回到了「先规划再执行」的模式。

第三阶段：Context Engineering（上下文工程）

MIT Technology Review 将这种转变称为从 Vibe Coding 到 Context Engineering——系统性地为 AI 提供正确信息以供决策。这不是简单的「写文档」，而是设计一套完整的上下文体系：项目记忆（CLAUDE.md）、代码规范、架构约束、历史决策等。

🚀 为什么这很重要：Agent 架构的设计启示

Spec-Driven Development 的兴起揭示了当前 AI Agent 架构的一个根本性局限：

• Agent 擅长执行明确的指令，但不擅长处理模糊性
• 人类开发者的优势在于「在模糊中做决策」——问澄清问题、做合理假设、标记不确定性
• Agent 的弥补方式是「把所有模糊性前置消除」——这正是规格文档的核心价值

这对 Agent 架构设计有重要启示：

• 记忆系统（如 CLAUDE.md）是减少规格冗余的关键——Agent 记住的上下文越多，每次需要的前置规格就越少
• Agent Teams（多 Agent 协作）需要明确的角色分工和接口定义——本质上也是「规格化」
• 未来的 Agent 架构应该原生支持「在执行中澄清」的能力——而不是等人类把所有歧义都消除

💡 引发思考：Vibe Coding 的终局是什么？

Spec-Driven Development 不是对 Vibe Coding 的否定，而是它的自然演进。Vibe Coding 解决了「如何让 AI 写代码」的问题；Spec-Driven Development 解决了「如何让 AI 写出可靠的代码」的问题。

一个有趣的观点是：开发者发现自己在「享受写规格」的过程。用 LLM 对话迭代规格的过程本身就是一个高效的反馈循环——LLM 会提出你没想到的边界情况、建议数据模型、暴露依赖关系。这比传统瀑布式的需求分析高效得多。

随着 Agent 记忆系统的持续改善（CLAUDE.md、Claude-Mem 等），每次需要的前置规格会逐渐减少。但在可预见的未来，「人定规格、Agent 执行」仍将是 AI Coding 的主流范式。

真正的终局可能是：当 Agent 足够智能到能自己做模糊决策时，Spec-Driven Development 就会重新演化为某种更高级的 Vibe Coding。但在此之前，「写好规格」是每个 AI 时代开发者的核心技能。

逍遥云初 | 2026.04.26