夜雨聆风6 月 27 日，一条西班牙语推文在开发者圈子里炸开了锅。
标题简单粗暴，全大写："GITHUB 刚刚解决了 VIBE CODING 最大的问题。"
24 小时内，9.3 万次浏览，1300 多个赞，97 次转发。评论区西班牙语、英语、中文、日语、土耳其语混成一团。所有人都在说同一件事——
终于有人给这辆失控的车装刹车了。
▲ @zaynmcps 的病毒帖，9.3 万浏览、1.3k 赞。标题直译：GitHub 刚刚解决了 vibe coding 最大的问题
这条帖子指向的项目叫Spec Kit，GitHub 官方出品，开源，MIT 协议。仓库星标此刻已经飙到11.6 万。
一个"写规格"的工具，凭什么让全球开发者集体失控？
答案藏在每个用 AI 写过代码的人最深的伤疤里。
所有用 AI 写代码的人，都被坑过
场景太熟悉了。
打开 Cursor，或者 Claude Code，输入一段 prompt：「帮我做一个相册 App，支持拖拽排序，按日期分组，本地用 SQLite。」
AI 立刻开始输出。React + Tailwind + 一堆你没听过的库，几十秒钟，一千多行代码砸到你面前。跑起来一看——哇，像模像样。
然后噩梦开始了。
没有图片的时候，页面直接白屏。拖拽到边界，整个列表崩溃。你说过要极简 vanilla，它还是偷偷塞了 Redux。两周后产品经理改了一个小需求，你发现代码已经锁死在某个架构决策里，改不动了。重构成本比从头写还高。
看起来对，离你的真实需求还差一截。
这种体验有个名字，叫vibe coding——扔给 AI 一个模糊的意图，祈祷它能猜对，然后花几个小时修补它猜错的地方。
GitHub 官方博客里对这个现象的诊断相当精准：
"You describe your goal, get a block of code back, and often... it looks right, but doesn't quite work."
「你描述了目标，拿回来一坨代码，通常……看起来对，但就是不太行。」
问题出在哪？LLM 擅长模式补全，但它不会读心。你给的 prompt 越模糊，它脑补的空间越大，脑补错的概率也越高。传统的 PRD 和设计文档写完就扔，代码成了唯一的"真相"，而你最初的意图在一轮轮迭代中逐渐漂移，直到面目全非。
▲ GitHub 官方博客 2025 年 9 月发文，标题直指 vibe coding 痛点
GitHub 的答案：先把意图锁死，AI 才准动手
2025 年 9 月 2 日，GitHub 悄悄发了一篇博文，标题叫《Spec-driven development with AI》。同一天，一个叫github/spec-kit的仓库上线。
没有大张旗鼓的发布会，没有铺天盖地的 PR 稿。就一篇博客，一个 repo。
但它提出的核心理念击中了所有人的痛点：在让 AI 写一行代码之前，先用结构化的规格把你的意图锁死。
具体怎么做？六个 slash 命令，一条完整的流水线：
/speckit.constitution→ 先定项目"宪法"。哪些原则不可违反？测试优先还是功能优先？用什么技术栈？这些规矩一旦定下来，AI 必须遵守，不能擅自发挥。
/speckit.specify→ 你来描述你要什么（what）和为什么要（why），AI 帮你生成结构化的 spec.md。注意，这一步只准写需求，禁止碰实现细节。遇到说不清的地方，AI 会自动标上[NEEDS CLARIFICATION]——逼你想清楚再往下走。
/speckit.clarify→ AI 主动向你提问，把那些模糊地带一个个澄清，记录下来。
/speckit.plan→ 规格锁定后，AI 生成技术方案：plan.md、research.md、数据模型、API 合约、快速上手指南，一整套。
/speckit.tasks→ 从方案里拆出带依赖关系的任务列表，标注哪些可以并行，严格按 TDD 顺序——先写测试，再写实现。
/speckit.implement→ AI 逐个任务执行，每次只改一小块，人类 review 小变更。
整套流程下来，AI 的角色从"自由发挥的创意写手"变成了"严格按契约施工的工程师"。你交给它的东西，从一句模糊的愿望，变成了一份有约束力的合同。
九条「宪法」，条条都是血泪教训
Spec Kit 里最狠的设计是Constitution——项目宪法。
这份宪法写在.specify/memory/constitution.md里，由 9 条 Article 组成，每一条都像是从无数次踩坑里提炼出来的教训：
Article I 库优先：所有新功能必须先抽象成可复用的库，然后才集成进应用。逼你从一开始就考虑架构。
Article III 测试优先：先写失败的测试，等你确认"Red 状态"之后，AI 才能开始写实现代码。没有商量余地。
Article VII 简洁门：初始实现最多 3 个项目，禁止"过度未来证明"。
Article VIII 反抽象门：直接用框架提供的能力，别再自己包一层。
Article IX 集成优先测试：用真数据库、真服务跑测试，合约测试先行。
这些规矩看起来严苛，但每一条都在解决同一个问题——防止 AI 过度发挥。
LLM 的毛病大家都知道：你给它自由度，它就会开始"创作"。多加一层抽象，多引入一个依赖，多写一段"以防万一"的代码。宪法系统就是一道道门禁，把 AI 的创造力约束在你划定的边界内。
规格模板的设计也很讲究。Spec 模板只允许写 WHAT 和 WHY，明确禁止出现 HOW——你不能在需求文档里偷塞实现细节。还有强制的 checklist 自检、Phase-1 门禁、复杂度追踪……每一步都有检查点，每一步都要你签字确认。
改需求的时候怎么办？改 spec，重新 plan，重新 tasks，重新 implement。几分钟的事。因为规格是"活的"，所有下游制品都从规格自动生成，变更成本从"推倒重来"降到了"编辑一段文字"。
▲ github/spec-kit 仓库：116k 星、10.2k fork、247 位贡献者、174 个 release
11.6 万颗星背后，藏着一场「静默革命」
数字很能说明问题。
116000+ 星标。10200+ fork。247 位贡献者。174 个版本发布。社区贡献了 105 个扩展、22 个预设配置、4 套角色 bundle（产品经理、业务分析师、安全工程师、开发者各一套）。
兼容 30 多个 AI 代理——Claude Code、Cursor、GitHub Copilot、Gemini CLI，几乎涵盖了主流的所有选择。
但真正让这些数字飙上去的，是 2026 年 6 月的那波多语言病毒式爆发。
西班牙语、土耳其语、中文、日语、英语，同一周内，不同语种的开发者几乎同时开始在 X 上安利这个项目。帖子的核心论点惊人地一致："我们等这个等太久了。"
Reddit 上 r/VibeCodeDevs 社区的讨论帖标题更直白：
"Goodbye Vibe Coding: Why GitHub's Spec Kit Might Change How We Build with AI"
「再见 Vibe Coding：为什么 GitHub 的 Spec Kit 可能改变我们用 AI 构建软件的方式」
帖子里有人说，早期用户反馈代码质量明显提升——甚至"复活了测试驱动开发的实践"。
▲ Reddit r/VibeCodeDevs 社区讨论帖，评论区有人说"it seems very token heavy"
GitHub Projects Community 的官方账号也下场推广：
"Spec Kit turns software specifications into executable code that directly generates working implementations, not just documentation."
「Spec Kit 把软件规格说明变成可执行代码，直接生成可运行的实现，不只是文档。」
▲ GitHub Projects Community 官方推文，54 赞，8500+ 浏览
质疑声同样不少
社区讨论里，赞美和质疑几乎各占一半。
有人指出了一个扎心的事实：Spec Kit 能帮你把需求结构化，但前提是——你得知道自己要什么。
X 用户 @nickventuri 的回复堪称"神评"：
"Now we just need a command to help clients know what they want."
「现在我们就差一个帮客户搞清楚自己要什么的命令了。」
这话听着好笑，但点到了需求工程几十年来的根本难题——Spec Kit 提供了结构，但填充这个结构的内容，仍然要靠人。
Reddit 上有人抱怨"it seems very token heavy"——走完整套流程，token 消耗确实不小。对于一个周末 hackathon 的小项目，这套仪式感可能 overkill。
还有人担心长规格的问题：当 spec 文件越写越长，LLM 的上下文窗口可能装不下所有信息，反而导致模型"迷失在规格的海洋里"。
另外有声音推荐替代方案，比如 GentleAI、Forge 等方法论。Spec Kit 的定位更像是"方法论的软件化落地"，但方法论本身还在快速演进中。
公平地说，Spec Kit 主要处理"意图传达"问题，"意图发现"还得留给人。它假设你已经想清楚了要什么，然后帮你把这些想法精确地翻译给 AI。如果你自己都不知道要什么——抱歉，那是另一个维度的挑战。
从码农到「规格工程师」
退一步看，Spec Kit 代表的趋势比它自身更重要。
过去十年，软件工程的中心一直是代码。代码是真相，文档是附属品，需求文档写完就过期。
AI 编程工具的出现打破了这个平衡。当 AI 可以在几秒钟内生成几千行代码的时候，代码本身的价值开始贬值。真正稀缺的变成了精确表达意图的能力——你到底要什么，边界在哪里，哪些约束不可妥协。
Spec Kit 的宪法系统、结构化规格、门禁机制，本质上都在做同一件事：把"意图"从人脑中提取出来，变成机器可执行的契约。
开发者的角色正在发生位移。机械的"把需求翻译成代码"这件事，AI 已经能做得不错了。留给人类的，是更高层次的工作——定义需求、设定约束、验证结果、做架构决策。
Microsoft 开发者博客上，Den Delimarsky 把这种模式称为"架构思考的版本控制"（version control for your thinking）。这个比喻很精准——你的每一个产品决策、每一次需求澄清，都像代码一样被版本化、可追溯、可回滚。
当然，说 vibe coding 的时代"结束了"未免太早。对于原型验证、快速实验、周末项目，扔一句 prompt 让 AI 自由发挥仍然是最高效的方式。
但对于任何超过一周生命周期的项目，对于需要多人协作的团队，对于有合规和安全要求的企业——先写规格，再让 AI 动手，可能会成为新的基本操守。
GitHub 把这个工具开源了，MIT 协议，兼容几乎所有主流 AI 代理。一行命令就能试：
uvx --from specify-cli specify init my-project --integration copilot 11.6 万开发者已经投了赞成票。剩下的，该你了。
