experts

专家评审团

概述

并行调度一组专家评审子 Agent，对项目进行审查。每个 Agent 扮演一位专业人士的角色，独立开展评审。随后将结果汇总为一份按严重程度排序的报告，并据此制定实施计划。

适用场景

• 上线前审查（“可以正式上线了吗？”）
• 重构后审计（“有没有破坏什么？”）
• 接手代码库评估（“我们面对的是什么？”）
• 定期健康检查
• 任何项目类型：Web、移动应用、API、CLI、基础设施、数据管道

工作流

digraph expert_review {
  rankdir=TB;
  "User requests review" -> "Identify project type";
  "Identify project type" -> "Present default panel for that type";
  "Present default panel for that type" -> "Suggest stack-specific additions";
  "Suggest stack-specific additions" -> "Ask: add, remove, or adjust?";
  "Ask: add, remove, or adjust?" -> "Finalize panel";
  "Finalize panel" -> "Dispatch all agents in parallel (run_in_background)";
  "Dispatch all agents in parallel (run_in_background)" -> "As each completes, note key finding";
  "As each completes, note key finding" -> "All done?";
  "All done?" -> "As each completes, note key finding" [label="no"];
  "All done?" -> "Consolidate into severity-ranked table" [label="yes"];
  "Consolidate into severity-ranked table" -> "Present full report";
  "Present full report" -> "Offer to write implementation plan for fixes";
}

按项目类型划分的默认评审团

Web（静态网站、SPA、服务端渲染应用）

#	专家	关注领域
1	SEO 专家	Meta 标签、标题层级、站点地图、robots.txt、URL 结构、RSS、结构化数据
2	无障碍专家	语义化 HTML、跳过导航、ARIA、色彩对比度、键盘导航、动态效果／动画
3	移动端 UX 专家	视口、响应式 CSS、触控目标（最小 44x44px）、字号、溢出
4	文案编辑	拼写、语法、所有模板与内容中的语气一致性
5	性能专家	CSS/JS 加载、图像优化、字体、缓存、构建配置
6	安全评审员	安全标头、XSS 攻击向量、敏感数据暴露、链接安全、CORS
7	社交／Meta 标签专家	OpenGraph、Twitter 卡片、网站图标、规范 URL、分享预览
8	Web 标准专家	HTML 验证、正确使用元素、规范合规性、ARIA 误用

API

#	专家	关注领域
1	API 设计评审员	RESTful 约定、命名一致性、版本管理、分页、错误响应
2	安全评审员	身份验证／授权、输入验证、速率限制、OWASP API 十大风险
3	性能评审员	查询效率、N+1 问题、缓存策略、负载大小
4	文档评审员	OpenAPI/Swagger 完整性、示例准确性、错误文档
5	可靠性评审员	错误处理、超时、重试、熔断器、优雅降级
6	数据模型评审员	模式设计、迁移、索引、约束、数据完整性

移动应用（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	文档评审员	手册页／--help 完整性、README、示例

建议添加项目专属评审角色。 呈现默认评审团后，分析技术栈并建议能够弥补评审盲区的角色。示例：

• 电商 Web 应用： 支付流程评审员、商品目录评审员
• Next.js + Vercel： 部署／配置专家
• 身份验证占比高的应用： 身份验证／会话评审员
• i18n 网站／应用： 本地化评审员
• 数据管道： 数据质量评审员、模式演进评审员

由用户决定是否添加这些角色——但始终要提出相关建议。

Agent 提示词模板

每个审查 Agent 的提示词都必须遵循以下结构：

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.

关键要素：

• 先设定角色——“你是一名 [角色]”为 Agent 提供专业定位
• 禁止编写代码——“不要编写任何代码”可防止 Agent 擅自修复问题
• Browser MCP——如果 dev server 正在运行，请提供 URL，让 Agent 检查渲染后的输出，而不只是源代码
• 严重程度分级——要求按结构化方式输出（严重／重要／轻微）
• 编号审查领域——每位审查者列出 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...

每个 Agent 完成后，简要告知用户其主要发现。等所有 Agent 都完成后，再进行完整汇总。

汇总结果

将所有发现整理到一个表格中，去重并按严重程度排序：

## [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）。

报告之后

1. 呈现汇总报告
2. 询问用户是否想逐项处理修复
3. 如果想处理，提出编写实施计划（如果可用，使用 writing-plans skill）
4. 先处理严重问题，再处理重要问题，最后处理轻微问题

常见错误

• 没有询问用户是否要自定义审查面板——始终先展示默认面板，并在调度前询问是否需要修改
• Agent 编写代码——如果没有“不要编写任何代码”的限制，Agent 就会开始修复问题，而不是报告问题
• 提示词过于笼统——“审查网站 SEO”过于含糊。应列出 8–12 个具体领域，并说明查看位置
• 按顺序调度——所有 Agent 都是独立的。务必使用 run_in_background 并行调度
• 没有注明来源——汇总报告必须标明每个问题由哪位专家发现，以便用户判断其可信度
• 跳过计划步骤——只有发现清单而没有修复计划并不完整。应提出制定实施计划
• 面板与项目类型不匹配——API 项目不要使用 Web 面板。默认面板应与项目类型匹配