Claude Code 之父 Boris Cherny 深入解读 Loop 工程：AI 编程的持续工作流

Claude Code 之父 Boris Cherny 最近在一次访谈中，与 WorkOS × Acquired 的对谈里提到，自己已经不再手动向 Claude 下达提示词了，而是运行着一堆 Loop，由这些循环驱动 Claude，并判断下一步该做什么。最后他幽默地总结道：“My job is to write loops。”

随后，不少 AI 自媒体便开始断章取义，高呼“AI 编程又变天了，咱们都转向 Loop 吧”。我只能说，哪来那么多变天。其实 Boris 只是在介绍和推荐 CC 的 loop 功能。

现在的媒体特别喜欢炒“变天”——从智能补全到 Copilot，从 Vibe Coding 到 Agent，从 Prompt 到 Context，再到 Loop Engineering……标题里的天变得我关节炎都快犯了。

Loop 工程当然值得关注，但它怎么可能让提示词工程一夜之间失效呢？这未免太扯了。难道有了 loop 这条指令，开发者就能立刻进入无人值守编程了吗？我真想建议这些写作者，也踏踏实实坐下来，用 Claude Code 或者 Codex 之类的 Agent 写点东西吧——哪怕就写那么一点。

用 AI 做出一个作品来，哪怕花点钱也好，也不至于动不动就把天变来变去。

前一阵子的 /goal，现在的 /loop，其实都是 Agent 工具在自然进化中增加的能力。比如，当 Agent 能够连续执行任务，我们就不再需要一步步告诉它该做什么了，这时就可以设定目标：要达成的目标是什么，怎么验收，什么时候停下来。这就是 /goal。一旦设定了 goal，AI 便会根据条件和目标，一直做到完成任务为止。

那 /loop 又是什么呢？其实就是写循环，提示词就在循环内部。用一下就知道了，比如我写下这样一个 loop：

/loop 180m 查一下我近 3 小时的墨问动态

执行结果如下：

Image

接着 Agent 还会完成首次执行：

Image

后面这个 loop 就会每隔 3 小时检查一次墨问动态，7 天后自动到期。

就这么点事。

以前写提示词，现在写循环。提示词消失了吗？没有，它就在循环里面待着呢，提示词永不消失。

嗨，loop 不就是一个 cron 嘛，能有多大用？喂，一定要小心这类“不就是”的句子。我们很可能刚躲开一个“变天的坑”，往右跨了一步，却又掉进简化问题的陷阱里。

你可以把墨问当成记笔记的卡片，我则拿它来做付费专栏和私域。你多了个笔记，他多了个专栏和付费用户，另一位用户则整理出了 20G 的高清画廊。这就是差别。

Loop Engineering 说的正是这个道理。我们既可以写简单的 loop，也可以用 loop 构建工作流，比如来一个 PR 守夜 Loop：

每 20 分钟检查当前 PR：

  1. 查看 CI 状态、测试失败日志、review comments 和 merge conflict。
  2. 如果 CI 失败，读取失败 job 的最后 200 行日志，判断是测试问题、类型问题、lint 问题还是环境问题。
  3. 为修复创建独立的 git worktree，避免污染主工作区。
  4. 只修复最小必要代码，不做顺手重构。
  5. 在本地运行对应测试、lint、build。
  6. 如果通过，提交 commit，并在状态文件里记录：
    • 问题来源
    • 修改文件
    • 验证命令
    • 是否需要人工复核
  7. 如果 review comments 有新的意见，逐条处理，无法处理的标记为 blocked。
  8. 如果 CI 全绿、无未解决评论、无冲突，停止 loop，并输出合并前摘要。
  9. 如果连续 3 轮失败原因相同，则停止 loop，交还给人来处理。

在 Claude Code 里，这个任务可以被拆成一个 /loop 和一个 /goal：

/loop 20m 检查当前的 PR。如果 CI 失败，诊断失败的 job，仅在 worktree 中修复最小原因，运行相关测试，并更新 .agent/pr-watch.md 记录所做的更改。如果 PR 是绿色且无异常的，说明情况并停止调度下一次运行。

/goal 当前 PR 已可合并：所有 CI 检查均已通过，没有未解决的评审意见，不存在合并冲突，npm test 和 npm run build 在本地通过，.agent/pr-watch.md 包含最终总结，或在 20 轮后停止。

更复杂一些，还可以构造一个 从用户反馈到产品改进的 Loop。

它每天早上读取 GitHub Issues、用户反馈、客服记录和产品埋点数据，把反馈聚类成三类：bug、体验问题、功能建议。然后只挑一个高频且可验证的问题进入工程处理。先写一页 mini spec，列出复现步骤、预期行为、验收标准，再开一个 worktree 做修复。修完后跑测试，必要时用 Playwright 打开页面验证关键流程。最后生成 PR 描述，并把“为什么做、改了什么、如何验证、风险在哪里”交代清楚。

你瞧，这也是 loop，这是不是 Loop Engineering？显然是。这考验的正是驾驭 AI 的能力。但你自己做 Vibe Coding 的时候，该怎样交流，不还是得怎样交流吗？

好的 loop，其实就是设计一个系统来完成某件事。一个 loop 可以理解成递归的目标：定义目的，让 AI 迭代，直到完成。

这神秘吗？一点也不。写过程序的人都知道，循环从来不只是重复那么简单。一个有用的循环，至少要有输入、状态、判断条件、动作、反馈和退出机制。缺少退出条件，循环会失控；缺少反馈，循环会跑飞；缺少状态，后续的循环就会失忆。

AI 编程里的 loop，本质也是一样。

Claude Code（Codex 也有）的 /loop 和 /goal，其实就是程序中的循环在 AI 时代的产品化体现。

/loop 用来按时间间隔重复运行提示词，可以检查部署、照看 PR、处理长时间构建。

/goal 则是用户设定一个完成条件，Claude 会跨多个 turn 持续工作，直到一个独立的小模型判断目标基本满足。

一个强调节奏，一个强调完成条件。真正的 Loop 工程，通常要把两者背后的思想结合起来。

这对 Vibe Coding 显然是有帮助的：

1、要有更好的工程上下文。Addy Osmani 在《Loop Engineering》里提到，长时间运行的 agent 需要一个存在于单次对话之外的记忆层，可以是 Markdown 文件，也可以是 Linear 看板。

Claude Code 的 memory 文档也提到，每个 session 都从新的 context window 开始，CLAUDE.md 和 auto memory 才是负责把项目知识带回来的角色。

换句话说，Vibe Coding 进入 loop 阶段后，上下文不能只靠聊天会话保留，它需要外置到仓库、规则、Skill 和状态文件里。

2、最好把“写”和“审”分开。让同一个 Agent 写代码，再让它判断自己是否完成，风险很高，它往往会相信自己不可能写出 bug，这跟人有点像。

更可靠的做法，是让一个 Agent 编程，让另一个 Agent 审查，或者至少让测试、类型检查、构建、Playwright 这类外部机制参与判断。

3、别忘了成本。Loop 非常迷人，它让 AI 看起来好像可以一直工作。但一直工作意味着一直消耗 token。因此刚开始 Vibe Coding 的时候，不要一上来就追求“全天候自动化”，除非你真的不在乎开销，嗷嚎。

回到开头，Boris 说“My job is to write loops”，这是什么意思呢？

新功能上线了，他用着觉得太爽了，所以赶紧招呼大家：“快用起来啊，兄弟萌～”