有一条传播很广的判断：GitHub 用 Spec Kit「杀死了 vibe coding」。
更准确的说法是——它没有禁止你用自然语言写软件，而是把「先聊天再碰运气」改成「先留下一份 Agent 必须遵守的规格」。模型还是那个模型，变的是输入结构。
仓库：https://github.com/github/spec-kit
文档入口：https://github.github.com/spec-kit/quickstart.html
官方定位是 Spec-Driven Development（规格驱动开发）工具包：规格不只是给人看的文档，而是后续计划、任务和实现要对照的活产物。MIT 许可。Star / Fork 数字在持续涨（传播帖里写过 9.5 万星；仓库页面之后更高），热度本身说明「Agent 老跑偏」是普遍痛点，不说明装上就能代替工程判断。
问题不在模型，在「一句想法」
常见流程是：
「帮我做个待办 App。」
Agent 自己补全用户是谁、要不要登录、数据存在哪、测什么、什么叫做完。补全的过程不可见，半路改需求就整段重写，上下文一长就开始忘约束。
Spec Kit 把顺序拧过来：
先冻结「做什么、为什么、质量底线」，再允许选栈和写代码。
这和传统 PRD 的差别在于：规格被切成 Agent 斜杠命令能读写的仓库内文件（constitution、spec、plan、tasks），每一步有输入、有产出、有门禁。
命令在干什么
初始化后，多数 Agent 里用 /speckit.*（部分 CLI 用 $speckit-*）。官方完整路径比传播帖更长：
短路径（小功能）
specify → plan → tasks → implement → converge
完整路径（更认真的功能）
constitution → specify → clarify → plan → checklist → tasks → analyze → implement → converge
对应含义：
命令 | 作用 |
/speckit.constitution | 项目宪法：质量、测试、架构原则。后面每步都对照它 |
/speckit.specify | 用自然语言写做什么、为什么，先不锁死技术栈 |
/speckit.clarify | Agent 先问清楚含糊点，而不是猜 |
/speckit.plan | 这时才选技术、写实现方案与设计产物 |
/speckit.checklist | 给规格做完整性检查，像「需求的单元测试」 |
/speckit.tasks | 按依赖拆成可执行任务 |
/speckit.analyze | 规格 / 计划 / 任务之间的一致性与覆盖 |
/speckit.implement | 按任务实现 |
/speckit.converge | 对照规格看还差什么，补回任务列表 |
传播帖里的 /speckit.clarity 官方名称是 clarify。相差一个词，用错命令会找不到技能。
核心交付从「一堆生成代码」变成：一套能被下一跳 Agent 读到的规格与计划，代码只是最后一跳。
为什么这比纯对话稳
- 职责分离
产品意图在 specify，技术决策在 plan，避免「一句话里既改需求又换框架」。 - 可审查
constitution 和 spec 是文件，人可以改，也可以在 implement 前否决。官方 workflow 甚至在 specify、plan 后设 approve/reject 门。 - 可重复
换一个 Agent（Copilot、Claude Code、Cursor、Codex、Gemini CLI 等，文档称可接几十种），读的是同一套仓库产物，而不是某次聊天的记忆。 - 约束幻觉的位置
模型仍会编，但编造被挤到「澄清与计划」阶段，比直接在业务代码里编更好拦。
它解决的是编排，不是智能本身。规格写错，实现会很忠实地错下去。
怎么开始（概念层面）
文档推荐用 uv 安装 CLI，再在项目里 specify init，并指定一种 integration（例如 Copilot）。需要 Python 3.11+ 和 Git。
之后不要一上来 /speckit.implement。最小有纪律的循环是：
- 写几条真会执行的 constitution（测试、安全、目录约定），不要写成壁纸口号。
- specify 只讲用户可感知行为。
- 自己读一遍 spec，再 clarify。
- plan 时才扔栈（语言、数据库、部署）。
- tasks 细到「一次 Agent 会话能做完」。
- implement 后用 converge 对账，而不是口头说「应该齐了」。
小脚本、一次性探索，不必走满九步。规格流程有成本：多几轮模型调用、多一批 markdown。收益出现在功能会活过两周、会换人或换 Agent 的时候。
「GitHub 宣布 vibe coding 已死」过满了
Vibe coding 不会消失：探索 API、画原型、扔草稿，一句话仍然最快。
Spec Kit 适合的是：已经知道要交付什么、不能接受每次重开聊天就漂移的工作。
它也不是自治公司操作系统。没有自动找客户、没有自动收款。它只把「软件怎么被说明、怎么被拆、怎么被实现」收进仓库。
若规格很空、constitution 从不过问，Agent 照样会在 implement 阶段即兴发挥——只是即兴发生在更晚、文档更多的仓库里。
小结
Spec Kit 的判断是：长程 Agent 任务里，最贵的不是 token，是方向错误的 token。
先留下 constitution 和 spec，再 plan、tasks、implement，让模型和人对着同一份「活规格」干活。
仓库：https://github.com/github/spec-kit
下次想打「帮我做个 App」之前，可以先问自己：有没有一份足够清楚、Agent 读完不会靠猜的说明。有，再用实现命令；没有，多半不是缺一个更强的模型，而是缺这一步。
No comments yet