AI规范驱动开发
先把要做什么和为什么写清楚，再让智能体动手：GitHub开源的Spec Kit用一套模板把需求落成规范、技术方案与可执行任务，让AI写出的代码可评审、可追溯，而不是一句提示词凭感觉生成
工具界面
交互式工具即将上线
功能特点
- ✓ 三个独立入口：造功能走规范驱动开发，修坏掉的行为走缺陷修复，判断点子值不值得投入走想法评估，不必三阶段全跑一遍
- ✓ 模板先定形状：规范长什么样、技术方案包含什么、任务怎么拆，模板先立好，团队不用每次重新发明文档结构
- ✓ 可执行而非摆设：规范最终被拆成智能体能一条条接手的任务，落到实现与收敛，而不是停在README里
- ✓ 不绑定单一智能体：GitHub Copilot、Claude、Cursor等主流编码智能体都可配，换工具不用重写流程
- ✓ 以智能体技能驱动：流程以 /speckit 技能的形式在你的智能体对话里逐步调用，每步人工确认后再继续
使用步骤
- 装好环境：准备Python 3.11+与uv，用 uv tool install specify-cli 装上命令行工具
- 初始化项目：用 specify init 创建工程并指定编码智能体集成，已有代码库另有对应指南
- 在智能体对话里逐步走流程：先写规范（做什么、为什么），再出技术方案，最后拆成任务并实现，每步先评审再往下
- 把规范纳入版本控制并按变更演进：规范是唯一事实来源，改动先改规范再改代码，评审时对照规范看偏离
常见问题
什么是规范驱动开发？
一种把先想清楚再动手写进工程流程的做法：先把要解决的问题、为什么做、验收标准写成规范，再让编码智能体按规范出技术方案与任务并实现。GitHub开源的Spec Kit把它做成了模板、脚本与技能的组合，官方定位是给AI编码智能体结构化的流程、可复用的模板与有据可查的产出。见 https://github.com/github/spec-kit
它和常见的氛围编程差在哪？
差在可评审与可追溯。氛围编程是把一句提示词丢给模型，改了哪里、为什么这么改往往说不清；规范驱动开发先把需求固化成文档，智能体的产出可以对照规范逐条验收，回归时也能看出偏离。微软官方博客把Spec Kit的定位写成从氛围编程走向按规范交付，参考 https://developer.microsoft.com/blog/spec-driven-development-spec-kit
三个流程必须按顺序全跑一遍吗？
不用，三者是各自独立的入口而不是三个阶段。要造功能或应用走规范驱动开发；要诊断和修复坏掉的行为走缺陷修复；要判断一个点子值不值得投入走想法评估。按官方说明，核心内置的是规范驱动开发，缺陷修复与想法评估是需要时再安装的扩展。见 https://github.com/github/spec-kit
需要什么前置条件和智能体？
官方要求Python 3.11+、uv，以及一个受支持的编码智能体，Linux、macOS与Windows都能跑。安装用 uv tool install specify-cli，初始化用 specify init。它不提供模型本身，只提供流程与模板，所以Copilot、Claude、Cursor等都可接入。见 https://github.com/github/spec-kit 与集成说明 https://github.github.io/spec-kit/reference/integrations.html
已经有代码库了还能用吗？
可以。官方专门提供了面向既有项目的指南，常见做法是先把现状反推成规范与架构说明，再让智能体在规范约束下改代码，避免它按自己的想象把你的系统重写一遍。见 https://github.github.io/spec-kit/guides/existing-projects.html 与主仓库 https://github.com/github/spec-kit
规范会不会变成没人看的文档负担？
关键看规范是不是真的被用来验收。若规范被拆成智能体逐条执行的任务，并在评审时对照它检查偏离，它就是活的；若只写不查，就会退化成摆设。社区里也有争论，认为碎片化的增量规范如果不作为系统唯一事实来源，就只是换了个壳的氛围编程，这类讨论见 https://github.com/github/spec-kit/discussions/152