Spec Kit | 开源规范驱动开发工具包，串起 AI 编码工作流

很多 AI 编程工具可以直接把一句需求变成代码，但当需求不完整、技术取舍没有记录，或者实现与最初目标逐渐偏离时，问题往往不在生成速度，而在缺少一条可回看的开发链路。Spec Kit 是 GitHub 维护的开源工具包，把 Spec-Driven Development（规范驱动开发，简称 SDD）落到项目文件、CLI 和 AI 编程代理命令上：先写清楚要构建什么，再形成技术计划、任务清单，执行后继续对照规范收敛。它不是新的编程语言、框架或代码托管平台，而是一套可以安装到项目里的开发流程与模板。本文按官方仓库当前资料介绍 v1.0.3、Specify CLI、代理集成、扩展机制和 MIT 许可边界。

截至 2026 年 9 月 2 日核对，github/spec-kit 最新稳定 Release 为 v1.0.3，发布时间为 2026 年 9 月 1 日；仓库页面约有 13.3 万 stars、1.2 万 forks，默认分支为 main，GitHub 标记的主要语言为 Python。仓库 main 分支的 pyproject.toml 已进入 1.0.4.dev0 开发版本，因此需要可复现安装时应固定 Release 标签，而不是直接跟随主分支。统计数字、版本和集成清单会继续变化，实际使用前应以官方 Release 与文档为准。

Spec Kit 把“先写规范”变成可执行工作流

Spec-Driven Development 的关键变化，是把规范从一次性的需求说明提升为实现过程中的参照物。Spec Kit 默认提供模板、命令和项目目录约定，让需求、设计决策、任务拆分与代码实现之间可以逐步回看；AI 代理负责理解和执行这些上下文，开发者仍然负责确认目标、技术取舍、验收标准和最终代码。它更适合需要多人协作、需要反复迭代，或希望让 AI 输出保持可追踪的项目，而不是把一次性提示词包装成“自动完成全部开发”。

阶段	主要产物	要回答的问题
Constitution	项目原则与开发约束	质量、测试、体验和性能底线是什么？
Specify	需求规范、用户故事和验收条件	要解决什么问题，什么结果才算完成？
Plan	技术实现计划	选择什么技术栈、架构和数据边界？
Tasks	可执行任务清单	怎样把计划拆成可以逐项完成的工作？
Implement / Converge	代码实现与收敛记录	实现是否仍然符合规范、计划和任务？

这种拆分带来的实际信息增量，不是多了几个命令，而是把“需求变了”“实现偏了”“任务漏了”分别暴露出来。规范、计划和任务可以作为后续审查的上下文；如果目标发生变化，应先更新对应文档，再让代理继续工作，而不是让聊天记录成为唯一依据。

从 Specify CLI 初始化到 Converge 的完整链路

1. 固定版本并初始化项目

官方 README 当前给出的源代码安装方式是用 uv 固定 GitHub Release 标签，再运行 specify init。例如：

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

如果更希望使用包索引，官方也发布了 specify-cli 到 PyPI，可以使用 uv tool install specify-cli、pipx install specify-cli 或 pip install specify-cli。源代码固定标签适合需要锁定仓库版本的场景；PyPI 路径更像常规 Python 工具安装。初始化时可用 --integration 指定代理，也可以用 --non-interactive 服务于 CI 或不能操作交互式选择器的环境；Windows 默认脚本类型为 PowerShell，也可用 --script sh|ps|py 明确选择。

2. 建立项目原则，再写需求规范

进入项目目录并启动已选 AI 编程代理后，先运行 /speckit.constitution 建立项目治理原则，例如测试标准、代码质量和性能要求。随后使用 /speckit.specify 描述用户要完成的事情与成功条件，重点写“做什么”和“为什么”，不要在需求阶段过早锁死实现技术。这样生成的规范才有机会成为后续计划与任务的共同输入。

3. 计划、拆任务并实现

/speckit.plan 接收技术栈与架构选择，形成实现计划；/speckit.tasks 将计划拆成可执行任务；/speckit.implement 按任务推进代码。完成一轮实现后，使用 /speckit.converge 评估代码是否与规范、计划和任务一致，并把遗漏工作追加回任务链。官方说明建议在未收敛时重复实现与收敛，而不是把第一次生成结果当作终点。

核心命令、质量检查与代理集成如何分工

初始化后，代理目录中会出现可调用的 Spec Kit 命令或 skills。核心命令包括 /speckit.constitution、/speckit.specify、/speckit.plan、/speckit.tasks、/speckit.taskstoissues、/speckit.implement 和 /speckit.converge；可选命令还包括 /speckit.clarify、/speckit.analyze 与 /speckit.checklist。它们分别解决需求澄清、跨文档一致性和质量清单问题，不应被理解成同一个“生成代码”按钮。

