Spec Kit：把 AI 编程从提示词拉回工程流程

AI 编程工具发展到今天，最大的问题已经不是“能不能写代码”，而是“怎么让它稳定地写对代码”。

很多团队第一次使用 AI Coding Agent 时，会自然地采用提示词驱动的方式：告诉它要做什么，等它生成代码，然后人工检查。这个流程在小脚本、Demo、一次性页面里很高效；但需求稍微复杂一点，问题就会出现：上下文散落在聊天记录里，验收标准没有固化，技术方案和任务拆分靠模型临场发挥，最后人要花大量时间判断“它到底有没有理解我的意思”。

GitHub 开源的 Spec Kit 正是针对这个问题而来。它不是又一个代码生成器，而是一套面向 AI 辅助开发的规格驱动开发工具包。它试图把 AI 编程从“凭感觉写提示词”拉回更接近工程实践的路径：先定义规格，再做计划，然后拆任务，最后实现。

Spec Kit 是什么

Spec Kit 的定位是 Spec-Driven Development（SDD，规格驱动开发）工具包。官方文档给出的核心描述很直接：先定义要构建什么，再让任意 AI Coding Agent 去构建。

它的基本工作流可以概括为四步：

Spec：描述要做什么、为什么要做、用户故事和功能需求是什么。
Plan：补充技术栈、架构选择、约束和实现策略。
Tasks：把规格和计划拆成可执行的任务列表。
Implement：让 AI Coding Agent 按任务实现功能。

这个流程的关键不在命令名字，而在每一步都会产出 Markdown 工件。规格不是一次性提示词，也不是会议后没人看的文档，而是后续计划、任务和实现的输入。换句话说，Spec Kit 想让“需求上下文”成为项目的一部分，而不是停留在对话窗口里。

它解决的不是代码生成，而是上下文治理

如果只把 Spec Kit 理解成“多了几个 slash command”，会低估它的价值。

AI 写代码的短板通常不在语法层面，而在上下文层面。模型很容易写出看似合理的实现，但它不知道团队真正的约束：哪些行为不能破坏，哪些边界条件必须覆盖，项目里哪些设计原则优先级更高，哪些技术选型是既定事实。

Spec Kit 的第一步是建立项目原则，也就是通过 /speckit.constitution 生成或更新 .specify/memory/constitution.md。这个文件记录代码质量、测试标准、用户体验一致性、性能要求等项目治理规则。后续的规格、计划和实现都要参考这些原则。

然后再用 /speckit.specify 写功能规格。官方特别强调，这一步应该聚焦“做什么”和“为什么”，不要急着讨论技术栈。技术方案放到 /speckit.plan 阶段处理，任务拆分交给 /speckit.tasks，实现则由 /speckit.implement 执行。

这套拆分的好处是把原本混在一个提示词里的内容分层了：业务目标、技术方案、任务列表、实现过程，各自有自己的产物和检查点。人可以在每一层介入，而不是等代码全部生成后再返工。

快速使用方式

Spec Kit 通过 Specify CLI 初始化项目。官方 README 推荐使用 uv 安装，也支持其他持久化安装方式。截至 2026-06-12，GitHub Releases 页面显示最新版本为 v0.10.2，安装命令如下：

1
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@v0.10.2

初始化项目时指定 Agent 集成：

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

如果是在当前目录初始化，也可以使用：

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

初始化完成后，项目里会出现 .specify 目录和对应 Agent 的命令或 Skill 文件。不同 Agent 的入口不同：大多数工具使用 /speckit.* slash command；Codex CLI 的 skills 模式使用 $speckit-*；GitHub Copilot CLI 则通过 /agents 选择或调用 Agent。

一个典型流程大致是：

1
2
3
4
5
6
7
/speckit.constitution  建立项目原则
/speckit.specify       编写功能规格
/speckit.clarify       澄清模糊需求
/speckit.plan          制定技术计划
/speckit.tasks         生成任务清单
/speckit.analyze       检查规格、计划和任务是否一致
/speckit.implement     执行实现

其中 clarify、analyze、checklist 属于增强质量的命令。对正式项目来说，它们比看起来更重要：需求没有澄清就进入计划阶段，后面大概率会把不确定性变成代码债。

多 Agent 支持是它的现实主义设计

Spec Kit 没有把自己绑定到某一个 AI Coding Agent 上。官方文档显示，它支持 30 个左右的集成，包括 Copilot、Gemini、Codex、Windsurf、Claude、Forge、Kiro 等。如果没有对应集成，也可以使用 generic 作为兜底方式。

这点很实用。真实团队很少永远只用一个 Agent：有人习惯 IDE 插件，有人偏好 CLI，有人需要在 CI 或远程环境里跑自动化流程。Spec Kit 试图把“开发方法”和“具体 Agent”解耦：规格、计划、任务这些项目工件保持一致，执行者可以替换。

它还提供扩展和预设机制。扩展适合新增能力，比如 Jira 集成、代码审查、领域工作流；预设适合改变模板和术语，比如加入合规字段、修改规格格式、适配某种工程方法。官方文档截至 2026-06-12 展示的数据是 105 个社区扩展、22 个预设、200 多位贡献者。这个生态方向说明 Spec Kit 不只想做一个模板仓库，而是想成为 AI 工程流程的可组合底座。

适合什么场景

Spec Kit 最适合三类场景。

第一类是从 0 到 1 的新功能。需求还没变成代码时，用规格先把用户故事、功能需求和验收条件写清楚，再生成计划和任务，能减少 AI 一上来就选择技术路径的冲动。

第二类是团队协作中的功能开发。多人参与时，聊天记录不是可靠的协作界面。规格、计划和任务落到仓库里，评审、修改和追溯都更自然。

第三类是对质量有要求的 AI 自动化流程。比如希望 AI 不只是“帮我写代码”，还要先澄清问题、生成 checklist、分析产物一致性，再开始实现。Spec Kit 提供的阶段化流程可以作为质量门禁的基础。

它不太适合所有事情。一次性脚本、很小的页面修改、明确到只有几行代码的 bug fix，用完整 SDD 流程可能显得重。它也不能替代产品判断和工程判断：规格写得含糊，计划就会含糊；任务拆错了，实现也会沿着错误方向前进。

我对 Spec Kit 的判断

Spec Kit 的价值不是让 AI “更聪明”，而是让 AI 更难跑偏。

过去我们习惯把提示词写得越来越长，试图把所有背景、约束、代码风格、验收标准一次性塞给模型。这个方法会遇到上限：提示词越长，维护成本越高；聊天轮次越多，关键决策越容易埋在历史上下文里。

Spec Kit 换了一个角度：把上下文产品化。项目原则是文件，规格是文件，计划是文件，任务是文件。文件可以评审，可以提交，可以 diff，可以作为下一步工作的输入。对软件工程来说，这比“我记得上次在对话里说过”可靠得多。

当然，它也会带来新的要求。团队需要愿意写规格，需要维护模板，需要判断哪些场景值得启动完整流程。否则，Spec Kit 也可能变成另一套形式化文档。

如果你正在尝试把 AI Coding Agent 引入真实项目，而不是只用它写零散代码，Spec Kit 值得认真看一遍。它提醒我们一件事：AI 编程的核心竞争力，可能不是谁的提示词更花哨，而是谁能把需求、约束和反馈组织成可持续运转的工程系统。