需求驱动开发（SDD）

权力的反转

几十年来，代码一直是王者。需求规格为代码服务——它们是我们搭建后又丢弃的脚手架，一旦开始编码这项”真正的工作”。我们编写产品需求文档(PRD)来指导开发，创建设计文档来告知实现，绘制图表来可视化架构。但这些始终从属于代码本身。代码即是真理。其他一切最多只能算是良好愿望。代码是事实的唯一来源，随着它不断演进，需求规格很少能同步更新。由于资产（代码）与实现合二为一，如果不从代码出发构建，就很难并行实现其他方案。

需求驱动开发(SDD)翻转了这一权力结构。需求规格不再服务代码——代码开始服务于需求规格。产品需求文档(PRD)不再是实现指南，而是生成实现的本源。技术方案不再是指导编码的文档，而是产出代码的精确定义。这不是软件开发方式的渐进改良，而是对发展驱动力的根本性反思。

自软件开发诞生以来，规范与实现之间的鸿沟就一直困扰着行业。我们尝试通过更完善的文档、更细致的需求、更严格的流程来弥合这道鸿沟。这些方法之所以失败，是因为它们默认鸿沟不可避免，仅试图缩小而非消除它。而规范驱动开发(SDD)通过让规范及其衍生的具体实施方案成为可执行文件，彻底消除了这道鸿沟。当规范和实施方案能自动生成代码时，鸿沟便不复存在——只剩下转化。

如今这种转化已成为可能，因为人工智能已能理解复杂规范并制定详细实施方案。但缺乏结构化处理的原始 AI 生成只会带来混乱。SDD 通过精确、完整且无歧义的规范及后续实施方案提供结构化框架，从而生成可运行系统。规范成为核心产出物，代码则成为其在特定语言和框架中的具象化表达（源自实施方案的实现成果）。

在这个新世界里，维护软件意味着演进规格说明书。开发团队的意图通过自然语言（” 意图驱动开发 “）、设计资产、核心原则和其他指导方针来表述。开发的通用语言提升到了更高层次，而代码则是最后一步的实现手段。

调试意味着修正那些生成错误代码的规格说明及其实现方案。重构则是为了提升清晰度而进行的结构调整。整个开发工作流围绕规格说明书这一核心事实来源重新组织，将实现方案和代码视为持续再生的产出物。由于人类天生具有创造力，为应用添加新功能或创建新的并行实现，就意味着需要重新审视规格说明并制定新的实现方案。因此这个过程表现为 0 -> 1, (1’, ..), 2, 3, N 的演进序列。

开发团队专注于发挥创造力、开展实验性探索以及进行批判性思考。

SDD 工作流的实践应用

工作流程始于一个模糊且不完整的想法。通过与 AI 的迭代对话，这个想法逐渐完善为一份详尽的产品需求文档（PRD）。AI 会提出澄清性问题、识别边界情况，并帮助定义精确的验收标准。传统开发中需要数天会议和文档整理的工作，在这里只需数小时专注的规范编写即可完成。这彻底改变了传统软件开发生命周期（SDLC）——需求与设计不再是离散阶段，而是持续进行的活动。这种方式尤其支持团队协作流程 ，团队成员可以评审、表达并版本化规范文档，通过在分支中创建并合并来实现协作。

当产品经理更新验收标准时，系统会自动标记受影响的技术决策；当架构师发现更优模式时，产品需求文档将实时更新以呈现新的可能性。

在整个规范制定过程中，研究代理会收集关键上下文信息。它们会考察库兼容性、性能基准以及安全影响。组织约束会被自动发现并应用——贵公司的数据库标准、认证要求和部署策略都能无缝集成到每个规范中。

基于产品需求文档(PRD)，人工智能会生成将需求映射为技术决策的实现方案。每个技术选择都有书面决策依据。每个架构决策都能追溯到特定需求。在此过程中，一致性验证持续提升质量。AI 会分析规范中的模糊表述、矛盾点和遗漏项——这种分析不是一次性关卡，而是持续优化的过程。

