规范驱动开发：为 AI 生成代码提供骨干

Source: Dev.to

请提供您希望翻译的具体文本内容，我将为您翻译成简体中文并保留原有的格式、Markdown 语法以及代码块和链接。谢谢！

AI辅助开发与“Vibe Coding”的崛起

AI 编码工具（Cursor、Copilot、Claude Code 等）已经彻底改变了我们构建软件的方式。它们快速、实用且日益强大，但也暴露了一个常见问题：“vibe coding”（氛围编码）。

• 你用宽泛的语言描述一个功能。
• AI 写出看似合理的代码。
• 大家都继续前进，期望结果符合真实意图。

有时它能奏效，但往往生成的代码隐藏了缺失的边缘情况、薄弱的契约、不一致的架构或未记录的假设。

什么是规范驱动开发？

规范驱动开发 (SDD) 指在让 AI 实现解决方案之前，先编写结构化的规范。该规范成为一个持久的工件，捕获意图、行为、约束和验收标准。

为什么“真相来源”很重要

• 没有规范时： 开发者和 AI 只能凭记忆、假设和部分上下文工作。
• 有规范时： 双方都以同一个工件为锚。人类对应构建的内容保持一致；AI 将其用作系统行为的结构化上下文。

一个简单的思考方式：

Prompt‑only development:
idea → chat → code → patch bugs → explain later

Spec‑driven development:
idea → spec → design → tasks → code → tests

区别不仅仅是文书工作——它把歧义提前到仍然廉价可解决的阶段。

传统开发 vs. 规范驱动开发

传统（以及 AI 诱惑）流程

Idea → Code → Docs

有人有一个想法，开始编码，然后如果有时间再写文档。
当代码瞬间出现时，跳过规划的诱惑会增加，实施最终会定义行为而不是团队。

规范驱动工作流

Idea → Spec → Code → Tests

或者，在更成熟的环境中：

Idea → Requirements → Design → Tasks → Implementation → Validation

从规范开始迫使你在代码生成器之前回答重要问题：

• 我们在解决什么问题？
• 边界是什么？
• 什么算作“完成”？
• 必须遵守哪些约束？
• 边缘情况应该如何处理？

规范为产品、工程和 AI 助手提供共享的地图，降低代码成为需求第一稿的可能性。

Source: …

规范驱动的工作流

不同工具以各种方式实现 SDD，但工作流通常遵循四个实用阶段。

1. 需求

用 行为层面 来定义功能——关注用户需求和验收标准，而不是类、端点或表。

示例：

**Feature:** Export user data as CSV  
**User Story:** As a user, I want to download my account activity so I can analyze it offline.  
**Acceptance Criteria:**  
- The CSV includes columns: Date, Action, Amount.  
- Only data from the last 30 days is exported.  
- The file size does not exceed 5 MB.  
- Export fails gracefully with an error message if the query exceeds the size limit.

需求 1：将发票导出为 PDF

作为一名会计，
我想将发票导出为 PDF，
以便我可以向客户发送可打印的版本。

验收标准

• GIVEN a valid invoice
  WHEN I click “Export PDF”
  THEN the system downloads a PDF file.

• GIVEN the invoice contains taxes
  WHEN the PDF is generated
  THEN tax totals must match the web view.

2. 设计

在此阶段，团队决定系统应 如何 满足规范，而不仅仅是 做什么。

示例流程：

flowchart LR
    UI[UI Button] --> Service[Invoice Service]
    Service --> Generator[PDF Generator]
    Generator --> Storage[Storage/Download]

3. 任务

将设计拆分为离散的工作项，有助于人类和 AI 将宽泛的意图转化为具体的执行步骤。

示例任务列表：

- [ ] Add PDF export endpoint
- [ ] Implement invoice‑to‑PDF transformer
- [ ] Add validation for missing invoice data
- [ ] Write integration tests for export flow
- [ ] Verify totals match rendered invoice

4. 实现

只有在前面的阶段都清晰之后，才应让 AI 生成或修改代码。这正是规范驱动开发（SDD）开始显得强大的地方：实现过程受到明确指引，而不是自由猜测。

为什么规范驱动开发与 AI 配合良好

AI 系统虽然强大，但仍是对上下文高度依赖的模式匹配器。当出现以下情况时，它们表现更佳：

• 问题表述清晰。
• 约束条件明确。
• 所需行为以结构化方式写下来。

好的规范为模型提供了遵循的轨道，缩小了解决方案空间，并使验收标准明确。

好处

• 团队对齐度提升 – 在实现前达成共享理解。
• 清晰的 API 合约 – 更干净的接口，便于验证。
• 文档质量提升 – 文档成为开发过程的一部分。
• AI 生成代码更可靠 – 明确的意图带来更一致的结果。

挑战

• 初始开销 – 编写需求、设计说明和任务需要时间。
• 糟糕的规范会导致糟糕的系统 – 模糊或矛盾的规范会产生错误的输出。
• AI 仍可能行为不可预测 – 模型可能遗漏指令或偏离计划。

目标不是用规范取代思考，而是让思考可视化。

结论

随着 AI 成为软件交付的更大部分，规范将变得更重要，而不是更不重要。在代码可以快速生成的世界里，稀缺资源是清晰度，而不是敲击键盘的次数。Spec‑Driven Development 将焦点从“助理产生了什么代码？”转向“我们实际上想要构建的系统是什么？”规范提供方向；代码是输出。

参考文献

• (未提供其他参考文献)