本文我们将通过一个实际案例，完整地介绍从编写规范说明的第一行到长期维护的整个工作流程。

如果你想了解如何将规范驱动开发付诸实践，以及像 GitHub Spec Kit 这样的工具如何帮助实现这一流程，本文将为你指明方向。

目录

开始之前规范驱动开发工作流程深度剖析AI 工具如何融入这一流程最后的思考

一、开始之前

在深入步骤详细的工作流程之前，有必要先了解规范驱动开发与传统的敏捷开发或文档繁重的方法有什么不同。

它并不是要增加文书工作。而是要创造清晰度。目标是达成共识，让每个参与者，无论是人类还是 AI，都围绕同一个思维模型保持一致。最好的规范说明书是由产品、工程和质量保证团队共同构建的，形成一个单一的真相来源（single source of truth）。

一旦你开始将规范说明书当作一份活生生的契约，而不是一份静态的文档，其余的流程就会自然地各就各位。

二、SDD 流程深度剖析

以下是一个以规范 spec 为先导的实用流程，以行程规划器 AI 智能体为例进行说明。我们将引用 GitHub 风格的规范工具，使用 GitHub 的 Spec Kit 来保持内容的具体性，但任何结构良好的 Markdown 规范都可以奏效。

这种流程同样适用于其他工具，或者从头开始编写，只要捕捉到相同的要素即可。

下面先初始化一个示例项目：

uvx --from git+https://github.com/github/spec-kit.git specify init trip-app

1) 规范（Specify）

目标：编写一份清晰的产品规范，说明问题、范围、用户、成功标准和约束条件。专注于“是什么”和“为什么”，避免涉及实现细节。

行程规划器示例（产品规范要点）：

问题：帮助旅行者规划多城市行程，提供现实的时间安排、预算指导以及离线可用性。用户：休闲旅行者、旅行博主以及小型旅游运营商。关键流程：创建行程、添加城市、自动生成行程安排、根据偏好（节奏、兴趣、预算）调整行程、导出到移动设备。非功能约束：对于 7 天行程，行程生成的 P95 延迟时间不超过 4 秒。安全存储个人身份信息（PII）。移动设备上的离线阅读模式。不在范围内的功能：航空预订、酒店支付。

现在运行/speckit.specify步骤，将上述内容记录在项目本地的规范中，该规范存储在版本控制中，以便人类和智能体都能参考。

在 VS Code 打开上述创建的实例项目：trip-app。

然后，输入如下 specify：

/speckit.specify 构建一个旅行规划工具，能够为多城市旅行生成每日行程。 需包含：用户画像、核心流程、成功指标以及约束条件（性能、隐私、离线）。 这是一个免费使用的平台。 问题： 帮助旅行者规划多城市行程，提供符合实际的耗时预估、预算指导和离线可用性。 用户： 普通游客、旅行博主、小型旅行社。 核心流程： 创建行程、添加城市、自动生成行程、根据偏好（节奏、兴趣、预算）调整、导出到移动端。 非功能约束： 对于为期7天的行程，95分位数的行程生成时间需低于4秒。安全存储个人身份信息。移动端支持离线只读模式。 排除范围： 机票预订、酒店支付。

它将生成一个带有初始规范的 Markdown 文件，基于你的请求。你提供的上下文和细节越多，第一份草稿就越完善。

请注意：这个文件并不是一份完整的规范，它只是一个起点。通常来说，修改一份草稿比从空白页面开始写作要容易得多。你需要仔细审查它——通读一遍，验证假设，根据实际需求进行调整，并填补任何空白。

智能体可能会在某些部分标记出[NEEDS CLARIFICATION]（需要澄清），这是提示你消除歧义或在继续之前做出关键的项目决策。

如下是完成状态：

如下是对应生成的 speck.md和requirements.md 文件，如图所示：

2) 计划（Plan）

目标：将产品规范转化为技术计划。选择技术栈、架构和集成边界，并指出风险。

