Speckit 规约驱动开发｜CodeBuddy

来源：腾讯云培训认证中心 · CodeBuddy 架构师认证课程 · ch5

第五章 · Chapter 5

Speckit 规约驱动开发

本章学什么

掌握 Speckit 标准七步工作流：constitution → specify → clarify → plan → tasks → analyze → implement
理解三大核心概念：规约驱动 / Constitution 项目宪法 / 先规划后施工闭环
用 Todo App 完整跑一次七步流程；学会旧项目 Bug 修复的简化路径

Speckit 的核心思路是——先写规约，再写代码。先把项目原则、需求、方案、任务和验收标准说清楚，AI 再按规约去执行。把 AI 开发从"直接写代码"升级为"规约驱动开发"。

关键说明 · 考试必记

Speckit（spec-kit）是 GitHub 官方开源的独立工具，地址 github.com/github/spec-kit，不是 CodeBuddy 的内置功能。本模块讲的是：单独安装 Speckit 之后，用 CodeBuddy 作为执行工具来跑 Speckit 工作流。/speckit.* 命令 = Speckit 模板 + CodeBuddy 自定义斜杠指令机制。

5.1 为什么需要 Speckit + 三大核心概念

直接让 AI 写代码 · 三类问题

问题	表现
需求脱节	需求说一套，代码做另一套——边界条件、异常处理和验收标准很容易遗漏
风格混乱	多人协作提示词各写各的，产出像"拼接工程"——命名、目录、处理方式都不统一
不可复现	同样的需求，不同时间生成的结果可能不同，质量很难稳定保障

Speckit 是 AI 时代的工程化护栏系统。

三大核心概念

概念	含义
规约驱动	Spec-driven——先定义"做什么、不能做什么、验收标准"，再进入实现。出问题也优先回到规约层修正，而不是直接改代码。在规约驱动下：维护软件 = 维护规约、调试 = 修复规约、重构 = 重构规约，代码自动重新生成
Constitution 项目宪法	项目的最高原则，决定技术和质量底线——存储方式、测试要求、UI 语言规范、安全与性能优先级。防止 AI 在关键决策上自由发挥
先规划后施工闭环	完整流程：`constitution → specify → clarify → plan → tasks → analyze → implement`。每步都有文档产出，可审计、可回溯

5.2 七步命令全景

命令	作用	产出
`/speckit.constitution`	定义项目不可协商原则——项目的"宪法"	`constitution.md`
`/speckit.specify`	用业务语言写需求（WHAT，不谈实现）	`spec.md`
`/speckit.clarify`	针对 spec 模糊点自动提问、补齐边界——强烈建议执行	更新后 `spec.md`
`/speckit.plan`	需求清晰后生成技术方案（HOW）	`plan.md` + 数据模型
`/speckit.tasks`	任务拆解，按 Phase 分子任务	`tasks.md`
`/speckit.analyze`	一致性检查——确认需求 / 方案 / 任务无矛盾。中大型项目必跑	分析报告
`/speckit.implement`	按任务顺序落地代码——前面所有步骤都是在打地基	可运行代码

三条核心规律

specify 只谈需求不谈实现。 clarify 强烈建议执行——能减少返工。 analyze 是返工预防器——中大型项目必跑。

5.3 快速入门实操 + 分步验收标准

环境准备与初始化

持久化安装 Specify CLI

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

项目初始化（工具选择 CodeBuddy）

specify init my-project复制

初始化会生成 .specify 目录、Git 仓库和相关配置文件。用 CodeBuddy 打开项目即可使用 /speckit.* 命令。

七步流程角色总览

七步流程可以按角色分成三类，每一步都对应明确的人机分工：

角色侧	角色	负责步骤	核心要点
需求侧	项目创始人	Constitution	制定宪法——技术栈 / 部署要求 / 三方库原则
产品经理	Specify + Clarify	自然语言定义 WHAT——功能 / 用户故事 / 验收标准，描述越具体越好
技术侧	架构师	Plan	设计 HOW——技术选型 / 架构 / 数据模型 / API 契约，你拥有最终决策权
审查者	Analyze	沙盘推演——检查 spec / plan 之间有没有矛盾或遗漏
执行侧	项目经理	Tasks	拆解施工步骤——tasks.md 是你与 AI 协作的核心界面，可随时调整优先级
程序员	Implement	按顺序执行开发——复杂任务逐个执行，随时检查每步产出

七步分步验收标准

步骤	验收标准
Constitution	至少 5 条可检查的规则——不要"代码要规范"，要"必须通过 ESLint 且无 error"
Specify	包含主流程、边界条件、异常场景；只写 WHAT，不写技术实现
Clarify	关键歧义必须关闭，每个问题要有明确规则和示例
Plan	技术方案完整覆盖 spec 的核心需求——有缺失先补齐，不要急着进入实现
Tasks	每个任务有目标和完成判定，能按顺序执行——太大的任务拆小
Analyze	没有重大冲突才能进入实现——需求冲突回改 spec，技术不可行回改 plan，覆盖不足重新生成 tasks
Implement	主流程可演示，关键边界可验证——问题回溯到规约，代码按规约执行

5.4 Todo App 全流程实战

用一个 Todo App 串完整流程——从一句话需求到可运行的应用，七步全流程跑通。

需求与宪法

需求目标

新增任务（标题 + 描述）/ 删除任务 / 标记完成 / 状态筛选（全部 / 未完成 / 已完成）/ LocalStorage 持久化。

