从氛围编码到规范驱动开发：AI编程时代的确定性产出实践
1. 从“氛围编码”到“规范驱动开发”：AI编程时代如何实现确定性产出
如果你和我一样，在过去一年里深度使用过 Cursor、Claude Code 或 GitHub Copilot 这类 AI 编程工具，那你一定体验过那种“过山车”般的感觉。有时候，你只是简单描述了一个想法，AI 就能生成一段近乎完美的代码，让你惊叹不已；但更多的时候，你发现自己在和 AI 进行一场无休止的“拉锯战”——你反复调整提示词，它却不断误解你的意图，生成的代码要么偏离核心需求，要么引入了你从未要求过的复杂设计。这种依赖模糊描述和不断试错的模式，我称之为“氛围编码”（Vibe Coding），它充满了不确定性，对于严肃的软件开发项目来说，风险极高。
这正是“规范驱动开发”（Spec-Driven Development, SDD）要解决的问题。SDD 不是一个新工具，而是一套全新的工作流和思维模式。它的核心思想极其简单却异常强大：将规范（Specification）作为唯一的真相来源（Single Source of Truth）。在 AI 动一行代码之前，我们必须先花时间把“要做什么”、“做成什么样”、“如何验证”这些事用清晰、无歧义的语言定义下来。这听起来像是回到了传统的需求文档时代，但 SDD 的精妙之处在于，它是一套为 AI 协作而生的、高度结构化的“沟通协议”。它通过一系列标准化的文档模板和检查点，强制你和 AI 在同一个频道上对话，从而将 AI 从一个“充满想象力的猜谜者”，转变为一个“严格按图施工的工程师”。
我最初接触 SDD 是通过一个名为mariano-aguero/spec-driven-development-skill的“智能体技能”（Agent Skill）。这个技能包本质上是一个提示词工程（Prompt Engineering）的集大成者，它预置了一整套针对 Claude Code、Cursor 等工具的对话指令、文档模板和工作流。使用它之后，我最深刻的体会是：项目的可控性和可预测性得到了质的飞跃。无论是开发一个用户认证模块，还是设计一个复杂的微服务 API，SDD 都能确保从需求到代码的链路是清晰、可追溯的。接下来，我将结合自己大量的实践，为你彻底拆解这套方法论，分享如何将其融入你的日常开发，并避开那些我踩过的“坑”。
2. SDD 核心工作流与五大阶段深度解析
SDD 的工作流被精心设计为五个顺序执行的阶段，每个阶段都有明确的输入、输出和“质量门禁”（Quality Gate）。你可以把它想象成软件开发的“流水线”，每个环节的产出物都是下一个环节的输入和约束条件。这种结构化的方式，正是对抗 AI 代码生成“随机性”的利器。
2.1 阶段零：澄清与界定（Clarify）
这是最容易被跳过，却也是最重要的一个阶段。它的目标是在编写正式规范之前，暴露并对齐所有隐含的假设。很多时候，需求描述（如“做一个登录功能”）背后隐藏着大量未言明的细节：支持哪些登录方式（密码、短信、第三方）？错误信息如何展示？是否需要记住登录状态？这些细节如果留到编码阶段才由 AI“自由发挥”，结果必然是灾难性的。
在这个阶段，你需要使用专门的“假设暴露提示词”（Assumptions Surface Prompt）。例如，你可以对 AI 说：“基于‘开发用户登录功能’这个需求，请列出你作为 AI 智能体所做出的所有隐含假设，包括但不限于用户角色、安全要求、UI 交互流程、错误处理策略和性能考量。” AI 会反馈一个清单。这时，你或产品负责人需要逐一审视这些假设，确认哪些是正确的，哪些需要修正，哪些属于范围之外。这个过程可能只需要几分钟，但它能避免后续数小时的返工。一个关键实践是，将达成一致的假设记录下来，作为后续编写规范时的“宪法”（Constitution），任何设计都不能违背这些基本原则。
2.2 阶段一：规范制定（Specify）
在假设对齐之后，我们进入正式的规范制定阶段。这里的产出物是一个名为spec.md的文件。这份文件不是一篇散文，而是一个结构化的清单。根据 SDD 的模板，它必须包含以下几个部分：
- 概述（Overview）：用一两句话描述功能的商业目标和用户价值。
- 范围与边界（Boundaries）：明确说明本功能包含什么，不包含什么（
[WONT]）。例如，“本认证功能包含邮箱密码登录和 JWT 令牌颁发，不包含第三方 OAuth 登录、密码重置和用户注册流程”。这一条能有效防止范围蔓延。 - 用户故事（User Stories）：从用户视角描述功能，格式为“作为[角色]，我希望[达成目标]，以便[获得价值]”。
- 验收标准（Acceptance Criteria, AC）：这是规范的核心，必须是独立可测试的。每条 AC 都应遵循“给定[条件]，当[操作]，那么[结果]”的格式。例如，“给定一个未登录用户访问需要认证的页面，当用户提交正确的邮箱和密码，那么系统应颁发一个有效期为7天的 JWT 令牌，并跳转到仪表盘页面。” 模糊的描述如“登录要快”在这里是不合格的。
注意：编写 AC 时，可以运用 MoSCoW 优先级法（Must have, Should have, Could have, Won‘t have）对条目进行标记。这能帮助团队在时间紧张时聚焦于核心功能。
2.3 阶段二：方案设计（Plan）
有了清晰的“做什么”（Spec），接下来就要设计“怎么做”（Plan）。本阶段会生成多个文档，共同构成技术方案：
plan.md（架构设计）：描述系统组件、数据流、技术选型和关键决策。例如，认证服务是独立部署还是集成在网关里？会话状态如何管理？>