review-loop

Review Loop

在单次会话中进行迭代式工作者—审阅者循环。你负责完成工作，启动审阅者子 Agent 进行批评，根据反馈修改，并不断重复，直至达到质量门槛。

核心原则： 初稿永远不是最终稿。迭代式批评比一次性完成更能产出优质结果。

平台说明： 此技能最适合支持启动子 Agent 的平台。 在不具备此功能的平台上，可通过开启一个全新的聊天上下文来模拟审阅步骤：只粘贴工作成果（不包含之前的推理），并要求对其进行 1–10 分评分并提供具体反馈。

快速开始

1. 说：“implement X, use review-loop”或“run review-loop on the file I just wrote”
2. Agent 完成工作（或读取现有成果）
3. 独立的批评者子 Agent 按 1–10 分评分并提供具体反馈
4. Agent 根据反馈修改并重复，直至评分 >= 8（默认质量门槛）
5. 最终输出附带循环摘要

---

适用场景

• 用户说“use review-loop”“polish this”“iterate on this”或“/review-loop”
• 重视质量甚于速度的复杂实现
• 设计文档、规范或技术写作
• 需要稳健可靠的代码（安全、数据管道、金融逻辑）
• 用户希望在流程中加入对抗性批评

不适用场景

• 简单修复、快速编辑、单行改动
• 测试就是质量门槛的任务（改用 TDD + CI）
• 用户只想快速完成任务
• 目标是学习而非交付的探索性工作
• 没有明确验收标准的任务——先定义标准，再使用 review-loop

---

默认设置

设置	默认值
最少循环次数	2
最多循环次数	4
质量门槛	8/10
工作模型	（你当前使用的模型）
审阅者模型	（你当前使用的模型或快速/均衡替代模型）

---

模型选择

审阅者任务负责评估逻辑和约束。工作者任务负责编写和修改代码。请据此选择子 Agent 的能力。

关键规则： 审阅者的能力必须始终不低于工作者。如果审阅者弱于工作者，就无法恰当地批评复杂逻辑或发现细微回归问题。

任务复杂度	工作者能力	审阅者能力	原因
简单/机械（CRUD、格式化、样板代码）	快速/轻量级	均衡	轻量级工作者速度快，均衡型审阅者能轻松发现问题
标准（功能、重构、文档）	均衡	均衡	兼顾成本、速度和质量
复杂（多文件、集成、设计）	均衡	高级/推理型	高级审阅者能发现细微的架构问题，均衡型工作者可以完成相应实现
非常复杂（安全、量化、分布式系统）	高级/推理型	高级/推理型	两者都需要完整的上下文理解和推理能力。审阅者的能力必须与工作者相当。

黄金法则： 工作者必须足够聪明，能够采纳审阅者的反馈。如果审阅者说“用基于通道的信号量修复竞态条件”，而工作者无法推理并发问题，这个循环就无法收敛。

升级信号： 如果连续 2 轮评分都没有提升，且反馈相同，说明工作者模型能力太弱。请升级：

• 选项 A：请用户切换到能力更强的模型
• 选项 B：暂时降低质量门槛，并向用户说明差距
• 选项 C：将任务拆分成更小的子任务，分别运行 review-loop

默认行为： 由于你（主 Agent）就是工作者，请根据任务选择能力与当前能力相当或更强的审阅者子 Agent：

• 大多数任务 → 标准/均衡型审阅者
• 专业/困难任务 → 高级/推理型审阅者
• 快速检查 → 快速/轻量级审阅者（仅当你也以轻量级工作者的身份执行时）

---

用户覆盖选项

用户可以在请求中覆盖任何默认值。请自然地解析：

"implement X with review-loop, quality gate 9, use advanced model for review, max 5 loops"
"polish this, 2 loops minimum, gate at 8"
"run review-loop with fast reviewer, max 2 loops"
"use review-loop, reasoning reviewer, quality gate 9, min 3 max 6"

解析规则：

• “quality gate N”或“gate N” → quality_gate = N
• “[model] reviewer”或“review with [model]” → 覆盖 reviewer 模型
• “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[Do the work] --> B[Spawn reviewer subagent]
    B --> C{Min loops met?}
    C -- no, always continue --> E[Revise based on feedback]
    C -- yes --> D{Score >= quality gate?}
    D -- yes --> F[Final polish pass]
    D -- no --> G{Max loops reached?}
    G -- yes, stop anyway --> F
    G -- no --> E
    E --> B
    F --> H([Done])

---

分步说明

步骤 1：完成工作

像平常一样完成任务。编写代码、创建规范、实现功能。尽情发挥，先尽力完成初稿。

步骤 2：启动审查子 Agent

使用 Agent 工具派遣审查者。审查者必须：

• 是一个独立的子 Agent（使用全新上下文，不受你的推理影响）
• 仅接收工作成果（文件、差异）——不接收你的思考过程
• 以 1 到 10 分评分，并给出具体、可执行的反馈
• 默认使用均衡/标准模型（对于复杂/专业任务，则使用高级推理模型）

审查者提示词模板：

You are a critical reviewer. Score the following work 1-10 and provide specific, actionable feedback.

## What was done
{brief description of the task}

## Review criteria
{task-specific criteria — what matters for THIS task}

Examples of well-written criteria:
  For a REST API endpoint:
    - Correct HTTP status codes used
    - Input validation present on all parameters
    - Auth enforced; no unauthenticated access
    - No N+1 query patterns

  For a design doc:
    - Problem statement is unambiguous
    - Alternatives considered with trade-offs
    - No hand-waving on implementation complexity
    - Success metrics are measurable

  For a data pipeline:
    - Idempotent — safe to re-run
    - Schema changes handled gracefully
    - Failure modes documented
    - PII handling addressed