当规范及其实现方案足够稳定时即可开始代码生成，但此时它们不必是”完整的”。早期生成的代码可能是探索性的——用于验证规范在实践中是否合理。领域概念转化为数据模型，用户故事转化为 API 端点，验收场景转化为测试用例。这种方式通过规范将开发和测试融为一体——测试场景并非在编码后才编写，而是作为规范的一部分，同时生成实现代码和测试代码。

反馈循环并不局限于初期开发阶段。生产环境指标和事件不仅会触发热修复——它们还会更新规范以指导下一轮代码生成。性能瓶颈转化为新的非功能性需求，安全漏洞成为影响所有后续版本的约束条件。这种规范、实现与运行现状之间的迭代调整，正是真正理解的诞生地，也是传统软件开发生命周期转型为持续演进的关键所在。

为何当下需要规范驱动开发

三大趋势使得规范驱动开发不仅是可能，更是必然的选择：

首先，AI 能力已达到临界点，能够可靠地根据自然语言规范生成可运行代码。这不是要取代开发者——而是通过自动化从规范到实现的机械转换来提升开发效率。它可以增强探索性与创造性，轻松支持”推倒重来”，并辅助进行增删改查与批判性思考。

其次，软件复杂度仍在呈指数级增长。现代系统集成了数十种服务、框架和依赖项。通过人工流程保持所有这些组件与原始意图保持一致变得越来越困难。规范驱动开发（SDD）通过基于规范的生成实现系统性对齐。未来框架可能会演变为优先支持 AI 而非人类，或是围绕可复用组件进行架构设计。

第三，变化节奏加速。当今时代的需求变更比以往任何时候都更为迅猛。转型调整不再是特例，而是常态。现代产品开发要求根据用户反馈、市场环境和竞争压力进行快速迭代。传统开发模式将这类变化视为干扰，每个调整都需人工将变更同步到文档、设计和代码中，结果要么是拖慢节奏的谨慎更新，要么是堆积技术债务的草率改动。

规范驱动开发支持假设性/模拟实验：”如果我们需重构或修改应用程序以推动’销售更多 T 恤’的商业需求，该如何实施方案并进行实验验证？”

规范驱动开发将需求变更从障碍转化为常规工作流。当规范驱动实现时，转型调整就变成系统性重建而非人工重写。修改产品需求文档中的核心要求时，相关实施方案会自动更新；调整用户故事时，对应 API 端点将重新生成。这不仅关乎初始开发阶段，更是为了在必然的变更中持续保持工程推进速度。

核心原则

规范即通用语言 ：将规范作为主要产出物。代码则成为其在特定语言和框架中的表达形式。维护软件意味着持续演进规范。

可执行规范 ：规范必须足够精确、完整且明确，能够生成可运行系统，从而消除意图与实现之间的鸿沟。

持续优化 :一致性验证是持续进行的过程，而非一次性关卡。人工智能会在整个开发周期中持续分析需求规格中的模糊点、矛盾点和疏漏。

研究驱动的情境 :研究代理会在需求规格制定过程中持续收集关键背景信息，包括技术方案调研、性能影响评估和组织约束考量。

双向反馈机制 :生产环境的实际情况将反哺需求规格的演进。运行指标、故障事件和运维经验都将成为需求优化的输入依据。

探索性分支 ：基于同一份规范生成多种实现方案，用以探索不同的优化目标——性能、可维护性、用户体验、成本。

实现方式

如今实践规范驱动开发需要整合现有工具并在整个过程中保持规范。该方法可通过以下方式实践：

• 用于迭代式需求开发的 AI 助手
• 用于收集技术背景的研究代理工具
• 将规范转换为实现代码的代码生成工具
• 为规范先行工作流程优化的版本控制系统
• 通过 AI 分析规范文档实现一致性检查 为便于中英对照查阅，建议将技术文档存为对照双语版本

关键在于将规范视为真理之源，而代码则是根据规范生成的产物，服务于规范本身，而非反之。

通过命令简化规范驱动开发流程

规范驱动开发方法论通过三个强大的自动化命令得到显著增强，实现了从规范→规划→任务派发的全自动工作流：

/speckit.specify 命令

该命令将简单的功能描述（用户提示）转化为完整的结构化规范，并自动管理代码仓库：

