Review Loop
迭代式的工单-审查循环，在单次会话内完成。你完成工作，生成一个审查子代理进行评价，根据反馈修订，重复执行直到达到质量标准。
核心原则： 初稿绝非终稿。迭代式评价比单次通过能产生更好的输出。
平台提示： 该技能在支持子代理生成的代理上效果最佳。 在不支持该功能的平台上，可以通过打开新的聊天会话，仅粘贴工作产物（不含之前的推理过程），要求其给出 1-10 分及具体反馈来模拟审查步骤。
快速开始
- 说：
"实现 X，使用 review-loop"或"对我刚写的文件运行 review-loop" - 代理完成工作（或读取已有工作）
- 一个独立的评价子代理为其打分（1-10 分）并给出具体反馈
- 代理进行修订并重复，直到评分 >= 8（默认质量标准）
- 最终输出时附带循环总结
何时使用
- 用户说“使用 review-loop”、“打磨这个”、“迭代此内容”、“/review-loop”
- 复杂实现，质量比速度更重要
- 设计文档、规格说明或技术写作
- 需要健壮的代码（安全、数据管道、金融逻辑）
- 当用户希望将对抗性评价融入流程时
何时不使用
- 简单修复、快速编辑、单行变更
- 以测试为质量门限的任务（应使用 TDD + CI）
- 用户只希望快速完成的情况
- 探索性/攻关工作，目标是学习而非交付
- 没有明确验收标准的任务——请先定义标准，再使用 review-loop
默认设置
| 设置 | 默认值 |
|---|---|
| 最少循环次数 | 2 |
| 最多循环次数 | 4 |
| 质量标准 | 8/10 |
| 执行模型 | （你当前的模型） |
| 审查模型 | （你当前的模型或快速/平衡的替代模型） |
模型选择
审查者任务评估逻辑和约束。执行者任务编写和修改代码。请相应选择子代理的能力。
关键规则： 审查者必须始终等于或强于执行者。如果审查者弱于执行者，则无法正确评价复杂逻辑或发现细微的退化。
| 任务复杂度 | 执行者能力 | 审查者能力 | 理由 |
|---|---|---|---|
| 简单/机械式（CRUD、格式化、样板代码） | 快速/轻量级 | 平衡 | 轻量级执行者速度快，平衡型审查者轻易发现问题 |
| 标准（功能、重构、文档） | 平衡 | 平衡 | 成本、速度和质量的良好组合 |
| 复杂（多文件、集成、设计） | 平衡 | 高级/推理型 | 高级审查者发现细微架构问题，平衡执行者可实现它们 |
| 非常复杂（安全、量化、分布式系统） | 高级/推理型 | 高级/推理型 | 双方都需要完整的上下文和推理能力。审查者必须匹配执行者的能力。 |
黄金法则： 执行者必须足够聪明，能够根据审查者的反馈采取行动。如果审查者说“使用基于通道的信号量修复竞态条件”，而执行者无法推理并发问题，则循环不会收敛。
升级信号： 如果在连续的 2 次循环后，评分仍未改善且反馈相同，则说明执行者模型太弱。请升级：
- 选项 A： 要求用户切换到能力更强的模型
- 选项 B： 暂时降低质量标准并向用户说明差距
- 选项 C： 将任务拆分为更小的子任务，并对每个子任务运行 review-loop
默认行为： 由于你（主代理）就是执行者，请根据任务生成能力与你当前能力匹配或更强的审查者子代理：
- 大多数任务 → 标准/平衡型审查者
- 专业化/困难任务 → 高级/推理型审查者
- 快速检查 → 快速/轻量级审查者（仅当你同时作为轻量级执行者时）
用户覆盖
用户可以在请求中内联覆盖任何默认设置。请自然解析这些内容：
"实现 X 并使用 review-loop，质量门 9，使用高级模型进行审查，最多 5 次循环"
"打磨这个，最少 2 次循环，质量门 8"
"运行 review-loop，使用快速审查者，最多 2 次循环"
"使用 review-loop，推理型审查者，质量门 9，最少 3 次最多 6 次"
解析规则：
- "质量门 N" 或 "门限 N" → quality_gate = N
- "[模型] 审查者" 或 "使用 [模型] 审查" → 覆盖审查者模型
- "最多 N 次循环" → max_loops = N
- "最少 N 次循环" → min_loops = N
- 如果用户未指定，则使用默认值
- 如果用户说“彻底”或“严格” → 视为 quality_gate 8，min_loops 2
- 如果用户说“快速”或“快点” → 视为 max_loops 2，quality_gate 6
流程
flowchart TD
A[完成工作] --> B[生成审查者子代理]
B --> C{达到最小循环数？}
C -- 否，始终继续 --> E[根据反馈修订]
C -- 是 --> D{评分 >= 质量门？}
D -- 是 --> F[最终润色]
D -- 否 --> G{达到最大循环数？}
G -- 是，无论如何停止 --> F
G -- 否 --> E
E --> B
F --> H([完成])
分步指导
第 1 步：完成工作
像往常一样完成任务。编写代码、创建规格说明、实现功能。不要保留——尽你所能完成最佳初稿。
第 2 步：生成审查者子代理
使用 Agent 工具分配一个审查者。审查者必须：
- 是一个独立的子代理（新上下文，不锚定你的推理）
- 仅接收工作产物（文件、差异）——而不是你的思考过程
- 给出 1-10 分的评分，并附带具体、可操作的反馈
- 默认使用平衡/标准模型（对于复杂/专业化任务使用高级推理模型）
审查者提示模板：
你是一个严格的审查员。请对以下工作进行 1-10 分评分，并提供具体、可操作的反馈。
## 完成的工作
{任务的简要描述}
## 审查标准
{针对此任务的特定标准——什么才是重要的}
编写标准的示例：
对于 REST API 端点：
- 使用了正确的 HTTP 状态码
- 所有参数都进行了输入验证
- 实施身份验证；没有未认证的访问
- 没有 N+1 查询模式
对于设计文档：
- 问题陈述明确无误
- 考虑了备选方案并权衡了利弊
- 实施复杂性没有含糊其辞
- 成功指标是可衡量的
对于数据管道：
- 幂等性——重新运行安全
- 优雅处理模式变更
- 记录了失败模式
- 处理了 PII 问题
## 说明
1. 仔细阅读工作内容
2. 评分 1-10，其中：
- 1-3：存在根本性错误或缺少主要需求
- 4-6：可用但存在重大问题
- 7-8：良好，仅有小问题
- 9-10：优秀，可以发布
3. 列出具体问题，并附上 file:line 引用（如适用）
4. 针对每个问题，解释为什么它重要以及如何修复
5. 不要客气——要诚实直接
6. 清晰陈述你的评分，格式为 "Score: N/10"
## 要审查的文件
{粘贴文件内容或列出文件路径及相关摘录}
第 3 步：解析反馈
从审查者的回复中提取：
- 评分（数字）
- 问题（按 关键 / 重要 / 微小 分类）
- 具体修复方法（需要更改什么）
向用户报告：
循环 {N}/{max}：评分 {X}/10
- {关键反馈要点摘要}
第 4 步：检查停止条件
按以下顺序：
- 如果完成的循环数 < min_loops → 继续（始终如此）
- 如果评分 >= quality_gate → 停止，进入最终润色
- 如果完成的循环数 >= max_loops → 停止，进入最终润色
- 否则 → 修订并循环
第 5 步：修订
处理审查者的反馈。修复关键和重要问题。微小问题可选。然后返回第 2 步。
重要提示： 每次修订应有针对性。不要重写所有内容——仅修复审查者标记的部分。在脑海中维护所有先前反馈的列表，以避免退化。
第 6 步：最终润色
一旦循环退出（达到质量标准或达到最大循环数）：
- 如果微小问题很简单，也一并处理
- 验证最终输出是连贯的（没有来自修订周期的残留）
- 向用户报告最终评分和循环次数
按任务类型调整审查标准
| 任务类型 | 审查者应重点关注 |
|---|---|
| 代码 | 正确性、边界情况、错误处理、可读性、无安全问题 |
| 规格说明/设计 | 完整性、可行性、无含糊之处、可实现性 |
| 重构 | 无行为变更、无退化、比以前更整洁 |
| 写作 | 清晰度、结构、适合受众、无废话 |
| 错误修复 | 根因已处理、存在回归测试、无副作用 |
| 基础设施 / IaC | 幂等性、最小权限、无硬编码密钥、安全销毁 |
| 数据库迁移 | 可逆性、索引策略、数据丢失风险、扩展性能 |
| API 设计 | 向后兼容、认证、版本控制、错误处理契约 |
| 测试套件 | 边界情况覆盖、无测试间依赖、有意义的断言 |
两种操作模式
模式 A：“执行并审查”（完整周期）
用户给出任务并要求使用 review-loop。你完成工作并运行审查循环。
用户：“实现缓存层。使用 review-loop，质量门 8。”
你：
1. 实现缓存层
2. 生成审查者 → 评分 6，反馈：缺少驱逐策略，无 TTL
3. 修订：添加驱逐策略 + TTL
4. 生成审查者 → 评分 8，反馈：命名问题
5. 最终润色，完成
模式 B：“审查已有工作”（仅审查）
用户已完成工作，或你已完成工作。仅对已有工件运行审查循环。
用户：“对我刚写的 auth 模块运行 review-loop”
你：
1. 读取 auth 模块
2. 生成审查者 → 评分 5，反馈：SQL 注入，无速率限制
3. 修复：参数化查询，添加速率限制器
4. 生成审查者 → 评分 8，通过
5. 完成
危险信号
绝对不要：
- 自我审查而非生成子代理（锚定偏差）
- 在没有充分理由的情况下跳过修订周期，因为“反馈是错误的”
- 抬高自己的分数（“我认为这实际上是 9 分”）
- 未获得用户同意就继续超过 max_loops
- 将你的完整推理/历史提供给审查者（他们必须审查工作，而不是你的意图）
如果审查者错了：
- 用证据反驳（展示反驳反馈的代码/测试）
- 在修订中跳过该特定点
- 在报告中向用户说明
- 不要为了弥补而降低质量标准
示例报告格式
--- 审查循环：{任务名称} ---
循环 1/4：评分 6/10
审查者：缺少输入验证，未处理网络超时错误，
函数过长（80 行）。
操作：修复所有三个问题。
循环 2/4：评分 8/10
审查者：干净。小问题：变量名 `d` 可以更描述性。
操作：达到质量标准（8 >= 8）。最终润色。
结果：2 次循环后达到 8/10。完成。
已知限制
- 审查者子代理没有之前循环的记忆——在每个审查者提示中显式包含先前反馈上下文，以避免重复已解决的问题
- 如果审查者提示标准过于模糊，可能出现评分膨胀——请花时间编写具体、可衡量的标准
- 该技能不能替代安全关键或合规敏感代码的人工代码审查；请将输出视为强力的初稿
- 如果任务定义不充分，循环收敛无法保证——开始前请明确验收标准
成本与速度
- 每次循环 = 1 次审查者子代理调用
- 完成一个完整的 3 次循环周期，预计耗时约为单次实现通过的 1-2 倍
- 与交付有缺陷的代码、模糊的规范或引发后期审查周期相比，这成本更低
- 对于大多数审查，使用默认/标准模型；仅在专业化领域（安全审计、分布式系统、量化金融）升级到高级推理模型
许可
MIT — 可免费使用、修改和与任何 AI 工具或平台重新分发。欢迎注明出处。欢迎贡献。