## `speckit`：把需求整理成可执行文档

<!-- slot: 目标 -->
`speckit` 不是一个单独技能，而是一组前后衔接的方法。

它解决的问题是：把一句自然语言需求，逐步整理成团队可执行的文档。

这组能力里，最值得长期保留的 4 个子技能是：

- `constitution`
- `specify`
- `clarify`
- `plan`

<!-- slot: 边界 -->
`speckit` 负责产出原则、规格和计划，不直接等于代码实现。

开源仓库：[`github/spec-kit`](https://github.com/github/spec-kit)

<!-- slot: 提示词 -->
```text
请不要直接开始写代码。
先按 `speckit` 的方式整理这件事：
1. 如果缺长期原则，用 `constitution` 定规则
2. 用 `specify` 写清需求规格
3. 用 `clarify` 补齐歧义
4. 用 `plan` 输出技术计划
```

<!-- slot: 流程 -->
### `speckit` 的核心价值

`speckit` 的核心价值，在于把“想法”逐步压缩成“团队可执行的文档”。

很多需求在最开始只是口头目标、模糊方向或一段粗略说明。真正进入研发协作前，团队至少要完成三次收缩：

1. 把长期原则说清楚
2. 把这次要做什么说清楚
3. 把技术上怎么落地说清楚

`speckit` 正是围绕这三层收缩来工作的。

### 四个子技能分别负责什么

#### 长期原则：`constitution`
`constitution` 负责定义长期原则。

它回答的是：这个项目以后在测试、安全、性能、质量、交付方式上，默认遵守什么规则。没有这层，团队每次任务都可能重新争论“什么叫完成”“什么必须补证据”“什么风险可以接受”。

#### 需求规格：`specify`
`specify` 负责把“这次到底要做什么”写成规格。

它要稳定产出的是：目标、范围、用户行为、非目标和验收口径。到了这一步，需求不再只是讨论材料，而应该开始变成可以被团队共同引用的明确文档。

#### 规格补全：`clarify`
`clarify` 负责补齐规格中的歧义。

很多团队的问题不是没写 spec，而是 spec 看起来完整、实际上仍然有关键空洞。`clarify` 的职责就是把这些空洞继续逼出来，避免它们在后续计划或实现阶段才爆炸。

#### 技术计划：`plan`
`plan` 负责把稳定的 spec 继续收敛成技术计划。

到了这一层，团队讨论的重点从“要做什么”切换到“如何拆解、如何落地、依赖是什么、验证路径是什么”。

### 推荐顺序

推荐顺序如下：

1. `constitution`：定义长期原则，如测试、安全、性能、代码质量要求
2. `specify`：把“要做什么”写成规格，重点写清目标、范围、行为和验收口径
3. `clarify`：把 spec 里还没说清楚的地方追问并补齐
4. `plan`：把已经稳定的 spec 继续整理成技术实现计划

可以把这组能力理解成一条链：

**`constitution` → `specify` → `clarify` → `plan`**

### 为什么顺序不能乱

`speckit` 失效时，问题通常不在 skill 本身，而在团队把顺序用反了。

常见情况包括：

- 规格还没稳定，就急着进入 `plan`
- 长期原则没定义，导致每个任务都重新争论质量标准
- `clarify` 被跳过，返工被推迟到代码阶段

一旦顺序错位，团队表面上是在“加速”，实际上只是把不确定性往后推。

### 它和其他 skill 的衔接位置

在这本书推荐的整体流程里：

- `grill-me` / `grill-with-docs` 负责先把问题问清楚
- `speckit` 负责把问题写清楚、定清楚、拆清楚
- `superpowers.test-driven-development` 或其他实现方法，才负责开始真正写代码

因此，`speckit` 处在需求澄清和实现之间，是把模糊输入转成执行文档的中间层。

<!-- slot: 配置 -->
| 子技能 | 解决的问题 | 主要产物 |
| --- | --- | --- |
| `constitution` | 这个项目长期遵守什么原则 | 项目原则 |
| `specify` | 这次到底要做什么 | 需求规格 |
| `clarify` | 规格里还有哪些地方没说清楚 | 补齐后的规格 |
| `plan` | 这件事技术上怎么落地 | 技术计划 |

<!-- slot: 异常 -->
如果项目里已经有成熟模板、规范或长期原则，`speckit` 的价值不是替代这些资产，而是把它们组织进当前任务的规格与计划产物中。

<!-- slot: 审批 -->
高风险需求在进入 `plan` 前，最好先让人确认 spec 是否已经稳定。

<!-- slot: 外部系统 -->
如果项目里已经有长期规范、模板或集成命令，`speckit` 会依赖这些已有资产来产出更稳定的文档。

<!-- slot: 验收 -->
读完本章后，读者应该能解释 `constitution / specify / clarify / plan` 各自负责什么，以及为什么它们必须按顺序衔接。

<!-- slot: 媒体槽位 -->