2860 star 的 loop-engineering，把循环工程拆成了 7 个能直接 clone 的模式

大家好，我是若风。

关于 loop engineering（循环工程），我前面已经写过两篇了。一篇拆 Addy Osmani 的概念，五个构建块怎么搭出一个循环系统。一篇拆 Codez 的 14 步路线图，从判断要不要做 loop，到最小可行循环怎么落地。

但说实话，那两篇都偏「想清楚」。

想清楚之后呢？你坐在编辑器前，要敲第一条 /loop 命令了，这时候发现概念是概念，落地是另一回事。Daily Triage 到底跑多频繁？CI Sweeper 的 token 花费会不会失控？怎么知道我这个 loop 现在是 L1 还是 L2，能不能放心让它自动改代码？

这些具体问题，Cobus Greyling 这个 2860 star 的 loop-engineering 仓库回答了。它不是又一篇概念文，而是一份操作手册。7 个能直接 clone 的生产级模式，3 个专门测「你准备好没有」的 CLI 工具，外加一份讲 loop 怎么挂掉的故障目录。

我把它拆开给你看。

这个仓库到底在干嘛

一句话定位，loop engineering 解决的核心问题是，取代你自己去 prompt Agent，转而设计一个系统替你做这件事。

这是 Peter Steinberger 和 Anthropic Claude Code 负责人 Boris Cherny 都说过的判断。Boris 原话很直接，「我不再手动 prompt Claude 了。我有循环在运行，它们负责 prompt Claude 并搞清楚该做什么。我的工作是编写循环。」

杠杆点已经从「写一条好 prompt」上移到了「设计那个会自动 prompt agent 的系统」。

但 Addy 和 Boris 给的是方向，Cobus 给的是落地。这个仓库做了三件实事，我觉得这是它能在不到三周（2026 年 6 月 9 日创建）攒到 2860 star 的原因。

第一，把抽象的「循环」拆成 7 个有名字、有 cadence、有成本档位的模式。第二，给了 3 个 CLI，让你在动手之前先量一下钱和风险。第三，诚实地记下了 loop 怎么挂，而不是只讲成功故事。

这三样东西，恰恰是前两篇概念文没法给你的。

7 个模式，不是一个套路套到底

说真的，很多人对 loop 的理解还停在「让 agent 一直跑」。但「一直跑」不是设计，是赌博。Cobus 给的 7 个模式，差别全在 cadence（运行频率）和风险档位上。

你想想看，这里面的差别有多大。

CI Sweeper 每 5 到 15 分钟跑一轮，还要碰代码，Token 成本标的是「非常高」。而 Changelog Drafter 一天跑一次，只产出草稿，成本是「低」。同样是 loop，一个能把你账单烧穿，一个几乎不花钱。如果不分模式地「让 agent 一直跑」，你大概率会撞上 CI Sweeper 这种烧钱档，然后觉得 loop engineering 不靠谱。

这正是这个表格的价值。它逼你在动手前先选档位。

而且每个模式都不只是个名字。仓库里每个模式都配了独立的 markdown，写清楚目标、所需 Skills、状态文件结构、典型运行周期、验证策略、人工接手点、各工具（Grok / Claude Code / Codex / GitHub Actions）的具体命令，还有失败模式对照表。比如 Daily Triage 单独算了一笔账，空跑约 5k token，完整 L1 分类约 50k，进入 L2 辅助修复约 200k。

这些数字，概念文给不了你。

想清楚还不够，得能量化

我自己觉得这个仓库最被低估的，是那 3 个 CLI 工具。loop-init、loop-cost、loop-audit。

loop-init 解决的是「从零到第一条命令」的冷启动。一行 npx 跑下去，它帮你复制 starter kit，生成 STATE.md、LOOP.md、loop-budget.md、loop-run-log.md 四个文件，然后直接打印出你应该跑的第一条命令。你不用自己琢磨状态文件长什么样。

loop-cost 这个最关键，它在你排定运行频率之前先估 Token 花费。你想想看，CI Sweeper 配 5 分钟 cadence 和 Daily Triage 配 1 天 cadence，账单能差两个数量级。先量后跑，这是成年人做 loop 的基本动作。

npx @cobusgreyling/loop-cost --pattern ci-sweeper --cadence 15m
npx @cobusgreyling/loop-cost --pattern daily-triage --level L1 --cadence 1d

loop-audit 给你的项目打 0-100 分，告诉你离 L1、L2、L3 还差什么，--suggest 出具体下一步。它还会读 loop-budget.md 和 loop-run-log.md，把「有没有预算」和「有没有运行记录」也纳入打分。甚至能给 README 生成一个 Loop Ready 徽章。

坦率的讲，这三个工具加起来，回答了一个前两篇都没回答的问题，你怎么知道自己准备好了。

