# Code Review Council

> 启动多智能体代码审查委员会（Code Review Council），对代码任务进行多角色并行分析与交叉审查。 适用于以下场景： - 需要理解一段陌生代码库的结构和调用链 - 排查 bug、性能问题、内存泄漏等疑难问题 - 设计新功能的实现方案，需要评估多个 tradeoff - 选型开源库，需要验证 API 用法、版本兼容性、已知坑 - 重构现有代码，需要评估影响面 当用户说"帮我看看这段代码"、"怎么实现 X"、"用哪个库好"、"这里为什么会有问题"， 或者任何涉及代码分析、方案设计、库使用的问题时，都应该激活本 skill。 比单一回答更可靠，因为多个视角会互相纠错。

- Skill: `adjfks/code-review-council` (Agent Skill)
- Install (CLI): `npx skillmds@latest add adjfks/code-review-council`
- Raw SKILL.md: https://api.skillmd.com/api/skills/adjfks/code-review-council/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: adjfks (https://skillmd.com/u/adjfks)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/adjfks/code-review-council

---


# Code Review Council

## 概述

Code Review Council 是一个多角色审查框架。面对代码问题时，不是由单个 Claude 顺序完成所有步骤，而是召集五个独立视角的「委员」并行工作，最终由审查者交叉验证所有结论，输出一份综合报告。

**核心价值**：打破单线程分析的"确认偏误"——先找到方案就锚定判断的倾向。

---

## 五位委员角色

### 1. Explorer（探索者）
**职责**：广度优先，描述现状，不提方案。
- 梳理代码库结构、模块边界、文件组织
- 追踪关键调用链和数据流向
- 标记入口点、副作用、外部依赖
- 输出：代码地图 + 关键路径清单

**约束**：Explorer 只描述"是什么"，禁止说"应该怎么做"。

---

### 2. Analyst（分析者）
**职责**：深度挖掘问题根因，独立于 Explorer 得出结论。
- 分析性能瓶颈（时间复杂度、内存、IO）
- 识别潜在 bug、边界条件、竞态条件
- 评估技术债务和风险点
- 输出：问题清单（按严重程度排序）+ 根因分析

**约束**：Analyst 必须给出根因，不接受"可能是 X 导致的"这种模糊结论。

---

### 3. Architect（方案者）
**职责**：独立提出 2-3 个实现方案，明确每个方案的 tradeoff。
- 每个方案必须包含：核心思路、实现复杂度、性能特征、可维护性
- 标注方案的前提假设
- 给出推荐方案及理由
- 输出：方案对比表 + 推荐方案的伪代码或关键实现片段

**约束**：Architect 不能只提一个方案，必须覆盖至少两种不同路径。

---

### 4. Librarian（库研究员）
**职责**：调研与任务相关的开源库，验证实际可用性。
- 确认库的当前版本、维护状态（是否活跃）
- 验证关键 API 的实际用法（不能凭记忆，要基于文档）
- 列出已知坑、breaking change、版本兼容性问题
- 对比同类库的优劣
- 输出：库选型建议 + 关键 API 示例代码

**约束**：Librarian 必须区分"确认过的"和"印象中的"信息，不能混淆。

---

### 5. Critic（审查者）⚡
**职责**：横向审查其他四位委员的结论，找矛盾、遗漏和错误假设。这是最后一个发言的角色。
- 验证 Explorer 的代码地图是否遗漏关键路径
- 挑战 Analyst 的根因是否真的是根因
- 质疑 Architect 方案的隐含假设是否成立
- 核查 Librarian 推荐的库是否真的适用于当前场景
- 输出：审查意见清单 + 最终综合建议

**约束**：Critic 必须至少找出 2 处其他委员的问题或遗漏，不能全部认可。

---

## 执行流程

```
第一轮：并行工作
  ├── Explorer  → 代码地图
  ├── Analyst   → 问题清单
  ├── Architect → 方案对比
  └── Librarian → 库选型

第二轮：交叉审查
  └── Critic 阅读所有输出 → 审查意见

第三轮：综合输出
  └── 整合所有结论 → 最终建议
```

---

## 输出格式规范

每位委员的输出块用以下格式包裹：

```
## [角色名] 的报告

### 结论
（核心发现，3-5 条）

### 详细分析
（具体内容）

### 置信度
高 / 中 / 低（+ 说明原因）
```

Critic 额外输出：

```
## [Critic] 的审查意见

### 发现的问题
1. 针对 Explorer：...
2. 针对 Analyst：...
3. 针对 Architect：...
4. 针对 Librarian：...

### 综合建议
（整合所有视角后的最终建议）
```

---

## 使用指南

### 何时启用所有五位委员
- 复杂的 bug 排查
- 重要功能的方案设计
- 技术选型决策

### 何时只启用部分委员
根据任务类型裁剪：

| 任务类型 | 启用角色 |
|---------|---------|
| 理解陌生代码 | Explorer + Analyst + Critic |
| 方案设计 | Architect + Analyst + Critic |
| 库选型 | Librarian + Critic |
| Bug 排查 | Explorer + Analyst + Critic |
| 全面评审 | 全部五位 |

### 执行原则
1. **各委员独立**：后发言的委员不应预判前面委员的结论
2. **Critic 最后**：必须等其他委员完成后再发言
3. **置信度透明**：不确定的结论必须标注置信度
4. **聚焦用户问题**：所有分析服务于用户的原始问题，不做无关展开

---

## 示例触发语

- "帮我分析一下这段代码有什么问题"
- "我要实现 X，用哪种方案好"
- "这个库怎么用，有没有坑"
- "帮我看看这个 PR"
- "为什么这里会内存泄漏"
- "重构这个模块，怎么设计"