Spec Kit 是 GitHub 开源的 AI 编码工作流工具包，采用 MIT 许可。它把需求、技术计划、任务和检查结果写成可以回看的材料，让编程代理沿着明确的目标推进。对于需求容易在对话中改变、实现后又难以判断是否完成的项目，这些材料能给开发和复核提供共同依据。
做新功能、修故障、评估想法，入口各不相同
当前 README 提供三种独立流程。规范驱动开发（SDD）属于核心功能；故障修复和想法评估是按需安装的扩展。它们不要求依次全部跑完，已有项目修一个故障，也不必先补齐一套新功能规范。
| 眼前的问题 | 选择的流程 | 最后看什么 |
|---|---|---|
| 需求已确定，准备实现功能 | SDD：规范 → 计划 → 任务 → 实现 → 收敛 | 代码是否满足规范，剩余差异是否已处理 |
| 某个已有行为出错 | Bug：评估 → 修复 → 验证 | 原始症状是否得到验证，结果是 verified、partial 还是 failed |
| 还没决定是否投入 | Assess：收集 → 研究 → 定义 → 成形 → 决策 | 依据与未知项，以及 go、needs-clarification 或 kill 的决定 |
工具会组织工作过程，模型能力、项目权限、依赖环境和人的判断仍影响结果。生成了任务列表，不能直接当作实现完成；输出了验证报告，也要看它实际检查了什么。
先在终端初始化，再到代理对话里调用
环境需要 Python 3.11+、uv 和受支持的 AI 编程代理，可在 Linux、macOS 或 Windows 上使用。下面沿用当前 README 的 GitHub Copilot 默认 skills 模式示例：
uv tool install specify-cli
specify init my-project --integration copilot
cd my-project初始化后，在项目目录中启动编程代理。下面的 /speckit-* 在代理聊天中逐条调用，不是终端命令。换用其他代理或模式时，集成标识和调用语法要按对应文档调整；固定使用旧版本时，也应查看该版本的命令说明。
用一个相册功能分清“要做什么”和“怎么做”
- 建立项目原则：用
/speckit-constitution写明质量、测试和维护要求。原则通常在项目层建立，后续功能沿用，发生变化时再修订。 - 描述需求：用
/speckit-specify说明相册按日期分组、每组有缩略图预览，以及用户怎样完成操作。此时先说行为和目的，不急着指定所有实现细节。 - 制定技术计划：用
/speckit-plan选择框架、图片存放位置和元数据方案。需要数据库或浏览器能力时，确认所选环境真能支持它们。 - 拆分任务：用
/speckit-tasks形成可执行安排，检查依赖顺序、验收条件和遗漏。 - 实现并收敛：用
/speckit-implement推进，再用/speckit-converge对照规范处理差异；按文档重复实现与收敛，直到报告 Converged。
例如，“照片留在本机”如果是产品约束，就要写进需求并在技术计划中落实。若计划后来引入云端上传，应先解决这处冲突，不能只因为生成代码能运行就放行。这些取舍写进规范后，开发和复核都有依据。
遇到描述含糊或规范与计划不一致时，可以补充澄清、检查清单和一致性分析。一个简单功能只要把行为和验收说明白；复杂权限、数据迁移或外部集成，再增加相应细节。文档多少应由问题决定。
现有代码出错时，走故障流程更直接
在项目目录的终端安装可选扩展：
specify extension add bug然后在代理对话中依次调用 /speckit-bug-assess、/speckit-bug-fix 和 /speckit-bug-test，使用同一个故障 slug。评估要说明复现条件和原因，修复围绕已经评估的原因，验证再回到原始症状。
当前文档把报告放在 .specify/bugs/<slug>/。最终结果有 verified、partial 和 failed，缺少验证不属于成功修复。报告应区分“代码改了”和“原始故障已通过验证”。
不确定是否值得做，先把依据留下来
想法评估扩展通过终端命令 specify extension add assess 安装，随后在代理对话中推进 intake、research、define、shape、decide。这个流程可以用于还没有源码的项目，材料保存在 .specify/assessments/<slug>/。
以离线模式为例，应先弄清用户在哪些场景断网、哪些操作必须可用、重新联网怎样处理冲突，再判断是否开发。结论是 go，可以接入 SDD；证据不足时继续澄清；决定停止时，也能留下原因。研究记录中的来源与未知项，需要读者自己核对。
扩展增加能力，presets 调整已有行为，workflows 自动组织步骤，bundles 打包角色配置；单个项目的临时模板变化可以用项目本地覆盖。改动流程前先明确要解决的重复问题，避免把更多配置本身当作改进。
- 项目仓库与流程说明：
https://github.com/github/spec-kit - 安装与版本选择：
https://github.github.io/spec-kit/installation.html - 代理集成与调用语法：
https://github.github.io/spec-kit/reference/integrations.html
暂无评论内容