8 月 21 日，GitHub Spec Kit 满一岁并发布 1.0.0。它的第一个 commit 是 2025 年 8 月 21 日由 Den Delimarsky 和 John Lam 提交的；一年后，仓库超过 13 万 star、150 多个社区扩展、30 多个预设，支持 35 种以上 coding agent。[3][2] 一个主张”先写文档再写代码”的工具能火成这样，说明受够了纯 vibe coding 的人比想象中多。

Spec Kit 要解决的失败模式很具体。Delimarsky 在发布博客里说：“问题不在 coding agent 的编码能力，而在我们的用法。我们把 coding agent 当搜索引擎用，其实它们更像字面意义的结对程序员。“[4] 你给一句模糊需求，agent 就自信地猜一个实现，代码看起来合理，方向却可能完全不对。Spec Kit 的思路是把”猜”换成”规格”：规格成为可执行的契约，代码只是它的编译产物。[2]

核心循环是 constitution → specify → plan → tasks → implement → converge。[2] 每个阶段产出一个 Markdown 产物，喂给下一阶段；规则是当前阶段没验证完，就不进下一个。[1] specify 只谈做什么、为什么，不碰技术栈；plan 才谈架构与约束，公司统一的技术选型在这里说清楚；tasks 把计划拆成能独立实现和测试的小块，比如”创建校验邮箱格式的用户注册端点”，而不是”做认证”。[1] 实现阶段你审的是聚焦的小改动，不是上千行的代码转储。[1] 规格本身是活文档，随着你对用户和需求的理解加深而演化；plan 也允许你换栈，比如开发用 SQLite、测试换 MySQL、部署再切 Azure SQL，规格和任务不用重写。[4]

最容易被忽略的是最后一步 converge。实现完后，agent 要对照规格、计划和任务清单逐项收敛，报告 Converged 才算完成；不收敛就回到 implement 继续，两个命令交替跑。[2] 这套循环把”完成”从感觉变成可检查的状态，跟单元测试断言一样明确。

最先值得抄的是 constitution。它是项目的”不可谈判原则”，相当于把团队既有架构标准固化成文字，agent 每一轮都要遵守。[4][5] Delimarsky 自己的例子是”静态网站、最小依赖、无外部服务、内容用 Markdown、数据用 JSON”这种约束，写进去之后 agent 就不会随手给你引数据库或上后端。[6] 后续所有命令都会回指这份文件，比 AGENTS.md 里零散的规则更系统。[6] 它跟传统 PRD 的区别在于：SDD 不是瀑布式的预测未来，而是把技术决策变得显式、可评审、可演进，官方博客的原话是”给思考做版本控制”。[5]

除了主干命令，还有三个命令值得单独说。specify 之后可以跑 clarify，让 agent 就规格里的歧义向你提问，而不是带着疑问往下走。[6] plan 之后有 checklist，它的定位是”给英文写单元测试”：检查规格在 UX、安全、无障碍这些维度有没有盲区。[6] tasks 之后有 analyze，扫描规格、计划和任务三者是否一致、是否都映射到 constitution。[6] 我试下来，这三步各花几分钟，能把后面 implement 的返工省掉一大截。

两个扩展机制也实用。bug 扩展把修 bug 拆成 assess → fix → test 三段：先验证诊断，再改代码，最后确认修复真的消除了原始症状，每段都留证据。[2] 评估新想法时可以用 assess 扩展，走 intake → research → define → shape → decide，最终给 go、needs-clarification 或 kill 三选一，避免为没想清楚的想法直接开写。[2] 另外，基座提示词里有个 [NEEDS CLARIFICATION] 标记：某个函数实现不了就插入这个标记并附上问题，而不是自己编一个假设；提示词还包含检查该标记的步骤，防止前面标记的问题被跳过。[4]

快速上手#

安装只需两条命令，用的是 uv：

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

然后在你常用的 agent 里依次跑 /speckit-constitution、/speckit-specify、/speckit-plan、/speckit-tasks、/speckit-implement、/speckit-converge。[2] 想先试试的话，也可以不安装，直接一行 uvx 跑完初始化。[1][5] CLI 本身只是把模板和提示词下载进项目，生成 .github 和 .specify 两个目录；不用它、手动从 Releases 下载解压也行。[5][6] 已有项目不用推倒重来：工具文件升级和 specs/ 产物分开维护，只有行为变化才更新 specs/。[2] 官方说这套流程支持 Copilot、Claude Code 和 Gemini CLI，选你已经在用的那个即可。[1]

它不解决所有问题。Delimarsky 自己说 specs 不是万灵药，人在环里依然重要；Mitchell Hashimoto 也观察过 agent 需要监督，放手跑容易跑偏。[6] 实现阶段通常要多轮迭代，需要管理员权限的安装它不会替你执行，会停下来等你手动完成再继续。[4] 维护者给 1.0.0 定的调子也值得记住：版本号”只是个数字”，当 agent 让改造成本急剧下降时，价值从稳定性转向可适应性，所以别指望这套流程一成不变。[3] 探索原型阶段，纯 vibe coding 仍然更快；等东西要进生产、要多人接手时再切规格驱动。Delimarsky 用这套方法把一个搁置一年的项目从想法做到能用的应用，只花了不到两小时；规格最大的价值不是文档本身，而是把”开发者意图”到”产出”之间的猜测空间压缩掉。[6]

Sources#

[1] https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit [2] https://github.com/github/spec-kit [3] https://www.manorrock.com/blog/2026/08/21/spec_kit_turns_one.html [4] https://www.infoworld.com/article/4062524/spec-driven-ai-coding-with-githubs-spec-kit.html [5] https://developer.microsoft.com/blog/spec-driven-development-spec-kit [6] https://den.dev/blog/github-spec-kit