GitHub 官方在 2025 年 8 月 21 日开了一个仓库，不到一年攒了 12.5 万颗星。它不造模型、不做编辑器、不提供云端 API，只干一件事：帮你在写代码之前，先把需求落成一份 spec（规格说明），再让 AI 按这份 spec 生成代码。这就是 github/spec-kit。截至 2026 年 8 月 1 日，仓库有 124,938 颗星、11,159 个 fork，主语言 Python，MIT 协议，创建于 2025 年 8 月 21 日，最近一次推送在 7 月 31 日。README 开篇一句话定调："Define what to build before building it - with any AI coding agent."--在动手构建之前，先定义要构建什么，跟你用的任何 AI coding agent 都能配合。GitHub 给它的定位是「Toolkit to help you get started with Spec-Driven Development」，topics 标签写着 ai、copilot、development、engineering、prd、spec、spec-driven，一看就是 GitHub 亲儿子。
解决什么问题：spec 和代码之间那道缝
写过软件的人都熟悉这个流程：产品经理写 PRD，架构师画设计文档，开发照着写代码，然后 PRD 过了两天就没人看了。spec-kit 的方法论文档 spec-driven.md 管这叫「权力结构」问题：几十年来 code 是 king，spec 只是脚手架，代码写完就扔。PRD 是"指导"，不是"源头"；设计文档是"参考"，不是"定义"。spec 和实现之间永远有一道缝。
spec-kit 的理念是反转这个权力结构：spec 不服务 code，code 服务 spec。PRD 不是实现的"指南"，而是生成的"源头"。spec-kit 做的事，就是把这套理念装进一个 CLI 工具加一组 slash 命令里，让 AI coding agent 按着 spec -> plan -> tasks -> implement 的链路走。它不是又一个 coding agent，而是给已有 agent 装上一套 spec 生产线。
核心机制：spec 变成可执行的
spec-kit 的核心主张是 spec 变成「可执行的」--不是挂在那看的文档，而是直接生成工作实现的源头。底层逻辑是：AI 已经能理解复杂 spec 了，但原始的 AI 生成没有结构就是一锅粥。SDD 提供结构：让 spec 足够精确、完整、无歧义，足以生成可工作的系统。spec 成为主要产物，code 是它在特定语言和框架下的表达式。维护软件变成维护 spec；调试变成修 spec。README 把哲学浓缩成四条：意图驱动（spec 定义"做什么"先于"怎么做"）、富 spec 创建（用护栏和组织原则）、多步迭代精炼（而非一锤子 prompt 出代码）、重度依赖 AI 模型能力解读 spec。spec-driven.md 还说此刻做这件事有三个理由：AI 能力到了临界点、软件复杂度指数级增长手动对齐越来越难、变化节奏加速让 pivot 成常态。
工作流拆解：从立宪到实现
spec-kit 的工作流靠一组 slash 命令串起来。先装 Specify CLI（uv tool install specify-cli，需 Python 3.11+ 和 uv），再 specify init my-project --integration copilot 初始化，--integration 指定你的 coding agent。进项目目录启动 agent 后，按顺序走：
第一步 /speckit.constitution（立宪）：给项目立治理原则和开发指南，后续所有开发受它约束。比如「代码质量、测试标准、用户体验一致性、性能要求」。
第二步 /speckit.specify（写 spec）：描述要构建什么，聚焦"做什么"和"为什么"，别管技术栈。比如「做一个按日期整理照片到相册的应用，可拖拽重排，相册不嵌套，平铺网格预览」。产出 PRD。
第三步 /speckit.plan（做计划）：给出技术栈和架构。比如「用 Vite，少依赖，原生 HTML/CSS/JS，图片不上传，元数据存本地 SQLite」。产出技术实现方案。
第四步 /speckit.tasks（拆任务）：从方案生成可执行任务清单。
第五步 /speckit.implement（实现）：按清单逐个执行。
两个可选步骤值得提：/speckit.clarify 在 plan 前跑，厘清 spec 里没说清的地方（前身叫 /quizme）；/speckit.analyze 在 tasks 后、implement 前跑，做跨产物一致性和覆盖率分析。后续还有 /speckit.taskstoissues 把任务转 GitHub issue，/speckit.converge 拿现有代码库跟 spec/plan 对照、把没做完的活追加为新任务（对付 brownfield 场景）。另有个 /speckit.checklist 生成自定义质量检查清单，README 管它叫"给英语写的单元测试"。核心命令七个：constitution、specify、plan、tasks、taskstoissues、implement、converge。
扩展体系：Extensions、Presets、Bundles 三层
spec-kit 还设计了三层扩展体系。Extensions（扩展）加新能力，比如 Jira 集成、实现后代码审查、V-Model 测试可追溯性。Presets（预设）改已有工作流的样式，比如把 spec 模板改成合规格式、用领域术语、加强制安全审查门、甚至本地化成另一种语言（README 提到有个海盗语演示预设）。Bundles（捆绑包）把扩展和预设打包成角色配置，一份 bundle.yml 清单给一个团队角色（产品经理、业务分析师、安全研究员、开发）一键配齐。
三层有个优先级栈，运行时从上到下解析：项目本地覆盖 > 预设 > 扩展 > 核心，第一个匹配的生效。这意味着不改核心代码就能做一次性调整、方法论级定制、加新阶段、给整个团队配齐。bundle 有四条保证：info 显示的就是 install 会装的；安装幂等且只动项目根目录；remove 不删别的 bundle 还在用的组件；所有命令支持离线。社区贡献页面分 extensions、presets、bundles、walkthroughs、friends 五类，欢迎社区扩展。
30+ agent 集成
spec-kit 跟 30 多个 AI coding agent 都能配合，包括 CLI 工具和 IDE 助手。跑 specify integration list 看当前版本支持哪些。大多数 agent 里命令暴露为 /speckit.* slash 命令；Codex CLI 的 skills 模式用 $speckit-*；GitHub Copilot CLI 用 /agents 选 agent。支持 skills 模式的 agent 传 --integration-options="--skills" 装成 agent skills 而不是 prompt 文件。好处是 spec 生产链路 agent 无关，从 Copilot 切到别的 agent，spec 和 plan 不用重写。Specify CLI 还内置自我管理：specify self check 查新版，specify self upgrade 直接升，--tag vX.Y.Z 钉版本。
三种开发阶段
spec-kit 把开发场景分三类。0-to-1（Greenfield）：从高层需求开始生成 spec、规划步骤、构建生产级应用。Creative Exploration：从同一份 spec 生成多个并行实现，比较哪个好，支持多技术栈和架构。Iterative Enhancement（Brownfield）：给已有项目加功能、现代化遗留系统，建议把工具升级和 feature 产物演化分开。背后是 spec-driven.md 的过程模型：开发不是线性 0->1->2->3，而是 0->1, (1'..), 2, 3, N--从同一份 spec 长出多个并行实现再迭代，spec 是源头，code 是表达式。
实验目标：GitHub 想验证什么
README 列了四组实验目标：技术无关性（验证 SDD 与特定技术栈无关）、企业约束（纳入组织约束和合规要求）、用户中心开发（从 vibe-coding 到 AI 原生开发）、创意与迭代流程（验证并行实现和迭代工作流）。GitHub 不是只做个脚手架，是在拿 spec-kit 当实验台，验证 spec 驱动开发能不能成为通用工程范式。
和 superpowers 的对比：spec 生产线 vs 工作纪律
本站已有 obra/superpowers 的盘点（264K 星）。两者都管 coding agent 行为，但定位不同。spec-kit 偏「spec 生成脚手架 + GitHub 官方」，重心在前端：怎么把模糊想法落成 PRD，怎么生成技术方案，怎么拆任务，有 Extensions/Presets/Bundles 三层定制体系，跟 Copilot 天然咬合，30+ agent 通吃。superpowers 偏「agent 工作纪律 + 技能自动触发」，重心在执行端：TDD 强制走 RED-GREEN-REFACTOR、subagent 派发、两阶段代码审查、git worktree 隔离，跨 11 个平台。一个管"开工前把需求想清楚"，一个管"开工后按纪律执行"。理想情况两个可以叠加：spec-kit 管 constitution -> specify -> plan -> tasks，superpowers 管 implement 阶段。但实际叠加能不能跑通要看 slash 命令和 skills 机制有没有冲突，需要实测别假设。生态策略也不同：spec-kit 有三层扩展加社区贡献页面，欢迎社区扩展；superpowers 明确说"通常不接受新技能贡献"，宁缺毋滥。
和本站的呼应：我们也用了 /spec
做这个网站（aiwebcool.com）时，项目内嵌了同样的 agent-skills 机制，DEV.md 里写着 /spec（spec-driven-development）命令负责把构架文档落成正式 PRD。项目起步就是先跑 /spec，经 AskUserQuestion 对齐四项决策，再生成 PRD 覆盖六大区块。这跟 spec-kit 的 /speckit.specify 是同一个理念：在写代码前先把需求落成 spec。区别是 spec-kit 做成了跨 30+ agent 的通用工具包，我们的 /spec 只是项目内一个 skill 命令。读到 spec-kit 的 constitution -> specify -> plan -> tasks -> implement 链路时，最大的感受是"原来这套 spec 生产线可以系统化到这个程度"。
适合谁，注意什么
适合：天天用 coding agent 但总在需求理解上跑偏的开发者；想给团队定统一 spec 流程的技术负责人；做从零开始项目想结构化需求的团队；在用 Copilot 生态的。
注意四点。一需 Python 3.11+ 和 uv，不是装个插件就完事，有 CLI 安装步骤。二价值取决于你愿不愿意在 constitution 和 specify 阶段花时间--spec 糊弄后面全糊弄，垃圾进垃圾出。三 30+ agent 集成成熟度不一样，README 自己说"遇到问题请开 issue 让我们改进集成"，有些还在路上。四 MIT 免费，但 coding agent 订阅费另算，spec-kit 省的是返工和需求扯皮时间。
背后的人
README 的 Acknowledgements 写着项目受 John Lam（GitHub: jflam）的工作和研究影响。spec-kit 是 GitHub 官方项目，仓库在 github/ 组织下，有官方文档站和视频概览。商业上 spec-kit 本身 MIT 免费，是 GitHub 生态一环--GitHub 卖 Copilot 订阅和企业版，spec-kit 是让这类工具更好用的基础设施，把 spec 做对，下游 code 生成质量才上得去。
spec-kit 不复杂--没有模型参数，不提供 API。它做的事是把"先定义要构建什么再构建它"变成一条 spec -> plan -> tasks -> implement 的可执行流水线，跟任何 coding agent 都能配合。12.5 万颗星的背后，是被需求跑偏折腾过的人发现"把 spec 做对"比"换个更强的模型"更值钱。
参考来源
- spec-kit GitHub 仓库（124,938 star / 11,159 fork，Python，MIT）：https://github.com/github/spec-kit
- README 原文（定位、工作流、扩展体系、集成列表）：https://github.com/github/spec-kit/blob/main/README.md
- Spec-Driven Development 方法论文档（权力反转、SDD 工作流）：https://github.com/github/spec-kit/blob/main/spec-driven.md
- 官方文档站（集成参考、扩展、预设、bundle 指南）：https://github.github.io/spec-kit/
- GitHub API 直核（star/fork/语言/许可证/创建日/最近 push，api.github.com/repos/github/spec-kit）