别再当人肉编译器：Claude Code /loop 与 /goal 的循环工程入门

源微信页触发了验证码拦截，正文以 Claude Code 官方文档：按计划重复跑 Prompt、Keep Claude working toward a goal、Addy Osmani《Loop Engineering》 与 OpenAI Codex Follow a goal 为准。源标题把「Loop」说成一个神秘新品——它不是 Cursor 插件，也不是某个叫 Loop 的独立 SaaS，而是 Loop Engineering（循环工程）：把「人每轮贴报错、再写下一句提示词」换成「你设计目标、工具、评估和刹车，系统自己驱动 Agent」。产品化入口主要是 Claude Code 的 /loop、/goal，以及 Codex 侧几乎同名的 /goal 加 Automations。

两年前你握着 Agent：写一句、看一眼、再写一句。2026 年春天，Claude Code 负责人 Boris Cherny 说自己已经不怎么直接 prompt 了，工作变成写 loop；OpenClaw 创始人 Peter Steinberger 把它压成一句更刺耳的话——你不该再给编程 Agent 写提示词，你该设计会去提示 Agent 的循环。争议很大：有人觉得这是 token 焚烧炉，有人觉得这是 harness 工程换皮。把命令文档摊开看，它其实很具体：一种时钟按时间叫醒，一种时钟按条件续跑。 设计不好会烧额度；设计好了，你才从人肉调度里退出来。

一、先分清三层：提示词、Harness、循环

提示词工程管的是这一轮说什么。Harness 工程管的是这一只 Agent 住在什么笼子里：权限、工具、工作目录、Skills、钩子。循环工程再往上一层：笼子可以自己找活、自己叫醒、自己把结果写回磁盘，而不必你坐在键盘前面当「人肉编译器」。Osmani 写得很直白：循环可以看成一个递归目标——你定义目的，AI 迭代到完成为止；人从「拿着锤子的那只手」变成「设计那套会自己抡锤子的制度」。

传统 for 循环执行的是固定指令序列：数据可以变，分支必须事先写死。Agent 循环执行的是目标。典型节拍是：观察当前仓库和测试 → 选一个动作 → 执行 → 再观察 → 评估离目标还有多远 → 修正。每一轮走哪条路事先不知道，所以你不能靠把所有 if/else 写进 Prompt 来「一次说完」。这也是为什么单次提示词再漂亮，也替代不了循环：很多反馈在任务开始时根本不存在——测试红了才有栈，CI 挂了才有日志，评审评论来了才有下一刀该切哪里。

2025 年 Geoffrey Huntley 的 Ralph loop 把这件事做成了极简 bash：反复把同一份提示词喂给 Agent，但每次把上下文重置到一组锚点文件，不让对话无限膨胀。2026 年春天，Claude Code 与 Codex 把同类能力收成了产品命令。/goal 是「跑到可验证条件成立」；Claude Code 另加 /loop 做会话内定时/自适应轮询。Steinberger 说的 loop 还更宽一层：循环本身可以是长期工作单元——每天扫 GitHub Issue、分流给子 Agent、测不过就继续改、绿了再开 PR。这时你设计的不是一次任务，而是一条会过夜的产线。

You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.

这句话容易被听成「Prompt 已死」。工程上不是。写得很烂的指令放进循环里只会更稳定地犯错。变的是杠杆点：提示词变成循环里的零件，评估、状态文件和停止条件才是骨架。

二、两套时钟：/loop 按时间叫醒，/goal 按条件续跑

很多人把 /loop 当成万能开关，结果要么把它当 cron 闹钟空转，要么一整晚没刹车。官方把三件事分得很清：

Claude Code 的 /loop 是捆绑技能，会话必须开着才开火。间隔和提示词都可省略：

/loop 5m 检查部署是否完成，告诉我发生了什么
/loop 看看 CI 过了没，处理新增的评审意见
/loop