1. 自动功能编号 ：扫描现有规范以确定下一个功能编号（例如 001、002、003）
2. 分支创建 ：根据描述生成语义化分支名并自动创建
3. 模板化生成 ：复制功能规范模板并根据需求进行定制化配置
4. 目录结构 : 为所有相关文档创建规范的 specs/[分支名称]/ 目录结构

/speckit.plan 命令

当特性规范存在时，该命令会生成全面的实施计划：

1. 规范分析 : 读取并理解特性需求、用户故事和验收标准
2. 宪章合规性 ：确保与项目章程和架构原则保持一致
3. 技术转化 ：将业务需求转化为技术架构与实施细节
4. 详细文档 ：生成数据模型、API 契约及测试场景等配套文档
5. 快速验证 ：编制包含关键验证场景的快速入门指南

/speckit.tasks 命令

当计划创建完成后，该命令会分析计划及相关设计文档，生成可执行任务清单：

1. 输入项 ：读取必选文件 plan.md，若存在则还会读取 data-model.md、contracts/ 目录及 research.md 文件
2. 任务派生 ：将合约、实体和场景转化为具体任务
3. 并行化处理 ：标记独立任务 [P] 并划分安全的并行组别
4. 输出 ：在功能目录中生成 tasks.md 文件，供任务代理直接执行

示例：构建聊天功能

这些命令如何改变传统开发流程：

传统方法：

1. Write a PRD in a document (2-3 hours)
2. Create design documents (2-3 hours)
3. Set up project structure manually (30 minutes)
4. Write technical specifications (3-4 hours)
5. Create test plans (2 hours)
Total: ~12 hours of documentation work

采用命令式 SDD 方法：

# Step 1: Create the feature specification (5 minutes)
/speckit.specify Real-time chat system with message history and user presence

# This automatically:
# - Creates branch "003-chat-system"
# - Generates specs/003-chat-system/spec.md
# - Populates it with structured requirements

# Step 2: Generate implementation plan (5 minutes)
/speckit.plan WebSocket for real-time messaging, PostgreSQL for history, Redis for presence

# Step 3: Generate executable tasks (5 minutes)
/speckit.tasks

# This automatically creates:
# - specs/003-chat-system/plan.md
# - specs/003-chat-system/research.md (WebSocket library comparisons)
# - specs/003-chat-system/data-model.md (Message and User schemas)
# - specs/003-chat-system/contracts/ (WebSocket events, REST endpoints)
# - specs/003-chat-system/quickstart.md (Key validation scenarios)
# - specs/003-chat-system/tasks.md (Task list derived from the plan)

15分钟内，你将：

• 包含用户故事与验收标准的完整功能规范
• 附带技术选型及决策依据的详细实施方案
• 可直接用于代码生成的 API 协议与数据模型
• 涵盖自动化与手工测试的完整测试场景
• 所有文档都在功能分支中进行了正确的版本控制

结构化自动化的力量

这些命令不仅节省时间，还能确保一致性和完整性：

1. 无遗漏细节 ：模板确保从非功能性需求到错误处理的每个方面都被考虑到
2. 可追溯的决策 : 每个技术选择都能追溯到具体需求
3. 活的文档 : 规范与代码保持同步，因为它们能生成代码
4. 快速迭代 : 变更需求并在分钟内重新生成方案，而非数日

这些命令通过将规范视为可执行产物而非静态文档，体现了规范驱动开发（SDD）的原则。它们将规范流程从”必要的麻烦”转变为推动开发的核心动力。

模板驱动质量：结构化约束如何让 LLMs 输出更优结果

这些指令的真正威力不仅在于自动化，更在于模板如何引导 LLM 行为生成更高质量的规范。这些模板如同精密的提示词，通过有效方式约束 LLM 的输出：

1. 防止过早涉及实现细节

功能规范模板明确要求：

- ✅ Focus on WHAT users need and WHY
- ❌ Avoid HOW to implement (no tech stack, APIs, code structure)

这种约束迫使 LLM 保持适当的抽象层次。当 LLM 可能自然地想到”使用 React 加 Redux 实现”时，模板会使其聚焦于”用户需要数据的实时更新”。这种分离确保了即使实现技术发生变化，规范仍能保持稳定。

