大语言模型（LLM）在生成新内容方面表现出色，但在代码质量、架构选择、API 模式和安全标准方面往往不尽如人意。这并非因为大语言模型的能力不如专业开发者，而是因为开发者很难在提示中准确定义他们想要什么、大语言模型应该如何实现目标以及如何验证结果。事实证明，尽管开发者在编写代码方面效率很高，但他们往往难以用普通文本准确表达自己的需求。

当我们审视“氛围编程（Vibe Coding）”的真正含义时，我们意识到它让我们可以忘掉代码的存在。主要想法很简单：我们不是用代码定义目标，而是用普通自然语言来表达它们。多亏了大语言模型，即使没有深厚技术知识的人也能将自己的想法变为现实。然而，这种方法通常只适用于原型。生产就绪的代码不能仅仅看起来很酷——它还需要没有错误、架构合理、安全且功能完备。为了实现这一点，开发者必须定义自定义指令、添加各种规则、设置 MCP 服务器，并编写精确的提示，为大语言模型提供清晰的指导。不幸的是，开发者常常低估了设置和提示工程所需的精力。

这就是规格驱动开发（Spec Driven Development, SDD）的用武之地。与其先编码再编写文档，SDD 从定义规格开始。这个规格充当了代码应该如何表现的契约，成为你的工具和 AI 智能体用来生成、测试和验证代码的依据。结果就是减少了猜测、减少了意外，提高了代码质量。

SDD 将开发过程分为四个不同的阶段，每个阶段都有特定的目标和成果。在这些阶段中，我们依赖所选择的 AI 编程工具提供帮助。我们的责任是以自然语言表达我们的目标。最终生成的代码仅仅是这些清晰规格的产物。

1. 定义规格（Specify）

在这个阶段，你提供一个关于你正在构建的内容以及原因的高级描述，然后编码智能体生成详细规格。这与技术栈或应用程序设计无关——而是关于用户旅程、体验和成功标准。你会定义谁将使用你的产品、它为他们解决了什么问题、他们将如何与之互动，以及哪些结果最为重要。可以将其视为绘制期望用户体验的蓝图，同时让编码智能体来完善细节。这个规格成为一个随着你对用户及其需求的深入了解而不断演变的活文档。

2. 规划（Plan）

在这个阶段，你开始涉及技术层面。你会向编码智能体提供你期望的技术栈、架构和约束条件，它将生成一个全面的技术计划。如果你的公司有标准化技术，请在这里指定。详细说明任何与遗留系统的集成、合规性要求或你需要满足的性能目标。你还可以请求多个计划变体，以便比较不同的方法。通过将内部文档提供给编码智能体，它可以将你的架构模式和标准直接纳入计划。可以将其视为在游戏开始之前设定规则——编码智能体需要了解参数，然后才能开始高效工作。

3. 任务（Tasks）

编码智能体将规格和计划转化为可操作的工作，通过生成小的、可审查的块，每个块都针对特定组件。每个任务都应该可以在隔离状态下实现并测试——这种方法允许编码智能体验证其工作并保持专注，类似于测试驱动开发过程。与其给出宽泛的指令，如“构建身份验证”，你得到的是精确的任务，例如“创建一个验证电子邮件格式的用户注册端点”。

4. 实施（Implement）

编码智能体根据需要顺序或并行地执行任务。这里的关键区别在于，你——开发者——评估的是针对特定问题的专注、具体的变化，而不是审查大量的代码。编码智能体有明确的方向：规格定义了要构建什么，计划概述了如何构建，而任务则指定了要做什么。

至关重要的是，你的角色不仅仅局限于指导——你必须验证。在每个阶段，都要反思并完善。规格是否真正捕捉到了你期望的产品？计划是否解决了现实世界的约束条件？AI 是否忽略了任何边缘情况或遗漏？该过程包括有意识的检查点，在这些检查点上，你评估生成的内容，识别差距，并在继续之前纠正方向。尽管 AI 生成了工件，但你确保了它们的准确性和相关性。