loop-engineering-skill

我为什么做它

Loop Engineering（循环工程）今年突然火了。它听起来很诱人：让 AI 自己检查、自己修改，一直跑到成功，人就能从重复劳动里退出来。

可我白天做 Agent 产品、晚上在同济做 agent 评估方向的研究，越看越不放心：如果负责判断「成功」的东西本身就偏了，循环就会一轮轮继续烧 token，把同一个错误打磨得越来越像答案。模型越强，甚至越会找到标准里的空子。

所以我把注意力从「怎么让循环跑起来」移到了那个负责验收的「裁判」上。循环的上限，就是裁判的上限；裁判决定下一枚 token 买到的是进展，还是更多垃圾。这个 skill 做的第一件事，是让 AI 在动手之前先回答：这项任务到底该不该自动循环？

我先让它学会说「不」

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，一起打磨。

git clone --depth 1 https://github.com/qingqingpi/loop-engineering-skill.git
mkdir -p ~/.claude/skills
cp -R loop-engineering-skill/loop-engineering ~/.claude/skills/
rm -rf loop-engineering-skill