---
name: dev-review
description: 开发流程 - 需求审核阶段，评估需求相关性、复杂度与可行性，决定推进、拒绝或上报决策
---

# 需求审核

> 开发流程第二阶段：审核需求的相关性、复杂度与可行性，过滤无关需求，拦截复杂/高风险需求上报决策。

## 调用方式

`/dev-review`，也可说"审核需求"。

## 产出目录

`docs/reviews/`（审核通过的记录）
`docs/reviews/pending/`（待决策的审核记录）

## 执行流程

### Checklist

- [ ] 前置检查：读取需求文档
- [ ] 相关性评估
- [ ] 复杂度评估
- [ ] 可行性评估
- [ ] 生成审核结论
- [ ] 更新状态（避免重复触发）
- [ ] 上报决策人（如需要，外部工具占位）

### 1. 前置检查

- 读取 `docs/requirements/` 目录下最新的需求文档
- 读取 `docs/processed-requirements.md` 已处理需求清单（如存在）
- 检查该需求是否已在处理中或已处理，避免重复审核
- 如未找到需求文档，提示用户先运行 `/dev-requirement`

### 2. 相关性评估

判断需求是否属于本系统的业务范围。

**评估标准：**
- 需求的功能领域是否在本系统职责范围内
- 是否涉及本系统已有模块的合理扩展
- 是否属于本团队/项目的维护范围

**结论：**
- **相关** → 继续下一步评估
- **无关** → 直接拒绝，记录原因

### 3. 复杂度评估

评估需求的技术实现复杂度。

| 等级 | 判断标准 | 处理方式 |
|------|---------|---------|
| 简单 | 现有模式直接套用，无新架构 | 直接通过 |
| 中等 | 需要新模块或接口设计，但技术路径清晰 | 直接通过 |
| 复杂 | 涉及架构变更、跨系统协调、性能敏感场景 | 标记需决策 |

**触发"需决策"的典型情况：**
- 需要引入新的技术栈或基础设施
- 涉及大量数据迁移或兼容性问题
- 需要与其他团队/系统协调接口
- 性能要求超出当前架构能力
- 安全合规风险较高

### 4. 可行性评估

检查需求在当前约束下是否可行。

**评估维度：**
- **技术约束**：现有技术栈是否支持
- **资源约束**：人力、时间是否足够
- **依赖约束**：是否依赖外部系统/团队
- **合规约束**：是否符合安全/合规要求

### 5. 生成审核结论

三种结论，只能有一种：

#### A. 通过

需求属于本系统范围，复杂度在可控范围内，可直接进入设计阶段。

**产出：** `docs/reviews/YYYY-MM-DD-<项目名>-review.md`

```markdown
# 需求审核报告

> 对应需求：docs/requirements/YYYY-MM-DD-xxx.md
> 审核日期：YYYY-MM-DD

## 审核结论：通过

## 评估详情
### 相关性：相关
[说明]

### 复杂度：简单/中等
[说明]

### 可行性：可行
[说明]

## 建议下一步
进入设计阶段：`/dev-design`
```

#### B. 拒绝

需求与本系统无关，或技术上不可行。

**产出：** `docs/reviews/YYYY-MM-DD-<项目名>-review.md`

```markdown
# 需求审核报告

## 审核结论：拒绝

## 拒绝原因
- 原因 1
- 原因 2

## 建议
[转交给哪个系统/团队，或建议用户如何调整]
```

**操作：**
- 将需求标记为"已拒绝"
- 更新 `docs/processed-requirements.md`
- 告知用户流程终止，不进入后续阶段

#### C. 需决策

需求相关但复杂度过高或存在不确定性，需要上报决策人评估。

**产出：** `docs/reviews/pending/YYYY-MM-DD-<项目名>-pending.md`

```markdown
# 待决策需求上报

> 对应需求：docs/requirements/YYYY-MM-DD-xxx.md
> 审核日期：YYYY-MM-DD

## 需决策事项

| # | 问题 | 影响 | 建议方案 |
|---|------|------|---------|
| 1 | 涉及架构变更 | 影响现有模块 A、B | 方案 X / 方案 Y |
| 2 | 需要跨团队协作 | 依赖团队 C 的接口 | 先协调再排期 |

## 复杂度评估
[详细说明]

## 推荐决策
[给出倾向性建议]
```

### 6. 更新状态（避免重复触发）

**当前实现（文件占位）：**

更新 `docs/processed-requirements.md`：

```markdown
# 已处理需求清单

| 需求文件 | 审核结论 | 状态 | 处理日期 |
|---------|---------|------|---------|
| YYYY-MM-DD-xxx.md | 通过 | 处理中 | YYYY-MM-DD |
| YYYY-MM-DD-yyy.md | 拒绝 | 已关闭 | YYYY-MM-DD |
| YYYY-MM-DD-zzz.md | 需决策 | 待决策 | YYYY-MM-DD |
```

**后续替换（外部工具接入时）：**

```
# TODO: 接入工单系统 API
# - 通过的工单：调用 set_status(ticket_id, "处理中")
# - 拒绝的工单：调用 set_status(ticket_id, "已拒绝")
# - 需决策的工单：调用 set_status(ticket_id, "待决策")
```

### 7. 上报决策人（外部工具占位）

对于"需决策"的需求，当前流程：

1. 生成 `docs/reviews/pending/xxx-pending.md`
2. 展示给用户，说明需要上报的内容
3. **提示用户手动转发给决策人**

**后续替换（外部工具接入时）：**

```
# TODO: 接入通知渠道
# 方案 A：邮件 MCP server
#   - 调用 send_email(decision_maker, subject, content)
# 方案 B：企业微信/钉钉 Webhook
#   - 调用 send_webhook(url, message)
# 方案 C：工单系统内置通知
#   - 调用 add_comment(ticket_id, "@决策人 请审核")
```

## 流转规则

| 审核结论 | 下一步 | 状态 |
|---------|--------|------|
| 通过 | `/dev-design` | 处理中 |
| 拒绝 | 流程终止 | 已关闭 |
| 需决策 | 等待外部反馈，之后重新 `/dev-review` | 待决策 |

## 关键行为

- 审核不通过时明确说明原因，给出替代建议
- "需决策"不是拒绝，而是暂停等待更多信息
- 每次审核都记录到 `processed-requirements.md`，确保不重复处理
- 用户可覆盖审核结论（强制推进），但记录覆盖原因