code-review-council

用途

Code Review Council 用于对代码任务进行多角色、多视角的审查与分析。它面向的不是由单个 Claude 顺序完成所有步骤，而是召集五个独立视角的「委员」并行工作，最终由审查者交叉验证所有结论，输出一份综合报告。

其核心价值是打破单线程分析的「确认偏误」，即先找到方案就锚定判断的倾向。

适用于以下场景：

需要理解一段陌生代码库的结构和调用链
排查 bug、性能问题、内存泄漏等疑难问题
设计新功能的实现方案，需要评估多个 tradeoff
选型开源库，需要验证 API 用法

主要能力与五位委员角色

Explorer（探索者）职责：广度优先，描述现状，不提方案。

梳理代码库结构、模块边界、文件组织
追踪关键调用链和数据流向
标记入口点、副作用、外部依赖输出：代码地图 + 关键路径清单约束：Explorer 只描述「是什么」，禁止说「应该怎么做」。

Analyst（分析者）职责：深度挖掘问题根因，独立于 Explorer 得出结论。

分析性能瓶颈（时间复杂度、内存、IO）
识别潜在 bug、边界条件、竞态条件
评估技术债务和风险点输出：问题清单（按严重程度排序）+ 根因分析约束：Analyst 必须给出根因，不接受「可能是 X 导致的」这种模糊结论。

Architect（方案者）职责：独立提出 2-3 个实现方案，明确每个方案的 tradeoff。

每个方案必须包含：核心思路、实现复杂度、性能特征、可维护性
标注方案的前提假设
给出推荐方案及理由输出：方案对比表 + 推荐方案的伪代码或关键实现片段约束：Architect 不能只提一个方案，必须覆盖至少两种不同路径。

Librarian（库研究员）职责：调研与任务相关的开源库，验证实际可用性。

确认库的当前版本、维护状态（是否活跃）
验证关键 API 的实际用法（不能凭记忆，要基于文档）
列出已知坑、breaking change、版本兼容性问题
对比同类库的优劣输出：库选型建议 + 关键 API 示例代码约束：Librarian 必须区分「确认过的」和「印象中的」信息，不能混淆。

Critic（审查者）⚡ 职责：横向审查其他四位委员的结论，找矛盾、遗漏和错误假设。这是最后一个发言的角色。

验证 Explorer 的代码地图是否遗漏关键路径
挑战 Analyst 的根因是否真的是根因
质疑 Architect 方案的隐含假设是否成立
核查 Librarian 推荐的库是否真的适用于当前场景输出：审查意见清单 + 最终综合建议约束：Critic 必须至少找出 2 处其他委员的问题或遗漏，不能全部认可。

使用方式

执行流程：

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

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

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

输出格式规范：

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

[角色名] 的报告

结论

（核心发现，3-5 条）

详细分析

（具体内容）

置信度

高 / 中 / 低（+ 说明原因）

Critic 额外输出：

[Critic] 的审查意见

发现的问题

针对 Explorer：...
针对 Analyst：...
针对 Architect：...
针对 Librarian：...

综合建议

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

适用场景

何时启用所有五位委员：

复杂的 bug 排查
重要功能的方案设计
技术选型决策

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

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

示例触发语：

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

执行原则

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

限制

资料中未提供该工具的收费、价格、平台支持等具体信息，暂未提供。