让 AI 写一个功能，最怕的情况是这样：它写了三百行，结构也像模像样，你 review 到一半才发现方向从一开始就偏了。你想要的是「按日期分组的相册」，它做成了「按上传时间排序的列表」。这时候你面对的不是几个 bug，是一堆需要推倒重来的代码。
Spec Kit 想解决的正是这一段。它的主张听起来有点反直觉：先别让 AI 写代码，让它先写文档。
是什么
Spec Kit 是 GitHub 官方开源的流程工具包，MIT 协议，主体是 Python。仓库当前 138,776 个 Star、12,426 个 Fork，2,064 次提交，最新版本 1.0.11 发布于 2026 年 9 月 24 日，同一天仓库还有提交。它自己说得很清楚：给 AI 编程代理提供「结构化的流程、可复用的模板、有据可查的产出」。
它提供的东西跟又一个代码生成器不搭边，是一套工作流。装完之后你的编程助手里会多出一组斜杠技能，按顺序调用它们，每一步产出一份 Markdown 文件：先是项目原则，再是功能规格，然后是技术方案和任务拆解，最后才进入实现。每一份你都能读、能改、能进 Git 做 review。这点很关键，判断方向对不对，看三千行代码远不如看一页规格快。
仓库首页。memory、bundles、presets、integrations 这些目录一眼能看出它的组织方式，侧栏显示最新版本是 1.0.11
它到底好用在哪儿
第一是三条流程彼此独立，这点比很多「全家桶」聪明。它给的是三个入口，没有一个必须从头走到尾的大流程：要建新功能走规格驱动开发，要修缺陷走行为修复，要判断一个点子值不值得投入走评估。缺陷修复和点子评估是可选扩展，得自己 specify extension add 装上，用不着的人不受打扰。
规格驱动开发这条主线，节奏是「每个项目定一次原则，每个功能走一遍五步」。原则那步叫 /speckit-constitution，写的是代码质量、测试、可维护性这些长期约束，定一次就够了。之后每个功能依次走 specify（要什么）、plan（怎么做）、tasks（拆成任务）、implement（实现）、converge（收敛）。收敛这一步是它的特色——不是写完就算完，还要回头核对实现跟规格是不是对齐了，报告 Converged 才算过，不满意就再来一轮 implement 加 converge。
第二是缺陷修复那条流程的分工，我觉得是整套东西里最实用的部分。它把「诊断原因」「动手修」「验证原症状」拆成三个独立技能：/speckit-bug-assess、/speckit-bug-fix、/speckit-bug-test。产出落在 .specify/bugs/ 下，最后给一个明确结论：verified、partial 还是 failed。文档里有句话写得很硬——「缺了验证不算修好」。让 AI 修 bug 最容易出的问题就是它改了个地方、说修好了，你也没细看；这套流程强制把「验证原来的症状还在不在」变成一个必须完成的步骤。
第三是点子评估能脱离代码用。评估流程是 intake、research、define、shape、decide 五步，产出落在 .specify/assessments/ 下，最后给一个 go、needs-clarification 或 kill 的结论。它的文档特意提了一句：这是个「连一行源码都没有的项目里也能用」的独立流程。而且它把「停下来并记录原因」也算作有效结果——大部分工具不愿意给你这个选项，它们默认你总是要往下做。
第四是可定制。扩展加能力、预设改行为、工作流串步骤、打包成面向角色的组合，还支持项目级覆盖模板。社区已经有扩展、预设、打包的目录在跑。GitHub 在 README 里还专门回答了「Spec Kit 自己用不用 Spec Kit」，链接指向贡献指南——这种自用的态度，比单纯的功能列表更能说明他们信这套流程。
官方文档站首页。开头就把三条流程和各自产出并排列出来，下面还有一张「会得到什么」的对照表
怎么用
前提是 Python 3.11 以上、装好 uv，以及一个它支持的编程助手。装和初始化各一行：
uv tool install specify-cli
specify init my-project --integration copilot
cd my-project
例子里的 copilot 是集成名，换成别的助手对应的键即可，文档里有一张集成对照表。已经有代码的项目不用重新建，官方单独写了一份存量项目的接入指南。
初始化完就进项目目录启动你的编程助手。注意这一步容易踩坑：这些是代理技能，不是终端命令，要在助手的对话里一条一条调用，而不是敲在 shell 里。规格驱动那条线大概是这个样子：
/speckit-constitution
/speckit-specify 建一个照片整理器，相册按日期分组，每个相册带一张平铺预览
/speckit-plan 用 Vite 配原生 JavaScript，图片存本地，元数据放 SQLite
/speckit-tasks
/speckit-implement
/speckit-converge
后面的 implement 和 converge 重复跑到收敛报告 Converged 为止。中途可以插入澄清、检查清单、一致性分析这类额外的质量闸门，不需要就跳过。要注意一个使用习惯上的差别：它建议你一步一步来，每一步产出都过一眼再继续——四个技能一口气连着调，等于把「先看清方向」这个最大收益扔掉了。
修缺陷和评估点子要先装扩展：
specify extension add bug
/speckit-bug-assess "提交空密码会让登录表单崩溃" slug=login-crash
/speckit-bug-fix slug=login-crash
/speckit-bug-test slug=login-crash
specify extension add assess
/speckit-assess-intake "让用户离线也能用，重连后同步" slug=offline-mode
/speckit-assess-research slug=offline-mode
/speckit-assess-define slug=offline-mode
/speckit-assess-shape slug=offline-mode
/speckit-assess-decide slug=offline-mode
不足也得说清楚
未关闭的 Issue 有 135 个，Pull Request 也堆了 153 个。考虑到它从 2025 年 8 月建仓库到现在已经打了 227 个 tag、发了 225 个版本，这个 backlog 更像是「迭代太快、社区跟进太猛」的结果，而不是没人管。但确实意味着你提的需求不一定马上有回应。
它不是零成本上手。你得先接受一整套方法论，还要有一个它支持的编程助手——这是一套「换个工作方式」的东西，不是装个插件就见效。团队里如果只有你一个人按这个流程走，收益会打折，因为规格和方案本来就是给多人评审用的。
流程本身也有重量。对一个两小时能改完的小需求，走一遍 specify 到 converge 可能比直接写还慢。它自己也没说三条流程都必须用——恰恰相反，三个入口独立设计就是为了让你按需挑。用错场景的话，你会觉得这东西在给简单事情加官僚流程。
另外它的产出质量跟你的输入质量强相关。规格写得含糊，后面 plan 和 tasks 只会把含糊放大。它能把「方向」这件事显性化、可评审，但没法替你判断方向本身对不对。
跟同类怎么比
市面上另一条路线是各种「PRD 生成器」或者提示词模板库。那类东西给你一份提示词，让 AI 吐一份需求文档，做完就结束了。Spec Kit 的差别在于它管的是全流程：文档不只给人看，还被后面的 plan、tasks、converge 接着消费，形成一条回路。它更像一套工程规范，而不是一段提示词。
还有一类是重型的规格工具，比如带形式化验证的方案。那些保证更强，但学习曲线陡、对普通业务开发来说太重。Spec Kit 停在 Markdown 这一层，门槛低得多，代价是它靠的是约定和流程纪律，而不是工具层面的强制。
跟各编程助手自带的「计划模式」比，这是最容易混淆的地方。计划模式通常只管一次对话里的任务拆解，会话结束就没了。Spec Kit 把产物落到仓库里的 Markdown 文件中，可以提交、可以 review、可以跨会话接着改——这是「一次对话里的计划」和「项目资产」的区别。
我的判断是：它适合那些「AI 写代码挺快，但返工率也高」的团队。如果你已经反复经历「代码写完才发现理解错了」，那多花二十分钟把规格写清楚是划算的。反过来，如果你做的是原型、探索性脚本、一次性的小工具，那些场景本来就不需要可评审的规格，硬套只会拖慢自己。GitHub 官方出品加一周内连续三个版本，说明这东西还在快速长，值得现在花点时间看一眼。
GitHub：https://github.com/github/spec-kit
官方文档：https://github.github.com/spec-kit/
标签：#SpecKit #规格驱动开发 #AI编程 #GitHub开源 #需求管理 #工作流 #缺陷修复 #点子评估
你用编程助手的时候，是习惯先让它出方案再看代码，还是直接让它开工、不对再改？