多角色 PR 审查团队

技能文档

---
name: mgiovani-team-review
title: 多角色 PR 审查团队
description: 组建多角色审查团队对 PR、提交或整个代码库做深度代码审查：架构、安全、性能、测试、风格、文档与用户体验六类专家审查员加一名对抗审查员，并行审查、交叉汇总、分级输出报告，并支持修复后的增量复审。当用户请求深度 PR 审查、多维度代码审查、安全敏感或架构级改动评审、大型改动审查时触发。触发词：团队审查、PR 审查、多角色评审、深度代码审查、安全审查、架构评审。
category: 开发工具
---

# 多角色 PR 审查团队

通过多代理团队协作完成全面的 PR 代码审查：并行启动 6 名专家审查员与 1 名对抗审查员。适用于安全敏感、架构级或高影响的代码变更——单一审查者难以覆盖的场景。

改动简单时，可直接使用单审查者方式，成本更低。

## 前置说明

- **完整模式**（7 名审查员并行）：需要运行环境支持并行子任务/子代理能力；不支持时自动降级为精简模式。
- **精简模式**（`--lite` 或自动降级）：用 4 个合并角色的子任务替代完整团队，审查员更少、成本更低，仍然全面。
- **仅分析不改码**：本技能只识别问题，不修改代码；修复请交给修复类技能或人工处理。

## 输入

用户以自然语言给出审查对象，可以是：PR 编号（如 `123` 或 `#123`）、提交 SHA（如 `abc123`）、`--all`（整个代码库），以及可选的 `--lite`（强制精简模式）与 `--focus <领域>`（只启动相关审查员）。

## 已知限制

- **无会话恢复**：会话中断后并行审查员会丢失，需要重新发起
- **每次一个团队**：同一会话不能同时运行多个团队审查
- **只分析不改码**：识别问题但不修改代码
- **任务状态可能滞后**：审查员偶尔忘记标记任务完成，协调者需主动跟踪

## 反幻觉准则

**关键要求**：所有审查员必须遵守：

1. **先读后说** —— 没读过的代码不得报告问题
2. **结论必须有据** —— 每条发现必须给出具体文件路径和行号
3. **结合上下文核实** —— 确认模式确实有问题，而非有意设计
4. **不制造误报** —— 不确定时标注「需人工确认」，不断言
5. **范围约束** —— 只审查指定范围内的文件（PR/提交/全库）
6. **尊重项目约定** —— 先理解既有模式，再判断风格问题

## 技能工作流

整体流程：

```
阶段0：范围识别与输入解析
阶段1：项目勘察
阶段2：团队编成与启动
阶段3：并行专家审查（6 名审查员 + 1 名对抗审查员）
阶段4：汇总与交叉引用
阶段5：报告生成
阶段6：收尾

可选：修复后的迭代复审
```

### 步骤1：范围识别与输入解析

从用户输入解析审查对象：

| 输入模式 | 来源类型 | 获取方式 |
|---------|---------|---------|
| `123` 或 `#123` | PR 编号 | `gh pr view 123 --json files,title,body,labels,comments` + `gh pr diff 123` |
| `abc123` | 提交 SHA | `git show abc123` + `git diff-tree --no-commit-id --name-only -r abc123` |
| `--all` 或无参数 | 整个代码库 | `git ls-files`（遵循 .gitignore） |
| `--lite` | 强制精简模式 | 使用合并角色的并行子任务 |
| `--focus <领域>` | 聚焦领域 | 只启动相关审查员 |

**PR/提交审查必须取全量 diff 上下文**：审查员的发现应聚焦在变更行，同时用周边代码做上下文。

### 步骤2：项目勘察

先了解项目背景（可交给轻量子任务执行）：

```
勘察项目的技术栈、编码约定与质量标准：
  1. 阅读 AGENTS.md、README.md 等项目约定文档
  2. 检查 package.json、pyproject.toml、pom.xml、go.mod 确认语言/框架
  3. 识别 lint/格式化配置：.eslintrc、.prettierrc、ruff.toml、.editorconfig
  4. 识别测试框架与测试模式
  5. 检查 CI/CD 质量门禁（.github/workflows 等）
  6. 记录架构模式：MVC、整洁架构、DDD 等
  7. 识别安全工具：SAST、依赖扫描、pre-commit 钩子
返回：技术栈、约定、质量标准与安全工具综述。
```

### 步骤3：团队编成与启动

**评估复杂度**，决定完整/精简模式：

