临渊羡鱼，不如退而结网。——《汉书董仲舒传》

当代码不再单打独斗，Spec Kit 如何把软件开发带回“先想清楚，再动手”的正轨

如果你最近在 AI 编程的浪潮里待得够久，大概已经见过这样的场景：

一句提示词丢给模型，代码很快就出来了，页面能跑，接口能通，甚至连样式都像模像样。你一边惊叹效率，一边又隐隐不安：这个东西为什么这么设计？需求真的被理解对了吗？后面改起来会不会像拆盲盒？团队里其他人接手时，能不能看明白它最初到底想解决什么问题？

这时候，Spec Kit 像一个不慌不忙的项目管家走了进来。它不会先急着撸代码，而是先把你拉到会议室里，摊开纸，扶正眼镜，然后认真地问一句：

你到底想做什么，为什么要做，成功长什么样？

这就是 github/spec-kit 想做的事。它的仓库描述只有一句话，却很有力量：

Toolkit to help you get started with Spec-Driven Development

翻译成更有人味的话就是：它不是来替你写几段零散代码的，它是来帮你把软件开发这件事，从“凭感觉往前冲”，重新带回“以规格驱动、按阶段推进、朝着可预测结果前进”的轨道上。

而 README 里给它定下的气质更鲜明：

Build high-quality software faster.

它想要的不是慢工出细活，也不是快得顾头不顾尾，而是——更快地做出高质量的软件。

Spec Kit 是什么

Spec Kit 是一个开源工具包，用来帮助开发者实践 Spec-Driven Development。

它最迷人的地方在于，它并不把“代码”当成唯一主角。README 里有一句特别传神的话，大意是说，传统软件开发很多年里，代码一直是王者，规格说明只是临时脚手架，等“真正的工作”开始后，它就被扔在一边了。而 Spec-Driven Development 则把这套逻辑反了过来。

在 Spec Kit 的世界里，规格不是陪跑，不是装饰，不是交付前随手补的文档。规格是方向盘，是地图，是队伍出发前先对准的北极星。

它鼓励你先定义：

要构建什么
为什么要构建
用户故事是什么
成功结果应该如何衡量
技术方案应该怎样服务这些目标

也就是说，它强调先把 what 和 why 说清楚，再进入 how。

如果把传统 AI 编程比作一个很能打、出手很快的工程师，那么 Spec Kit 更像那个会在白板前先搭框架的产品技术搭档。它不会阻止你快，恰恰相反，它是为了让你快得更稳、更准、更能复用。

它到底在反对什么

Spec Kit README 里提到一个很有辨识度的表达：不要从头到尾都靠 “vibe coding”。

这句话很戳当下的现实。

很多 AI 开发流程的问题，不是模型不会写代码，而是：

需求本来就没讲清楚
功能边界模糊
约束条件没有前置
计划没有拆开
实施没有承接规格
结果一边生成，一边漂移

最后的代码可能写出来了，但它更像一次即兴发挥，而不是一次可复盘、可协作、可演进的工程实践。

Spec Kit 就像一个对“即兴冲刺”有点不放心的老练导演，它会说：

先别急着上台，剧本过一遍，角色关系理一理，场景顺一下，技术实现再开拍。

所以你会发现，它的核心不是“多一个 CLI 命令”，而是“给 AI 协作开发建立一条结构化流水线”。

Spec-Driven Development 到底是什么感觉

如果只用一句话来形容，我会说：

它像是在 AI 编程时代，把产品思维、工程纪律和自动化执行重新捏成一体。

Spec Kit 所倡导的流程，不是让你一口气甩给模型一大段需求，然后盼它从宇宙中抽到最优解；而是把开发分成多个彼此衔接的阶段，让 AI 在每一步都站在更清晰的上下文里工作。

这个过程大致是：

先建立项目原则
再定义规格
然后明确技术计划
接着拆分任务
最后再实施

这一整套流程像什么？

像是你不是在雇一个只会冲刺的写手，而是在带一个会开会、会整理、会列计划、会执行、还会回头核对目标的全能助手。

