loop-engineering-skill

我为什么做它

Loop Engineering（循环工程）今年突然火了，但大多数人把「循环」当成了万能加速器。我白天做 Agent 产品、晚上在同济做 agent 评估方向的研究，越看越确信一件事：一个循环的上限，不是模型多强，而是那个「裁判」（verifier）有多忠实。

一个没有可靠裁判的循环，只是一台更快、更自信地产出垃圾的机器——而且模型越强，它积累错误越快。大多数循环翻车，翻在「这任务根本不该上循环」和「裁判不靠谱」，而不是循环体本身写错。所以我把这套判断固化成一个 Claude Code skill，让 AI 在帮你搭循环之前，先逼自己回答「这个任务到底该不该循环」。

先说清楚：它不是自带的 /loop

Claude Code 自带一个 /loop，那是去执行循环——按固定或自适应的间隔，把一个 prompt 反复跑到你喊停。这个 skill 是另一半：它本身不跑任何东西，只帮你想清楚自带 /loop 不管的两件事——这个任务该不该上循环、以及循环的裁判 / 闸门 / 停止条件怎么设。先用它把循环设计对，再交给 /loop、cron 或队列去驱动。

它做什么

skill 一激活，AI 就不再把「包个循环让它自己跑」当默认动作。它先做一件大多数人会跳过的事——分流：按四个维度（能不能机器判对错、判一次便不便宜、错了能不能撤、能不能拆小）给出 GREEN / YELLOW / RED 结论 + 决定性理由，外加两条硬否决——没有忠实裁判、或有不可逆动作关不进闸门，直接 RED。

GREEN：裁判忠实又便宜、能回滚、能拆——确定性循环，基本无人值守。
YELLOW：裁判得靠模型 + 评分量表，或只能半回滚——留个人把关、把迭代次数卡死。
RED：造不出忠实裁判，或不可逆动作关不进闸门——别全自动，先把裁判造出来、或让人留在环里。

判定能上之后，它把循环搭成三层（外层调度 / 内层精炼 / 提交闸），并守住几条生产里最容易翻车的红线。它一共有五个模式：评估（assess）、设计（design）、诊断（diagnose）、加固（harden）、落地（implement）。

它守的那几条红线

maker ≠ 验收权。做事的模型不能给自己的活打分，它会打得过松；而且「证据独立」比「换个模型来判」更重要。
护住控制面。一个卡住的 agent 最爱的「修复」是改测试、降标准，而不是修产物——skill 明确禁止 maker 去碰验收契约、锁定测试、预算和停止条件。
不可逆动作关进「提交闸」。群发、发布、转账这类一旦泼出去就收不回的动作，活在内层循环之外的提交闸里，先审批、先预演，再提交。
三个硬停一个都不少：达标停、预算停、无进展停——而「无进展」得盯一个真信号，不能被一堆没意义的小改动糊弄过去。

它的脾气：会说「不」的诚实顾问

它的设计哲学就一句：让 AI 当一个会说「这个任务你造不出裁判，所以别全自动」的诚实顾问，而不是一个「什么都能自动」的推销员。

哪怕你点名要「全自动」，它也不会把审批 / 沙盒 / 提交闸拿掉，只会给你一个在安全边界内最接近的设计。最该被它拦下来的，恰恰是那些「裁判造不出来、可你又特别想全自动」的活——纯创意、定方向、拍战略。

评估，以及现状（老实说）

我给它做了配对实验：同一批任务，一组 agent 不带 skill（对照）、另一组读了 skill（实验），来隔离 skill 到底加了什么——五个场景 × opus / sonnet / haiku 三档模型，还补了一组全新领域的 held-out 测试。结论我写得很诚实：强的基座模型在那些一眼就该拒绝的场景（转账、删测试、被逼着无审批上线）本来就会做对，skill 真正的边际价值在「一致性、结构、和它强制要求的那些验证指标」，要到更小 / 更快的模型、大量重复运行下才会放大。

评估方法本身我还在迭代——怎么严谨地证明「带上这个 skill 真的让循环更可靠」，本身就是个难题，也正是我研究方向想啃的东西。它现在是 v1，仓库里连 evals（用例、prompt、量表、原始输出、局限说明）和 schemas 都开源了，欢迎来提 issue，一起打磨。

怎么装、怎么用

装：clone 仓库，把里头的 loop-engineering/ 子目录拷进 ~/.claude/skills/，开个新会话即可。
用：设计 / 评估 / 诊断 / 加固一个 agent 循环时它自动激活；也能直接问「这活适不适合上循环」。
读：SKILL.md 是主判断，三个 references 分别讲生产加固、上线部署、以及完整的「它为什么像把强化学习搬到了推理期」的推导。