深入探索GitHub Spec Kit:规范驱动开发实践指南
什么是规范驱动开发
规范驱动开发(SDD)不是编写冗长乏味的需求文档,也不是关于瀑布式规划或通过广泛规划练习预测未来。它更不是创建减慢工程团队进度的官僚主义。
SDD是让技术决策变得明确、可审查和可演进。将其视为思维的版本控制。不是将关键架构决策困在电子邮件线程、分散的文档或锁在某人头脑中,而是以能够随着项目和对问题空间理解增长而发展的格式捕获技术选择背后的“原因”。
想象一下:您正在构建通知系统的第三个冲刺周期。产品经理认为“通知偏好”意味着每个频道的切换开关。后端工程师将其构建为单个开/关开关。前端开发人员假设它会与用户的操作系统通知设置集成。而设计师?他们模拟了需要重建一半用户服务的东西。这不是沟通失败——这是共享上下文的失败。每个人都基于不完整的信息做出了合理的假设。SDD为您提供了一种轻量级的方法,可以在早期揭示这些假设,此时改变方向只需几次按键,而不是整个冲刺周期。
规范成为与代码一起演化的活文档,而不是写一次就忘记的陈旧工件。它们是活跃的工具,帮助您思考边缘情况、跨团队协调和引导新成员。当正确实施时,更新规范变得像重构代码一样自然——而无需实际接触任何代码。
这对于依赖AI代理构建产品的流程尤其关键,因为共享上下文成为可以引导代理找到正确解决方案的宝贵资产。由于规范本身与代码分离,甚至可以轻松创建多变量实现。好奇用Rust编写的组件与用Go编写的组件之间的性能差异?要求AI代理基于规范生成两种完全不同的实现。探索功能的几种设计方向?要求AI代理创建依赖通过Figma MCP服务器暴露的不同Figma模型的几种实现。SDD解锁了不依赖一种刚性实现的新场景。
这就是GitHub Spec Kit的用武之地。
开始使用Spec Kit
GitHub Spec Kit是我们将SDD实践带入生活的方法。要获得GitHub Spec Kit项目的完整概述,您可以先观看本项目的指南视频:
GitHub Spec Kit有两个关键组件值得我们探索:
- Specify CLI:一个帮助CLI,为SDD引导项目。它从GitHub仓库下载所选编码代理和平台的官方模板,并以代理可以开始迭代的方式设置SDD脚手架。
- 一组模板和帮助脚本:这为我们的SDD体验奠定了基础。模板定义了规范的外观、技术计划包含的内容,以及如何将所有内容分解为AI代理可以拾取和执行的任务。
除了工具包的这两个部分外,没有其他魔法。您甚至可以手动管理模板,如果从GitHub仓库的Releases选项卡下载并直接解压到项目文件夹中。GitHub Spec Kit设计用于在您已经构建软件的环境中工作。
Specify CLI
GitHub Spec Kit的重要组成部分是内置CLI。Specify CLI是一个基于Python的工具,可用于快速为SDD设置项目。您可以直接使用uvx安装它,并仅用一个命令引导项目:
|
|
运行Specify时,系统将提示您选择受支持的编码代理之一。Specify默认是跨代理的——内置模板的设计方式使其与大多数现代代理兼容,无需任何调整。Specify将确保下载适合您构建代理的正确版本。
捆绑的帮助脚本也有两种风格。对于POSIX兼容系统,如Linux、macOS,甚至Windows子系统Linux内部,您可以使用shell脚本。在原生Windows环境上——PowerShell脚本也可用。
一旦Specify引导项目,您将在项目中看到两个新创建的文件夹——.github和.specify:
|
|
.specify文件夹包含所有SDD模板,例如规范、技术计划和任务的模板,以及您所选平台的脚本。代理特定文件夹,如GitHub Copilot的.github,将包含提示定义,可以帮助您遵循SDD流程,而无需手动键入实际流程要求。代理特定提示通常也可以通过斜杠命令使用——在我们的案例中,是/specify、/plan和/tasks。
除了上述内容,GitHub Spec Kit还引入了一个您可能以前没见过的额外文件——constitution.md。在SDD上下文中,宪法文档为项目建立了一套不可协商的原则。例如,您的组织可能有一组关于Web应用程序测试方法的要求。或者可能有一个约定,特定团队构建的每个应用程序应始终是CLI优先的。所有这些都可以在解决任何基于SDD的迭代之前捕获在宪法文档中。这也是组织建立有主见的堆栈的强大工具——一套指导每个新项目和现有项目开发和演化的约定。
当然——powershell或bash文件夹中的帮助脚本是从各个提示内部调用的,以帮助确保SDD脚手架一致应用。当Specify首次引导项目时,它确保要么在现有的Git仓库内部,要么如果不是,则为您创建一个。然后脚本帮助代理管理源代码一致性,并确保所有操作都在同一功能分支内完成,以及所有后续提示都有对先前创建工件的适当引用,例如代理为项目生成的规范、计划和数据契约。
斜杠命令
为了更容易遵循SDD流程,我们引入了三个可用于所有受支持编码代理的斜杠命令:
命令 | 描述 |
---|---|
/specify | 概述项目的“内容”和“原因”。这将用于引导项目、功能或变更的产品需求文档(PRD)。此步骤明确排除技术决策——您不是定义技术堆栈,而是关注动机和功能需求。 |
/plan | 概述项目的“方式”——需要使用什么框架、库、数据库或基础设施。这将生成一个计划,以及额外的元数据,例如研究、数据契约和快速入门,概述队友如何开始构建和试验项目。此计划基于我们上面提到的宪法,确保所有决策符合您建立的规范指导。 |
/tasks | 将规范和计划分解为可管理的、分阶段的部分,AI代理可以处理这些部分以实现项目。 |
每个斜杠命令必须按顺序使用——首先,您使用/specify创建规范。然后,您使用/plan建立技术要求。接下来,您使用/tasks将其分解为可管理的部分。
一旦您对需求、计划和任务分解满意——只需要求您的代理基于概述的任务实现项目。
值得注意的是,当您使用Specify注入项目的斜杠命令时,拥有非常详细的第一个提示将产生代理可以用于进一步项目构建的更好规范。
仔细考虑项目需求以及您希望在最终输出中看到和不看到的内容。对于规范,是否有特定体验对您构建的内容的成功至关重要?对于技术计划,选择特定库而不是让AI为您做出选择有多重要?您能融入指导提示的细节越多,您花费在调整生成文档上的时间就越少。
当您完成各个步骤时,您的AI代理将在specs文件夹内创建新工件。您可以手动或借助代理审查和调整它们——它们是纯Markdown文件,您可以根据项目需要轻松更改它们。
虽然SDD流程本身很灵活,并让您对项目细节有很多控制,但GitHub Spec Kit融入了一些关于如何构建项目的假设。您可以在检查任何捆绑模板时看到这些。如果您觉得脚手架的一个或多个部分不是您项目想要的,请随时修改.specify文件夹中提供的提示和模板以满足您的需求。开箱即用的脚手架是我们已成功用于一系列项目的示例实现,但它当然可以扩展和调整以适应特定的组织要求。
我们想要您的反馈
首先,GitHub Spec Kit是一个实验——有很多问题我们仍然想要回答,如果社区反馈是一个指标,我们仍然可以添加相当多的功能来使SDD流程更易于使用。我们对过去一周该项目受到的热烈欢迎表示非常感谢,并期待其成长并向在其项目中采用它的开发人员的经验学习。
如果您尝试过它,并发现缺少某些东西、无法工作或可以改进——请提出问题。
我们期待看到您使用GitHub Spec Kit和SDD构建的内容!