| name | multi-perspective-review |
| description | 多视角评审技能，融合 gstack 的 CEO/Design/Eng/DevEx 四视角 review 方法论。 在每次评审中从多个角色视角审查同一产出，避免单一视角盲区， 增强现有 /team-review 的评审深度。
|
Multi-Perspective Review
用途
- 把"只从工程视角 review"改成"从多个利益相关方视角同时 review"。
- 适合方案评审、代码评审、上线前检查等需要全面审视的场景。
- 增强现有
/team-review 的覆盖面，补充非工程维度的审视。
预设视角
用户/产品视角
- 这个改动是否真正解决了用户的问题？
- 用户操作路径是否直觉？有没有让用户困惑的状态？
- 异常情况下用户看到什么？能否自助恢复？
- 权限不足、数据为空、网络异常时的体验如何？
工程视角
- 代码可读性、可维护性、边界处理是否到位？
- 测试覆盖是否充分？测试能否捕获回归？
- 性能是否可接受？有没有明显的 N+1、全表扫描、内存泄漏？
- 是否遵循现有架构模式和编码规范？
安全/合规视角
- 输入验证是否到位？有没有注入风险？
- 鉴权和授权是否正确？有没有越权访问的可能？
- 日志中是否泄露敏感信息？
- 数据处理是否符合合规要求？
运维/可观测性视角
- 监控和告警是否配套？关键路径是否有 metric？
- 日志是否结构化且可检索？
- 部署和回滚路径是否清晰？
- 配置变更是否有版本管理？
默认做法
1. 确定评审范围
从 /team-review 或用户请求中接收评审对象：
- 代码变更（diff）
- 方案文档
- 架构设计
- 上线方案
2. 多视角扫描
对每个评审对象，从 4 个视角分别产出发现：
### 用户/产品视角
- ✅ {通过项}
- ⚠️ {关注项}（Revision Gate）
- ❌ {阻塞项}（Abort Gate）
### 工程视角
- ✅ {通过项}
- ⚠️ {关注项}
- ❌ {阻塞项}
### 安全/合规视角
- ✅ {通过项}
- ⚠️ {关注项}
- ❌ {阻塞项}
### 运维/可观测性视角
- ✅ {通过项}
- ⚠️ {关注项}
- ❌ {阻塞项}
3. 综合结论
汇总所有视角的发现，输出：
- 放行建议：放行 / 有条件放行 / 不建议放行
- 阻塞项列表：跨视角合并后的 Abort Gate 项
- 改进项列表：Revision Gate 项，按优先级排序
- 视角覆盖度：标注哪些视角的审查是充分的，哪些因信息不足需要补充
与现有能力的关系
| 能力 | 职责 |
|---|
multi-perspective-review | 多视角审查框架（本技能） |
/team-review | 标准 QA 评审主链命令 |
code-reviewer agent | 工程视角的代码级 review |
security-reviewer agent | 安全视角的深度审查 |
cross-model-review | 跨模型第二意见（可选叠加） |
触发信号
/team-review 中的评审任务。- 方案评审（Design Review Board）。
- 用户要求"全面审查"或"多角度 review"。
- 关键功能（支付、鉴权、数据迁移）的代码 review。
配套约束
- 不替代专项 review：多视角 review 是快速全面扫描，深度问题仍需专项 agent（
security-reviewer、database-reviewer）。
- 证据可追溯：每个发现必须指向具体的代码位置或文档段落。
- 时间控制：单次多视角 review 控制在 4 个视角以内，避免分析过度。
