审阅循环（Review Loop）

平台说明： 此技能在支持子代理生成的Agent平台上效果最佳。 在不具备该能力的平台上，可以通过打开新的聊天上下文，仅粘贴工作成果（不包含之前的推理过程），并要求其给出1-10分的评分和具体反馈，以此模拟审阅者环节。

快速开始

1. 输入：

   "实现X，use review-loop"

   或者

   "对我刚写的文件run review-loop"

2. Agent完成工作（或读取现有工作成果）
3. 独立的批评家子代理给出1-10分的评分和具体反馈
4. Agent根据反馈修订内容，重复此过程直到评分≥8（默认质量门槛）
5. 最终输出时会附带循环总结

使用场景

• 用户输入"use review-loop"、"polish this"、"iterate on this"、"/review-loop"时
• 质量优先于速度的复杂实现场景
• 设计文档、规格说明或技术写作
• 需要具备鲁棒性的代码（安全、数据管道、财务逻辑相关）
• 用户希望在流程中加入对抗式批评的场景

不适用场景

• 简单修复、快速编辑、单行代码修改
• 以测试作为质量门槛的任务（改用TDD + CI）
• 用户只追求快速完成的任务
• 以学习而非交付为目标的探索性/spike工作
• 没有明确验收标准的任务——先定义验收标准，再使用审阅循环

默认设置

模型选择

• 选项A：请求用户切换到更强大的模型
• 选项B：暂时降低质量门槛，并向用户说明差距
• 选项C：将任务拆分为更小的子任务，对每个子任务运行审阅循环

• 大多数任务 → 标准/平衡型审阅者
• 专业/高难度任务 → 高级/推理型审阅者
• 快速检查 → 快速/轻量型审阅者（仅当你同时作为轻量型工作者时）

用户自定义设置

"实现X并use review-loop，质量门槛设为9，使用高级模型作为审阅者，最大循环次数5次"
"polish this，最小循环次数2次，质量门槛8"
"run review-loop，使用快速审阅者，最大循环次数2次"
"use review-loop，推理型审阅者，质量门槛9，最小3次最大6次循环"

• "quality gate N" 或 "gate N" → quality_gate = N
• "[model] reviewer" 或 "review with [model]" → 覆盖审阅者模型
• "max N loops" → max_loops = N
• "min N loops" → min_loops = N
• 用户未指定时，使用默认值
• 用户说"thorough"或"strict" → 解析为quality_gate 8，min_loops 2
• 用户说"quick"或"fast" → 解析为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：生成审阅者子代理

• 是独立的子代理（全新上下文，不依赖你的推理过程）
• 仅接收工作成果（文件、差异）——不包含你的思考过程
• 给出1-10分的评分和具体、可落地的反馈
• 默认使用平衡/标准模型（复杂/专业任务使用高级推理模型）

你是一名严格的审阅者。请对以下工作成果给出1-10分的评分，并提供具体、可落地的反馈。

## 任务内容
{任务简要描述}

## 审阅标准
{任务特定标准——此任务的核心要求}

优秀标准示例：
  对于REST API端点：
    - 使用正确的HTTP状态码
    - 所有参数均有输入验证
    - 强制认证；不允许未授权访问
    - 无N+1查询模式

  对于设计文档：
    - 问题陈述清晰明确
    - 考虑了替代方案并分析了利弊
    - 对实现复杂度没有含糊表述
    - 成功指标可衡量

  对于数据管道：
    - 幂等性——可安全重跑
    - 优雅处理 schema 变更
    - 记录故障模式
    - 处理PII数据

## 说明
1. 仔细阅读工作成果
2. 给出1-10分评分，评分标准：
   - 1-3分：存在根本性缺陷或缺失主要需求
   - 4-6分：可运行但存在显著问题
   - 7-8分：良好，仅存在 minor 问题
   - 9-10分：优秀，可直接交付
3. 列出具体问题，如有可能注明文件:行号
4. 针对每个问题，说明**为什么重要**以及**如何修复**
5. 无需客气——保持诚实直接
6. 明确给出评分格式："Score: N/10"

## 待审阅文件
{粘贴文件内容或列出文件路径及相关片段}

步骤3：解析反馈

• 评分（数字）
• 问题（分为严重/重要/次要）
• 具体修复方案（需要修改的内容）

第{N}/{max}次循环：评分{X}/10
- {关键反馈要点总结}

步骤4：检查停止条件

1. 已完成循环次数 < 最小循环次数 → 继续循环（必须）
2. 评分 ≥ 质量门槛 → 停止，进入最终润色
3. 已完成循环次数 ≥ 最大循环次数 → 停止，进入最终润色
4. 其他情况 → 修订并循环

步骤5：修订内容

步骤6：最终润色

• 如果次要问题容易修复，处理剩余的次要问题
• 验证最终输出连贯（无修订周期产生的冗余内容）
• 向用户汇报最终评分和循环次数

按任务类型调整审阅标准

两种运行模式

模式A：“完成并审阅”（全周期）

用户："实现缓存层。Use review-loop，质量门槛8。"

你：
1. 实现缓存层
2. 生成审阅者 → 评分6，反馈：缺少淘汰机制、无TTL
3. 修订：添加淘汰机制 + TTL
4. 生成审阅者 → 评分8，反馈：minor命名问题
5. 最终润色，完成

模式B：“审阅现有成果”（仅审阅）

用户："对我刚写的认证模块run review-loop"

你：
1. 读取认证模块
2. 生成审阅者 → 评分5，反馈：存在SQL注入风险、无速率限制
3. 修复：参数化查询、添加速率限制器
4. 生成审阅者 → 评分8，通过
5. 完成

注意事项

• 自我审阅而非生成子代理（锚定偏差）
• 无正当理由跳过修订环节，声称“反馈有误”
• 抬高自己的评分（比如“我认为这实际上是9分”）
• 未经用户同意超过最大循环次数
• 将你的完整推理/历史记录提供给审阅者（他们必须审阅工作成果，而非你的意图）

• 提供证据反驳（展示证明反馈错误的代码/测试）
• 跳过该特定反馈点的修订
• 在向用户的汇报中注明此情况
• 不得因此降低质量标准

示例汇报格式

--- 审阅循环：{任务名称} ---

第1/4次循环：评分6/10
  审阅者反馈：缺少输入验证、无网络超时错误处理、
            函数过长（80行）。
  行动：修复所有三个问题。

第2/4次循环：评分8/10
  审阅者反馈：代码简洁。Minor问题：变量名`d`可更具描述性。
  行动：达到质量门槛（8≥8）。进行最终润色。

结果：2次循环后评分8/10。完成。

已知局限性

• 审阅者子代理没有之前循环的记忆——需在每次审阅者提示中明确包含之前的反馈上下文，避免重复已解决的问题
• 如果审阅者提示标准过于模糊，可能出现评分虚高的情况——需投入时间编写具体、可衡量的标准
• 此技能无法替代针对安全关键或合规敏感代码的人工代码审阅；将输出视为高质量初稿即可
• 如果任务定义不明确，循环可能无法收敛——开始前先定义清晰的验收标准

成本与速度

• 每次循环 = 1次审阅者子代理调用
• 完整3次循环的时间大约是单次实现时间的1-2倍
• 这与交付有bug的代码、模糊的规格说明或触发后期审阅周期相比成本更低
• 大多数审阅使用默认/标准模型；仅在专业领域（安全审计、分布式系统、量化金融）使用高级推理模型

许可证