旅行规划器示例（技术方案要点）：

架构： 采用 API 优先的设计。包括后端服务 + 用于存储兴趣点（POI）嵌入的向量数据库。前端为 Web 端和移动端外壳。（POI 指"兴趣点"，即规划器用来构建行程的地标、景点或餐厅。）AI 设计： 使用路由智能体选择兴趣点，调度智能体安排每日行程，评判智能体检查时间安排和交通衔接。数据： 城市信息目录、兴趣点元数据、交通耗时数据。性能： 目标是在 95% 的情况下，端到端行程规划耗时低于 4 秒。安全： 在日志中脱敏处理个人身份信息（PII），静态数据加密存储。风险： 外部 API 的速率限制、长提示词导致的成本激增、冷启动问题。

使用 GitHub 的规范工具包，你可以使用 /speckit.plan 在仓库中记录技术栈和架构选择，以便智能体不会猜测。

使用此命令时，你无需遵循任何严格格式。它接受自由形式的文本提示，因此只需用自己的话描述你的技术栈、工具和架构选择即可。你可以使用逗号、分号，甚至换行符。该工具会在上下文中读取你的输入，并自动将其转换为结构化的技术计划。

这种灵活性是经过精心设计的。其目的是捕捉你的意图、技术、角色和依赖关系，而不是强迫你遵循某种僵化的语法。

如果你愿意，也可以将输入写成项目符号或单独的行。结果将完全相同。

/speckit.plan Stack: FastAPI + Postgres + Redis; Next.js 前端；通过 Expo 实现移动端。智能体：规划器planner、调度器scheduler、评论器critic。使用 OpenRouteService 获取旅行时间。

一旦规范看起来合理，你运行此命令后，工作流程将转向更详细的实施计划阶段。在这个阶段，规范不仅描述了“要构建什么”，还开始塑造“如何构建它”，使开发与你定义的架构和方向保持一致。

在这个阶段，规范开始塑造实施。计划减少了模糊性并加速了审查。请记住，使用这些工具只是编写出色规范并将其提供给智能体的辅助工具。始终是你有责任检查并调整生成的规范中的任何内容。

3）分解任务（Tasks）

目标：将计划转化为有序的、可测试的任务列表，并附上验收标准。包括负责人、依赖关系以及指向规范各部分的链接。

行程规划器示例（任务）：

行程生成的 API 合同，附带请求/响应模式。规划器、调度器、评论器的智能体提示和限制。POI 元数据的数据加载器。缓存和速率限制处理。前端流程：创建行程、编辑偏好设置、查看行程、导出。可观测性：时间跨度、成本跟踪、错误分类。

当你在规范工具包中运行 /speckit.tasks 命令时，你将得到类似上面的输出。在幕后，该工具会扫描你的 SPEC.md 和 PLAN.md 文件，然后构建一个清晰、连贯的待办事项列表，其中包含验收标准、依赖关系以及指向规范中正确部分的链接。

基本上，你无需亲自动手编写每个任务。规范工具包会根据你的项目背景自动生成它们。从那里开始，你可以根据自己的喜好审查、调整和重新排列列表，然后分配负责人或启动开发。

因此，你只需运行 /speckit.tasks 来生成一个引用规范和计划的可操作待办事项列表。

如下是生成的 tasks.md 文件：

4）实现（Implement）

目标：以小块的方式执行任务。通过将智能体指向 SPEC.md 和 PLAN.md 来保持它们在你的约束范围内。

行程规划器示例（一个切片）：

实现 POST /itinerary，附带模式验证和预算检查。添加调度智能体提示，尊重每日步行限制和营业时间。缓存 POI 查询和交通矩阵。

智能体可以从规范、计划和任务文件中工作，而不是使用临时提示。

5) 测试

目标：将测试直接附加到需求上，以便你可以追溯“承诺了什么”和“交付了什么”。规范工具包中没有单独的 /test 命令，测试是内置在工作流程中的。

