Spec Kit：把需求先讲清楚，再让 AI 去写代码的 GitHub 开源工具

已经在用 Copilot、Codex、Claude Code 这类 AI 编程工具的人，会最先明白 Spec Kit 的价值：AI 写代码越来越快，但如果一开始需求没说清、边做边改、上下文到处散，最后很容易得到一堆看似能跑、其实不好维护的代码。Spec Kit 想解决的不是“让 AI 更聪明”这个问题，而是把人和 AI 协作时最容易丢失的那部分东西补回来：先定义要做什么、为什么做、怎么拆任务，再让 AI 按这个轨道去实现。

它到底在帮你做什么

Spec Kit 的核心思路可以用一句大白话概括：别一上来就让 AI 写代码，先让 AI 和你一起把“要做什么”写成一套能继续往下执行的说明书。

在普通的软件开发里，需求文档、技术方案、任务列表经常是分散的，甚至写完就没人看。Spec Kit 提倡的 Spec-Driven Development，也就是规范驱动开发，是把这些说明放到开发流程中心。AI 不是凭一句提示词自由发挥，而是根据规范、计划和任务一步步推进。

• 先写项目原则：例如代码质量、测试标准、用户体验、性能要求。
• 再写功能规格：重点讲清“做什么”和“为什么做”。
• 然后写技术计划：选择技术栈、架构和约束。
• 接着拆成任务：把可执行的开发步骤列出来。
• 最后交给 AI 编程助手实现：让实现尽量沿着前面的文档走。

最值得看的不是“生成代码”，而是把流程管住

很多 AI 编程工具的问题不是不能写代码，而是太容易直接开写。Spec Kit 的价值在于给 AI 写代码之前加了几道“减速带”，让人先把意图说清楚。

这对个人开发者和团队的意义不一样。个人用它，可以少一点反复改提示词的混乱；团队用它，则更像是把产品、技术、测试之间的共识固定下来，避免大家对同一个功能各想各的。

• 支持多种 AI 编程助手：项目资料里提到它支持 30 多种 AI coding agent，包括命令行工具和 IDE 里的助手。具体可用列表要以官方集成文档和本地 specify integration list 为准。
• 有一套明确命令流：/speckit.constitution、/speckit.specify、/speckit.plan、/speckit.tasks、/speckit.implement 这些命令，把“想法到实现”的过程拆开了。
• 可以检查和补齐需求：/speckit.clarify 用来澄清不完整的地方，/speckit.analyze 用来分析规格、计划、任务之间是否一致，/speckit.checklist 则能生成质量检查清单。
• 能做扩展和预设：Extensions 用来增加新的命令或工作流，Presets 用来调整规格、计划、任务的模板格式，Bundles 则能把一组配置按角色打包。
• 不绑死技术栈：它强调的是开发方法，而不是只服务某个框架或语言。你可以在计划阶段告诉它项目使用什么技术栈。

举个更贴近日常的例子

假设你想做一个本地照片整理小工具。如果直接丢给 AI 一句“帮我做个照片管理应用”，AI 很可能马上生成一套界面和代码，但细节会非常飘：相册能不能嵌套？照片存在哪里？元数据放哪？拖拽怎么处理？

Spec Kit 的流程会鼓励你先把这些问题写进规格。比如相册按日期分组、相册之间可以拖拽排序、相册不允许嵌套、照片以网格预览、本地存储元数据。这样后面生成计划和任务时，AI 有更清楚的边界。

适合谁，不太适合谁

第一类适合人群，是已经频繁使用 AI 编程助手的开发者。你可能已经感受到，AI 能帮你写很多代码，但越复杂的功能越需要清晰上下文。Spec Kit 就是在帮你整理这个上下文。

第二类适合人群，是小团队、内部工具团队、创业项目里的技术负责人。它不只是个人提示词技巧，而是把需求、原则、计划、任务放进项目目录，让团队以后还能回头看。

