| name | hany-planreview |
| description | 需求文档评审优化。触发:/hany:planreview。针对已创建的需求文档,挑战不合理性并优化文档质量。 |
| author | hany |
| version | 1.0 |
hany-planreview — 需求文档评审 & 优化
触发方式:/hany:planreview
调用方:可独立触发 /hany:planreview,也可由 hany-auto Step 2.5 自动调用。
核心原则:不盲从,敢质疑。用批判性思维审视每一条需求,识别逻辑漏洞、边界不清、不可行之处,然后给出优化建议。
编码约束:读取 hany-common/rules/rules.md,11 条规则全程生效。
适用场景
- 需求文档刚创建完成,需要评审
- 需求实现前,想再次确认合理性
- 发现需求有矛盾、模糊或不合理之处
恢复检查
启动时检查 docs/hany/requirements/ 下是否有正在进行评审的文档(含评审相关的中间状态标记)。如果存在,使用 AskUserQuestion 询问:继续上次 / 重新开始。
评审维度
- 完整性 — 需求是否覆盖所有关键场景?是否有遗漏?
- 一致性 — 文档内部是否有矛盾?与其他相关文档是否冲突?
- 可行性 — 技术上是否能实现?资源是否足够?
- 清晰性 — 描述是否模糊、有歧义?边界条件是否明确?
- 合理性 — 需求本身是否合理?是否有过度设计或不必要的复杂性?
- 可测试性 — 是否能够验证需求被满足?
工作流程
Step 0:定位需求文档
查找 docs/hany/requirements/ 目录下的需求文档:
- 如果用户指定了文档,直接使用
- 如果未指定,列出目录下的文档供用户选择
Step 1:读取并初步分析
- 读取需求文档全文
- 了解项目背景和技术栈
- 识别文档结构是否完整
Step 2:逐条质疑与评审
对文档中的每一条需求进行批判性审视:
- 功能描述:是否清晰、无歧义?
- 验收标准:是否可验证、可测试?
- 边界条件:是否覆盖了边界情况?
- 优先级:是否合理?
- 依赖关系:是否明确?
Step 3:输出评审报告
## 评审报告
### 发现的问题
| 编号 | 位置 | 问题描述 | 严重程度 | 建议 |
|------|------|----------|----------|------|
| 1 | ... | ... | 高/中/低 | ... |
### 优化建议
1. ...
### 总体评价
- 完整性:X%
- 一致性:X%
- 可行性:X%
- 清晰性:X%
Step 4:与用户确认
- 询问用户是否接受评审意见
- 根据用户反馈调整
- 生成优化后的需求文档
Step 5:输出优化版本
- 生成优化后的需求文档
- 保存到原文档同级目录,命名加
-review 后缀
- 或直接覆盖原文档(用户确认后)
注意事项
- 敢质疑:不要因为需求是"用户写的"就不敢质疑
- 讲证据:每一条质疑都要有理由支撑
- 提方案:指出问题的同时给出解决方案
- 看全局:不仅要审视单条需求,还要看需求之间的关联