让 Claude Code 自主运行的两种方式，实测只有一种靠谱

2026-05-12

1. 两种方式，截然相反的哲学
2. /goal：有裁判的自主运行
- Judge 的局限
3. Ralph Loop：忘记一切的暴力循环
4. 四个容易混淆的概念
5. 什么时候用哪个
6. 两个组合技
- /goal + Auto mode（日常最强）
- Ralph Loop 套 /goal（过夜模式）
7. 两个都会坑你
8. 真正的问题
9. 核心建议

1. 两种方式，截然相反的哲学

你给 AI 一个大任务，走开去冲杯咖啡，回来发现它在某个错误循环里转了 45 分钟。或者它说”全部完成”——但一半代码没写。

作者尝试了两种让 Claude Code 自主运行的方式。表面上看它们像双胞胎——都是让 Claude 自己跑不用管。但底层工作方式完全相反。

/goal 记住一切。 它保持一个对话，让 Claude 从每次尝试中学习。第 3 步失败了？Claude 在第 7 步时知道这一点。

Ralph Loop 忘记一切。 它杀死会话，重新开始，一遍又一遍。Claude 完全不知道五分钟前自己做了什么。

这不是一个微小差异。它决定了什么任务能工作、哪里会出问题、以及你会烧掉多少钱。

2. /goal：有裁判的自主运行

/goal 是 Claude Code 内置的命令。你设定一个终点线，它一直跑到冲线。

/goal `npm test` exits 0 and `npm run lint` exits 0

关键设计：一个独立的小模型——Judge（裁判）——观察聊天，每轮判断是否完成了目标。

Claude 不决定什么时候完成。Judge 决定。Judge 说完成了，结束。Judge 说还没完成，它告诉 Claude 缺什么，Claude 再来一轮。

这个看似平淡的设计其实是整个系统最聪明的部分——Claude 不能再对自己撒谎了。 它不能说”我觉得可以了”而测试还在报错。裁判看到了真实情况。

Judge 的局限

裁判不能跑命令、不能读文件。它只看 Claude 已经在聊天里输入了什么。

所以如果你写的目标是”让测试通过”但 Claude 从来不输出测试结果，裁判永远不知道有没有通过。它会不断判定”未完成”，循环永远进行下去。

修复方法： 把能证明目标完成的内容写进 chat 可见的输出。"npm test 返回 exit code 0 出现在输出中" 比”测试通过”好得多。要显而易见，裁判不是在读你的心思。

3. Ralph Loop：忘记一切的暴力循环

Ralph Loop 不是 Anthropic 官方功能——是开发者 Geoffrey Huntley 发明的。名字来自一个卡通角色，以永远说同样的话著称。

只有三行 shell：

while :; do
  cat prompt.md | claude -p
done

Shell 启动 Claude → Claude 做事 → Claude 退出 → Shell 用同样的 prompt 再次启动 Claude。永远循环。

惊人之处：Claude 在回合之间零记忆。 每次启动都像第一次见面。同样的 prompt，同样的项目，同样的空白石板。

这听起来很糟糕。但忘记有时是功能。

长对话让 Claude 变得奇怪——陷入早期形成的错误想法、记住并不真实的东西、上下文窗口用到一半就不够了。重新开始跳过所有这些。

但代价很明确：Claude 忘记，所以你的项目必须替它记住。这意味着真实的文件——spec.md、todo.md、state.json——来保存当前工作状态。状态文件不是可选项，它们是全部意义。

4. 四个容易混淆的概念

人们把 /goal 和其他三个 Claude Code 功能混为一谈，选错工具浪费大量时间：

模式	触发条件	核心特性
/goal	完成触发	消除”回合之间”的确认
/loop	时间触发	按间隔启动，不管是否完成
Stop hook	每回合结束	永久生效的全局脚本
Auto mode	回合内部	消除”回合内部”的工具调用确认

一句话记忆法：

/goal 消除回合之间的确认
Auto mode 消除回合内部的确认
/loop 按时间表启动回合
Stop hook 是永久的每回合结束时脚本

不同层次，不同任务。

5. 什么时候用哪个

大多数日常任务应该用 /goal。 当任务能在一个会话内完成、需要真正的完成证明、想让 Claude 从错误中学习时。例子：修 Bug 直到测试全绿、迁移一个数据库、重构一个模块。

Ralph Loop 用于罕见的大任务。 当任务太大一个会话装不下、能把状态写在文件里、能接受远程监护时。例子：实现 50 页的规格文档、重构大型代码库、跨多文件的批量任务。

作者诚实地说：开发者太容易过早选 Ralph，因为它听起来很酷。其实大部分工作 /goal 就够了。

6. 两个组合技

/goal + Auto mode（日常最强）

Auto mode 消除回合内的审批提示（”我能跑这个吗？”）。/goal 消除回合间的审批提示。两者叠加后，Claude 持续行动从不被阻断。

对 90% 的工作来说，这是最强配置。比单独用 /goal 更快，比 Ralph Loop 更可靠。适合所有能在一次会话内完成的任务。

Ralph Loop 套 /goal（过夜模式）

外层: Ralph Loop (死循环)
内层: /goal (需完成才退出)

外层 shell 循环跑一整夜。每一轮循环启动一个全新的 /goal 会话，必须完成才能进入下一轮。

你得到了 Ralph 的无限运行时间，得到了 /goal 的客观检查。两者兼得。这是作者唯一信任能在他睡觉时跑 8 小时的模式。设置更多，但值得。

7. 两个都会坑你

/goal 的坑： 如果 Claude 默默工作不输出命令结果，裁判看不到任何东西，判”未完成”然后继续循环。解决方案：告诉 Claude 展示工作输出。另外加回合预算上限防无限循环。

Ralph Loop 的坑： 没有停止条件，真的会永远跑下去。意味着真实的 API 账单。状态文件写得不好，Claude 在每一轮重做同样的步骤。而且没有裁判——如果你想信任输出，必须自己写检查脚本（make verify 或类似）。

8. 真正的问题

大多数开发者问：”哪个更好？”这是错的问题。
正确的问题是：你能相信这个 AI 说它完成了吗？

/goal 把信任建在结构里。一个独立的裁判检查每一轮。Claude 不能作弊。系统天生诚实。

Ralph Loop 信任你自己建立信任。你写验证脚本、读输出、决定何时停止。诚实是手动的。

两者都没错。它们把工作放在不同的地方。

9. 核心建议

作者用一句话总结了他的全部经验：

下次你要走开让 AI 跑长任务之前，问自己一个问题：我需要 AI 记住，还是需要它忘记？
答案决定一切。

/goal 是聪明、短、有监督的。适合完成你已经理解的任务。

Ralph Loop 是笨、长、原始的。适合大到装不进一个会话的任务。

/loop 用于观察。Stop hook 是全局规则。Auto mode 是去除每次操作的摩擦。

大多数开发者不需要花哨的自主性。他们需要知道哪个工具适合哪个工作，别再搞混了。单单这个清醒的认识就能节省几小时的浪费运行和数不清的浪费 token。