| name | multi-perspective-review |
| description | 设计方案或实施计划完成后、定稿前需要多角色质量把关时使用（不是 PRD 正式评审会）。 当用户说「审视一下」「帮我审查」「检查这个设计」「review 一下」「看看有没有问题」 「多视角审视」「专家审查」「设计有没有漏洞」时触发。 边界：审查对象是「设计方案/实施计划」。若用户要审的是 PRD——正式评审会用 ai-pm-review，PM 风格 lint 用 ai-pm-driver，不要用本技能。
|
多视角专家审视
并行派发多个专家视角审查设计方案或实施计划，汇总问题清单供用户决策。
所有审视输出必须使用简体中文。
触发时机
- brainstorming 之后 — 设计方案就绪、写入设计文档之前
- writing-plans 之后 — 实施计划写完、开始执行之前
- 用户随时手动调用
流程
输入文档（设计方案或实施计划）
-> 检测范围（前端 / 后端 / 全栈）
-> 选择审视视角
-> 并行派发审视者（每个视角一个 Agent）
-> 汇总去重
-> 呈现问题清单
-> 用户决定修订哪些
第一步：检测范围
读取文档内容，判断涉及哪些层。识别信号：
前端信号：component, page, UI, UX, CSS, styling, layout, dialog, modal,
button, input, form, animation, responsive, Toast, Badge, sidebar, Tailwind, React,
tsx, useState, useEffect, onClick, 组件, 页面, 弹窗, 样式, 交互
后端信号：API, database, SQL, Rust, command, endpoint, reqwest, struct,
Cargo, migration, schema, query, invoke, Tauri command, provider, stream,
数据库, 命令, 接口, 查询
判定：
- 同时有前端和后端信号 ->
全栈
- 只有前端信号 ->
纯前端
- 只有后端信号 ->
纯后端
- 都没有（纯文档/流程变更）->
纯后端（默认走架构审视）
第二步：选择审视视角
| 范围 | 审视者 |
|---|
| 全栈 | 架构师、后端、前端、UI/UX |
| 纯前端 | 前端、UI/UX |
| 纯后端 | 架构师、后端 |
第三步：派发审视者
用 Agent 工具并行派发所有审视者（一条消息中发出所有 Agent 调用）。
每个审视者拿到完整文档 + 视角专属 prompt。
架构师审视
你是一位资深软件架构师，正在审视一份设计方案/实施计划。请用简体中文输出。
审视重点：
- 职责边界：模块/命令的划分是否清晰？
- 数据流：数据路径是否简洁明了？
- 与现有系统的集成：是否与现有代码冲突或重复？
- 过度设计：是否有不必要的复杂性？
- 遗漏的边界情况：错误处理、失败模式、并发问题
- API 设计：接口是否干净一致？
输出问题清单。每个问题标注：严重程度（严重 / 重要 / 建议），
问题描述，具体改进建议。
如果没有发现问题，回复"未发现问题"。
文档内容：
{document_content}
后端审视
你是一位资深后端工程师，正在审视一份设计方案/实施计划。请用简体中文输出。
审视重点：
- 技术可行性：按描述能否实际构建？
- 性能：是否有明显瓶颈（N+1 查询、无界循环、缺少分页）？
- 安全：路径遍历、注入、鉴权绕过
- 错误处理：失败场景是否有有意义的错误信息？
- 依赖：新增依赖是否合理？版本兼容性？
- 可测试性：方案是否易于测试？
输出问题清单。每个问题标注：严重程度（严重 / 重要 / 建议），
问题描述，具体改进建议。
如果没有发现问题，回复"未发现问题"。
文档内容：
{document_content}
前端审视
你是一位资深前端工程师，正在审视一份设计方案/实施计划。请用简体中文输出。
审视重点：
- 组件设计：组件是否可复用、职责是否单一？
- 状态管理：state 提升是否合理？是否有不必要的重渲染？
- 可访问性：键盘导航、ARIA 标签、屏幕阅读器支持
- 性能：大列表是否缺少虚拟化？渲染中是否有重计算？
- 类型安全：TypeScript 类型是否正确完整？
- 与代码库现有模式的一致性
输出问题清单。每个问题标注：严重程度（严重 / 重要 / 建议），
问题描述，具体改进建议。
如果没有发现问题，回复"未发现问题"。
文档内容：
{document_content}
UI/UX 审视
你是一位资深 UI/UX 设计师，正在审视一份设计方案/实施计划。请用简体中文输出。
如果项目有设计规范文件（如 docs/design-system.md），请先读取作为参考基准。
审视重点：
- 认知负荷：是否要求用户一次做太多决策？
- 信息层级：最重要的内容是否最突出？
- 一致性：是否与应用现有模式匹配？
- 反馈：每个用户操作是否有清晰的视觉反馈？
- 边界状态：空状态、加载态、错误态是否都已处理？
- 可关闭性：用户能否关闭/隐藏不需要的内容？
- 文案：语言是否清晰、对目标用户友好？
输出问题清单。每个问题标注：严重程度（严重 / 重要 / 建议），
问题描述，具体改进建议。
如果没有发现问题，回复"未发现问题"。
文档内容：
{document_content}
第四步：汇总呈现
所有审视者返回后，汇总为统一的问题清单：
- 去重：多个视角指出相同问题的，合并为一条，标注来源视角
- 按严重程度排序：严重 > 重要 > 建议
- 用以下格式呈现：
## 多视角审视结果
范围：{全栈 / 纯前端 / 纯后端}
审视视角：{参与审视的视角列表}
### 严重问题
- **[架构师] 问题标题**：描述。建议：...
- **[UI/UX + 前端] 问题标题**：描述（2 个视角同时指出）。建议：...
### 重要问题
- ...
### 建议
- ...
### 未发现问题的视角
- {视角名称}
---
共发现 {N} 个问题。需要修订哪些？
后续处理
呈现问题清单后：
- 等用户决定修订哪些问题
- 用户可能说"全部修"、"只修严重和重要的"、"跳过建议"或指定某几条
- 按用户选择修订设计/计划文档
- 修订后不自动重新审视（避免死循环），除非用户明确要求
注意事项
- 审视者并行派发以提高速度——一条消息中发出所有 Agent 调用
- 每个审视者是独立 Agent，无共享上下文
- 设计规范文件（docs/design-system.md）由 UI/UX 审视者自行读取，不注入其他审视者
- 审视输出保持简洁——只列问题，不表扬、不复述文档内容
- 文档过短（< 20 行）时可能不值得全面审视——先询问用户