Spec Kit 最吸引人的地方，是它把“流程”做成了可操作命令

很多方法论看上去都很好，真正难的是落地。Spec Kit 很聪明，它没有把自己停留在理念层，而是把流程直接变成了一组可以执行的命令。

README 中最核心的一组命令非常清晰：

命令	作用
`/speckit.constitution`	创建或更新项目原则和开发治理规则
`/speckit.specify`	定义你要构建的内容，也就是需求和用户故事
`/speckit.plan`	根据技术选型生成实现计划
`/speckit.tasks`	把计划拆成可以执行的任务列表
`/speckit.taskstoissues`	把任务转换成 GitHub Issues 方便追踪
`/speckit.implement`	按计划执行实现

另外还有几位重要配角：

命令	作用
`/speckit.clarify`	对不明确的需求进行澄清，推荐在计划前执行
`/speckit.analyze`	做跨文档一致性与覆盖分析
`/speckit.checklist`	生成质量检查清单，验证需求是否完整、清晰、一致

这些命令组合在一起，像一个秩序井然的小团队。

/speckit.constitution 很像项目里的宪法起草人，它先把原则立起来：代码质量怎么要求，测试标准怎么定，用户体验要遵循什么一致性，性能边界到哪里。

/speckit.specify 像产品经理和用户研究员的合体，它追问的不是你准备用 React 还是 Vue，而是你到底要给谁解决什么问题。

/speckit.plan 则像技术负责人，开始谈架构、技术栈、依赖关系、实现路径。

/speckit.tasks 是项目经理，把抽象计划拆成一条条能被执行和追踪的事项。

/speckit.implement 终于轮到工程师上场了，但这时候他不再是对着一团模糊空气开工，而是在一整套前置上下文的托举下精准落子。

快速启动也很直接

如果你想试试，README 里的启动路径相当清晰。

先安装 Specify CLI：

1	uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z

然后初始化项目：

1 2	specify init my-project --integration copilot cd my-project

如果你想检查更新或升级 CLI，也有对应命令：

specify self check
specify self upgrade --dry-run
specify self upgrade
specify self upgrade --tag vX.Y.Z[suffix]

接着就可以进入 Spec Kit 最有戏剧感的一段旅程。

先立规矩：

1	/speckit.constitution Create principles focused on code quality, testing standards, user experience consistency, and performance requirements

然后说清楚你到底要做什么：

1	/speckit.specify Build an application that can help me organize my photos in separate photo albums. Albums are grouped by date and can be re-organized by dragging and dropping on the main page.

再告诉它技术方案：

/speckit.plan The application uses Vite with minimal number of libraries. Use vanilla HTML, CSS, and JavaScript as much as possible. Images are not uploaded anywhere and metadata is stored in a local database.

拆任务：

1	/speckit.tasks

最后实施：

1	/speckit.implement

如果你看着这些命令觉得很顺，那正说明它设计得好。Spec Kit 没有把流程搞成令人望而却步的大部头，它只是把开发真正该走的路，一步一步铺平了。

它为什么会让人有安全感

因为它不是在赌“这次模型刚好理解对了”，而是在建立一套可以反复验证的机制。

README 里反复强调几件事：

先讲意图，再讲实现
通过多阶段细化，而不是一次性生成
借助项目原则和规范来约束产出
用规格、计划、任务这些工件串起整个过程
在执行前后都留出澄清、分析、检查的空间

这是一种很成熟的工程观。

软件开发最怕的并不是慢，真正怕的是表面很快，实际上一路返工。你今天省掉的规格说明，可能会在下周变成十倍的沟通成本；你现在略过的澄清步骤，可能会在功能联调时变成一连串“原来你是这个意思”。

Spec Kit 就像一个经验丰富的船长，它知道开船最浪费时间的，不是出发前那十分钟检查航线，而是出了港以后才发现地图拿反了。

它特别适合 AI 编码时代

这一点非常重要。

