核心工作流：六阶段详解

这一阶段做什么

Constitution 的作用是定义项目中不可违反的工程原则与技术约束，例如技术栈边界、测试要求、安全边界、代码规范、接口规范等。 这份“宪法”会在后续阶段被持续引用，因此它不是一次性的说明文，而是团队一致性的治理文件。

产出文件：.specify/memory/constitution.md

宪法通常包含哪些内容

• 技术栈约束：后端、前端、数据库、不可引入的框架。
• 测试优先：覆盖率目标、测试类型、提交前门槛。
• 安全边界：权限校验、敏感数据处理、密钥管理。
• 代码规范：命名、层次职责、文档要求。
• 接口规范：响应格式、分页约定、风格限制。

操作步骤

1. 在 Claude Code 中执行 /speckit.constitution。
2. 告诉 Claude 你们的技术栈、编码规范、测试策略和安全要求。
3. 审阅生成的宪法文件，确认描述清楚、没有冲突。
4. 将它提交到项目仓库，作为团队共享约束。
5. 后续所有阶段都以它为准，不再反复口头说明。

这一阶段做什么

Specify 负责把自然语言需求转成结构化的 spec.md。 它会自动分配功能编号、创建功能目录，并根据模板组织用户场景、功能需求、边界条件、成功标准等内容。

产出文件：specs/NNN-feature-name/spec.md

核心流程

1. 你用自然语言描述一个功能需求。
2. spec-kit 扫描 specs/ 目录，计算下一个编号。
3. 自动创建 Git 分支和功能目录。
4. Claude 读取 spec-template.md，生成结构化规格文档。

spec.md 常见结构

# 003-exam-registration 功能规格

## 用户场景
### P1（核心场景）
作为考生，我想在线报名参加考试，以便不用去现场排队

#### 验收标准（Gherkin）
- Given 考生已登录且资格审核通过
- When 考生选择考试科目并提交报名
- Then 系统生成报名确认单并发送短信通知

## 功能需求
- FR-001：报名表单包含姓名、身份证号、报考科目、照片上传
- FR-002：身份证号需实时校验格式和重复性
- [NEEDS CLARIFICATION: 是否支持多次报名不同科目？]

## 边界条件
## 成功标准

这一阶段最重要的设计点

• 优先级分层：P1 是 MVP，P2/P3 可以后续迭代。
• Gherkin 验收标准：Given / When / Then 方便测试直接编写用例。
• 模糊点显式标记：用 [NEEDS CLARIFICATION] 明确指出不确定项。
• 每个用户故事独立可测试：便于分批实现、分批验证、分批上线。

这一阶段做什么

Clarify 会扫描 spec.md，识别模糊、缺失、冲突的部分，按优先级生成若干澄清问题。 它不是“重新写一遍规格”，而是用问答方式把不确定项逐个落地到原规格中。

典型流程

1. 扫描 spec.md，按功能范围、数据模型、交互体验、非功能属性、边界情况等维度检查模糊性。
2. 给每类问题标记为 Clear / Partial / Missing。
3. 挑出优先级最高的最多 5 个问题。
4. 逐个向你提问，并把答案自动写回规格。
5. 确保没有重复、矛盾或含糊表述残留。

产出：更新后的 spec.md 与澄清记录。

为什么推荐使用

• 能显著减少 Plan 阶段反复返工。
• 能避免实现时才发现需求没定义清楚。
• 对产品经理尤其有价值，因为它能把“隐含决策”显性化。

这一阶段做什么

Plan 负责把功能规格转换成技术实现方案。 它不直接写代码，而是先把技术上下文、数据模型、接口设计、约束检查、复杂度评估梳理清楚，确保实现前所有关键设计都已成文。

产出文件：specs/NNN-feature/plan.md，以及可能生成的 data-model.md、contracts/、quickstart.md

plan.md 通常包含什么

• 宪法检查：方案是否满足项目基本法。
• 技术上下文：语言、框架、数据库、测试工具。
• 数据模型：实体字段、约束、关系。
• 接口设计：API、入参出参、权限要求。
• 复杂度评估：哪些模块简单，哪些模块有技术风险。

Plan 阶段的三个子阶段

这一阶段做什么

Tasks 会根据 plan.md 把实现工作拆成阶段化的任务，明确依赖顺序、用户故事归属、可并行执行标记和文件路径。 它是连接“设计”与“编码”的桥梁。

产出文件：specs/NNN-feature/tasks.md

任务清单中的关键标记

依赖关系规则

Setup → Tests → Models → Services → Controllers → Integration → Polish

默认强调测试先行（TDD 红-绿-重构），标记了 [P] 的任务可以由不同人或不同 AI 并行推进。

执行策略

这一阶段做什么

Implement 会加载 tasks.md、plan.md 和相关文档，按阶段顺序执行任务。 它的价值不在于“自动生成代码”本身，而在于代码生成过程是被任务清单强约束的：有前置依赖、有目标文件、有完成回写。

典型执行流程

1. 加载 tasks.md、plan.md 和补充设计文档。
2. 检查是否有未完成 checklist，如有则先确认。
3. 按 Phase 顺序执行：Setup → Tests → Core → Integration → Polish。
4. 有依赖的任务等待前置完成后再开始。
5. 标记 [P] 的任务允许并行。
6. 每完成一项任务，就在 tasks.md 中把 [ ] 更新为 [x]。
7. 若非并行任务失败，则暂停并报告错误。

这一阶段的关键行为

• 持续参考宪法文件，确保代码符合团队约束。
• 优先写测试，再写实现，遵循 TDD 节奏。
• 任务中明确写了文件路径，避免 AI 放错位置。
• 扩展可以在实现前后自动执行钩子，例如 lint、测试或同步动作。

这一阶段做什么

Analyze 是一个只读检查器，不负责改文件，只负责指出问题。 它会跨越 spec.md、plan.md、tasks.md 以及实现代码，找出不一致、未覆盖、术语冲突和宪法违规等问题。

检查维度

产出与特点

• 输出结构化分析报告，通常包含严重级别、位置与修复建议。
• 发现数可控，避免一次返回过多无关噪音。
• 只读，不会自动改任何文件，因此适合作为阶段性审阅工具。

这个命令适合什么时候用

• 实现完成后，准备提 MR / PR 前。
• 需要和产品、测试一起过功能验收时。
• 想从“有没有写完代码”升级到“有没有真正满足规格”时。

它的价值

Checklist 会基于 spec.md 自动生成可勾选的质量检查项。 它适合做最后一公里核对：不是讨论设计，而是确认每条需求、边界条件、成功标准是否已经在实现中有对应落点。