## Instructions
1. Read the work carefully
2. Score 1-10 where:
   - 1-3: Fundamentally broken or missing major requirements
   - 4-6: Works but has significant issues
   - 7-8: Good, minor issues only
   - 9-10: Excellent, ready to ship
3. List specific issues with file:line references where applicable
4. For each issue, explain WHY it matters and WHAT to fix
5. Do NOT be polite — be honest and direct
6. State your score clearly as "Score: N/10"

## Files to review
{paste file contents or list file paths with relevant excerpts}

步骤 3：解析反馈

从审查者的回复中提取：

• 分数（数字）
• 问题（按严重 / 重要 / 轻微分类）
• 具体修复（需要更改的内容）

向用户报告：

Loop {N}/{max}: Score {X}/10
- {summary of key feedback points}

步骤 4：检查停止条件

按以下顺序检查：

1. 如果已完成的循环次数 < min_loops → 继续（始终如此）
2. 如果分数 >= quality_gate → 停止，进入最终润色
3. 如果已完成的循环次数 >= max_loops → 停止，进入最终润色
4. 否则 → 修改并继续循环

步骤 5：修改

处理审查者的反馈。修复严重和重要问题。轻微问题可酌情处理。然后返回步骤 2。

重要： 每次修改都应有针对性。不要重写全部内容——只修复审查者指出的问题。记住所有先前的反馈，避免引入回归问题。

步骤 6：最终润色

循环结束后（达到质量门槛或达到最大循环次数）：

• 如果剩余的轻微问题很容易处理，则一并解决
• 验证最终输出连贯一致（不留修改过程中的痕迹）
• 向用户报告最终分数和循环次数

---

根据任务类型调整审查标准

任务类型	审查者应关注的方面
代码	正确性、边缘情况、错误处理、可读性、无安全问题
规范/设计	完整性、可行性、避免含糊其辞、可实现性
重构	无行为变更、无回归问题、改进代码整洁度
写作	清晰度、结构、符合受众需求、无冗余内容
Bug 修复	是否解决根本原因、是否存在回归测试、是否有副作用
基础设施 / IaC	幂等性、最小权限、无硬编码密钥、销毁安全性
数据库迁移	可逆性、索引策略、数据丢失风险、大规模场景下的性能
API 设计	向后兼容性、身份验证、版本管理、错误契约
测试套件	边缘情况覆盖率、测试之间无相互依赖、断言有意义

---

两种运行模式

模式 A：“执行并审查”（完整流程）

用户给出任务并要求使用 review-loop。你需要完成工作并运行审查循环。

User: "Implement the caching layer. Use review-loop, quality gate 8."

You:
1. Implement caching layer
2. Spawn reviewer → Score 6, feedback: missing eviction, no TTL
3. Revise: add eviction + TTL
4. Spawn reviewer → Score 8, feedback: minor naming nit
5. Final polish, done

模式 B：“审查现有内容”（仅审查）

用户已完成工作，或者你已完成工作。只需对现有内容运行审查循环。

User: "Run review-loop on the auth module I just wrote"

You:
1. Read the auth module
2. Spawn reviewer → Score 5, feedback: SQL injection, no rate limiting
3. Fix: parameterize queries, add rate limiter
4. Spawn reviewer → Score 8, approved
5. Done

---

警示信号

切勿：

• 不启动子 Agent，而是自行审查（锚定偏差）
• 因为“反馈有误”而跳过修订轮次，却不给出理由
• 虚报自己的评分（“我觉得这其实能打 9 分”）
• 未经用户同意就超出 max_loops 继续
• 将你的完整推理过程／历史记录提供给审查者（他们应该审查的是工作成果，而不是你的意图）

如果审查者有误：

• 用证据反驳（展示能证明反馈不成立的代码／测试）
• 在修订中跳过这一具体问题
• 在给用户的报告中注明
• 切勿为了补偿而降低质量标准

---

报告格式示例

--- Review Loop: {task name} ---

Loop 1/4: Score 6/10
  Reviewer: Missing input validation, no error handling for network timeout,
            function too long (80 lines).
  Action: Fixing all three issues.

Loop 2/4: Score 8/10
  Reviewer: Clean. Minor: variable name `d` could be more descriptive.
  Action: Quality gate met (8 >= 8). Final polish.

Result: 8/10 in 2 loops. Done.

---

已知限制

• 审查子 Agent 不记得之前的轮次——在每次审查提示词中明确加入先前反馈的背景，避免重复处理已解决的问题
• 如果审查提示词中的标准过于模糊，评分可能虚高——投入时间编写具体、可衡量的标准
• 对于安全关键或合规敏感的代码，此技能不能替代人工代码审查；应将其输出视为扎实的初步审查
• 如果任务定义不充分，循环不一定会收敛——开始前应明确验收标准

---

成本与速度

• 每轮 = 调用 1 次审查子 Agent
• 完整的 3 轮周期，预算约为单次实现所需时间的 1–2 倍
• 相比发布有缺陷的代码、模糊的规范或触发后期审查周期，这样做成本很低
• 大多数审查使用默认／标准模型；只有在专业领域（安全审计、分布式系统、量化金融）才升级到高级推理模型

---

许可证

MIT — 可免费使用、改编，并通过任何 AI 工具或平台重新分发。欢迎注明出处，也欢迎贡献。