锦麟 王
5.6 KiB
5.6 KiB
name, description
| name | description |
|---|---|
| dev-review | 开发流程 - 需求审核阶段，评估需求相关性、复杂度与可行性，决定推进、拒绝或上报决策 |
需求审核
开发流程第二阶段：审核需求的相关性、复杂度与可行性，过滤无关需求，拦截复杂/高风险需求上报决策。
调用方式
/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
# 需求审核报告
> 对应需求：docs/requirements/YYYY-MM-DD-xxx.md
> 审核日期：YYYY-MM-DD
## 审核结论：通过
## 评估详情
### 相关性：相关
[说明]
### 复杂度：简单/中等
[说明]
### 可行性：可行
[说明]
## 建议下一步
进入设计阶段：`/dev-design`
B. 拒绝
需求与本系统无关，或技术上不可行。
产出： docs/reviews/YYYY-MM-DD-<项目名>-review.md
# 需求审核报告
## 审核结论：拒绝
## 拒绝原因
- 原因 1
- 原因 2
## 建议
[转交给哪个系统/团队，或建议用户如何调整]
操作：
- 将需求标记为"已拒绝"
- 更新
docs/processed-requirements.md - 告知用户流程终止，不进入后续阶段
C. 需决策
需求相关但复杂度过高或存在不确定性，需要上报决策人评估。
产出： docs/reviews/pending/YYYY-MM-DD-<项目名>-pending.md
# 待决策需求上报
> 对应需求：docs/requirements/YYYY-MM-DD-xxx.md
> 审核日期：YYYY-MM-DD
## 需决策事项
| # | 问题 | 影响 | 建议方案 |
|---|------|------|---------|
| 1 | 涉及架构变更 | 影响现有模块 A、B | 方案 X / 方案 Y |
| 2 | 需要跨团队协作 | 依赖团队 C 的接口 | 先协调再排期 |
## 复杂度评估
[详细说明]
## 推荐决策
[给出倾向性建议]
6. 更新状态（避免重复触发）
当前实现（文件占位）：
更新 docs/processed-requirements.md：
# 已处理需求清单
| 需求文件 | 审核结论 | 状态 | 处理日期 |
|---------|---------|------|---------|
| 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. 上报决策人（外部工具占位）
对于"需决策"的需求，当前流程：
- 生成
docs/reviews/pending/xxx-pending.md - 展示给用户，说明需要上报的内容
- 提示用户手动转发给决策人
后续替换（外部工具接入时）：
# 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，确保不重复处理 - 用户可覆盖审核结论（强制推进），但记录覆盖原因