2. 强制标记明确的不确定性

两个模板都强制要求使用 [需要明确] 标记：

When creating this spec from a user prompt:
1. **Mark all ambiguities**: Use [NEEDS CLARIFICATION: specific question]
2. **Don't guess**: If the prompt doesn't specify something, mark it

这能防止 LLM 常见的行为——做出看似合理但可能错误的假设。例如，LLM 不能直接猜测”登录系统”使用邮箱/密码认证，而必须标记为 [NEEDS CLARIFICATION: auth method not specified - email/password, SSO, OAuth?] 。

3. 结构化思维检查清单

模板包含全面的检查清单，这些清单可作为规范的”单元测试”：

### Requirement Completeness

- [ ] No [NEEDS CLARIFICATION] markers remain
- [ ] Requirements are testable and unambiguous
- [ ] Success criteria are measurable

这些检查清单迫使 LLM 系统地自我审查输出，捕捉那些可能被遗漏的漏洞。这相当于为 LLM 提供了一套质量保证框架。

4. 通过关卡实现架构合规

该实现计划模板通过阶段关卡强制实施架构原则：

### Phase -1: Pre-Implementation Gates

#### Simplicity Gate (Article VII)

- [ ] Using ≤3 projects?
- [ ] No future-proofing?

#### Anti-Abstraction Gate (Article VIII)

- [ ] Using framework directly?
- [ ] Single model representation?

这些关卡通过要求 LLM 明确论证任何复杂度，从而防止过度工程化。若未通过关卡，LLM 必须在”复杂度追踪”章节记录原因，为架构决策建立问责机制。

5. 层级化细节管理

模板强制执行适当的信息架构：

**IMPORTANT**: This implementation plan should remain high-level and readable.
Any code samples, detailed algorithms, or extensive technical specifications
must be placed in the appropriate `implementation-details/` file

这解决了规范文档沦为难以阅读的代码堆砌的常见问题。LLM 学会了保持适当的细节层次，将复杂性抽取到独立文件中，同时确保主文档保持可浏览性。

6. 测试优先思维

该实现模板强制采用测试优先开发模式：

### File Creation Order
1. Create `contracts/` with API specifications
2. Create test files in order: contract → integration → e2e → unit
3. Create source files to make tests pass

这种顺序约束确保 LLM 在实现前先考虑可测试性和契约，从而产生更健壮且可验证的规范。

7. 预防推测性功能

模版明确阻止主观臆断：

- [ ] No speculative or "might need" features
- [ ] All phases have clear prerequisites and deliverables

这种做法禁止 LLM 添加”锦上添花”的功能而增加实现复杂度。每个功能必须能追溯到具有明确验收标准的具体用户故事。

复利效应

这些约束条件共同作用，生成的规格说明具有以下特性：

• 完整性 ：检查清单确保无一遗漏
• 明确性 ：强制标注机制突显待澄清项
• 可测试性 ：测试优先思维融入流程
• 可维护性 ：恰当的抽象层级与信息架构
• 可实施性 ：明确的阶段与具体交付物

这些模板将 LLM 从创意写作者转变为严谨的规范工程师，引导其能力用于持续产出真正驱动开发的高质量可执行规范。

宪制根基：实施架构纪律

规范驱动开发(SDD)的核心在于其宪法——一套决定规范如何转变为代码的不可变准则。这部宪法（memory/constitution.md）作为系统的架构基因，确保每个生成的实现都保持一致性、简洁性和质量。

开发九章

章程界定了塑造开发流程各个维度的九条原则：

第一条：库优先原则

所有功能必须始于独立库——绝无例外。此原则强制实现初始模块化设计：

Every feature in Specify MUST begin its existence as a standalone library.
No feature shall be implemented directly within application code without
first being abstracted into a reusable library component.

这一原则确保了规范能生成模块化、可复用的代码，而非单一庞大的应用。当 LLM 生成实施方案时，必须将功能构建为界限清晰、依赖极少的库形式。

第二条：命令行界面规范

每个库必须通过命令行界面暴露其功能：

All CLI interfaces MUST:
- Accept text as input (via stdin, arguments, or files)
- Produce text as output (via stdout)
- Support JSON format for structured data exchange