Spec Kit 并不是一种脱离时代的“传统规范主义回潮”，它恰恰是为 AI 编码时代量身打造的。

README 里明确提到，它支持 30+ AI coding agents，既包括 CLI 工具，也包括 IDE 助手。你可以通过下面这个命令查看本地安装版本支持哪些集成：

1	specify integration list

这意味着它不是要替代 AI，而是要给 AI 配一套更完整的工作上下文。

过去我们觉得规范文档是给人看的，现在在 AI 开发时代，规范文档同样也是给模型看的，而且往往更重要。因为模型特别依赖上下文质量。上下文模糊，结果就容易漂；上下文扎实，结果才更稳定。

Spec Kit 很像一个懂 AI 脾气的人，它知道不能只对模型喊“给我写个应用”，而是要层层铺垫，把业务目标、约束边界、项目原则、实施计划都喂到位。这样 AI 才不是在猜，而是在执行。

它不是只适合从零开始

很多人一看这种流程化工具，会误以为它只适合从零搭新项目。其实 README 里列出的适用阶段非常有意思，它覆盖了好几种典型场景：

0 到 1 的绿地开发

从一张白纸开始，先有高层需求，再生成规格、计划、任务，最后落地实现。

创造性探索

并行探索多种方案、多种技术栈、多种架构和 UX 路径，给创新留空间。

存量系统迭代和现代化改造

不是所有项目都生在新时代。很多团队面对的是老系统、旧架构、历史包袱。Spec Kit 也把这种渐进式改造纳入了方法论中。

这很重要，因为现实中的开发从来不是清一色的新项目。更多时候，我们面对的是一栋住了很多年的房子：地基还在，管线复杂，住户众多，改造必须谨慎。Spec Kit 并不只会在空地上画蓝图，它也能拿着探照灯走进旧楼，一边摸清结构，一边规划翻新路线。

它的“核心哲学”其实很对味

README 总结了几条核心哲学，我觉得每一条都踩在关键点上：

以意图驱动开发，规格先于实现
用护栏和组织原则来丰富规格创建过程
通过多阶段细化代替一次性代码生成
充分依赖先进 AI 模型对规格的理解能力

这几条放在一起，构成了一种很现代的开发姿态：

不是否认 AI 的能力，而是承认 AI 很强，所以更应该把它放在结构化流程里发挥。

这像什么呢？

像你有了一台动力极强的赛车。你当然可以直接踩油门，但真正专业的做法，从来不是“看它能飙多快”，而是“给它赛道、给它规则、给它导航、给它策略，然后让它快得漂亮”。

Spec Kit 就是那条赛道。

它还给了团队可扩展的空间

一个成熟工具不能只有主线，还得允许不同团队长成自己的样子。Spec Kit 在这方面也做得很灵活，它提供了 Extensions 和 Presets 两套机制。

这是 README 里很值得一提的一部分。

Extensions

当你需要为 Spec Kit 增加新的能力时，用扩展。

比如：

Jira 集成
实现后的代码评审流程
V-Model 测试可追溯性
项目健康诊断
其他领域特定工作流

Presets

当你不是想增加新能力，而是想改变现有工作方式时，用预设。

比如：

调整规格模板结构
让流程更贴合 Agile、Kanban、Waterfall 等方法
加入监管与合规要求
嵌入企业内部标准术语和文档格式

安装命令也同样简洁：

1 2	specify preset search specify preset add <preset-name>

这两者的区别，可以理解为：

Extension 像给工具箱新增工具
Preset 像给原有工具换一套更适合你团队的握把和使用方式

Spec Kit 不强迫所有团队长成一个样子。它像一个骨架结实、但留足了可塑空间的系统，让不同组织能把自己的方法论、行业要求、协作习惯嵌进去。

它甚至连“项目个性化”都想到了层级关系

README 里有一个很有工程味的优先级设计：

项目本地覆盖
Presets
Extensions
Spec Kit Core

这意味着它的模板解析是有层次的，运行时会按优先级从上往下找第一个匹配项。