• 适合：用 AI 辅助写新项目，希望从 0 到 1 更有章法的人。
• 适合：要在已有项目里逐步加功能、改老代码、做现代化整理的团队。
• 适合：希望把组织里的测试、性能、体验、合规要求提前写进开发流程的人。
• 不太适合：只想让 AI 临时写一个很小脚本、完全不想碰命令行和项目结构的人。
• 不太适合：没有任何开发背景、也没有 AI coding agent 使用经验的普通办公用户。它不是面向纯小白的一键应用生成器。

实际可以怎么用

第一个场景是做新产品原型。你可以先用 /speckit.constitution 约定质量标准，再用 /speckit.specify 写清楚功能边界，接着用 /speckit.plan 指定技术栈，最后拆任务并实现。

第二个场景是给老项目加功能。Spec Kit 的资料里明确提到 brownfield，也就是已有项目的迭代和现代化。这里的重点不是把旧项目推倒重来，而是让新需求有规格、有计划、有任务。

第三个场景是团队统一 AI 开发方式。比如产品经理、业务分析师、安全研究员、开发者可能需要不同的模板和流程，Spec Kit 的 Bundles 概念就是把一组扩展、预设和步骤打成角色化配置。

• 个人项目：减少“想到哪写到哪”的 AI 生成方式。
• 团队协作：让需求和实现之间有可追踪的文档。
• 企业约束：把云平台、技术栈、工程实践、合规要求提前放进计划。

上手门槛：不是点开网页就能用

Spec Kit 是开源开发工具，不是网页 SaaS。安装 CLI 时推荐使用 uv，也可以从 PyPI 安装 specify-cli。项目要求里列出了 Linux、macOS、Windows，Python 3.11+，Git，以及受支持的 AI coding agent。

官方给出的初始化方式是运行 specify init my-project --integration copilot 这类命令，然后进入项目目录，再配合 AI 编程助手使用对应的 slash commands。Codex CLI 的 skills mode 和 GitHub Copilot CLI 有各自的使用差异，这部分需要按官方文档确认。

现在要注意的限制

Spec Kit 解决的是“让 AI 按规格开发”的流程问题，不保证 AI 生成的代码一定正确。测试、代码审查、运行验证仍然要做，尤其是在真实业务系统里。

另外，它的很多能力依赖你所选的 AI coding agent。某些工具使用 slash command，某些工具使用 skills mode，GitHub Copilot CLI 还需要通过 /agents 选择或调用 agent。换句话说，Spec Kit 是一套协作框架，体验好不好也受你现有 AI 工具链影响。

• 社区扩展需要自行审查源码，官方也提醒社区贡献由各自作者维护。
• 扩展、预设、Bundle 很强，但也会带来配置复杂度，不适合一上来全装。
• 目前公开信息里没有把所有集成工具的实际体验差异讲得很细，初次使用最好先选自己已经熟悉的 AI 编程助手。
• 版本更新较活跃，升级时要区分 Spec Kit 管理文件更新和项目规格文档演进，避免把工具升级误当成功能变更。

官方链接和补充资料

如果你准备认真试，建议先看官方 Quick Start，再看 CLI Reference。GitHub 仓库适合看源码、Release 和 Issue；官网文档适合查集成、扩展、预设、Bundle 等使用细节。

• GitHub 仓库：https://github.com/github/spec-kit
• 官网：https://github.github.com/spec-kit/
• 最新 Release：Spec Kit – 0.13.0
• Release 列表：https://github.com/github/spec-kit/releases
• 视频概览：YouTube Video Overview

最后怎么判断值不值得试

如果你已经在用 AI 写项目代码，并且开始讨厌那种“AI 很快，但项目越来越乱”的感觉，Spec Kit 值得现在就试。它不会替你做产品判断，也不会免掉工程基本功，但它能把需求、计划、任务这些容易被跳过的环节重新放回桌面上。

如果你只是偶尔让 AI 写几段脚本，或者还没准备好使用命令行、Git、Python 工具链，可以先观望。Spec Kit 的价值不在轻量娱乐式生成，而在认真把 AI 编程纳入开发流程。愿意多花一点前期整理时间的人，会更容易从它身上得到回报。