GitHub Spec Kit 是什么？用规格驱动开发约束 AI 编程

Mon, 25 May 2026 00:19:14 +0800

GitHub 的 Spec Kit 是一个面向 AI 编程的新工具包，目标是帮助开发者实践 Spec-Driven Development，也就是规格驱动开发。

它解决的问题很直接：现在很多 AI 编程工作流太像“边聊边写”。人类给一个大概想法，Agent 立刻开始改代码，短期看很快，但需求边界、验收标准、技术取舍和任务拆分往往没有沉淀下来。项目稍微复杂一点，就容易变成一次性的 vibe coding。

Spec Kit 的思路是反过来：先把规格写清楚，再进入计划、任务和实现。代码不再是第一步，规格才是第一步。

Spec Kit 是什么？

Spec Kit 是 GitHub 开源的规格驱动开发工具包。它提供 specify CLI、模板、脚本和面向 AI coding agent 的命令，让团队可以围绕同一套结构化产物推进开发。

它强调的不是“让 AI 少问问题”，而是让 AI 在写代码前先生成并完善这些内容：

项目原则：团队对质量、测试、体验、性能等方面的约束；
功能规格：要做什么、为什么做、用户故事和功能需求；
技术计划：使用什么技术栈、如何落地、有哪些架构决策；
任务清单：把计划拆成可执行步骤；
实现过程：按任务逐步修改代码，而不是一次性乱改。

这套流程让 AI 编程更像工程协作，而不是一次提示词表演。

基本使用流程

官方 README 给出的入门流程大致是这样：

1
2
3

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z
specify init my-project --integration copilot
cd my-project

初始化后，项目里会生成 .specify 目录、模板、脚本和与 Agent 集成的命令。随后在支持的 AI coding agent 中使用 /speckit.* 命令推进开发。

典型顺序是：

/speckit.constitution
/speckit.specify
/speckit.clarify
/speckit.plan
/speckit.tasks
/speckit.implement

其中 /speckit.constitution 用来建立项目原则，/speckit.specify 描述产品需求，/speckit.clarify 补齐模糊点，/speckit.plan 生成技术计划，/speckit.tasks 拆任务，最后由 /speckit.implement 执行实现。

这和直接对 Agent 说“帮我做一个应用”差别很大。Spec Kit 要求你把“做什么”和“怎么验收”先说清楚，再让 Agent 动手。

它改变了 AI 编程的入口

传统 AI 编程经常从代码开始：

`1`	`我想做一个任务管理应用，帮我写出来。`

Spec Kit 更像这样：

先定义这个任务管理应用的用户、场景、功能边界、验收标准和非目标；
再根据这些规格选择技术方案；
然后拆成任务；
最后逐步实现。

这个变化很重要。因为 AI 最擅长根据上下文执行，但如果上下文本身是松散的，执行速度越快，偏离方向也可能越快。Spec Kit 把上下文变成文件和模板，让需求、计划和任务都能被 review、修改和版本管理。

换句话说，它不是让 AI 更“自由”，而是让 AI 在更清晰的工程轨道上自由发挥。

核心命令怎么理解？

`/speckit.constitution`

这是项目的“宪法”。它会生成或更新 .specify/memory/constitution.md，用于记录项目长期遵守的原则，例如代码质量、测试标准、用户体验一致性、性能要求和技术决策规则。

这一步适合写团队共识，而不是单个功能需求。

`/speckit.specify`

这是功能规格阶段。你需要描述要构建什么、用户是谁、解决什么问题、有哪些核心流程。

官方特别强调：这一阶段不要过早关注技术栈。先把 what 和 why 写清楚，再讨论 how。

`/speckit.clarify`

这是补问题的阶段。很多需求第一次写出来都会有空洞：权限怎么处理？异常状态是什么？数据是否持久化？边界条件如何验收？

/speckit.clarify 的价值，是让 Agent 主动发现规格中的不确定点，并把回答记录回规格文档，减少后面返工。

`/speckit.plan`

这是技术计划阶段。到了这里，才开始明确框架、数据库、架构、API、测试策略和约束。

如果说 /speckit.specify 是产品语言，/speckit.plan 就是工程语言。

`/speckit.tasks`

这一步把计划拆成可执行任务。好的任务清单应该能让 Agent 逐步推进，也能让人类看懂每一步的目的。

`/speckit.implement`

最后才进入实现。Agent 根据前面沉淀的规格、计划和任务修改代码。这时它不再是凭一段大 prompt 猜需求，而是在一组结构化文档里执行。

为什么它适合 AI 编程？

Spec Kit 的价值不在于某个神奇命令，而在于它把 AI 编程中最容易缺失的东西补了回来：

需求可审查；
计划可讨论；
任务可追踪；
决策有上下文；
产物可以进入 Git 历史；
团队可以复用模板和原则；
Agent 的实现不再只依赖一次性聊天记录。

这对复杂项目尤其有用。越是多人协作、长期维护、质量要求高的项目，越不能只靠临时 prompt 驱动开发。

扩展和 Preset

Spec Kit 还提供了两类自定义能力：

Extensions：增加新命令、新模板或外部工具集成；
Presets：改变现有规格、计划、任务模板的格式和术语。

简单理解：如果要新增能力，用 Extension；如果要改造工作流风格，用 Preset。

例如，团队可以通过 Preset 强制加入安全审查、监管追踪、领域术语或测试优先规则；也可以通过 Extension 增加 Jira 集成、代码审查、项目健康检查等新阶段。

这说明 Spec Kit 并不想把所有团队锁进同一种流程，而是提供一个可扩展的规格驱动骨架。

适合谁用？

Spec Kit 适合这些场景：

用 AI coding agent 做新项目原型；
想把 vibe coding 变成可复盘流程；
团队希望统一 AI 生成代码前的需求和计划格式；
项目需要明确验收标准和测试要求；
希望把需求、计划、任务和实现过程都纳入版本管理；
正在探索 GitHub Copilot、Claude Code、Codex CLI 等工具的团队化用法。

它不一定适合非常小的一次性脚本。对于几行代码能解决的问题，完整规格流程可能显得重。但只要任务开始涉及多个页面、多个模块、状态管理、权限、数据模型或长期维护，Spec Kit 的结构化收益就会变明显。

我的理解

Spec Kit 代表的是 AI 编程工具的一种重要转向：从“让 Agent 更快写代码”，转向“让 Agent 更可靠地参与软件工程”。

过去的 AI 编程关注提示词和模型能力；Spec Kit 更关注流程、产物和约束。它提醒我们：AI 写代码越快，规格、计划和验收就越不能省。

如果你已经习惯让 AI 直接实现功能，可以尝试用 Spec Kit 改变起手式：

先让 AI 帮你把需求写成规格，再让它写代码。

这一步看似变慢，实际是在减少后面“代码写完了，但不是我想要的”的返工。

参考链接

github/spec-kit

规格驱动开发 on KnightLi的博客