核心用法
Iterative Code Review 是一种多智能体协作的代码审查工作流，通过并行启动3个独立审查子代理（Reviewer-1/2/3）分别聚焦功能正确性、代码质量与安全性，汇总问题后由用户决定是否启动 Fixer 进行修复。整个流程采用轮次迭代机制，最多10轮，直到连续两轮无高优先级问题或用户主动终止。
关键执行流程：
1. 预检阶段：确认模型选择（建议启用 thinking: high）、检查 maxSpawnDepth 配置、评估变更规模以调整超时时间、识别新增代码、读取PR历史避免重复审查、选择 Full/Delta Review 模式
2. 多轮审查：每轮并行启动3个 Reviewer → 汇总问题（P0-P3分级）→ 用户确认是否修复 → 用户同意后启动 Fixer → 用户审核修改 → 进入下一轮
3. Final Round：强制全量审查，验证编译与测试，确认所有历史问题已修复
显著优点
- 多维度覆盖：3个独立审查员分工明确，避免单一视角盲区
- 用户全程控制：每步操作需明确确认，杜绝自动修改风险
- 自适应超时：根据变更规模（<10/10-50/>50文件）动态调整4-20分钟超时
- 防重复审查：通过
git log读取 commit history，避免对已修复问题重复报告 - 分级问题管理：P0-Critical 到 P3-Low 四级严重度，修复优先级清晰
潜在缺点与局限性
- 依赖用户决策：流程频繁中断等待确认，大规模审查时交互成本高
- 子代理深度限制：需
maxSpawnDepth ≥ 1，否则直接中止 - Final Round 强制全量：大PR的最终轮可能超时，需预留20分钟
- 模型选择无推荐：用户需自行判断代码能力强的模型，增加认知负担
- 无自动修复闭环：必须用户逐轮确认，无法无人值守批量处理
适合人群
- 追求高质量代码审查的开发者与团队
- 需要多维度安全扫描（功能+质量+安全）的项目
- 偏好人工介入控制而非全自动修复的谨慎用户
- 处理中大型PR（10-50+文件）需结构化审查流程的场景
常规风险
| 风险点 | 说明 |
|--------|------|
| 配置依赖 | `maxSpawnDepth` 为0时完全不可用 |
| 超时风险 | 大型PR（>50文件）Final Round 20分钟可能不足 |
| 误报累积 | 多轮迭代中历史问题若未正确标记可能重复出现 |
| 用户疲劳 | 高频确认交互在复杂PR中可能导致审查疲劳 |
安全等级判定依据：全流程强制用户确认，禁止自主修改代码，子代理仅读取分析，Fixer 必须显式授权，符合高安全标准。