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：
# 安装 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 设计了四层优先级覆盖机制：
优先级 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）同时消费的模式可能会成为主流——届时"规格质量"的权重会比今天高得多。
📚 参考来源