这确保了可观测性和可测试性。LLM 不能将功能隐藏在晦涩的类中——所有功能必须能通过基于文本的界面进行访问和验证。

第三条：测试优先准则

最具变革性的原则——测试之前不写代码：

This is NON-NEGOTIABLE: All implementation MUST follow strict Test-Driven Development.
No implementation code shall be written before:
1. Unit tests are written
2. Tests are validated and approved by the user
3. Tests are confirmed to FAIL (Red phase)

这种方法彻底颠覆了传统的 AI 代码生成模式。LLM 不再直接生成代码并期待它能运行，而是必须先创建定义行为的完整测试用例，在获得批准通过后，才能生成对应的实现代码。

原则七与八：简洁性与反抽象

这两项配套原则旨在对抗过度工程化：

Section 7.3: Minimal Project Structure
- Maximum 3 projects for initial implementation
- Additional projects require documented justification

Section 8.1: Framework Trust
- Use framework features directly rather than wrapping them

当 LLM 可能自然创建复杂抽象时，这些文章强制要求它为每一层复杂性提供合理性证明。实现计划模板中的”阶段-1 关卡”直接贯彻了这些原则。

第九章：集成优先测试

优先进行真实环境测试而非孤立单元测试：

Tests MUST use realistic environments:
- Prefer real databases over mocks
- Use actual service instances over stubs
- Contract tests mandatory before implementation

这能确保生成的代码实际可用，而不仅停留在理论层面。

通过模板实现规范约束

该实施计划模板通过具体的检查点将这些条款转化为可操作性实践：

### Phase -1: Pre-Implementation Gates

#### Simplicity Gate (Article VII)

- [ ] Using ≤3 projects?
- [ ] No future-proofing?

#### Anti-Abstraction Gate (Article VIII)

- [ ] Using framework directly?
- [ ] Single model representation?

#### Integration-First Gate (Article IX)

- [ ] Contracts defined?
- [ ] Contract tests written?

这些关卡充当架构原则的编译时检查。除非通过所有关卡或在”复杂度追踪”章节中记录合理的例外情况，否则 LLM 无法继续推进。

不可变原则的力量

宪法的力量源于其不可变性。虽然实施细节可以演变，但核心原则始终保持不变。这提供了：

1. 跨时间一致性 ：今天生成的代码与明年生成的代码遵循相同原则
2. 跨 LLMs 一致性 ：不同 AI 模型产生的代码具备架构兼容性
3. 架构完整性 ：每项特性的引入都应强化而非削弱系统设计
4. 质量保障 ：测试优先、库优先及简洁性原则确保代码可维护性

宪章演进

原则虽不可变，实践方式可与时偕行：

Section 4.2: Amendment Process
Modifications to this constitution require:
- Explicit documentation of the rationale for change
- Review and approval by project maintainers
- Backwards compatibility assessment

这种方法论能够在保持稳定性的同时不断学习与改进。章程通过带有时间标记的修订案展现自身演进，示范了如何基于实际经验精进原则。

超越规则：一种开发哲学

该章程不仅仅是规则手册——它更是一种塑造 LLMs 如何思考代码生成的哲学：

• 可观测性高于不透明性 ：所有内容都必须能通过 CLI 界面进行检查
• 简约胜于机巧 ：从简单入手，仅在确有必要时才增加复杂度
• 整合优于隔离 ：在真实环境中测试，而非人造环境
• 模块化优于单体 ：每个功能都是边界清晰的独立库

通过将这些原则嵌入规范和规划流程，规范驱动开发（SDD）不仅能生成功能性代码，更能保障代码的可维护性、可测试性和架构合理性。这套准则将 AI 从单纯的代码生成器提升为尊重并强化系统设计原则的架构伙伴。

转变

这并非要取代开发者或自动化创造力。其核心在于通过自动化机械翻译来增强人类能力，构建一个规范、研究与代码协同演进的紧密反馈循环——每一次迭代都能深化理解，使设计意图与实现效果达到更佳的统一。

软件开发需要更好的工具来保持设计意图与实现的一致性。规范驱动开发(SDD)通过生成代码而非仅指导代码的可执行规范，为实现这种一致性提供了方法论。