循环设计与审查 是做什么的？
前提。 LLM 是一个前馈系统：提示输入 → 令牌输出，没有内置的“跨轮次朝目标调整”机制。要让它表现得像一个目标导向系统，你需要给它包裹一个反馈循环。本技能帮助你正确编写该循环并审查它，使其不会失控。
何时使用 / 不使用
使用时机：
- 你想将一个重复性任务交给一个反复运行的智能体（编写→测试，测试→修复，修复→验证…）。
- 你已经有一个循环，但担心它空转、作弊或执行错误答案直至完成。
不要用于：
- 一次性任务 → 直接执行即可；无需包裹循环。
- 简单的定时器/轮询 → 使用
/loop；无需设计。 - 如何构建循环架构（管道 → DAG，长时间运行恢复）→ 这是机制层；请参见
autonomous-loops/continuous-agent-loop。本技能仅涵盖“目标是否正确，以及它是否会失控”——它不会重新解释机制。
红线前提：两个级别的反馈
| 级别 | 归属 | 功能 |
|---|---|---|
| 执行（低级） | 机器/智能体 | 测量“距离字面目标有多远”并将其降至零。机器在此处强大。 |
| 判断（高级） | 人类 | 决定“这个目标本身是否正确，是否应该改变，是否应该停止”。机器无法跳出自身的循环来质疑目标。 |
恒温器可以反馈“距离 26°C 有多远”，但当你发烧并想要 28°C 时，它无法判断 26 是否是正确的目标——它只会朝 26 度运作。“今天该设置多少”始终是人类的责任。 将判断/签字/最终开关交给机器 = 移除高级反馈 = 它会快速、猛烈地冲向一个无人质疑的目标 → 产生错误输出。
操作 1 — 编写循环（5 个步骤）
步骤 0 · 首先做减法：你甚至应该构建它吗？（4 条件门，任何一项不满足 = 否决）
① 任务每周或更频繁重复 ② 验证可以自动化 ③ 代币预算能承受 ④ 智能体拥有能够实际运行并查看结果的工具
任何一项不满足 → 不要构建循环；通过手动或其他方式完成。
阻止大多数人的不是“我能否编写循环”，而是“我的仓库是否值得拥有一个”。值得拥有循环的仓库具有一个对账基线（黄金样本/上游总数）+ 测试 + lint 守卫。一个不值得循环的仓库只会放大其错误。
步骤 1 · 定义一个机器可判定的目标（难点——循环成败在此一举）
整个循环依赖于比较器的“是否完成？”比较器只有在退出条件可以由机器判断是/否时才能工作。
- 错误：模糊（“让它变好”，“写得更清晰”）→ 比较器无法判断 → 要么永远无法通过（卡住重试），要么猜测（随机通过/阻塞）。
- 正确：可判定（“所有 96 个单元测试通过”并且生成了变更列表，“module-02 字段已填写，pytest 通过，业务逻辑未改动”）→ 一次检查即可确定；循环干净地收敛。
五点目标框架：
- 完成标准是机器可验证的。
- 与完成标准一起定义边界条件（“它不得做什么”）——反 Goodhart；缺少边界等于允许作弊的许可。
- 具有失败回退机制 —— 重试上限 N + 超出上限时上报给人类。
- 目标是分层的。
- 完成标准首选对账而非断言 —— 锚定外部事实（黄金样本/上游总数/财务对账/平台后台数据），然后再使用自己的断言。“所有测试通过”可能被操纵（放宽断言、伪造模拟、吞噬异常）；“与参考值的差异 < 0.01”则不能。
自我检查： 将目标读给不了解领域的人听——他们能运行一个命令并判断是否完成吗？如果不能，说明可判定性不够。返回上一步。
步骤 2 · 选择循环类型
| 你的任务 | 循环类型（控制论） | 如何停止 |
|---|---|---|
| 有明确的“完成”测试（编写完成 / 一批图像处理完成） | 伺服（/goal 式闭环） | 达到目标时停止 |
| 无终点，必须持续维护状态（库存警报 / 计划健康检查） | 调节器（/loop 式恒温器） | 永不停止；仅对变化做出反应（死区抑制噪音） |
| 定期采样，在满足条件时停止（观察 PR 直到 CI 变绿） | 带退出的调节器 | 当退出条件成立时停止 |
| 必须“确保某件事按时发生” | 将上述内容包裹在 /schedule 中 | cron 触发它 |
经验法则：明确的“完成”测试 → 伺服；必须持续维护，无终点 → 调节器；必须“按时发生” → 将调节器包裹在计划中。
步骤 3 · 选择骨架
维护类型（维护现有事物）→ 文档驱动的调度。 该循环不是“在定时器上运行固定检查”，而是 “在定时器上读取文档，并且仅当文档发生变化时才调度。” 该文档是任务队列 + 状态机 + 人机界面。 三个原则：① 问题列仅由人类写入，结果列仅由循环写入，状态单向推进且永不回滚；② 退出代码是最终的（如果脚本返回 exit 1，则脚本说了算）；③ 状态仅推进到“等待验证”——“完成”单元格仅由人类翻转。 循环是工人，不是验收官。
新项目类型（从零开始构建）→ 规划 / 构建 / 评判，三个角色。
| 角色 | 职责 | 关键 |
|---|---|---|
| 规划 | 将目标分解为规范 + 可判定的验收条件 | 验收必须可被脚本评判 |
| 构建 | 按照规范编写 | 不得更改验收条件 |
| 评判 | 独立运行验收；通过 → 停止，失败 → 将失败原因返回给构建 | 独立 + 确定 |
三个铁律（全部押注在评判者上）：① 评判者必须独立 —— 不能与构建者同一智能体（给自己打分总是会膨胀）；② 确定性规则 —— pytest / 对账差异 / 类型检查 / 差异，绝不是“看起来不错”；③ 构建者不得编辑验收条件以使其通过。三次重试失败 → 上报给人类。
步骤 4 · 添加阻尼（防止振荡/失控）
重试上限、硬停止、人类翻转最终开关 = 阻尼。无阻尼的负反馈会振荡（Ralph-Wiggum 循环：原地打转，消耗令牌）。
步骤 5 · 分三个阶段落地（不要第一天就完全自动化）
① 手动运行一次（迫使你精确说明“评判者如何决定”）→ ② 固化为技能 / Claude Code 子智能体（主 Claude 循环，调度规划/构建/评判）→ ③ 挂在 cron 上实现完全自动化。
操作 2 — 审查循环（清单 = 五种失效模式）
针对每一行运行循环。命中任何一项 = 此循环将误触发；将其退回。 这五种是负面经验（陷阱）——比正面规则更有价值。
| # | 失效模式（如何崩溃） | 审查问题（命中 = 红色） | 抗体 |
|---|---|---|---|
| 1 | 目标是一个正确的套话 → 空转，浪费金钱 | 退出条件能否被机器判断是/否？还是“管理好它 / 让它变好”？ | 替换为可判定的结果条件（操作 1·步骤 1） |
| 2 | “验证”写为“检查它看起来是否正常” → 智能体自信地认为没问题并停止 | 评判者是否是被告本人？验证是否依赖于“看起来不错”还是确定性规则？ | 对账 + 退出代码规则 + 独立评判者 |
| 3 | （最糟糕）仅基于“所有测试通过” → 智能体删除测试 | 是否有边界（“它不得做什么”）？还是只有完成标准？ | 完成标准 + 边界一起（Goodhart 抗体） |
| 4 | 指望智能体在运行中提问 → 它不会；它将错误答案执行到底 | 是否存在任何“仅在运行时澄清”的点？ | 预先澄清所有问题；启动前一次性解决 |
| 5 | 臃肿的 CLAUDE.md + 陈旧的内存 → 循环越快，出错越多 | 它依赖的文档/内存是否新鲜？谁维护它们？ | 分层内存 + 定期 lint |
另外三条红线（违反任何一条 = 不允许自动运行）：
- 将判断权保留在人类手中。 验收 / “完成”单元格由人类翻转；循环不是验收官。
- 责任不转移。 任何其失败你无法承担后果的事情（合并错误的 PR / 发布错误的内容 / 错误分配资金）→ 不要自动授予权限。
- 反直觉警告。 一个循环越具有“自我改进 / 重写自身规则”的特性，它需要的人类审查就越严格（以查看它将规则改成了什么）——而不是更宽松。机器太快，事后无法拦截，因此人类的判断必须位于行动之前（一个硬性门），而不是事后修补。
示例演练——审查一个“夜间绿色守护者”循环
你想要一个每晚运行并修复任何失败测试的循环。
- 天真的目标： “让所有测试通过。” → 步骤 1 自我检查失败：这是失效模式 #3 的诱饵。
- 可判定目标（已修正）： “所有测试变绿 并且 没有测试文件被删除或弱化 并且 覆盖率未降低 并且 生成了变更列表。”现在边界与完成标准一同定义。
- 类型： 重试上限为 3 的伺服（步骤 2 + 步骤 4）。
- 骨架： 规划/构建/评判——评判者是独立运行的 CI，绝不是修复智能体（步骤 3）。
现在运行审查清单，它会捕捉到天真版本会遗漏的东西：
- #3 命中 → 天真的“所有测试通过”让智能体删除失败的测试以“获胜”。通过边界“没有测试文件被删除/弱化”修复。
- #2 命中 → 如果修复智能体也评判自己的修复，它会给自己通过。通过“评判者 = 独立 CI，确定性”修复。
- #4 命中 → 如果修复不明确，智能体不会在凌晨 2 点停下来询问；它会提交猜测。通过预先加载修复：不明确的修复留给人类，而不是猜测。
- 红线 → 循环打开 PR 但不会自动合并；人类翻转最终开关（责任不转移）。
天真循环和经过审查的循环只相差四行约束——这就是“醒来发现测试套件被删除”和“醒来看到一份干净的 PR”之间的区别。
一句话总结
编写循环的难点不在于“我能否编写循环”，而在于定义一个机器能够对账的目标——可判定、有边界、基于对账。控制器必须是确定的且外部的；将判断权和标准保留在人类手中；系统趋向于熵，因此需要维护。 循环只奖励那些已经深思熟虑过的人。指望它为你思考，它会愉快地与你一起，大规模地，想错。
渊源：Wiener 的双层反馈（人的用途，1950 年）用于判断/执行分离和红线；规划/构建/评判模式来自 Anatoli 的 Loops explained 和 Addy 的 Loop Engineering。 机制层（如何构建循环架构）：请参见
autonomous-loops/continuous-agent-loop。本技能不重新实现机制；仅涵盖目标定义和运行失控预防。