这个设计很妙。

它像一个会讲秩序的总管家，知道什么该以项目现场为准，什么该继承团队标准，什么该继承扩展能力，什么最后再回退到核心默认值。这样的机制对团队落地特别友好，因为你不用在“统一规范”和“项目特殊性”之间二选一。

它允许你既有制度，也有弹性。

真正让我觉得它靠谱的是它鼓励澄清，而不是迷信第一次生成

README 的详细流程里，有一段我特别喜欢：在生成技术计划前，应该先做需求澄清。

它推荐优先执行 /speckit.clarify，并明确说，如果第一版规格没说清楚，就要继续 refinement，不要把 AI 的第一次输出当成终稿。

这是一种非常健康的态度。

很多人现在用 AI，最大的误区之一就是：它既然能答，那第一次答出来的东西就默认够用了。但真实世界不是考试题，软件需求更不是一锤定音。需求本来就需要拉扯、补充、核对、追问。

Spec Kit 很像一个有耐心的采访者。你说一句，它不会立刻冲出去盖楼，而是会追问：

这里边界是什么
这个行为在异常情况下怎么办
你的用户到底是谁
你是不是还有没说出来的隐含要求
有没有什么你以为理所当然、但机器根本不知道的前提

如果说一般的 AI 工具像很会接话的演员，那 Spec Kit 更像一个会在开拍前反复对剧本的编剧统筹。

它还考虑到了质量检查和一致性分析

除了主流程命令，Spec Kit 还提供了一些非常关键的质量控制环节。

比如 /speckit.analyze，用来检查跨工件的一致性与覆盖情况。

再比如 /speckit.checklist，README 里把它形容得很有意思，像 “unit tests for English”。也就是在你还没开始写代码之前，先对需求表达本身做质量校验：它是不是完整、是不是清晰、是不是自洽。

这太有价值了。

很多项目不是死在代码里，而是死在语言里。需求文档写得像谜语，讨论记录像口头传说，最后团队每个人脑子里都是不同版本的“正确答案”。Spec Kit 试图把这种偏差尽量前置解决。

它像一个对歧义零容忍的编辑，总在关键节点把句子拎出来看看：

你这句话，到底是不是所有人都会理解成同一个意思？

README 里那套完整流程，几乎就是一部 AI 协作开发剧本

如果顺着 README 的 Detailed Process 读下来，你会发现 Spec Kit 给的不只是命令，而是一整套开发剧本。

大概可以概括成这样：

第一步，初始化环境

1	specify init <project_name>

或者在当前目录初始化：

specify init .
specify init --here
specify init . --force
specify init --here --force

还可以明确指定集成：

specify init <project_name> --integration copilot
specify init <project_name> --integration gemini
specify init <project_name> --integration codex

specify init . --integration copilot
specify init . --integration codex --integration-options="--skills"

specify init --here --integration copilot
specify init --here --integration codex --integration-options="--skills"

第二步，建立项目原则

通过 /speckit.constitution 生成项目的治理准则。

第三步，创建功能规格

通过 /speckit.specify 让 AI 根据你描述的产品目标写出规格。

第四步，做澄清

通过 /speckit.clarify 补足那些仍模糊的部分，降低后续返工。

第五步，生成技术计划

通过 /speckit.plan 引入明确的技术栈和实现思路。

第六步，验证计划

审视有没有遗漏、有没有过度设计、有没有执行顺序不合理的地方。

第七步，拆任务

用 /speckit.tasks 生成具体、可执行、带依赖关系的任务清单。

第八步，实施

用 /speckit.implement 按计划真正开始构建。

这一整套看下来，你会感觉 Spec Kit 像在说：

“别怕快，我支持你快，但你得先把前面的地基踩实。只要地基稳了，后面就能跑得漂亮。”

它适合什么样的人

我觉得有几类人会特别喜欢它。

第一类，正在用 AI 写代码，但经常被返工折磨的人

