夜雨聆风凌晨两点，某开发者盯着终端反复刷新。AI几分钟前刚交出一整套代码，变量命名工整，注释一应俱全，运行起来却在提交表单那一步直接崩掉。翻回聊天记录，自己当时只说了一句：“帮我做个照片相册App，能拖拽排序，按日期分组。”AI并没有偷懒，它只是把没说出口的那些细节，全部按自己的理解补全了一遍。
7月4日，AI工具博主Nainsi Dwivedi把这种崩溃写成了一条推文，戳中了一大片开发者的痛处。
别急着怪AI
"Your AI writes code that looks right and works wrong. That's not the model's fault. It's yours. You gave it a vibe and expected a spec."
「你的AI写的代码，看着对，跑起来错。这锅该你背，模型没这个责任，你给的是一个vibe（氛围感提示），却指望它照着规格去执行。」
这条推文底下配的图，正是GitHub刚刚交出的答案。
▲ Nainsi Dwivedi在推文里画出GitHub Spec Kit的六步流程，发布当天866次浏览，14个赞、7条评论。
她说的这套“修复方案”，叫Spec Kit，GitHub官方开源的工具包，核心是把开发者和AI之间那场猜谜游戏，改造成一份双方都认账的规格文档（spec）。
这套东西2025年9月就已经上线，GitHub工程师Den Delimarsky在官方博客里这样写道：
"We've been treating our coding agents like search engines, when we should be treating them like literal-minded pair programmers."
「我们一直把编码代理当成搜索引擎在用，实际上应该把它当成一个字面意义上的结对程序员。」
▲ GitHub官方博客《Spec-driven development with AI》，作者Den Delimarsky，2025年9月2日发布。
模型擅长的是模式补全，谈不上猜心思。一句模糊的提示词，等于把成千上万个没说出口的需求，一股脑丢给AI自己拍板。拍对了算运气，拍错了就落成那种看着对却跑不通的代码。行业里给这种打法起了个名字，vibe coding（氛围式编程），凭感觉给提示，靠运气收代码。
几天冲到118K星，GitHub把“写需求”这件事重新搬回台面
Spec Kit去年9月低调上线，今年7月突然被顶上风口。多条推文都提到同一件事：短短几天，星标从数万飙到95K。等到这次截图采集，数字已经涨到了118K星、10.4K Fork。
▲ github/spec-kit仓库主页：118K星标、10.4K Fork、248位贡献者，MIT开源协议。
这套工具死磕的问题只有一个：AI到底该照着谁的意思写。原理并不复杂：逼着人和AI在动手写代码之前，先把话讲明白，而且这个讲清楚的过程要留痕、可追溯。
具体落地成六条指令，每一条都吐出一份Markdown文档，喂给下一步当上下文：
/speckit.constitution，先立项目宪法。代码质量红线、测试标准、性能门槛这些不可协商的规则，都要写进去，往后所有决策照着这份宪法审。
/speckit.specify，只谈“做什么”和“为什么”，技术栈一个字都不能提。就拿那个照片相册App举例，这一步只描述用户故事、功能边界、验收标准，AI会自动标出哪些地方还没交代清楚。
/speckit.clarify，轮到AI反过来提问。它把spec里含糊的地方挑出来，一条条追问，答案记进文档。这一步专门堵住“AI事后才发现问题”这个大坑。
/speckit.plan，技术栈终于登场。用Vite还是纯原生JS、数据库选SQLite还是别的，这时候才拍板，输出架构方案、数据模型、接口约定。
/speckit.tasks，把计划拆成一个个能独立测试的小任务，标好哪些能并行跑，哪些要按TDD顺序来。
/speckit.implement，AI逐个任务落地、跑测试、修bug。开发者审查的是一个个小改动，用不着面对几千行的巨型diff。
▲ Spec Kit官方Quick Start页面，列出从安装到六步指令的完整推荐流程。
装这套工具只要一行命令：uvx --from git+https://github.com/github/spec-kit.git specify init。Windows、macOS、Linux通吃，也能完全离线跑在内网。
118K星标背后，是一整条正在长大的生态
Spec Kit能在几个月里从小众工具滚到百万级关注。“能用”只是第一层，真正黏住开发者的，是它没把人焊死在GitHub自家生态里。
▲ 官方文档首页数据：30+编码代理集成、105个社区扩展（60+作者贡献）、22个预设、200+贡献者。
Claude Code、Copilot、Cursor、Gemini CLI、Codex……30多个AI编码代理都能直接接入，换哪个都不用推倒重来。围绕它长出来的105个社区扩展里，有专门做安全合规审计的角色化配置包，也有团队把整套流程改成了自己的版本，比如给.NET老系统做迁移的专用流程，或是多代理协同加质量门禁的重型版本。
这套方法论有个专有名词，规格驱动开发（Spec-Driven Development，简称SDD），也吸引了不站队任何一家公司的行业观察者。Thoughtworks杰出工程师Birgitta Böckeler专门写文章拆解过Spec Kit、Kiro、Tessl这几家做SDD的思路差异。
▲ martinFowler.com刊出的《Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl》，作者Birgitta Böckeler。
她把“规格驱动”拆成三层：spec-first（先写规格再动手，用完即扔）、spec-anchored（规格写完留着，后续迭代接着用）、spec-as-source（规格才是主文件，人从头到尾只碰规格，代码全交给AI生成）。眼下市面上打着SDD旗号的工具，基本都停在第一层，第三层，规格该怎么长期维护，行业里其实还没答案。
星标涨得快，吐槽也不少
热闹归热闹，把Spec Kit捧上天的人和吐槽它的人，几乎一样多。
Reddit的r/GithubCopilot板块里，一条帖子标题就是“Good start but long way to go（开了个好头，但路还长）”，发帖人试用之后的评价毫不客气：
"it's better than Gemini for sure. but at this moment it's not as refined as Kiro's spec flow. At this moment it feels more like an overnight hacked product than a refined, polished enterprise product."
「肯定比Gemini好用。但目前它没有Kiro的规格流程打磨得精细，现在这个阶段，感觉更像是连夜攒出来的东西，谈不上是打磨到位的企业级产品。」
▲ Reddit r/GithubCopilot板块讨论帖，29个赞、20条回复，评论区里有人分享自己用Kiro风格提示词模拟同款效果。
评论区里还有一条更扎心的中文反馈：给AI写需求，比自己写代码还难一点。这话戳中了要害，Spec Kit解决不了“写好规格本身就很难”这个老问题，它只是把这个老问题，变成了一套可重复、可检查的流程。对付小bug用不着动这么重的仪式；真正省心的场景，是从零搭一个新项目，或是往规矩很多的老系统里加复杂功能。GitHub自己也承认，这套东西还在实验阶段，VS Code的深度集成、大规模规格文件的管理，都还在补课路上。
代码退到最后一公里
争议归争议，一个趋势很难否认：规格正在从写完就扔的文档，变回软件工程里真正的主角。
瀑布时代写厚厚的PRD，写完压箱底，代码才是活的东西。敏捷时代把文档减到最薄，一切以能跑的软件为准。现在AI把“规格”和“能执行”这两件事焊在了一起，规格改一个字，AI就能重新生成对应的计划和代码，规格头一回变得像代码一样，能被直接执行。
这也在悄悄挪动开发者的工作重心。花在clarify和plan阶段的时间变多了，动手敲代码反而成了流程里最快的一环。有人把这变化说成：意图成为真相的来源，代码只是它的产出物。
这话听着有点玄，落到每一个被AI写出的“看着对却跑不通”的代码坑过的人身上，其实特别朴素，提前把话讲明白，好过事后拆解AI的脑补。118K颗星标，投的也许正是这份朴素。
