锦麟 王
219 lines
5.6 KiB
Markdown
219 lines
5.6 KiB
Markdown
---
|
||
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`，确保不重复处理
|
||
- 用户可覆盖审核结论（强制推进），但记录覆盖原因
|