📐编写规格，而非代码 · 用 GitHub Spec Kit 实现规格驱动开发

那个时刻 · 当「告诉它你想要什么」不再够用

一开始 vibe coding 很神奇。你跟 AI 说话，出现一个界面，能跑，你鼓掌。但会到达一个点——几乎总是在第五或第六个功能左右——魔法破灭了。你要求一个小改动，结果一个你没碰过的东西崩了。你第三次跟它解释登录该怎么工作 「因为它忘了」。你第二天打开项目，连自己都不知道一半的文件为什么存在。那就是那个时刻：当对话不再足以作为真相来源，而你需要比一个记忆像金鱼一样的聊天更坚实的东西。

Spec-Driven Development（规格驱动开发，即 SDD）正是诞生于此。这个想法简单到几乎冒犯人：在 AI 写下一行代码之前，你先写下应用应该做什么——清晰、有条理，并保存在一个文件里。那份文档，即 spec，成为唯一的真相来源。智能体则从它出发，生成一个计划 → 一份任务清单 → 代码。就按这个顺序。中间穿插着你的检查点。

那个痛点 · 科学怪人从哪里来

问题不是 AI 笨。而是AI 没有意图的记忆。在每条消息里它都为 那条消息 做出最佳决定，却没有一幅关于你在构建什么、为什么构建的完整图景。你脑子里有那幅图景——但脑子不是智能体能读取的文档。所以 AI 靠猜来填空，而且每次猜得都不一样。有一次购物车保存了税，另一次却没有。有一次用户可以编辑自己的资料，另一次这个功能在一次重构中消失了。没有人撒谎：只是从来就没有存在过一份说明什么才是正确的合同。

如果你不解决这个问题会怎样？不是世界末日——是一场缓慢的事故。你最终得到一个 几乎 能跑的应用，无法向另一个人（或者下周的 AI）解释清楚，每次修补都有它自己弄坏别的东西的概率。而这些概率不会宽容你：在这同一系列的一篇博客里我们讲过 27% 的数学 ——一个每一步都有 85% 命中率的智能体，只有 27% 的概率完成一个八步的流程（0.85⁸），因为命中率是相乘的，不是相加的。盲目构建同样地把脆弱的步骤串在一起。规格正是打破这条脆弱链条的东西：它给 AI 一个固定的点，让它对照着验证每一步，而不是让每一步都依赖上一步的运气。

解决办法 · 把顺序反过来（先规格，后代码）

在 vibe coding 里流程是：说话 → 代码 →（有时候）写文档。在 SDD 里它被完全反了过来：编写规格 → 计划 → 生成任务 → 代码。文档不再是最后被遗忘的残余，而成了 起点。而且这不是官僚流程：每一个阶段都是智能体从上一个阶段几乎自动生成的产物，中间有一个你的检查点让你在继续前批准。你指挥；AI 执行。

那个工具 · GitHub Spec Kit

你不必手动发明这套流程。GitHub Spec Kit 是一个 open source 工具包——出自 GitHub，免费，MIT 许可——它把 SDD 作为一系列命令安装进你的 AI 智能体里。你用自然语言编写规格；它给你结构、检查点和命令，好让 AI 把它变成应用。它是增长最快的 AI 工具之一：GitHub 上 122,000 颗星，其最新稳定版本 v0.13.0 于 2026 年 7 月 17 日 发布。它集成了 30 多个智能体——Claude Code、GitHub Copilot、Cursor、Gemini CLI 以及你用的那个。

安装 · 两条命令你就进去了

Spec Kit 用 uv 安装，那是现代的 Python 包管理器（快，不折腾）。如果你没有 uv，先装它——一行。然后持久化地安装 Spec Kit 的 CLI，并选择你的智能体来初始化你的项目。别被终端吓到：就是这几条命令，按顺序来，而且真正的工作里你不用再碰它（真正的工作在你 AI 的聊天里进行）。

# 1) 如果你没有 uv（Python 的包管理器），先装它：
curl -LsSf https://astral.sh/uv/install.sh | sh

# 2) 持久化地安装 Spec Kit 的 CLI（固定到稳定版本）：
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@v0.13.0

# 3) 看看你可以选哪些智能体（--integration 这个 flag 的确切取值）：
specify integration list