默认情况下，它遵循测试驱动开发（TDD）结构：当你运行 /tasks 时，测试相关项目会自动包含在内，并且在实现任务之前进行排序。这确保了需求能够尽早且一致地得到验证。

如果你的项目不遵循 TDD，你可以在规范中明确说明，以调整任务顺序。

6) 维护

目标：随着需求的变化安全地演变。首先更新规范，重新生成计划和任务，并让智能体在这些边界内进行重构。

行程规划器示例（变更请求）：

添加“家庭模式”，优先选择适合儿童的 POI 和较短的步行段。更新 spec.md 约束条件，重新运行计划，重新生成受影响的任务，调整提示，并为新规则扩展测试。保留规范修订的变更日志，以便未来的贡献者了解为何做出这些权衡。

规范驱动开发（SDD）将规范视为一个动态的工件，它为任务、提示和验证提供支持。这使得中途调整更加便宜且更可预测。

处理部分更新和重新规划

一个常见问题是，当你调整规范并要求规划器重新运行时，部分代码已经存在。由于大语言模型每次产生的结果并不完全相同，重新规划有时会意外地调整你原本不想触碰的项目部分。

团队通常依赖两种实用的变通方法来控制局面：

1. 标记已完成的任务为已完成

Spec Kit 会跟踪哪些任务已经完成。在重新规划之前将某项任务标记为“已完成”，你实际上是在告诉系统以及背后的 AI 智能体，不要触碰这一部分。

话虽如此，这种保护措施并不完美。用户注意到，全面的重新规划有时仍然会调整或覆盖这些“已完成”的区域。因此，在将新输出合并回主线之前，仔细阅读仍然是明智之举。

2. 为新功能创建单独的规范

如果你正在添加一个大型功能或尝试一些新的东西，最好创建一个新的规范分支（例如，001-feature-family-mode），而不是编辑主分支。这种方法遵循Spec Kit 基于分支的工作流程，并保持你的新代码独立，尽量减少对项目其他部分的连锁反应。

这两种方法都是经过社区测试的临时解决方案，直到规范工具包提供真正的增量更新支持。它们依赖于大语言模型尊重边界而不是强制执行边界，这意味着人工审查步骤不是可选的，而是在接受任何重新生成的计划或任务之前是必不可少的。

三、AI 工具如何融入这一流程

这个工作流程的每个阶段都可以由不同的工具支持。有些团队使用 Markdown 和 GitHub 保持简单。其他团队则依赖于像 Kiro 或 Claude Code 这样的 AI 原生平台。

最重要的是保持一致性。一旦你决定了规范的存放位置，确保每个计划、任务和测试都指向同一个事实来源。

纪律严明的设置总是优于花哨的工具。

关于工具的注意事项

我在这里使用了 GitHub 的规范工具包，因为它为 规范 → 计划 → 任务 → 实现 提供了一条现成的路径，并且提供了仓库友好的模板。任何有良好文档的规范文件都可以工作，只要你涵盖了主要领域：目标、用户、范围、约束条件、架构、数据契约、验收标准和测试。使用适合你环境的工具，原则保持不变。

因此，随意编写自己的规范文件或使用其他模板。最重要的是为 AI 智能体提供一个单一的事实来源。它们不会对项目做出任何假设，它们只是按照你指定的方式执行，然后你可以审查工作。

工具并不能取代判断。团队仍然需要在开始编码之前审查、提炼和批准规范。

四、最后的思考

规范驱动开发（Spec-Driven Development）并不是取代创造力，而是为其提供形式。通过将 AI 驱动的工作锚定在明确的意图和可追溯的工件上，你可以构建出更快交付且更安全演进的系统。

无论你使用的是 GitHub Spec Kit、Claude Code 还是自定义的 Markdown 设置，节奏都是一样的：

明确规范，有目的的计划，毫不妥协的测试，以及有目标的演进。

这就是团队从 氛围编程 转变为真正的工程纪律的方式。