三种形态分别是：固定节奏、让模型自己在 1 分钟到 1 小时之间选等待、以及跑内置保养提示（或项目里的 .claude/loop.md）。间隔支持 s/m/h/d，秒会向上取整到分钟；映射不到干净 cron 步长的值（如 7m、90m）会被改到最近的合法间隔。底层工具是 CronCreate / CronList / CronDelete，一条会话最多 50 个定时任务。固定间隔循环会一直跑到你取消或满 7 天自动过期；自适应循环在等待下一轮时按 Esc 可清掉待唤醒。官方也写明：关终端就停；漏掉的触发不会补跑；--resume 能恢复 CronCreate 出来的任务，但自适应 /loop 不会被恢复，要自己再开一次。

/goal 要的是另一类时钟。你写一个完成条件，命令立刻开一轮，条件本身就是指令。每轮结束后，会话配置的小快模型（Claude API 上默认 Haiku）只看对话里已经出现的证据，给出「未达成 / 已达成 / 不可能」三选一。写代码的模型和判卷的模型必须拆开——这就是 maker/checker 分离在停止条件上的落地。条件最多 4000 字符，且评估器不会自己跑命令或读文件，所以「test/auth 全部通过且 lint 干净」之所以有效，是因为主模型会去跑测试，结果落进 transcript 供评估器阅读。模糊的「优化一下」评估器判不了，循环就会空转或过早停。

三、产品对照：Claude Code 与 Codex 零件几乎一一对应

Osmani 的观察是：一年前你要自己维护一堆 bash 才配得上「循环」；现在零件就装在产品里。名字略有差别，能力同构。

Codex 没有 /loop 这条斜杠命令。社区里常见的踩坑是：在 Claude Code 学会循环工程后，原样敲进 Codex，以为功能缺失。Codex 把工作拆开了：会话内持久目标用 /goal（CLI 0.128+，[features] goals = true 或 codex features enable goals），重复触发用 App 里的 Automations，或把 codex exec 包进 cron / GitHub Actions。/goal 可 pause / resume / clear；官方强调完成必须基于证据，不能靠模型「觉得做完了」。长时间无人值守时，它更像一条后台任务，而不是每五分钟把同一句 Prompt 再贴一遍。

选工具时先问时钟，再问环境。只要会话开着、要盯本地构建或 PR，Claude Code /loop 最轻。要可验证终点、允许连续多轮甚至数小时，两边都走 /goal。要关机后仍跑，Claude Code 用云端 Routines 或桌面定时任务（文档对比表：云端最小间隔 1 小时、桌面 1 分钟、/loop 也是 1 分钟但必须会话在）；Codex 用 Automations。不要把三种调度叠成「既按分钟轮询又按目标死磕」——那是账单加速器，不是更强的 Agent。

四、动手：一份 loop.md 和一个可判定的 /goal

Bare /loop 默认跑内置保养：先续上对话里没做完的事，再照料当前分支的 PR（评审、红 CI、冲突），没事可做才跑清理或简化。它不会擅自开新项目；推送、删除这类不可逆动作，只在 transcript 里已经授权过的前提下继续。要把默认提示换成自己的产线，放一份纯 Markdown：

文件没有强制结构，按你要喂给 /loop 的那句话来写即可。命令行一旦带了提示词，这份文件会被忽略。超过 25,000 字节会被截断。改文件下一轮就生效，循环开着也能改。仓库 practice/loop.md 给了一份发布分支保养稿，核心是：红了修最小补丁，有评论逐条回，全绿只回一行。

/goal 则要把「完成」写成评估器能在对话里看见的东西。官方建议三条：一个可测终点、一种证明方式、若干不可破坏的约束。把时间或轮次写进条件，例如 or stop after 20 turns，可以防止完美主义空转。权限模式不会被 /goal 改掉：想无人值守，先开 auto mode，否则测试命令仍可能弹确认。非交互可以：

