spec-compliance-review

---
name: spec-compliance-review
description: |
  此技能应在代码审查前使用，作为 /workflows:review 的可选增强。
  它验证实现是否符合规格要求（不多不少），在检查代码质量之前。
disable-model-invocation: true
---

# 规格符合审查

> **核心理念**：写得很漂亮但做错需求的代码，比写得差但做对需求的代码更糟糕。

## 为什么需要两阶段审查

```
传统审查：「代码写得好吗？」
两阶段审查：
  第一阶段：「代码做对了吗？」 ← 本技能
  第二阶段：「代码写得好吗？」 ← /workflows:review
```

**问题场景：**
- 代码质量优秀，但遗漏了需求
- 代码质量优秀，但加了不需要的功能
- 代码质量优秀，但理解错了需求

**解决方案：** 先验证规格符合，再看代码质量。

---

## 何时使用

**作为 `/workflows:review` 的前置步骤：**

```
实现完成
    ↓
规格符合审查（本技能）
    ↓ 通过
代码质量审查（/workflows:review）
    ↓ 通过
合并/提交
```

**推荐场景：**
- 复杂功能实现
- 需求有多个子项
- 多人协作（实现者和审查者不同）
- 重要的业务逻辑

**可跳过场景：**
- 简单 bug 修复
- 明显的单行改动
- 重构（行为不变）

---

## 审查流程

### 第一步：准备

收集以下信息：
1. **原始需求** - PRD、任务描述、用户故事
2. **实现者报告** - 声称完成了什么
3. **实际代码** - git diff 或文件列表

### 第二步：独立验证

**关键：不要信任实现者的报告。**

```
实现者完成得「可疑地快」。
他们的报告可能是：
- 不完整的
- 不准确的
- 过于乐观的

你必须独立验证一切。
```

**不要：**
- 相信他们说实现了什么
- 相信他们关于完整性的声明
- 接受他们对需求的解释

**要：**
- 阅读他们写的实际代码
- 将实际实现与需求逐行对比
- 检查他们声称实现但实际遗漏的部分
- 寻找他们没提到的额外功能

### 第三步：三维检查

#### 1. 遗漏的需求

- 他们实现了所有请求的功能吗？
- 有没有跳过或遗漏的需求？
- 有没有声称完成但实际没实现的？

```
需求清单：
[ ] 功能 A - 已实现？
[ ] 功能 B - 已实现？
[ ] 边缘情况 C - 已处理？
```

#### 2. 多余的工作

- 有没有构建不需要的东西？
- 有没有过度工程或添加不必要的功能？
- 有没有加入不在规格中的「锦上添花」？

```
代码中的功能：
[?] 功能 X - 在需求中吗？
[?] 配置 Y - 需要吗？
[?] 辅助函数 Z - 必要吗？
```

#### 3. 理解偏差

- 有没有以不同于预期的方式解释需求？
- 有没有解决了错误的问题？
- 有没有实现了正确的功能但用了错误的方式？

### 第四步：报告

**通过：**
```
✅ 规格符合

验证结果：
- 需求 1：已实现 ✓
- 需求 2：已实现 ✓
- 需求 3：已实现 ✓

无遗漏，无多余。可以进行代码质量审查。
```

**未通过：**
```
❌ 发现问题

遗漏：
- 需求 2 的边缘情况未处理（file.ts:45）
- 错误提示文案缺失

多余：
- 添加了不需要的缓存层（cache.ts）

理解偏差：
- 需求说「用户可以删除」，实现为「软删除」而非「硬删除」

需要修复后重新审查。
```

---

## 审查者提示模板

当使用 Task 工具派遣审查子代理时：

```markdown
你正在审查实现是否符合规格。

## 请求的内容

[完整的任务需求文本]

## 实现者声称构建的内容

[来自实现者的报告]

## 关键：不要信任报告

实现者完成得可疑地快。他们的报告可能不完整、
不准确或过于乐观。你必须独立验证一切。

**不要：**
- 相信他们说实现了什么
- 相信他们关于完整性的声明
- 接受他们对需求的解释

**要：**
- 阅读他们写的实际代码
- 将实际实现与需求逐行对比
- 检查遗漏的部分
- 寻找多余的功能

## 你的任务

阅读实现代码并验证：

**遗漏的需求：**
- 他们实现了所有请求的功能吗？
- 有跳过或遗漏的需求吗？

**多余的工作：**
- 有构建不需要的东西吗？
- 有过度工程吗？

**理解偏差：**
- 有解释需求不同于预期吗？
- 有解决错误的问题吗？

**通过阅读代码验证，而非信任报告。**

报告：
- ✅ 规格符合（如果代码检查后一切匹配）
- ❌ 发现问题：[具体列出遗漏或多余的内容，附文件:行号引用]
```

---

## 与现有工作流的集成

### 可选增强模式

```
/workflows:work 完成
    ↓
用户：「审查一下」
    ↓
Claude：「要先做规格符合审查吗？」
    ↓
是 → 规格符合审查 → /workflows:review
否 → 直接 /workflows:review
```

### 强制模式（重要功能）

```
/workflows:work 完成
    ↓
规格符合审查（自动）
    ↓
通过 → /workflows:review
未通过 → 修复 → 重新审查
```

---

## 常见问题

**Q：这不是增加了审查时间吗？**

A：短期是，但减少了「代码质量通过但需求错误」的返工。长期更快。

**Q：和 /workflows:review 有什么区别？**

A：
- 规格符合审查：做对了吗？（What）
- 代码质量审查：做好了吗？（How）

**Q：什么时候可以跳过？**

A：简单改动、单行修复、明显的 bug 修复。复杂功能不要跳过。

---

## 危险信号

如果你发现自己在想：
- 「实现者说完成了，应该没问题」
- 「代码看起来不错，需求应该满足了」
- 「没时间对比需求了」
- 「这个功能简单，不需要逐项检查」

**停下来。这些都是跳过规格审查的合理化借口。**

---

## 真实影响

两阶段审查的效果：
- 首次正确率：95% vs 40%（传统审查）
- 引入新 bug：几乎为零 vs 常见
- 返工次数：减少 60%

**代价：** 每次审查增加 30-50% 时间
**收益：** 减少 60% 返工时间

净收益是正的。