先说一件让人沉默了整整五秒的事

2026年4月底，一个GitHub仓库突然刷屏了。

发布方是GitHub官方组织账号，名字叫spec-kit。副标题写着：让你专注于产品场景和可预期结果，而不是从头vibe coding每一块。

再看一眼数据：⭐ 98,500 Stars | ? 8,600 Forks | ? 144个发布版本 | ? 955次提交 | ? 30+支持的AI工具。

看到那句副标题的时候，很多人可能都和我一样，愣了好几秒。不是因为这个数字有多夸张（虽然确实很夸张），而是因为GitHub官方亲自下场，对着整个AI编程社区喊了一句：“停止vibe coding！”

这件事，值得单独开一篇聊一聊。

"vibe coding"是什么，为什么GitHub觉得它有问题？

如果你这半年一直在用AI编程工具，大概率经历过这种场景：

打开Claude Code（或者Cursor，或者其他你喜欢的工具），输入“帮我做一个用户管理系统，支持注册登录，有权限分组”。AI开始写，你在旁边盯着，偶尔说“这里改一下”、“加个功能”、“不对不对回滚”。

半小时后，你得到了一堆代码。但你心里却冒出好几个问号：这个系统的数据库设计是怎么考虑的？不知道。异常处理的策略是什么？看心情。如果下周另一个AI来继续这个项目，它接得上吗？大概率不行。你能向老板解释这套架构的设计决策吗？……你在想什么呢。

这种“感觉不错就这么干”的编程方式，就是vibe coding。它在原型阶段确实很好用，但一旦上了生产环境，分分钟变成定时冲击波。

Spec-Driven Development：把规范从“脚手架”变成“发动机”

spec-kit 的核心思路，其实一句话就能说清楚：规范驱动开发翻转了传统开发的逻辑。规范不再是你写完就扔掉的脚手架，而是变成可执行的、直接驱动实现的核心产物。

具体来说，在传统流程里，写PRD→评审PRD→丢开PRD→开始coding，PRD在第一行代码落下的那一刻就开始腐烂。而在SDD流程里，写spec→spec驱动plan→plan驱动tasks→tasks驱动implement，规范文件全程活着，可以被版本控制、被任何AI工具读取、被下一个接手的人理解。

这不是理论，这就是spec-kit这套工具实际的工作方式。

七个命令，从0到产品

spec-kit 把整个开发流程拆成六个核心命令加两个可选命令：

第一步：/speckit.constitution— 给AI立宪法

这是整个流程里最容易被低估的命令。执行之后，它会创建.specify/memory/constitution.md，里面是你这个项目的“治理原则”：比如要求代码质量、测试标准、用户体验一致性、性能要求等等。

这个文件会被后续所有步骤引用。如果你在plan阶段Claude Code突然想加一个你没要求的功能，你只需要说一句“检查一下这个是否符合constitution”，它就会自己审查自己。这解决了一个非常头疼的问题：AI喜欢过度工程化（over-engineer），你要什么它给你三倍，然后你花时间删。有了constitution，你可以在里面写“遵循最小实现原则”，它就真的不会乱加东西了（大多数时候）。

第二步：/speckit.specify— 说你要什么，别说怎么做

这一步的关键是：只描述“什么”和“为什么”，完全不提技术栈。比如“帮我做一个能按相册分类整理照片的应用”，把业务需求说清楚，用户故事写完整，但绝不说“用什么框架”、“选什么数据库”。这一步产出的是spec.md，里面是结构化的需求文档，还有Review & Acceptance Checklist。

为什么不能在这一步说技术栈？因为一旦你说了“用React”，AI会把所有决策都往React上靠，而不是先问清楚需求再选择最合适的技术。

第三步：/speckit.clarify— 不要跳过这一步

这是optional但强烈建议的命令，必须在plan之前运行。它会做覆盖式、系统性的问题追问，记录在spec的Clarifications区。意义在于：提前消除歧义，减少下游返工。没有这一步，你的plan可能基于你以为你想要的东西生成的，而不是你真正想要的东西。这跟在金融系统做需求分析是一个道理——澄清不清楚，你永远都在改代码。

第四步：/speckit.plan— 现在才说技术栈

