夜雨聆风你对着 Cursor 敲下一行字：「帮我做一个照片管理 app，支持拖拽排序、按日期分组。」
30 秒后，一个能跑的页面出现在屏幕上。
你截图发朋友圈，配文「AI 写代码太爽了」。点赞如潮水涌来。
第三天，你让 AI 加个标签功能。它用 Redux 重写了整个状态管理——而你第一天明明用的是本地 state。
第三周，你发现认证逻辑跟公司 SSO 彻底冲突。你翻遍代码库，找不到一行注释能告诉你「当初为什么要这样设计」。
测试覆盖率：0%。CI 一跑就红。修一个 bug，冒出来三个。
你盯着屏幕，后脊发凉：到底是 AI 在帮你写代码，还是你在帮 AI 收拾烂摊子？
这就是 2026 年全球开发者最熟悉的一种工伤——vibe coding。
凭感觉写提示，凭运气跑代码。原型爽翻天，项目深似海。
而现在，GitHub 官方亮出了一把刀。
▲ 西班牙语开发者 @zaynmcps 的推文引爆 X：25 万次浏览。「GitHub 刚刚解决了 vibe coding 最大的问题——95k 星背后有真实需求。」
一条西班牙语推文，炸出了上百万开发者的隐痛
2026 年 6 月中下旬，几条西班牙语推文开始在 X 上刷屏。
"GitHub acaba de resolver el mayor problema del vibe coding."
「GitHub 刚刚解决了 vibe coding 最大的问题。」
推文配了一段短视频，展示了一个叫Spec Kit的工具。画面里，AI 不再是一口气吐代码——它先问你要什么，再问你怎么做，等全部检查点绿灯亮了，才动手写第一行。
六步流程被截图、转发、拆解、逐帧分析。短短几天，相关推文累计超过 25 万次浏览。评论区彻底沸腾。
「终于不用再为 AI 偏离意图反复修 bug 了。」 「spec 持久化之后，跨 session 的一致性大幅提升。」 「我就想知道这东西对我的屎山代码库有没有用……」
争议也紧跟着来了。一条高赞回复直指要害：「这个 repo 上线一年多了，星是一年多慢慢涨起来的，推特上「几天 95k」的说法有误导。」
没错。Spec Kit 的 GitHub 仓库 2025 年 9 月就已公开。但它真正引爆的时间点，是 2026 年春夏——当足够多的开发者被 vibe coding 反复毒打之后，这把「刹车」终于等来了属于它的时刻。
截止本文写作时，仓库数据：116k Star、10.2k Fork、174 个 Release、200+ 贡献者。
▲ Spec Kit 仓库页面。README 开宗明义：专注产品场景和可预测的结果，而非凭感觉写代码。
六步「缴械」流程：先交作业，再碰代码
Spec Kit 的核心玩法极其明确：强制 AI 在写代码之前，先交一份你亲手审过的「作业」。这份作业分六步完成，每一步都有硬门禁。AI 不能跳步，不能「我觉得用户大概想要……」，更不能偷偷塞进自以为聪明的技术选型。
第一步：/constitution —— 立宪
团队的底线全部写进一个叫constitution.md的文件：测试先行、最多 3 个 project、禁止过度抽象、集成测试必须跑真实数据库……
条款写进文件，就是不可逾越的红线。AI 每次生成代码，都得先把这些条款过一遍。
第二步：/specify —— 只谈「什么」和「为什么」
*最硬核的一步。*谁用？解决什么痛点？成功标准是什么？
技术栈？一个字都不许提。模板里嵌了明确的约束——AI 敢在规格阶段提「用 React + Tailwind」，立刻被拉回来。
第三步：/clarify —— 把坑填干净再走
AI 主动列出所有[NEEDS CLARIFICATION]标记，挨个追问：照片导入是选文件夹还是逐张选？拖拽到同一秒多张照片怎么排序？一万张照片时性能撑不撑得住？
你没答清楚，后面步骤直接卡住。大量实测反馈表明：做完这一步，后续返工量断崖式下跌。
第四步：/plan —— 现在才允许谈技术
Vite 还是 Next.js？SQLite 还是 Postgres？Tailwind 还是原生 CSS？
AI 会帮你写技术对比、版本选型理由、风险清单。但人类必须回答最关键的问题：「这个技术，我们团队真有维护能力吗？」
第五步：/tasks —— 拆到文件路径级别
生成的tasks.md按用户故事分组，每条标依赖、支持并行标记[P]、强制 TDD 顺序（先写测试契约，再写实现代码）。
第六步：/implement —— 执行
代理不再一股脑吐 500 行。它按任务逐条提交小 PR 级别的变更，你逐条 review。
出 bug 了？不用翻代码。翻回 spec 第 3 条用户故事：「哦，验收标准白纸黑字写着——AI，你跑偏了。」
▲ 2025 年 9 月 GitHub 官方博客首次公开 Spec Kit 理念：「AI 生成的代码看起来能跑，实则暗藏偏差。规格必须可执行，而非写完即弃的文档。」
「宪法」—— 整条工具链里最被低估的杀器
六步流程里，constitution 是最容易被跳过的。
但用了一个月以上的开发者，反馈惊人地一致：真正帮你省掉无尽扯皮的，就是这份宪法。
条款长这样：
- Article III: Test-First Imperative
—— *不可协商。*没写测试，不许实现。 - Article VII: Simplicity Gate
—— 初始实现最多 3 个 project。想加第 4 个？先写复杂度跟踪记录，亮出正当理由。 - Article IX: Integration-First Testing
—— 不用 mock，上真实数据库。契约测试先行。
团队争论「要不要再加一层抽象」的时候，一句「看宪法 Article VII」，架直接吵完。
红线圈好了。人和 AI，都不许踩。
Visual Studio Magazine 在 2026 年 5 月的报道中，引用了首席维护者 Manfred Riem 的评价：
"It's a very capable intern and it's a very quick intern but it's still an intern nonetheless."
「AI 是个非常能干、非常快的实习生，但它终究还是个实习生。」
你不会让实习生拿到一句「做个 app」就自己闷头干半个月。你会给他需求文档、设计规范、验收标准和代码红线。Spec Kit 做的就是这件事——只不过实习生换成了 AI。
▲ Visual Studio Magazine 2026 年 5 月报道标题：「GitHub Spec Kit Takes Off as Antidote to Piecemeal 'Vibe Coding'」。maintainer Manfred Riem 在 Open Source Friday 直播中演示了完整的 constitution → implement 闭环。
Reddit 和 HN 上的真实回响：赞美、质疑，以及那句最扎心的追问
热度之下，社区的声音远比「牛逼」二字复杂。
Reddit 上一个被反复顶起的帖子问得犀利：「Spec-Driven Development + Copilot——你们到底用什么来规划整个产品，而不只是生成单个 spec？」
潜台词不言自明：一个 feature 的规格问题解决了，但 50 个 feature 的产品——优先级怎么排？roadmap 怎么管？这些都在 Spec Kit 的能力边界之外。
HN 上更热闹。有人认真跑完 spec-driven.md 后写了长帖，结论是「greenfield 新项目效果拔群，但已有复杂代码库需要大量反向工程」。还有人翻出社区 fork 列表，论证「一刀切方案根本不存在」。
最扎心的一条来自试用三个月的匿名开发者：
"The tool's value isn't in killing vibe coding. It's that the next time you say 'build me a feature,' you first ask yourself: have I written my spec?"
「工具的意义不在消灭 vibe coding。而是下次你对 AI 说'帮我写个功能'之前，你先会问自己：我的 spec 写了吗？」
▲ Reddit r/GithubCopilot 下一线开发者的真实讨论：Spec Kit 在项目中的落地体感，以及与其他 SDD 框架的取舍。
vibe coding 没有死。它只是终于学会了先看路，再踩油门。
Spec Kit 并非「AI 编程终结者」。
它是一套方向盘、后视镜和刹车踏板——装在你和 AI 共同驾驶的那辆车上。
快速探索？仍然可以。放在 specify 和 clarify 阶段，成本低、改起来快。方向确认了，plan + tasks + implement 才是轰油门的时刻。
改需求也不再是噩梦。以前是：改需求 → 重写大段代码 → 祈祷别引入新 bug。现在是：改需求 → 更新 Markdown spec → 重新生成 plan/tasks → AI 按新路线图执行。
Manfred Riem 说过：
"Specifications don't serve code — code serves specifications."
「规格文档不服务于代码——代码服务于规格文档。」
规格不再是用完即扔的脚手架。它是活文档，是团队共识的源代码，是 AI 每次生成前必须穿越的那道门禁。
116k 星还远没到终点。它只亮了一盏灯——
写代码的姿势，正在从根上被改写。