宪法要点

中文界面；不使用"AI 味"蓝紫渐变，采用清新简洁风格；代码风格统一 Lint / Format；基础测试必须存在；纯前端 LocalStorage。

七步命令脚本

初始化（工具选择 CodeBuddy）

specify init todo-app

Step 1 · Constitution 定义宪法

/speckit.constitution 这是一个任务清单管理系统，中文界面，清新简洁风格，纯前端 LocalStorage 持久化

Step 2 · Specify 编写需求

/speckit.specify 实现任务清单应用：新增任务（标题+描述）、删除任务、标记完成、状态筛选、LocalStorage 持久化

Step 3 · Clarify 需求澄清（AI 提 4-5 个问题，逐一回答）

/speckit.clarify 进行需求澄清

Step 4 · Plan 生成技术方案

/speckit.plan

Step 5 · Tasks 任务拆解

/speckit.tasks

Step 6 · Analyze 一致性检查

/speckit.analyze

Step 7 · Implement 代码实现

/speckit.implement复制

验收清单

功能完整可用——新增、删除、标记完成、筛选都正常
刷新后数据不丢（LocalStorage 持久化生效）
界面是中文且清新简洁（无"AI 味"蓝紫渐变）
控制台无关键报错
基础测试通过

下面这段视频用 Todo App 完整走一遍 Speckit 七步全流程——从宪法到代码落地，全部跑通。

三个高频问题

问题	解决
任务优先级怎么改？	直接编辑 `specs/xxx/tasks.md` 调整任务顺序，重新执行 `/speckit.implement`。`tasks.md` 是与 AI 协作的核心界面，不是只读的
中途暂停怎么办？	implement 执行中可直接打断对话。下次用 `/speckit.implement --continue` 继续——AI 从上次停止的任务继续往下做
数据怎么清空？	浏览器开发者工具 Application 面板手动清空 LocalStorage；或让 AI 在代码里加"清空数据"按钮

5.5 旧项目 Bug 修复

Speckit 不只适合新项目，旧项目修 Bug 同样可以用——简化流程，避免"拍脑袋修"。

简化流程

在旧项目根目录初始化（注意一个点 = 当前目录）

specify init .

Step 1 · 描述缺陷现状和期望结果（必须写清楚验收标准）

/speckit.specify 现状：点击保存会报错；期望：保存成功并展示提示

Step 2 · 修复策略（AI 分析现有代码，输出根因和修复策略）

/speckit.plan

Step 3 · 任务拆解（问题定位 → 代码修复 → 测试验证）

/speckit.tasks

Step 4 · 执行修复

/speckit.implement复制

核心价值：把"拍脑袋修"变成有依据的修复闭环——先描述缺陷 → 分析方案 → 拆任务 → 执行 → 回归验证。

5.6 练习与自测

练习重点是把七步流程完整跑通一遍——不要求项目多复杂，关键是每一步的产出都合格。

三个层级的练习

**Todo App 全流程（必做）。**用 Speckit 跑完一次 Todo App：从 specify init 到 /speckit.implement，七步全走完。验收：每一步都有对应文档产出（constitution.md / spec.md / plan.md / tasks.md），且最终项目能 npm run dev 跑起来
**Clarify 效果对比（推荐）。**同一个项目，一次跳过 Clarify 直接 Plan，一次先 Clarify 再 Plan。对比两次 spec.md 的完整度和 plan.md 的准确度。记录差异——这个实验会让你直观感受 Clarify 的价值
**Analyze 返工预防（进阶）。**故意在 spec.md 和 plan.md 里留一个矛盾（比如 spec 说"纯前端"，plan 却写了后端 API），然后跑 /speckit.analyze，看它能不能发现。能被 Analyze 捕获的矛盾，就是省掉的返工

自测清单

以下问题都能答上来，说明 Speckit 主线已经掌握：

能力维度	自测问题
七步流程	能按顺序说出七步命令和每步的产出文档？/ `specify` 和 `clarify` 的区别是什么（一个只写需求，一个补盲区）？
Constitution	能写出至少 5 条可检查的项目原则（不是"代码要规范"，而是"必须通过 ESLint 且无 error"）？
Analyze 价值	能解释为什么 Analyze 是"返工预防器"而不只是"检查工具"？/ 知道发现冲突后应该回改哪个上游文档？

5.7 核心收获

三个核心要点

**规约是源头。**不要只盯着代码——需求、边界、验收标准都先沉淀到规约里。维护规约，才能稳定维护代码
**Constitution 是护栏。**定义项目不可协商的底线，防止 AI 在关键决策上自由发挥。数据存储、安全要求、测试要求、UI 风格——都先写进宪法
**Analyze 是保险。**真正动手编码前，用 analyze 检查 spec、plan、tasks 是否一致。中大型项目里这一步往往能省掉大量返工

本章小结

规约驱动——先定义，再实现。不要让 AI 上来就写代码，先把需求和边界说清楚
七步闭环——constitution → specify → clarify → plan → tasks → analyze → implement，全程有文档产出，有据可查
质量保障——Constitution 定底线（防 AI 自由发挥）/ Analyze 查一致（防文档互相打架）
新旧通用——新项目完整跑七步，旧项目用简化流程做 Bug 修复闭环

下一模块进入**「Skills 技能系统」**——如果说 Speckit 是把一次开发流程规约化，那么 Skills 就是把重复的 Prompt 工作流封装成可复用的技能包：一次配置，反复使用。