用途
Expert Panel 用于在项目需要多视角评审时，派发一组专家评审子代理并行审计项目。每个代理采用特定专家角色独立审查，结果汇总为按严重程度排序的单一报告，并可进一步生成修复实施计划。
适用场景包括：
- 上线前评审（“可以上线了吗？”）
- 重构后审计（“我们有没有改坏什么？”）
- 接手代码库评估（“我们面对的是什么？”）
- 定期健康检查
- 任意项目类型：Web、移动、API、CLI、基础设施、数据管道
主要能力
按项目类型的默认专家面板
Web（静态站点、SPA、服务端渲染应用）
- SEO 专家 — Meta 标签、标题层级、sitemap、robots.txt、URL 结构、RSS、结构化数据
- 无障碍专家 — 语义化 HTML、跳转导航、ARIA、颜色对比度、键盘导航、动效/动画
- 移动端 UX 专家 — viewport、响应式 CSS、触控目标（最小 44x44px）、字号、溢出
- 文案编辑 — 所有模板和内容中的拼写、语法、语气一致性
- 性能专家 — CSS/JS 交付、图片优化、字体、缓存、构建配置
- 安全评审员 — 响应头、XSS 向量、敏感数据暴露、链接安全、CORS
- 社交/Meta 标签专家 — OpenGraph、Twitter cards、favicon、canonical URL、分享预览
- Web 标准专家 — HTML 校验、元素使用正确性、规范符合性、ARIA 误用
API
- API 设计评审员 — RESTful 约定、命名一致性、版本控制、分页、错误响应
- 安全评审员 — 认证/授权、输入校验、限流、OWASP API Top 10
- 性能评审员 — 查询效率、N+1 问题、缓存策略、负载大小
- 文档评审员 — OpenAPI/Swagger 完整性、示例准确性、错误文档
- 可靠性评审员 — 错误处理、超时、重试、熔断、优雅降级
- 数据模型评审员 — Schema 设计、迁移、索引、约束、数据完整性
移动应用（iOS/Android）
- UX 评审员 — 导航模式、手势处理、平台约定、引导流程
- 无障碍评审员 — VoiceOver/TalkBack、动态字体、对比度、触控目标
- 性能评审员 — 启动时间、内存、电量、网络效率、图片处理
- 安全评审员 — 数据存储、keychain/keystore 使用、证书固定、认证流程
- 商店合规评审员 — App Store/Play Store 指南、权限说明、隐私标签
- 文案编辑 — UI 文本、错误消息、引导文案、本地化准备
CLI 工具
- UX/人体工学评审员 — 标志命名、帮助文本、输出格式、渐进式披露
- 错误处理评审员 — 错误消息、退出码、边界情况、优雅失败
- 兼容性评审员 — Shell 兼容性、操作系统支持、路径处理、编码
- 安全评审员 — 输入清理、凭据处理、文件权限
- 文档评审员 — man page / --help 完整性、README、示例
项目特定补充建议
在展示默认面板后，分析技术栈并建议覆盖空白的评审员。例如：
- 电商 Web 应用：支付流程评审员、商品目录评审员
- Next.js + Vercel：部署/配置专家
- 认证密集型应用：认证/会话评审员
- i18n 站点/应用：本地化评审员
- 数据管道：数据质量评审员、Schema 演进评审员
由用户决定是否添加，但始终建议相关项。
使用方式
工作流
- 用户请求评审
- 识别项目类型
- 展示该类型的默认面板
- 建议技术栈特定的补充项
- 询问：添加、移除还是调整？
- 确定最终面板
- 并行派发所有代理（run_in_background）
- 每个代理完成时记录关键发现
- 全部完成后，汇总为按严重程度排序的表格
- 展示完整报告
- 提供为修复编写实施计划
代理提示词模板
每个评审代理提示词必须遵循以下结构：
You are a [ROLE] reviewing a [PROJECT TYPE] [before launch / after refactor / etc.].
Do NOT write any code — only research and report findings.
If browser MCP tools are available, use them to inspect the running site at [URL].
The project is at [PATH]. [Brief description with key tech details].
Review the following and report issues ranked by severity
(critical, important, minor):
1. [Area] — [What to check, where to look]
2. [Area] — [What to check, where to look]
...
10. [Area] — [What to check, where to look]
Check [key directories]. Report a prioritized list of findings.
关键要素：
- 角色优先 — “You are a [ROLE]” 为代理提供专家框架
- 禁止写代码 — “Do NOT write any code” 防止代理直接修复
- 浏览器 MCP — 如果开发服务器正在运行，包含 URL 以便代理检查渲染输出而非仅源码
- 严重程度排序 — 强制结构化输出（critical/important/minor）
- 编号评审区域 — 每个评审员 8-12 个具体区域，贴合其专长
- 目录提示 — 告知查看位置（src/、配置文件等）
派发模式
对所有评审员使用 Agent 工具并设置 run_in_background: true。在单个消息块中派发所有代理以实现最大并行度。
Agent(description="SEO expert site review", subagent_type="general-purpose", run_in_background=true, prompt="...")
Agent(description="Accessibility expert review", subagent_type="general-purpose", run_in_background=true, prompt="...")
...all agents in one message block...
每个代理完成时，简要向用户记录头条发现。等待全部完成后再进行完整汇总。
汇总结果
将所有发现编译为单一表格，去重并排序：
## [Review Type]: [Project Name]
### CRITICAL (must fix)
| # | Issue | Source |
|---|-------|--------|
| 1 | **[Issue description]** ([specific detail]) | [Which reviewer] |
### IMPORTANT (should fix soon)
| # | Issue | Source |
|---|-------|--------|
### MINOR (backlog)
| # | Issue | Source |
|---|-------|--------|
### DEFERRED (noted, not blocking)
| # | Issue | Source | Reason |
|---|-------|--------|--------|
交叉引用：当多个评审员标记同一问题时，合并为一行并列出所有来源（例如 Standards、A11y、Security）。
报告之后
- 展示汇总报告
- 询问用户是否要处理修复
- 如果是，提供编写实施计划（如可用，使用 writing-plans 技能）
- 先处理 critical 项，再 important，再 minor
适用场景
- 上线前审计
- 重构后检查
- 接手代码库评估
- 定期健康检查
- Web、移动、API、CLI、基础设施、数据管道等任意项目类型
限制与常见错误
- 未让用户自定义面板 — 始终先展示默认面板并在派发前询问变更
- 代理写代码 — 没有 “Do NOT write any code” 防护，代理会开始修复而非报告
- 提示词过于笼统 — “Review the site for SEO” 太模糊。列出 8-12 个具体区域及查看位置
- 顺序派发 — 所有代理相互独立。始终使用 run_in_background 并行派发
- 无来源归属 — 汇总报告必须显示每位专家发现了哪个问题，以便用户权衡可信度
- 跳过计划步骤 — 只有发现列表而没有修复计划是不完整的。提供创建实施计划
- 项目类型面板错误 — 不要对 API 项目使用 Web 面板。将默认面板与项目类型匹配