| 信号 | 完整模式 (+2) | 中等 (+1) | 精简模式 (0) |
|------|--------------|-----------|-------------|
| 变更文件数 | 15+ 个 | 5-14 个 | <5 个 |
| 安全敏感度 | 认证、支付、个人敏感数据 | 权限校验 | 无敏感数据 |
| 架构影响 | 新模式、schema 变更 | 修改既有模式 | 局部改动 |
| 跨模块关注点 | 多模块/多服务 | 2 个组件 | 单组件 |

**阈值**：
- 得分 0-2：自动使用**精简模式**
- 得分 3-4：询问用户（出于成本建议精简）
- 得分 5+：自动使用**完整模式**

**覆盖**：`--lite` 强制精简模式。

**完整模式团队**（各角色完整提示词见 [references/agent-catalog.md](references/agent-catalog.md)）：

| 角色 | 标识 | 模型档位 | 关注点 |
|------|------|---------|--------|
| 架构审查员 | `arch-reviewer` | 高性能 | 系统设计、API 契约、数据建模、依赖图 |
| 安全审查员 | `security-reviewer` | 标准 | OWASP Top 10、认证授权、输入校验、密钥 |
| 性能审查员 | `perf-reviewer` | 标准 | 算法复杂度、查询、缓存、内存 |
| 测试审查员 | `test-reviewer` | 标准 | 覆盖缺口、断言质量、测试架构 |
| 风格与模式审查员 | `style-reviewer` | 标准 | 命名、DRY/SOLID、框架惯用法、可读性 |
| 文档与体验审查员 | `docs-reviewer` | 轻量 | API 易用性、错误信息、文档、变更记录 |
| 对抗审查员 | `adversary-reviewer` | 标准 | 挑战假设、发现边界情况、压测设计 |

**精简模式**（4 个合并角色子任务）：

| 合并角色 | 覆盖 | 模型档位 |
|---------|------|---------|
| 架构与安全 | arch-reviewer + security-reviewer | 标准 |
| 性能与风格 | perf-reviewer + style-reviewer | 标准 |
| 测试与错误处理 | test-reviewer + 边界情况 | 标准 |
| 对抗与文档 | adversary-reviewer + docs-reviewer | 标准 |

**聚焦模式**：指定 `--focus` 时只启动相关审查员：

| 聚焦领域 | 启动的审查员 |
|---------|-------------|
| `architecture` | arch-reviewer、adversary-reviewer |
| `security` | security-reviewer、adversary-reviewer |
| `performance` | perf-reviewer、adversary-reviewer |
| `testing` | test-reviewer、adversary-reviewer |
| `style` | style-reviewer、docs-reviewer |

### 步骤4：并行专家审查

所有审查员同时处理同一批文件，各自遵循 agent-catalog 中的专属提示词。

**任务分配**：为每个审查员创建独立任务并跟踪状态（如「PR #N 架构审查」「PR #N 安全审查」……），完成后逐一销账。

**每位审查员收到**：
1. 范围内文件清单
2. 全量 diff（PR/提交审查时）
3. 阶段 2 的项目勘察结果
4. 自己的专属审查提示词

**每位审查员必须**：
1. 逐个读取范围内文件
2. PR 审查时聚焦变更行、以周边代码为上下文
3. 按自身维度检索特定模式
4. 结合上下文读码核实每条发现
5. 评定严重级别：Critical / Major / Minor / Nit
6. 以结构化格式写出发现：file:line、代码片段、说明、修复建议
7. 将自己的审查任务标记为完成
8. 把发现汇总提交给协调者

**对抗审查员（特殊角色）**：
1. **等待**至少 3 名其他审查员的初步发现（由协调者转发摘要）
2. **质疑**这些发现：有没有误报？严重级别准确吗？
3. **找缺口**：其他审查员漏了什么？哪些假设未经检验？
4. **压测**：规模放大 10 倍会怎样？输入恶意会怎样？依赖故障会怎样？
5. **汇报**：补充发现 + 对既有发现的质疑

### 步骤5：汇总与交叉引用

全部审查员完成后，协调者：

1. **收集** 7 名审查员（6 专家 + 1 对抗）的全部发现
2. **去重** —— 合并多名审查员重复标记的发现（如同一个函数被安全与性能同时标记）
3. **吸收对抗意见** —— 调整严重级别、剔除确认的误报、纳入对抗审查员的独有发现
4. **交叉引用** —— 标注横跨多个维度的发现
5. **按严重度排序**：
   - **Critical**：数据丢失、安全漏洞、崩溃、业务逻辑错误
   - **Major**：性能退化、可靠性风险、重大测试缺口
   - **Minor**：可读性、一致性、次要改进
   - **Nit**：风格偏好、可选增强
