用途
Expert Panel 用于在项目需要多视角审查时，派发一组专家评审子代理并行审计项目。每个代理采用一个专家角色独立审查，结果被汇总为一份按严重程度排序的报告，并可作为实施计划的输入。
适用场景包括：
- 上线前审查（“可以上线了吗？”）
- 重构后审计（“有没有改坏什么？”）
- 接手代码库评估（“我们面对的是什么？”）
- 定期健康检查
- 任何项目类型：Web、移动、API、CLI、基础设施、数据管道
工作流程
- 用户请求审查
- 识别项目类型
- 展示该类型的默认专家组
- 建议针对技术栈的补充专家
- 询问：增加、移除还是调整？
- 确定专家组
- 并行派发所有代理（run_in_background）
- 每个代理完成时记录关键发现
- 全部完成后，汇总为按严重程度排序的表格
- 呈现完整报告
- 提出可为修复编写实施计划
按项目类型的默认专家组
Web（静态站点、SPA、服务端渲染应用）
| # | 专家 | 关注领域 |
|---|---|---|
| 1 | SEO 专家 | Meta 标签、标题层级、sitemap、robots.txt、URL 结构、RSS、结构化数据 |
| 2 | 无障碍专家 | 语义 HTML、跳转导航、ARIA、颜色对比度、键盘导航、动效/动画 |
| 3 | 移动 UX 专家 | 视口、响应式 CSS、触摸目标（最小 44x44px）、字号、溢出 |
| 4 | 文案编辑 | 所有模板和内容中的拼写、语法、语气一致性 |
| 5 | 性能专家 | CSS/JS 交付、图片优化、字体、缓存、构建配置 |
| 6 | 安全审查员 | 响应头、XSS 向量、敏感数据暴露、链接安全、CORS |
| 7 | 社交/Meta 标签专家 | OpenGraph、Twitter cards、favicon、canonical URL、分享预览 |
| 8 | Web 标准专家 | HTML 校验、元素使用正确性、规范符合性、ARIA 误用 |
API
| # | 专家 | 关注领域 |
|---|---|---|
| 1 | API 设计审查员 | RESTful 约定、命名一致性、版本控制、分页、错误响应 |
| 2 | 安全审查员 | 认证/授权、输入校验、限流、OWASP API Top 10 |
| 3 | 性能审查员 | 查询效率、N+1 问题、缓存策略、负载大小 |
| 4 | 文档审查员 | OpenAPI/Swagger 完整性、示例准确性、错误文档 |
| 5 | 可靠性审查员 | 错误处理、超时、重试、熔断、优雅降级 |
| 6 | 数据模型审查员 | Schema 设计、迁移、索引、约束、数据完整性 |
移动应用（iOS/Android）
| # | 专家 | 关注领域 |
|---|---|---|
| 1 | UX 审查员 | 导航模式、手势处理、平台约定、引导流程 |
| 2 | 无障碍审查员 | VoiceOver/TalkBack、动态字体、对比度、触摸目标 |
| 3 | 性能审查员 | 启动时间、内存、电量、网络效率、图片处理 |
| 4 | 安全审查员 | 数据存储、keychain/keystore 使用、证书固定、认证流程 |
| 5 | 商店合规审查员 | App Store/Play Store 指南、权限说明、隐私标签 |
| 6 | 文案编辑 | UI 文本、错误消息、引导文案、本地化就绪度 |
CLI 工具
| # | 专家 | 关注领域 |
|---|---|---|
| 1 | UX/人体工学审查员 | 标志命名、帮助文本、输出格式、渐进式披露 |
| 2 | 错误处理审查员 | 错误消息、退出码、边界情况、优雅失败 |
| 3 | 兼容性审查员 | Shell 兼容性、操作系统支持、路径处理、编码 |
| 4 | 安全审查员 | 输入清理、凭据处理、文件权限 |
| 5 | 文档审查员 | man page / --help 完整性、README、示例 |
项目特定补充建议
展示默认专家组后，分析技术栈并建议覆盖缺口的审查员。示例：
- 电商 Web 应用：支付流程审查员、商品目录审查员
- Next.js + Vercel：部署/配置专家
- 认证密集型应用：认证/会话审查员
- i18n 站点/应用：本地化审查员
- 数据管道：数据质量审查员、Schema 演进审查员
由用户决定是否添加，但始终建议相关项。
代理提示模板
每个审查代理的提示必须遵循以下结构：
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
常见错误
- 未让用户自定义专家组——始终先展示默认专家组并询问变更后再派发
- 代理写代码——没有“Do NOT write any code”防护，代理会开始修复而非报告
- 泛泛的提示——“Review the site for SEO”过于模糊。列出 8-12 个具体领域及查看位置
- 顺序派发——所有代理相互独立。始终用 run_in_background 并行派发
- 无来源归属——汇总报告必须显示每个问题由哪位专家发现，以便用户权衡可信度
- 跳过计划步骤——只有发现列表而没有修复计划是不完整的。提出创建实施计划
- 项目类型与专家组不匹配——不要对 API 项目使用 Web 专家组。将默认专家组与项目类型匹配