Multi-Perspective Review

用途

• 把"只从工程视角 review"改成"从多个利益相关方视角同时 review"。
• 适合方案评审、代码评审、上线前检查等需要全面审视的场景。
• 增强现有 /team-review 的覆盖面，补充非工程维度的审视。

预设视角

用户/产品视角

• 这个改动是否真正解决了用户的问题？
• 用户操作路径是否直觉？有没有让用户困惑的状态？
• 异常情况下用户看到什么？能否自助恢复？
• 权限不足、数据为空、网络异常时的体验如何？

工程视角

• 代码可读性、可维护性、边界处理是否到位？
• 测试覆盖是否充分？测试能否捕获回归？
• 性能是否可接受？有没有明显的 N+1、全表扫描、内存泄漏？
• 是否遵循现有架构模式和编码规范？

安全/合规视角

• 输入验证是否到位？有没有注入风险？
• 鉴权和授权是否正确？有没有越权访问的可能？
• 日志中是否泄露敏感信息？
• 数据处理是否符合合规要求？

运维/可观测性视角

• 监控和告警是否配套？关键路径是否有 metric？
• 日志是否结构化且可检索？
• 部署和回滚路径是否清晰？
• 配置变更是否有版本管理？

默认做法

1. 确定评审范围

从 /team-review 或用户请求中接收评审对象：

• 代码变更（diff）
• 方案文档
• 架构设计
• 上线方案

2. 多视角扫描

对每个评审对象，从 4 个视角分别产出发现：

markdown
### 用户/产品视角
- ✅ {通过项}
- ⚠️ {关注项}（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。

配套约束

1. 不替代专项 review：多视角 review 是快速全面扫描，深度问题仍需专项 agent（security-reviewer、database-reviewer）。
2. 证据可追溯：每个发现必须指向具体的代码位置或文档段落。
3. 时间控制：单次多视角 review 控制在 4 个视角以内，避免分析过度。