多角色评审靠视角差异
让同一份输出接受多个专家角色分别点评，再合并成一份修改清单，用视角多样弥补单一视角的盲区。有效的关键在角色绑定具体关注维度：可靠性看失败模式与恢复、安全看权限与数据边界、运维看可操作性。如果角色只换了称呼（「专家 A」「专家 B」），输出会高度雷同，评审等于做了一遍。
基本信息
| 角色设计 | 每个角色绑定具体关注维度，而非只改称呼 |
|---|---|
| 意见条数 | 每个角色固定条数，便于比较覆盖面 |
| 合并阶段 | 去重并按影响排序，形成修改清单 |
| 常见失误 | 点评与裁决混在一段，诱发讨好式评价 |
典型使用场景
- 方案评审：可靠性、安全、可运维三个视角分别点评
- 上线检查：产品、研发、运维各自列出风险点
- 文档评审：读者视角与技术视角分别提出修改意见
- 对外材料审核：合规、品牌、业务三种视角交叉检查
- 架构设计：性能、成本、维护性三个维度分别质疑
评审模板
评审模板
对下面的方案，分别以三种角色各写 2 条意见（必须指到具体句子）：
① 可靠性工程师：关注失败模式与恢复
② 安全工程师：关注权限与数据边界
③ 一线运维：关注可操作性
最后合并为一个修改清单（去重、按影响排序）。
# 角色要绑定关注维度，否则三条意见内容雷同
# 意见必须指到具体句子或步骤，泛泛评价不接受
# 合并阶段做去重与排序，避免同一问题重复列出角色与关注维度
| 角色 | 关注维度 | 典型意见 |
|---|---|---|
| 可靠性工程师 | 失败模式、恢复路径 | 缺少回退步骤，失败后无法快速恢复 |
| 安全工程师 | 权限、数据边界 | 该步骤未说明执行账号的最小权限 |
| 一线运维 | 可操作性 | 命令缺少预期输出，无法判断是否成功 |
| 产品视角 | 用户影响 | 变更会影响哪些用户未说明 |
角色只改称呼不改视角时输出高度雷同；把角色与具体关注维度绑定，评审才有增量。
点评与裁决混在一段会诱发讨好式评价（先夸后提），评审与结论分成两段效果更好。