Claude Code之父说的 “Loop 工程”到底是怎么回事？就问咋变天的？

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

然后一堆 AI 自媒体就开始断行取义了，啊，AI 编程又变天了，咱们都 Loop 吧。我只能说，变你二爷。其实人家只是在介绍和推广 CC 的 loop 功能。

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

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

用 AI 写个作品出来，哪怕花点钱呢，也不至于变天变这么快。

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

/loop 是啥呢，其实就是写循环，提示词就在循环里，用一下就知道，比如我来写个 loop：

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

执行结果如下：

然后 Agent 还会做首次执行：

后续这个 loop 就会 每 3 小时查一次墨问动态，7 天后自动过期。

就这么个事。

以前写提示词，现在写循环。是提示词没了吗？人家提示词就在循环里呢，提示词永不消失。

嘿，loop 不就是个 cron 么，能有啥用。你看，一定要警惕这种“不就是”的句子，我们很可能躲过了“天坑”，向右跨一步，掉入了简化问题的陷阱。

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

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、用户反馈、客服记录和产品埋点数据，把反馈聚类成 3 类：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”，这啥意思呢？

新功能上线了，我使着老爽了，赶紧用起来啊兄弟萌～

我也吆喝一下，Vibe 社群开启二群啦，快来啊