你已经感受到了 AI 的速度红利，但也开始被模糊需求、上下文漂移、产出不可控折腾得头大。Spec Kit 能帮你把这些混乱前置收束。

第二类，想把 AI 协作纳入团队流程的人

个人写着爽和团队能协作不是一回事。团队需要共享上下文、可追踪工件、标准化过程。Spec Kit 正好提供了这条桥梁。

第三类，做复杂项目、企业项目、受约束项目的人

README 提到它关注 enterprise constraints，包括云平台约束、技术栈约束、工程实践、设计系统、合规要求。也就是说，它不是只为玩具 demo 准备的。

第四类，希望让开发“更像工程”而不是“更像表演”的人

如果你不满足于每次都靠模型临场发挥，而是希望形成一套可复用的生产方式，那 Spec Kit 很值得研究。

它并不神秘，反而很务实

有些工具喜欢把自己讲得像未来降临，仿佛用了它就能自动进入下一个软件开发纪元。Spec Kit 不是这种路数。

它很务实。

它要求的前提条件也都很普通：

Linux、macOS 或 Windows
支持的 AI coding agent
推荐用 uv，也可以用 pipx
Python 3.11+
Git

也就是说，它并没有试图把你拖进一套封闭生态，而是基于现有工具链帮你搭起方法框架。

这种克制反而让人信任。它不装神，不卖玄学，不假装一键解决所有问题。它只是很认真地告诉你：如果你愿意把规格、计划、任务这些环节放回开发核心位置，AI 的价值会被释放得更稳定。

为什么它会在今天变得重要

因为我们正处在一个很微妙的时间点。

一方面，AI 已经把“写代码”这件事的门槛和速度都改写了。另一方面，越是写得快，越容易暴露一个事实：真正稀缺的，从来不只是代码生成能力，而是把问题定义清楚、把目标边界讲明白、把实现过程组织起来的能力。

Spec Kit 的价值就在这里。

它不是来和 AI 比谁更会写代码，它是来告诉你：

当“写”已经不那么稀缺时，“想清楚再写”会重新变得昂贵。

这也是为什么它看上去像一个工具包，骨子里却更像一种开发观念的更新。

如果把 Spec Kit 拟人化，它像谁

我会把它想象成一个这样的角色：

它不是最先冲进工位敲键盘的人，也不是会议上话最多的人。它更像那个总能在关键时刻把场子稳住的核心搭档。

你说想做一个产品，它先递给你白板笔；
你说想赶紧写代码，它轻轻拉住你，说先把成功标准讲清楚；
你说需求差不多就这样吧，它又提醒你，还有些边角没说透；
你终于准备开工时，它已经把路径、任务、节奏、约束都收拾妥当。

它不抢戏，但你越做复杂项目，越会发现它的重要。

它像一个不爱喧哗的编排者，让产品、工程、AI 三方终于不再各说各话，而是坐进同一张乐谱里。

一个值得认真尝试的开源项目

github/spec-kit 不是那种看完 README 就结束的仓库。它更像一个邀请：邀请你重新审视，在 AI 编程越来越快的时代，软件开发应该怎样保持质量、秩序和可预测性。

它给出的答案并不花哨：

先定义原则
再明确规格
然后形成计划
接着拆分任务
最后执行实现

听起来朴素，但正因为朴素，才难得。

在一个人人都在追求“更快出结果”的阶段，Spec Kit 没有逆潮流而行，它只是更冷静地指出：真正高级的快，从来不是跳过思考，而是让思考变成流程的一部分。

如果你已经开始和 AI 一起开发项目，如果你正在寻找一种更稳、更清晰、更适合团队协作的方式，那么 Spec Kit 很可能不是你工具箱里的又一个新玩具，而是一条能把混沌工作流整理成方法论的主骨架。

它像一颗种子，名字里写着 Kit，气质里却藏着一整片工程化的花园。

你把它种进项目里，它不会立刻替你开出所有花，但它会先把土翻好，把水路理顺，把季节排明白。

剩下的生长，才会更像生长本来的样子。