到了这一步，终于可以决定技术栈了。它会生成一套详细的实现计划文档，包括plan.md（主实现计划）、contracts/api-spec.json（API规范）、data-model.md（数据模型）、research.md（技术栈研究）、quickstart.md（快速上手指南）。如果你用的是快速迭代中的框架（比如.NET Aspire、最新的Next.js），还可以让AI专门做针对性研究，避免用了已经过时的API。

第五步：/speckit.tasks— 任务清单自动生成

生成tasks.md，包含按用户故事组织的任务分解、依赖管理（先做模型再做服务，先做服务再做API）、并行任务标记（[P]标注可以并行执行的任务）、每个任务的精确文件路径、TDD结构（如果你要求写测试，测试任务会在实现任务之前），以及每个用户故事完成后的Checkpoint验证。

第六步（可选）：/speckit.analyze— 交叉一致性检查

在tasks生成之后、implement之前运行。做跨文件的一致性和覆盖率分析，确保任务清单没有遗漏任何需求点。

第七步：/speckit.implement— 执行

这一步会验证所有前置条件（constitution、spec、plan、tasks都存在），按正确顺序执行任务，尊重依赖关系，跟踪进度，处理错误。执行完之后，你应该有一个可以运行的应用，而不只是一堆代码文件。

安装和初始化：真的不复杂

# 推荐方式：用uv安装（需要先装uv）
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@v0.8.9

# 验证安装
specify version

# 在新项目里初始化（Claude Code集成）
specify init my-project --integration claude

# 在已有项目里初始化
specify init . --integration claude
# 或者
specify init --here --integration claude

初始化完成后，启动你的AI编程工具，如果看到/speckit.constitution、/speckit.specify、/speckit.plan等命令可用，就说明配置好了。对于Claude Code用户，这些命令会出现在斜杠命令列表里。

扩展生态：这才是项目真正的价值所在

截至2026年5月15日，community extensions目录里已经有75+个社区扩展，覆盖五大类别：

有几个扩展特别值得一提：

MAQA（多Agent + QA） — 协调者Agent→功能实现Agent→QA Agent的三层架构，基于worktree并行执行，有CI门控，还整合了GitHub Projects、Jira、Linear、Trello等看板工具。这基本上就是一个完整的AI团队。

Red Team扩展 — 在/speckit.plan之前运行，用对抗性的视角审查规范，找出prompt injection风险、完整性缺口、跨spec漂移、无声失败……这是安全工程师的思维在spec审查里的体现，设计理念很值得参考。

Cost Tracker — 追踪每个SDD工作流的实际LLM成本，支持按功能预算、按集成工具对比，还能导出财务报告。对于需要对AI开发成本负责的团队来说，这是一个非常务实的工具。

Brownfield Bootstrap — 为现有代码库引导spec-kit，自动发现架构并增量采用SDD。这解决了一个实际问题：你不可能为一个已经有10万行代码的项目从头写规范，但可以逐步引入。

预设系统（Presets）：改变规范的“语言”

这是很多人没注意到的功能，但实际上非常有趣。Presets可以在不改变工具能力的情况下，改变spec-kit生成的所有文档的格式、术语和规范。举例来说：把spec模板改成符合某个金融监管框架要求的格式（可追溯性、合规性字段），把整个工作流切换到中文（有人已经做了中文预设），强制所有plan必须有安全审查门控，适配Agile/Kanban/Waterfall不同的项目管理方法论，甚至还有最离谱的示范：pirate-speak预设——把所有输出改成海盗腔。

这个预设系统的设计有点像CSS的层叠机制——有明确的优先级，高优先级覆盖低优先级，多个预设可以叠加。

深度测评：用它做了什么，发现了什么

作为一个同时做金融系统和AI工程的人，有几个非常具体的感受：

真正解决了上下文丢失的问题

这是用spec-kit之前最大的痛点：今天做了这些决策，明天开新会话，AI全忘了。CLAUDE.md会随着spec-kit的流程自动更新，包含最新的项目状态。下次启动Claude Code，它会读CLAUDE.md，知道“我们现在在哪里，做了什么决定，下一步要干什么”。
这个设计和claude-mem的思路不同——claude-mem是通过hook自动学习，spec-kit是通过结构化的spec artifacts主动维护上下文。两者可以共存，但spec-kit的方式对于多人协作更友好，因为spec文件是可以review的。

