review-loop 是一个面向 AI 代理的迭代式“工作者—评审者”循环技能，目标是在单次会话中通过多轮批判与修订获得更高质量的输出。
核心用途 该技能把“完成工作”和“审查工作”拆成两个独立角色。主代理负责执行任务，随后生成一个独立的评审子代理，对工作成果进行 1-10 分打分，并给出具体、可执行的反馈；主代理再依据反馈修改，循环往复，直到达到质量门槛。其核心理念是：初稿永远不是终稿，迭代式批判优于单次成稿。
主要能力
- 支持在单次会话中完成多轮“执行—评审—修改”循环。
- 评审子代理使用全新上下文，只接收工作成果（如文件、diff），不接收主代理的推理过程，以减少锚定偏差。
- 评审反馈要求具体、可操作，并明确打分与问题分类。
- 支持用户内联覆盖默认参数，例如质量门槛、循环次数、评审模型。
- 支持两种模式：模式 A“执行并评审”，即用户给任务并启用 review-loop；模式 B“仅评审已有成果”，即对已完成的代码或文档直接跑评审循环。
- 提供按任务类型调整评审标准的建议，覆盖代码、规格/设计、重构、写作、缺陷修复、基础设施/IaC、数据库迁移、API 设计和测试套件等。
使用方式 用户可以说“implement X, use review-loop”“run review-loop on the file I just wrote”“polish this”“iterate on this”或“/review-loop”。流程为：第 1 步完成工作；第 2 步生成评审子代理并给出任务描述、评审标准和工作成果；第 3 步解析评分、问题与具体修复点；第 4 步按顺序检查停止条件；第 5 步针对反馈进行有目标的修改；第 6 步在退出循环后进行最终打磨，并向用户报告最终评分与循环次数。
默认设置与覆盖 默认最少循环 2 次，最多循环 4 次，质量门槛 8/10，工作者使用当前模型，评审者使用当前模型或快速/均衡替代模型。用户可自然语言覆盖，例如“quality gate 9”“max 5 loops”“reasoning reviewer”等。若用户说“thorough”或“strict”，解释为质量门槛 8、最少循环 2；若说“quick”或“fast”，解释为最多循环 2、质量门槛 6。
模型选择与升级信号 评审者必须始终等于或强于工作者。简单/机械任务可用快速工作者配均衡评审者；标准任务双方均可用均衡模型；复杂任务可用均衡工作者配高级/推理评审者；极复杂任务双方都需高级/推理能力。若连续两轮相同反馈后分数仍无提升，说明工作者模型太弱，可选择请用户换更强模型、临时降低质量门槛并说明差距，或把任务拆小后分别跑 review-loop。
适用场景 适合用户明确要求使用 review-loop、需要打磨或迭代、质量比速度更重要的复杂实现、设计文档与规格、技术写作，以及需要更稳健的代码（如安全、数据管道、金融逻辑）。也适合希望把对抗性批判内置到流程中的情况。
不适合场景 不适合简单修复、快速编辑、单行修改；不适合以测试为质量门槛的任务（应使用 TDD + CI）；不适合用户只求快速完成；不适合探索性/刺探性工作；不适合缺少明确验收标准的任务，这类任务应先定义验收标准再使用。
平台与限制 该技能最好在支持子代理生成的代理平台上使用。若平台不支持，可模拟评审步骤：新开一个聊天上下文，只粘贴工作成果，不含先前推理，要求其打 1-10 分并给出具体反馈。已知限制包括：评审子代理不记忆先前循环，需在每次评审提示中显式包含先前反馈上下文；评审提示标准过于模糊时可能出现分数膨胀；该技能不能替代针对安全关键或合规敏感代码的人工审查；任务描述不充分时循环不保证收敛。成本与速度方面，每次循环等于一次评审子代理调用，完整 3 轮循环大约需要单次实现 1-2 倍的时间。该技能以 MIT 许可发布，可自由使用、改编和再分发。资料未提供收费与价格信息。