概念文会告诉你「先报告后动手」，但「报告」到「动手」中间那条线在哪？loop-audit 用分数画出来了。分数到了约 40 分算 L1，可以开始第一个 loop。到 L2 才能动手辅助修复。L3 才能真正无人值守。这不是拍脑袋，是把判断变成了可量化的东西。

三层放量，而不是一步到位

这也是我特别想单独拎出来讲的一点。Cobus 反复强调一个原则，第一周只报告，不自动修复，不自动合并。

仓库里把它固化成了三个档。

L1，report only。loop 只读 CI、读 issue、读 commit，产出一份优先级清单，写进 STATE.md。它不碰代码，你读完它写的东西，自己决定下一步。

L2，assisted fix。在隔离的 worktree 里，让 implementer sub-agent 写补丁，再让 verifier sub-agent 验证。但 PR 还是要你点。

L3，unattended。loop 自己改、自己验证、自己提交。但 L3 的前提是 loop-budget.md 和 loop-run-log.md 都填好了，LOOP.md 里写清了人工 gate，而且有足够多的成功运行记录。

这个分层的意义在于，它把「放权给 AI」做成了一个可逆的渐进过程，而不是一次性跳崖。你可以在 L1 停两周，确认 triage 质量稳定了，再往 L2 走。出问题了，随时退回去。

loop 怎么挂的，仓库比谁都诚实

老实说，很多讲 loop 的内容都在讲它能干什么。这个仓库专门有一份 failure-modes.md，按严重程度分 S1（烦人）、S2（有害）、S3（严重），列了一堆 loop 真实的死法。

我挑几个最扎心的。

Infinite Fix Loop（无限修复循环）。同一个 PR 或 CI 任务被自动修复尝试 5 次以上，永远不收敛。原因通常是 verifier 太弱，或者根本和 implementer 是同一个会话，或者把 flaky test（偶发性测试失败）当成了 regression（回归错误）。解法很朴素，硬性上限 3 次尝试，超过就升级给人工。

Verifier Theater（验证器表演）。verifier 说「看着没问题」，结果 CI 挂了，review 一眼看出 bug。根因是 verifier 的 prompt 太模糊，只说「looks good」，或者干脆不跑测试，或者和 implementer 用同一个模型同一个上下文。解法是 verifier 必须真的跑 test 和 lint，而且指令要写成「找理由拒绝我」。

Comprehension Debt（理解债）。这个最隐蔽。loop 跑得越快，你仓库里没读过自己写的代码就越多。你想想看，这个债增长的速度，比你读代码的速度快多了。Addy 那句，「构建循环。但要像一个打算继续当工程师的人那样去构建，而不是那个按下启动键的人。」

Cobus 还点了一句很清醒的话，我觉得值得原样转述。loop 放大的是判断力，好的坏的都放大。两个人跑同一个 loop 可能得到相反的结果。loop 不知道，你知道。

这不是吹 loop 多厉害，这是在提醒你别把脑子交出去。

这套东西的实际边界

我得讲句实话，这个仓库不是银弹，它自己也明确承认了几条边界。

Token 成本可能爆炸。子 Agent 和长时间运行的 loop 叠在一起，账单能飞。这就是为什么 loop-cost 要在排 cadence 之前先跑。

验证永远是你自己的活。无人值守的 loop，也会无人值守地犯错。L3 不是放手不管，是你已经验证了足够多次。

理解债增长比你还快。除非你真的去读 loop 产出的东西，否则仓库里会堆满你没看过的代码。

还有一层我自己的观察。这套模式现在主要围绕 Grok、Claude Code、Codex 三个工具展开，Cursor 和 Windsurf 还没有对应的 loop-init starter，需要手动迁移。仓库的 Primitives Matrix 把这几个工具的能力做了对照，但工具本身的循环能力还在快速变化，这份对照表的有效期有限。

说真的，这些诚实的限制，恰恰是这个仓库最值钱的地方。一个开源项目敢把自己的失败模式单独成文、按严重程度分级，说明维护者是真的在生产里跑过，不是写个 demo 凑 star。

写在最后

如果你已经看过 Addy 或 Codez 的文章，心里认同 loop engineering 的方向，那 Cobus 这个仓库是你下一步该去的地方。

它把「想清楚」之后的「怎么动手」拆得很细。7 个模式让你按风险档位选起手式，3 个 CLI 让你先量钱再跑，三层放量让你可逆地放权，故障目录让你知道哪会挂。

我自己最直接的感受是，loop engineering 现在已经过了「要不要做」的争论期，进入了「怎么做才不翻车」的工程化阶段。Cobus 这个仓库，是少数几个把这个阶段的需求认真接住的开源项目。

想上手的话，最快的路径是这样。挑一个你正头疼的痛点（比如每天早上的 CI 收拾），跑 loop-init 选 daily-triage 模式，用 loop-cost 估一下钱，loop-audit 看看自己到了哪一档，然后第一周老老实实只读 STATE.md，不碰代码。

别嫌它慢。loop engineering 的第一课，就是学会在该慢的地方慢下来。