6. **统计**：发现总数、各级别数量、各审查员数量、涉及文件数

### 步骤6：报告生成

按 [references/report-template.md](references/report-template.md) 生成完整审查报告。

**报告章节**：
1. 执行摘要：总体评估与团队共识
2. 严重度分布与计数
3. 按审查维度分类的发现（每条含 file:line、代码片段、说明、修复建议）
4. 对抗审查员的发现与质疑
5. 跨维度关注点
6. 正面观察 —— 表扬写得好的代码与良好模式
7. 按优先级排列的行动项

### 步骤7：收尾

- **完整模式**：向所有审查员代理发送关闭请求并等待确认，清理团队资源，向用户呈现最终报告
- **精简模式**：收集全部子任务结果，向用户呈现最终报告

### 步骤8（可选）：修复后的迭代复审

初审后若已修复并请求复审：

1. **检测变更**：`git diff --name-only <上次审查的提交>..HEAD`
2. **只看变更文件** —— 不重新审查整个代码库
3. **只重启相关审查员** —— 修复涉及安全发现时，只重启 security-reviewer 与 adversary-reviewer
4. **验证修复** —— 检查此前的 Critical/Major 问题是否已解决
5. **输出增量** —— 展示已解决、仍存在、新引入的发现

## 质量门禁

| 门禁 | 位于 | 通过标准 | 失败处理 |
|------|------|---------|---------|
| 范围校验 | 0 → 1 | 文件存在且可读 | 报错并中止 |
| 勘察完成 | 1 → 2 | 已识别技术栈 | 以默认值继续 |
| 全部审查完成 | 3 → 4 | 所有审查任务已标记完成 | 等待（超时 10 分钟） |
| 对抗审查完成 | 3 → 4 | 已收到对抗发现 | 无对抗意见继续 |
| 报告已生成 | 5 → 6 | 所有发现都有 file:line 引用 | 核实并补齐缺口 |

## 使用示例

```text
对 PR 123 做团队审查（自动判断复杂度）
用精简模式审查 PR 123
只聚焦安全维度审查这次提交 abc123
审查整个代码库
修复完成后做增量复审
```

## 何时用团队审查 vs 单审查者

| 场景 | 建议 |
|------|------|
| 常规 PR 审查 | 单审查者（更快更省） |
| 安全敏感改动（认证、支付、个人数据） | 团队审查 |
| 架构级改动（新模式、schema） | 团队审查 |
| 大型 PR（15+ 文件） | 团队审查 |
| 合并前快速检查 | 单审查者 |
| 合规或审计要求 | 团队审查 |
| 修复后复审 | 两者均可（都支持仅 diff） |

## 本技能做什么 / 不做什么

**做**：
- 编排 7 名专家审查员并行工作
- 提供多维度的深度代码审查
- 包含挑战假设、发现盲区的对抗审查
- 生成带交叉引用的完整报告
- 支持修复后的仅 diff 增量复审

**不做**：
- 不修改任何代码
- 不自动修复问题
- 不提交变更
- 不运行测试或基准
- 不替代合规签核所需的人工审查

使用说明

# 多角色 PR 审查团队

组建 7 名专家审查员（架构、安全、性能、测试、风格、文档与体验、对抗）并行审查代码变更，交叉汇总后输出分级报告。适合安全敏感、架构级或大型改动。

## 适用场景

- 安全敏感改动：认证、支付、个人数据处理
- 架构级改动：新模式、数据库 schema 变更
- 大型 PR（15+ 文件）或合规审计要求
- 修复完成后需要增量复审

## 使用方式

对 AI 助手说：

```text
对 PR 123 做团队审查
用精简模式审查这次提交，聚焦安全
修复完成后做增量复审
```

- 完整模式：7 名审查员并行，需要环境支持并行子任务
- 精简模式：自动降级或 `--lite` 指定，4 个合并角色，成本更低
- `--focus <architecture|security|performance|testing|style>` 只启动相关审查员

## 输出内容

- 执行摘要与团队共识（通过 / 小修后通过 / 需修改 / 阻塞）
- 按严重度（Critical/Major/Minor/Nit）分类的发现清单，每条含文件行号与修复建议
- 对抗审查员的质疑与补充发现

## 注意事项

- 只分析不修改代码；修复请交给修复类技能或人工处理
- 会话中断后并行审查员会丢失，需重新发起

如何安装此技能？

访问技能市场，点击「安装」按钮，按提示将技能包放入 AI 编程助手的 skills 目录即可。