claude -p "/goal CHANGELOG.md 为本周合并的每个 PR 都写了条目"

默认文本输出会等到整段循环结束才打印，多轮时看起来像卡住，加上 --output-format stream-json --verbose 才能边跑边看。Codex 侧的合同写法类似：一个目标、一个停止条件、先读哪些文件、用哪条命令当证据、按检查点记进度。两边共同的反模式是把 backlog 整锅端进一个 goal——那不是循环，是假装有终点的无限工单。

五、刹车比油门重要：停止条件、额度与会变锋利的三种债

循环一旦能自己跑，失败模式也从「这一轮写错」变成「你不在的时候持续写错」。停止条件至少要准备四类，而不是只写成功：

1. 成功：评估全过，任务达标。

2. 失败：连续多轮无进展，或同类错误超过阈值，停下来换方案，而不是同一份补丁打十遍。

3. 资源：时间、轮次、token / 美元上限。Claude Code 的 7 天过期、抖动（整点任务最多推迟 30 分钟或半个间隔）、以及 CLAUDE_CODE_DISABLE_CRON=1 整段关掉调度，都是预算工具而不是装饰。

4. 风险检查点：删数据、强推、改密钥——停，等人。好的循环不是把人踢出去，是把人放在贵的决策上。

/goal 还有一批产品级护栏值得当设计约束来读。评估器判定「不可能」会清掉目标并记下失败原因。认证失败、额度耗尽、自动压缩救不回来的上下文溢出、模型不可用，会清目标并提示你修好再 /goal。过载、断线会自动重试，三次后暂停；限速或用量上限则暂停等待。子 Agent 或后台 shell 还在跑时，这一轮不评估；后台工作让目标空等 30 分钟会做一次巡检，之后间隔翻倍，每个目标在你两次输入之间最多三次空闲巡检。把 CLAUDE_CODE_GOAL_CHECKIN_MINUTES 设为 0 会同时关掉巡检和自动重试——适合你自己盯着，不适合通宵放飞。

Osmani 提醒三件会随循环变好而变锋利的事：验证仍在你身上（「完成」是声明不是证明）；理解会腐烂（循环越顺，你没读过的代码越多，这是理解债）；舒服的姿势最危险（把循环当逃避思考的加速器，就是认知投降）。两个人可以搭同一套循环，一个用它加快自己懂的工作，一个用它避免去懂。循环分不出这两种人，你分得出。所以设计循环比写提示词更难，不是更容易——杠杆点挪了，责任没消失。

环境变量和命令速查（完整列表以官方文档为准）：

六、什么时候不该开循环

不是所有工作都配得上一个过夜的系统。单文件重命名、一眼能看完的文案、需要你当场拍板的产品取舍，直接 prompt 更快，也更省钱。循环吃的是重复、可验证、反馈延迟出现的活：红测试、迁移到新 API、按验收清单实现设计文档、把大文件拆到体积预算以下、清空带标签的 Issue 队列。

还要避开三种「假循环」。第一种是没有磁盘状态：模型每轮失忆，循环就在重复发明项目约定；Skills 和进度 Markdown 是为了让循环复利，不是为了好看。第二种是 maker 兼 checker：同一条上下文既写代码又宣布写完，/goal 用小模型判卷，正是为了堵住这条捷径。第三种是把 /loop 当守护进程：它活在当前会话里，本意就是关终端即停，避免孤儿进程凌晨烧钱；要关机仍跑，请升级到 Routines、桌面定时任务或 CI，而不是把会话挂在 tmux 里假装有了平台。

最后回到那句被吵了八百万次浏览的判断：提示词仍是输入，循环才是过程。你要交付的不是更长的系统提示，而是一份别人能接手的制度——目标可测、工具够用但不泛滥、评估能自动跑、停止条件能在失败和超支时响。把循环搭起来，但要搭得像还打算继续当工程师的人，而不是只负责按开始键的人。