# 4) 选择你的智能体来初始化你的项目（这里用 Copilot 作为例子）：
specify init mi-proyecto --integration copilot

# 5) 检查有没有更新的版本（不改任何东西，只读取）：
specify self check

这个协议 · Spec Kit 的命令，按顺序

一旦初始化完成，Spec Kit 给你一系列 slash commands，你在你的智能体里输入它们。它们不神奇：每一个都请求 AI 生成流程里的下一个产物。顺序很重要——这是一条级联，每一步都依托于上一步。这些是真实的命令，正如 v0.13.0 里的样子：

真实的流程 · 4 个阶段，穿插着你的检查点

把一切拼起来，一个项目从头到尾就是这个样子。注意在每一个边界上 你都审查并批准 才让 AI 前进。这就是诀窍：不是 AI 毫无制动地独自工作，而是它 在你控制的检查点之间 独自工作。

这个习惯 · 什么时候写规格，什么时候不写

SDD 不是万事皆用。一行的改动、一个按钮的颜色、一段文字——那些你正常跟 AI 说就行了。为那些写一份规格，就像为了挂一幅画去请建筑师画图纸。好的习惯是认出 那个门槛：在一个任务触及 多于一个文件、有业务规则、或者你下周还会回来碰它 的那一刻——那时候，先写规格。从那以后，每一个大的新功能都诞生于一份规格，而不是一时冲动。

那个主提示词 · 以 spec-first 启动一个项目

这里是你唯一需要记住的提示词。就是你交给你的 AI（Spec Kit 已初始化）的那一个，用来从第一分钟就开好头：它要求 AI 先定下宪法，然后跟你一起构建规格、缺什么就问，而且在你批准之前不写代码。复制它，填好 [方括号]，在启动任何认真的项目时把它粘给你的智能体。

我们要用 Spec-Driven Development 来构建这个项目，使用 GitHub Spec Kit，它已经初始化好了。先不要写代码。跟着我走这个流程，在每一个检查点停下来，等我批准了再前进。

我的项目是：[用 3-5 句话描述你想构建什么、给谁用]。
它不该做什么 / 我的界限：[例如 不保存信用卡、要能在手机上运行、日志里不放敏感数据]。

第 1 步 — 宪法。首先，跑 /speckit.constitution 并提出这个项目不可违背的原则（安全、输入验证、一致性，以及任何适用的）。把它们展示给我，等我点头。

第 2 步 — 规格。然后跑 /speckit.specify，根据我的描述起草规格：清晰的需求和用户故事。之后跑 /speckit.clarify，把消除含糊所需的所有问题都问我——不要猜，问我。在我说规格没问题之前不要继续。

第 3 步 — 计划和任务。规格获批后，跑 /speckit.plan 并提出技术栈和架构（用大白话跟我解释你为什么选每一样）。然后 /speckit.tasks 做分解，再 /speckit.analyze 验证规格、计划和任务不互相矛盾。把这一切展示给我，等我批准。

第 4 步 — 实现。只有在我授权时，才跑 /speckit.implement 并构建。完成后，生成一份 /speckit.checklist，验证构建出来的东西满足规格。

整个过程的黄金规则：规格是唯一的真相来源。如果代码里有什么偏离了规格，规格说了算——或者你提醒我，我们一起更新它。永远不要悄无声息地改变行为。

最省事的路径 · 哪些用聊天做，哪些用命令做

为了让你不迷路：几乎一切都发生在 跟你的 AI 说话 里。终端你只碰一次（安装并初始化）。那些 /speckit.* 你在你智能体的聊天里输入，就像任何别的消息一样。而规格你用自己的话来写——不是用代码。这就是分工：

这一切从何而来（这个系列的演进）

如果你一直跟着这个资料库，这对你不新鲜——它是下一个台阶。C-A-R 协议 教你把构建和审计分开，好不把 bug 发出去。设计系统 那份资源教你在第一个界面 之前 定下视觉规则。两者共享同一个想法：在执行之前决定合同。 SDD 把这个想法带到最纯粹的形式：规格就是合同，而且它是 整个 应用的唯一真相来源——设计、逻辑、行为。你从 「组织好你的上下文」 走向 「写好合同，让 AI 去履行它」。