GitHub Spec Kit：用「先写规格后写代码」重新定义 AI 辅助开发

核心观点

Spec Kit 是 GitHub 官方开源的一套工具链，推行一种叫做 Spec-Driven Development（SDD，规格驱动开发） 的工作方式------核心逻辑是：在让 AI 写任何一行代码之前，先把"要建什么、为什么建"用结构化规格文档定义清楚，再由 AI 依据规格生成实现。

这不是在做新发明。SDD 的思路脱胎于 BDD（行为驱动开发）和 TDD，但现在这个时机节点上出现得恰到好处：当 AI Coding Agent 可以几秒内产出一千行代码时，瓶颈已经不在"生成速度"，而在于"有没有说清楚要生成什么"。

关键机制：为什么「先写规格」会改变 AI 的输出质量

传统 AI 编程的核心缺陷是歧义驱动猜测 ：你说"帮我做个照片相册功能"，AI 必须自己猜文件格式、存储方式、权限模型、压缩策略......这就是业界戏称的 "vibe coding"------代码看起来跑得通，但充满了未声明的假设。

SDD 的关键点在于：规格文档对 AI 来说是一种结构化超级提示（super-prompt） 。它把一个大需求拆成了模块化的、符合 AI 上下文窗口限制的、可以精确消费的合同（contract）。arxiv 上一篇 2026 年初的学术论文（下文「交叉验证」部分）给出了量化数据：基于精炼规格工作时，LLM 生成代码的错误率降低最高可达 50%。

工作流全景：七步骤 + 核心命令

Spec Kit 将一次完整的功能开发切分为七个阶段，通过 specify-cli 初始化项目后，在任意支持斜杠命令的 AI Coding Agent（目前兼容 30+ 款，包括 GitHub Copilot、Claude Code、Codex CLI 等）中执行：

步骤	命令	作用
1. 项目原则	`/speckit.constitution`	定义代码质量标准、测试规范、风格约定等"宪法"
2. 写规格	`/speckit.specify`	用自然语言描述要建什么、为什么建（不涉及技术栈）
3. 澄清歧义	`/speckit.clarify`	主动询问未明确的边界条件（可选但强烈建议）
4. 写计划	`/speckit.plan`	给定技术栈，生成架构与实现方案
5. 拆任务	`/speckit.tasks`	把计划拆成可执行的任务列表
6. 执行实现	`/speckit.implement`	AI 按照任务列表逐步编码
7. 收敛校验	`/speckit.converge`	对比规格与当前代码库，找出遗漏的工作并追加任务

安装方式非常轻量，只依赖 uv：

bash 复制代码

# 安装 CLI
uv tool install specify-cli

初始化一个 Copilot 项目



specify init my-project --integration copilot
cd my-project



检查更新



specify self check



升级到最新版



specify self upgrade
`specify self upgrade
`

项目初始化后，Spec Kit 会在 .specify/ 目录下写入模板和配置，命令文件（如 .claude/commands/）在安装时写入 Agent 的专属目录。

可扩展性：不是一个封闭工具箱

Spec Kit 设计了四层优先级覆盖机制：

bash 复制代码

优先级 1（最高）：项目本地覆盖  .specify/templates/overrides/
优先级 2：Presets（改变流程行为，比如合规格式要求）
优先级 3：Extensions（新增能力，比如 Jira 集成、V-Model 测试追踪）
优先级 4（最低）：Spec Kit Core 内置命令

Extensions 用于扩展"能做什么"，Presets 用于定制"怎么做"------这个区分比较清晰，避免了混乱叠加。社区贡献的 Extensions/Presets 已经涵盖 Jira 集成、代码审查、项目健康诊断等场景。

交叉验证

信源一：arXiv 学术论文《Spec-Driven Development: From Code to Contract in the Age of AI Coding》（2026-01）

这篇论文从学术角度系统梳理了 SDD 的三个严格程度层次：

Spec-First（仅在初始开发阶段指导，之后可丢弃）
Spec-Anchored（规格与代码全程并行维护，自动测试强制对齐，BDD/OpenAPI 均属此类）
Spec-as-Source（人只编辑规格，代码全部机器生成，如汽车行业 Simulink）

