[Github] Spec Kit – 用规范驱动 AI 编程流程

Spec Kit 是 GitHub 推出的规范驱动开发工具套件：它不直接替你决定产品该做什么，而是把项目准则、功能规范、技术方案、任务清单和实现检查串成一条可重复的 AI 编程流程。真正值得关注的不是“又多了一组提示词”，而是需求在交给编码智能体之前，先被整理成可审查、可版本化的制品。对于复杂功能、多人协作或需要追溯决策的项目，这比直接让 AI 开始写代码更稳；一次性脚本和很小的修改，则可能不值得承担整套流程成本。

它改变的是顺序

普通的 AI 编程常从一句需求直接跳到代码，结果是技术选型、权限边界、验收条件和异常处理一起在实现阶段临时补齐。Spec Kit 把顺序改成“先说明做什么与为什么，再决定怎么做，最后才拆任务和实现”。规范不再只是项目启动时写完就放在一边的文档，而是后续计划、任务和校验的输入。

先定准则

/speckit.constitution 用来建立项目不可轻易绕过的原则，例如测试标准、安全要求、体验一致性和性能边界。后续规划会以这些准则为约束。它的意义不是增加一份口号式文档，而是把团队原本散落在约定、评审意见和个人经验里的规则放进同一条工作流。

先消除歧义

/speckit.specify 聚焦用户需要什么以及为什么需要，不在这个阶段混入框架、数据库和 API 选择。描述不充分时，可在制定技术方案前运行 /speckit.clarify；对于需要更严格审查的功能，还可以用 /speckit.checklist 生成需求质量清单。这里的关键判断是：结构化文档不会自动让错误需求变正确，但它能让假设更早暴露，方便人来改。

一条完整工作流

官方快速指南给出两条常用路径。小功能可以采用较短的 specify → plan → tasks → implement → converge；生产功能则加入项目准则、澄清、质量清单和跨制品分析。后者的步骤更多，但每一步都有明确输入和输出，不必把所有上下文塞进一条超长提示词。

1. constitution：设定项目治理准则。
2. specify：把自然语言需求整理为功能规范。
3. clarify：解决规范中的歧义和缺口。
4. plan：加入技术栈与架构选择，形成实施方案。
5. checklist：检查需求是否完整、清楚且一致。
6. tasks：生成按依赖排序的可执行任务。
7. analyze：只读检查规范、方案与任务是否冲突或遗漏。
8. implement：按任务依赖执行实现。
9. converge：把代码库与制品重新对照，将剩余工作补回任务清单。

这条链路把“计划后才发现需求不清”和“实现后才发现任务遗漏”变成显式检查点。代价也很直接：规范、计划和代码都要有人审阅并持续更新，否则流程只会生产更多看起来整齐、实际已经失真的文档。

从 CLI 开始

安装与初始化

截至 2026 年 8 月 31 日，官方最新稳定版为 v1.0.1。项目支持 Linux、macOS 和 Windows，需要 Python 3.11+；官方推荐用 uv 安装，也支持 PyPI、pipx、一次性 uvx 和离线 wheel。若希望锁定官方 Release，可按下面方式安装并初始化：

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

specify init 在交互式终端中可以选择编码助手，也可通过 --integration 明确指定；CI 或无交互环境应增加 --non-interactive，避免卡在选择器。自动化脚本可选 Bash、PowerShell 或 Python，Windows 默认使用 PowerShell。Git 现在不是基础流程的硬依赖，只有启用可选的 git 扩展时才需要。

命令形式不同

Spec Kit 官方文档列出 30 多种 AI 编码助手集成。多数助手使用 /speckit.* 斜杠命令；Codex CLI 采用 $speckit-* 技能形式，部分集成还有自己的调用前缀。初始化前应先确认对应 integration key，而不是把某个助手的命令形式原样复制到另一个环境。WarpNav 已收录 GitHub Copilot 与 Claude Code 的独立入口，可先确认助手本身的安装和使用条件。

制品如何落盘

Spec Kit 当前用 .specify/feature.json 记录活动功能目录，命令按这个状态解析当前功能，而不是依赖当前 Git 分支。一个功能通常会逐步形成 spec.md、plan.md 和 tasks.md；规划阶段还可能生成 research.md、data-model.md、contracts/ 与 quickstart.md。这使需求、技术决策、接口和任务之间有可追踪的落点。

也正因为制品会落盘，切换分支并不等于切换活动功能；需要更新 .specify/feature.json 或设置 SPECIFY_FEATURE_DIRECTORY。对于已有代码库，官方另有 adoption 指南，不能把绿地项目的初始化流程无条件套到存量项目。

1.0 后的扩展层

v1.0.1 的 Spec Kit 已经不只是核心命令集合。扩展、预设和捆绑包分别解决三类不同需求：

• 扩展：添加新命令、钩子或外部工具集成，改变“能做什么”。
• 预设：覆盖规范、方案或任务模板，改变“按什么方式做”。
• 捆绑包：把扩展、预设、步骤和工作流锁定到具体版本，为某类团队角色一次性配置。

项目本地覆盖、预设、扩展与核心模板存在明确优先级。社区组件由各自作者维护，官方也提醒安装前审阅源代码。团队若要把它用于合规、安全或组织级流程，应该锁定版本、审查组件来源，并把模板变更纳入代码评审，而不是默认信任社区目录。

何时值得采用

Spec Kit 更适合需求容易漂移、需要多人评审、要在不同编码助手之间保持一致上下文，或必须说明“为什么这样实现”的项目。绿地功能可以从规范一路推到实现；棕地项目则适合先按官方指南建立现有系统上下文，再逐步让新功能进入这条流程。

它不太适合无需长期维护的一次性脚本、几行就能解释清楚的小修改，以及没有人负责评审规范的团队。最大的风险不是命令太多，而是把 AI 生成的结构误当成事实：验收条件、权限、安全边界和业务规则仍需负责人确认。若这些决定尚未明确，先澄清，再让智能体执行，通常比增加更多实现提示词更重要。

项目信息

• 项目：GitHub Spec Kit / Specify CLI
• 最新稳定版：v1.0.1（2026 年 8 月 21 日发布）
• 主要语言：Python，要求 Python 3.11+
• 许可证：MIT
• 仓库状态：未归档；最近提交核验至 2026 年 8 月 28 日
• 关注度：截至 2026 年 8 月 31 日，GitHub API 显示约 13.2 万 Stars、1.19 万 Forks；数据会继续变化

相关链接

• GitHub 仓库：https://github.com/github/spec-kit
• 官方文档：https://github.github.io/spec-kit/
• 快速开始：https://github.github.io/spec-kit/quickstart.html
• Release：https://github.com/github/spec-kit/releases