Spec Kit 的 CLI、模板与 AI 代理是三层分工：specify 负责安装、初始化、集成和项目文件管理；模板规定规范、计划和任务的结构；AI 代理负责在这些上下文中生成或修改内容。仓库 README 当前称其支持 30 多种 AI coding agent，实际可用集成应在已安装版本中运行 specify integration list 查看。不同代理的命令目录、skills 模式和参数可能不同，不能把一个代理的交互方式直接套到另一个代理上。

扩展、预设与 Bundle：按需求组合流程

Spec Kit 不只提供核心 SDD 命令，还把可定制性拆成三个层次。Extensions 用来增加新的命令、模板或外部工具工作流，例如官方内置的 bug 扩展可以把评估、修复和测试拆成独立步骤；Presets 用来改变已有规范、计划或任务的格式与术语，例如对合规追踪、测试优先或组织术语做统一约束；Bundles 则把一组扩展、预设和工作流按角色打包，便于一次性配置产品经理、业务分析师、安全研究员或开发者等团队角色。

# 搜索并安装扩展
specify extension search
specify extension add bug

# 搜索并安装预设
specify preset search
specify preset add lean

# 查看和安装 Bundle
specify bundle search
specify bundle info <bundle-id>
specify bundle install <bundle-id>

这套组合机制的价值在于保持项目本地可审计：模板按优先级解析，项目级 overrides 可以覆盖预设和扩展，安装与移除会根据清单处理组件。社区扩展、预设和 Bundle 由各自作者维护，官方文档特别提醒安装前应审查源代码与来源；“能被搜索到”不等于“经过 GitHub 官方安全背书”。

安装前提、升级策略与可复现边界

官方前置条件包括 Linux、macOS 或 Windows，Python 3.11 及以上、uv（推荐）或 pipx，以及一个受支持的 AI 编程代理。Git 在 README 的一般前置条件中列出，但安装指南说明只有启用 git 扩展时才是必需项；Windows 已支持 PowerShell 脚本，不再必须依赖 WSL。

CLI 与项目文件升级是两件事。specify self check 只读检查是否有新版本，specify self upgrade --dry-run 预览升级命令，specify self upgrade 执行 CLI 升级；已经初始化的项目还应使用 specify integration status、specify integration upgrade <key> 和 specify extension update 刷新项目侧集成与扩展。使用带标签的源安装时，建议把 CLI、代理集成、模板和扩展版本一起记录，避免只升级其中一层导致命令或模板不一致。

适合什么项目，哪些边界需要自己把关

适合把上下文和决策留在项目里的团队

如果项目需要多人理解同一组需求，或者经常在“需求—设计—实现—验收”之间往返，Spec Kit 的规范、计划、任务和收敛检查能提供比聊天记录更稳定的上下文。它也适合希望尝试多种技术栈、做棕地项目渐进改造，或把需求拆成可审查任务后再交给 AI 代理执行的团队。

不替代测试、代码审查与供应链判断

Spec Kit 生成的是流程文件、提示模板和对代码的操作建议；它不会自动保证实现正确、性能达标或符合业务安全要求。AI 代理的实际联网、模型调用、代码上传与数据保留取决于你选择的代理和服务条款，仓库的 MIT 许可也不等于对第三方模型服务的隐私或安全承诺。处理私有仓库、凭据、客户数据或商业机密时，应先审查代理的权限和出站策略，避免把敏感内容直接交给未评估的服务。

v1.0.3、Python CLI 与 MIT 许可

仓库的稳定 Release v1.0.3 对应 specify-cli 1.0.x 系列；pyproject.toml 要求 Python >=3.11，入口脚本为 specify，依赖包括 Typer、Click、Rich、PyYAML、Packaging、PathSpec 和 JSON5 等。仓库 LICENSE 文件采用 MIT License，允许在保留版权与许可声明的前提下使用、修改和再分发；这只说明仓库代码的许可条件，项目内生成的代码、所用模板内容、AI 代理服务和第三方扩展仍需分别核对其来源与条款。

综合来看，Spec Kit 的核心卖点不是“替你写完所有代码”，而是把 AI 辅助开发变成一条有中间产物、有质量检查、可以重复收敛的工作链。对小型一次性脚本，直接使用熟悉的编辑器和测试流程可能更轻；对需要长期维护的产品，固定 CLI 版本、审查扩展、保留规范与任务记录，往往比追逐浮动的主分支更重要。