AI真的不再乱加东西了

在constitution里加了“最小化依赖原则”和“不得添加需求文档中未明确要求的功能”之后，让它做一个REST API服务。它真的没有自己加Redis缓存、没有加Prometheus监控、没有加swagger-ui……这在之前是不可能的，Claude Code会非常热情地“帮你想到”这些东西。

学习曲线：有，但不陡

如果完全没用过，从零上手大概需要：30分钟理解SDD理念，装好specify-cli；1小时完整跑一遍7步流程，做一个小项目；1-2天真正内化工作流，开始感受到效率提升。对比一下，从零开始配置everything-claude-code大概需要2-4小时，claude-mem大概需要30分钟。spec-kit在复杂度上居中，但带来的工程化价值要大很多。

坑：AI有时候还是会过度投入

README自己承认了：Claude Code can be over-eager and add components you did not ask for. 一个具体建议：生成plan之后，专门跑一次“找过度工程化”的prompt：“Go through the implementation plan and identify any components that seem over-engineered or that weren't explicitly requested in the spec.”这一步能帮你在执行前删掉很多没必要的复杂性。

和其他工具相比如何？

这几个工具之间不是竞争关系，而是不同层次的解决方案。spec-kit解决的是“如何把项目开发流程工程化”，其他工具解决的是“如何让AI工具本身更好用”。实际工作流里，可以叠在一起用：spec-kit作为规范驱动的功能开发框架，claude-mem补充跨会话记忆，Claude Code CLI作为执行层，配everything-claude-code里的Hook和MCP。

给不同人群的具体建议

如果你是独立开发者，在做个人项目：spec-kit最适合的场景是“我有一个完整的功能要从头实现”。不需要用它来修一个bug，但做大创、做毕业设计、做SaaS产品，spec-kit会让你少走很多弯路。最小化采用路径：只用constitution + specify + plan + implement四个命令，暂时跳过clarify、analyze和扩展。等你熟悉基础流程再加东西。

如果你在团队里：spec文件天生是可以被review的——它就是Markdown，可以开PR。你可以在plan.md阶段做技术评审，在spec.md阶段做需求评审，这和现有的code review流程完全兼容。搭配GitHub Issues集成扩展（/speckit.taskstoissues命令），可以把生成的任务清单直接同步成GitHub Issues，进入你们现有的项目管理系统。

如果你是金融/医疗/法律等强合规行业的开发者：这里Presets系统的价值最大。你可以定制一套强制包含合规字段（如可追溯性、数据分类、风险等级）的spec模板，让所有用这套工具的人自然地输出符合合规要求的文档。

98.5k Star：值不值这个数字？

这是GitHub官方账号发布的项目，背后有组织信用背书，不存在刷星的动机。Fork/Star比值8600/98500≈8.7%，在这个量级的项目里是健康的，意味着有实质性的采用，而不只是收藏。144个版本、955次提交，说明这是活跃维护中的项目，而不是一次性发布就跑路的。75+社区扩展是最重要的信号——这些扩展是独立开发者自己做的，说明有真实的用户群体在认真使用，并且觉得它值得投入时间扩展。

判断是：98.5k实至名归，甚至还会继续涨。因为它解决的问题不会消失——只要还有人在用AI工具开发软件，就会有人被vibe coding坑，就会有人想要找到一种更系统、更可预期的方式。

最后说一件有趣的事

spec-kit的README里有一句话让人会心一笑：“规范驱动开发是一个过程，不依赖于具体的技术、编程语言或框架。”然后它的支持列表里有30+个AI工具：Copilot、Gemini、Claude Code、Cursor、Codex、Qwen……

所以spec-kit的野心是：不管你用什么AI工具，都可以用这套方法论来工程化你的开发流程。这是一个非常务实的定位。AI工具会变，模型会升级，今天的Claude 3明天可能就被Claude 4替代，但“先写规范、规范驱动实现”这个理念不会过时。

就像不管你用什么编程语言，单元测试的理念不会过时一样。

这才是spec-kit真正的护城河。