论文与 Spec Kit 的观点高度一致，并补充了原文未强调的重要警示："规格错了，AI 会忠实地实现一个错误的东西" ------False Confidence 是 SDD 最危险的副作用，通过规格测试并不等于软件正确，因为规格本身需要和代码一样严格审查。该论文还引用了金融微服务案例，引入 OpenAPI + 合同测试后集成周期时间缩短 75%，数据具体可信。

信源二：Microsoft Developer Blog《Spec-Driven Development: A Spec-First Approach to AI-Native Engineering》（2026-06-10）

微软发布了官方背书文章，以甲方视角补充了 Spec Kit 所强调的工程视角之外的组织视角。微软识别出了四个"意义流失断层"：需求→架构→实现→验证，每一层都会丢失上下文，SDD 的价值在于为整个链路提供"连接组织"（connective tissue）。

微软还给出了一个落地数据：通过 SDD 将新资产类型的上线流程从2-3 周压缩到几天。

两个信源与原文的分歧主要体现在重心上：Spec Kit README 重在工具化操作，论文与微软更强调"规格本身也是需要治理的资产"------一旦忽视这点，SDD 可能变成另一种形式的文档主义泡沫。

个人启发：该怎么用这套东西

对独立开发者 ：Spec Kit 最直接的价值是防止自己和 AI "共同漫游"------每次开新功能前先跑 /speckit.specify，哪怕只是给自己写清楚，也能大幅减少"写到一半发现方向不对"的返工。

对团队工程师 ：/speckit.constitution 值得认真对待。把团队的测试标准、代码风格、架构边界一次性固化进去，之后每个 AI 生成的 PR 都在同一套约束下产出，Code Review 的摩擦会显著降低。

对技术决策者：SDD 不是"让 AI 替代工程师"的路线，是"把工程师精力前移到需求与架构阶段"的路线。如果你的团队正在引入 AI Coding Agent 却发现产出质量忽高忽低，根本原因大概率是输入侧的规格质量，而不是 AI 能力本身。

当前需要警惕的地方 ：Spec Kit 目前版本号仍在 v0.x，属于 Experimental 阶段，命令格式和模板结构可能发生 breaking change。现在用于探索和小团队试验是合适的，但大规模生产部署前需要评估升级成本。

局限与边界：不适用的场景

短期一次性原型：规格投入会被直接丢弃，ROI 很低；
高度探索性研究性编码：需求本来就是在写代码过程中被发现的，先写规格是强行拟合；
纯 CRUD 的简单应用：需求歧义极低，SDD 的收益不足以覆盖流程开销；
团队没有维护规格的纪律：SDD 最大的陷阱是"规格腐烂"------规格写了不更新，最终成为比没有规格更危险的误导文档。

延伸思考

"规格即制品"会不会产生新的技术债？ 代码层面的技术债已经有成熟的治理方法（重构、测试覆盖率等），但规格文档如何评估质量、如何度量"规格债"，目前工业界几乎没有成熟答案------这是 SDD 大规模落地前最需要解决的基础设施问题。
SDD 与 AI Agent 自主编码的张力 ------ 当 AI Agent 可以自主完成端到端任务时，"人写规格、AI 写代码"的分工会不会被"AI 自己写规格再自己验证"的闭环取代？Spec Kit 目前的 /speckit.converge 命令已经在做这个方向的探索，但人类监督的介入点在哪里是一个尚未收敛的开放问题。
SDD 在多 Agent 协作中的价值乘数效应 ------ 论文中提到规格文档可以让多个 AI Agent 并行处理互不重叠的任务。随着 MCP（Multi-Agent Coordination Protocol）类基础设施成熟，一份高质量规格被多个专业化 Agent（测试 Agent、安全审查 Agent、文档 Agent）同时消费的模式可能会成为主流------届时"规格质量"的权重会比今天高得多。

📚 参考来源

GitHub - github/spec-kit: 💫 Toolkit to help you get started with Spec-Driven Development · GitHub