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