深入探索GitHub Spec Kit规范驱动开发

开发者越来越依赖AI代理来构建新软件并扩展现有项目能力。然而基于AI的系统面临一个挑战：要产生正确输出，首先需要建立良好的上下文环境。如果不提前决定构建内容和原因，代码库就会成为事实上的规范——一堆看似分离但能协同工作的组件，难以维护、演进和调试。

代码确实不是需求协商的最佳媒介——没人愿意先写代码，然后在需求出现时逐步调整，技术架构会将开发人员锁定在特定解决方案中。代码本质上是具有约束力的产物——一旦编写实现，就很难解耦。任何重大重写或实验无疑都需要大型团队付出大量努力。

这就是GitHub上周推出Spec Kit的原因。

GitHub Spec Kit为基于AI的软件开发工作流带来了新方法——团队可以不再凭感觉编写每个新功能和错误修复，而是先发制人地概述具体项目需求、动机和技术方面，然后交给AI代理，让它们准确构建最初需要的内容。如果你曾与需要编写产品需求文档（PRD）并经过评审后实施的产品经理合作，可能会听到类似流程的回声。

什么是规范驱动开发

规范驱动开发（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安装，只需一个命令即可引导项目：

1

uvx --from git+https://github.com/github/spec-kit.git specify init <PROJECT_NAME>

运行Specify时，系统将提示你选择受支持的编码代理之一。Specify默认跨代理——内置模板设计为与大多数现代代理兼容而无需调整。Specify将确保下载适合你构建代理的正确版本。

捆绑的辅助脚本也有两种风格。对于POSIX兼容系统（如Linux、macOS，甚至在Windows Subsystem for Linux内），可以使用shell脚本。在原生Windows环境——PowerShell脚本也已准备就绪。

一旦Specify引导项目，你将看到项目内创建了两个新文件夹——.github和.specify：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

├───.github
│   └───prompts
│           plan.prompt.md
│           specify.prompt.md
│           tasks.prompt.md
│
└───.specify
    ├───memory
    │       constitution.md
    │       constitution_update_checklist.md
    │
    ├───scripts
    │   └───powershell
    │           check-task-prerequisites.ps1
    │           common.ps1
    │           create-new-feature.ps1
    │           get-feature-paths.ps1
    │           setup-plan.ps1
    │           update-agent-context.ps1
    │
    └───templates
            agent-file-template.md
            plan-template.md
            spec-template.md
            tasks-template.md

.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创建规范。然后使用/plan建立技术要求。接下来使用/tasks将其分解为可管理块。

一旦你对需求、计划和任务分解满意——只需要求代理基于概述的任务实现项目。

值得注意的是，当你使用Specify注入项目的斜杠命令时，非常详细的第一个提示将产生代理可用于进一步项目构建的更好规范。

仔细考虑项目需求以及你希望在最终输出中看到和不看到的内容。对于规范，是否有特定体验对你构建内容成功至关重要？对于技术计划，选择特定库而非让AI为你做出选择有多重要？你能融入指导提示的细节越多，花在调整生成文档上的时间可能越少。

当你完成各个步骤时，AI代理将在specs文件夹内创建新工件。你可以手动或借助代理评审和调整它们——它们是纯Markdown文件，可以根据项目需要轻松更改。

虽然SDD流程本身灵活，让你对项目细节有很多控制，但GitHub Spec Kit融入了一些关于如何构建项目的假设。你可以在检查任何捆绑模板时看到这些。如果你觉得脚手架的一个或多个部分不适合项目，请随意修改.specify文件夹内提供的提示和模板以满足需求。开箱即用的脚手架是我们已成功用于一系列项目的示例实现，但肯定可以扩展和调整以适应特定组织要求。

我们需要你的反馈

首先，GitHub Spec Kit是一个实验——我们仍想回答很多问题，如果社区反馈是指标，我们仍可以添加相当多功能使SDD流程更易使用。我们对过去一周该项目获得的压倒性积极反响非常感激，并期待其成长并向在项目中采用它的开发人员经验学习。

如果你尝试过并发现缺少某些内容、无法工作或可以改进——请提出问题。

我们期待看到你用GitHub Spec Kit和SDD构建的内容！