Loops 入门：让 Claude 自己把一件事做完

看完这份笔记，你会知道的四件事

1. loop 到底是什么，以及你其实已经在用它。你送出的每一个提示都已经启动了一个 loop，差别只在于它的停止条件是「Claude 判断这一轮讲完了」。
2. 决定一个 loop 好坏的三个设定。这三个设定分别是何时启动、卡住时什么让它停、谁判定它做完了。
3. 五种模式各自在什么时候启动、什么时候停、适合哪一类任务。五种分别是回合制、目标制、定时制、主动制与动态工作流。
4. 怎么判断手上哪一件事可以交出去。讲者给了三个自检问题，三题都答是就代表那件事不再需要你守在键盘前。

看完这份笔记，你可以立刻动手做的三件事

1. 筛出一件你自己就是瓶颈的事。用第 6 节的三个问题去筛，例如每天要重复填写的表单、每天要看一遍的清单、每天要整理一次的收件匣。
2. 替那件事写出一句机器能验收的完成条件。写不出量化条件时，改成描述一份合格的成品长什么样，例如要求它逐条查证事实并确认每个引用都指向真实网页。
3. 挑对应的模式起一个 loop，同时设好回合上限。讲者建议的上限值是 10 到 15 个回合，这笔预算是为了防范失控而花的。

五种模式速览

现在多数人使用 AI 助手的方式是一问一答：你提出一个要求，它执行一轮，把结果交回给你，你看过之后再提下一个要求。这个循环的每一轮都需要你坐在电脑前。

Loop 指的是同一个循环由 Claude 自己重复执行，直到你事先设定的停止条件被满足为止。差别不在于模型变聪明了，而在于「要不要再来一轮」这个判断从你手上移交了出去。

讲者在简报第 04 页给出的定义是：loop 是 agent 反复执行工作循环，直到停止条件被满足。一轮循环包含三个动作，分别是收集上下文（读档案、搜索资料、必要时向你发问）、执行动作（编辑档案、运行指令、构建项目）、以及检查自己的成果。如果检查没有通过，它回到第一步再跑一轮。

这一页真正的重点在标题上：你送出的每一个提示，其实早就启动了一个 loop。讲者举的例子是你在网页上问「纽约今天天气如何」，Claude 会接收这个提示、上网查资料、检查查到的东西有没有回答你的问题，没有就继续找。只是这个 loop 的停止条件是「Claude 判断这一轮讲完了」，所以它跑完一轮就把控制权交还给你。后面五种模式的差别，只在于什么启动这个循环、以及什么结束它。

简报第 03 页把这个转变命名为 loop engineering，并且和大家熟悉的 prompt engineering 做了对照。Prompt engineering 处理的是「模型没照我的意思做，我该怎么把话讲得更精确」；loop engineering 处理的是「我要怎么让 Claude 反复地、甚至在我不在场时替我做事」。讲者在这一页给出的判断是，现在把这三个决定弄错，已经比写坏一句提示更常见。

1. 何时启动。触发它的可以是你送出的一句提示、一个目标、一个计时器，或是一个事件。
2. 卡住时什么让它停。你可以让它跑满几个回合就停，也可以设成跑满 30 分钟或 5 小时就停；如果你不介意成本，也可以让它一直跑。讲者强调这一条的作用是守住 token 预算。
3. 谁判定它做完了。判定的依据可以是一个测试、一份格式规范、或一段脚本。这三样你如果一样都没给，就等于接受由 Claude 自己判断什么时候算完成。

第三个决定是整场的重心。讲者的说法是，很多情况下让 Claude 自己判断完全没有问题，但有些情况你会想亲自定义一个判准。你写不写得出这个判准，直接决定了这件事能不能交出去。

开场投票问的是「你现在对 loop 有多熟悉」，现场结果是 58.29% 从来没有用过、28.76% 用过几次、12.95% 每天都在用。讲者当场的回应值得记下来。他说，你们很快会发现情况恐怕不是这样，因为按照第 04 页的定义，凡是送出过提示的人都已经在用 loop 了，只是没有意识到。所以这场讲座要跨过的门槛不在能力，而在于知不知道停止条件是可以由你来设定的。

简报第 05 页把四种基础模式并列出来，第 18 页的对照表又补上第五种。这五种可以放在同一条轴上理解：你需要出现的时刻越来越少，而「怎样算做完」必须写得越来越明确。

4.1　回合制 Turn-based：你已经在用的那一种

你送出一句提示，Claude 执行一轮就停。这是每个 Claude Code 会话的默认行为。

• 什么时候启动你送出一句提示，它就开始运行。
• 什么时候停Claude 判断任务完成时它停下，或者它认为需要你补充信息时停下。讲者举的例子是你请它用 Gmail 送一封信，它回过头来问你这样可不可以，那次询问就是一个停止条件在起作用。
• 适合什么任务它适合较短的一次性任务，例如修一个 bug、改一个命名、问一个关于代码库的问题。
• 怎么管它你要把提示写具体，并且把验收交给 skill。

换到非技术场景整理一批客户反馈、去掉重复项、给每一条起草回覆，这类做完就结束的任务，用回合制就够了。

关于 skill 讲者补了一段说明：它的用途是把过去反复试出来的做法固化下来。假设你做一份设计稿，来回调了很多轮才调出想要的样子，那就把那套做法打包成一个 skill；下次你说「帮我做一份新产品的设计稿」，它会自动引用这份 skill，不必再走一遍同样的来回。

演示里，一句提示同时带上了验收指令。Claude 读完收件匣、标掉重复项、写出分类后的档案与回覆草稿，最后自己运行 check_triage.sh 这个检查脚本并回报通过。画面底部那句注解点出了关键：检查是写在提示里的，所以是 Claude 去跑它，不是你。

4.2　目标制 /goal：你说清楚怎样算做完

• 什么时候启动你在 Claude Code 里输入 /goal 加上目标，由你亲自启动它。
• 什么时候停它达成目标时停下，或者触到你设的回合上限时停下。讲者建议两个都设，让这个 loop 有两条结束的路。
• 适合什么任务它适合有可验证结束条件的任务，例如测试要全部通过、构建要成功、输出要符合某个规格。他举的例子是产出一则少于 250 字元的推文，Claude 会一直修改到字数达标。
• 怎么管它你要把检查写进目标本身，同时给出回合上限。

换到非技术场景把一份文件改写到符合一张明确的检查清单，例如每一节都要有具体数字、全篇不得出现指定的几个词、总长不超过两页。只要你写得出这张清单，它就能自己改到达标。

回合上限该设多少，讲者给了具体建议：它的作用是防止失控，所以值可以设高一点，10 或 15 都合理，为了防范万一的情况，这笔预算是值得花的。

演示里发生了两件事。第一，它在两个回合内就停住了；第二，所有检查项都通过。讲者补充说，假设你设的是五个回合而检查还有三四项没过，它会报告还差哪些然后停下，不会无限跑下去。

4.3　定时制 /loop 与 /schedule：挂在计时器上

• 什么时候启动计时器到点时它自动启动。你输入 /loop 加上提示与间隔来建立它。
• 什么时候停你取消它，或者被观察的那件事已经完成，例如那个 PR 合并了、那个队列清空了。
• 适合什么任务它适合观察一个会变动的对象，例如待审的 PR、部署队列、收件匣。
• 怎么管它你要把间隔配合被观察对象的实际变化速度，不要设得比它更快。

避开三个容易出错的地方

1. 每一次重跑都是全新的一次，不是接着上次继续。你写「每 30 分钟查一次纽约天气」，它每 30 分钟就原样跑一次那句提示。
2. 间隔要按需要定，不是越快越好。他用收件匣举例：身为创办人，没有必要每三五分钟查一次邮件，但也不想等上一整天，所以设成每小时一次。这样既不会把预算耗在无效运行上，事情也不会拖太久。
3. 本机运行依赖你的电脑开着。/loop 需要你的笔电开着并且 Claude Code 在运行，要摆脱这个限制就换成 /schedule。

上面四条要点的英文原页在下方。讲者在这一页的重点是最后一格：间隔要配合被观察对象的实际变化速度设定，不要设得比它更快。

演示里，第一轮检查发现持续集成还没跑完、审查也还没到齐，于是它什么都不做就退出；间隔过去之后条件成立，它才执行合并。画面最后一段把这个 loop 交给云端，间隔也随之从每分钟一次改成每小时一次。

简报第 12 页把两个落脚点的差别讲得很清楚。

• 本机运行 /loop它在你的终端里运行，你关掉会话它就结束，最小间隔是 1 分钟。
• 云端运行 /schedule它把同一件事交给云端，以 Routine 的形式运行，你的笔电关着也照跑，最小间隔是 1 小时。
• 上云的取舍它必须在你不在场的情况下跑完。没有人会去拦一次跑坏的运行，所以那个完成条件必须是你信得过的。
• 怎么取消它你先执行 /schedule list，再执行 /schedule remove <id>；你也可以到 claude.ai/code/routines 这个页面上管理与删除。

讲者对上云的一句实务提醒你看不到它在跑。它可能每小时跑一次、连跑十周，而你毫无察觉。所以他建议客户务必让它把结果输出到一个你会看到的地方，例如发一则 Slack 消息或一封邮件，用来提醒你这项任务还在运行。

如果你需要的频率是每几分钟一次，云端 1 小时的下限就不适用；讲者建议这种情况改用 Agent SDK 或 Managed Agents 这类产品。

4.4　主动制 routines：连开始都不用你

• 什么时候启动一个事件或一份排程会触发它，例如一个 webhook、一张新建的工单、每天夜里的某个时刻。
• 什么时候停每一次运行达到它的目标就退出；背后那份 routine 会一直待命，直到你把它关掉。
• 适合什么任务它适合会自己找上门、而且时间不固定的工作，例如故障报告、工单分派、依赖升级。讲者的判断标准是，什么时候来不可预测，但来的东西长什么样是描述得出来的。
• 怎么管它你要按模型分流，把例行的简单判断交给较小较快的模型，把需要下判断的交给能力最强的模型。

模型分流他给了一组对照：单纯的例行检查用 Haiku 就够；要在一堆产品分析数据里推断某个客诉的成因，那就该用 Opus 或 Fable。主动制还有一个成本上的优点，讲者说它反而是最不容易失控的一种，因为它只在被触发时才启动，达到目标或发现信息不足需要找人时就关闭。

演示的场景是先注册一次触发条件「出现 Sev-1 级故障就分派处理」。事件发生后 Claude 自己拉出告警、翻查最近的部署记录、定位到某个把超时从 30 秒改成 3 秒的提交，然后把摘要、可疑提交与回滚指令发到 Slack 的 #incidents 频道，做完就回到等待下一次触发。全程没有人碰键盘。

换到非技术场景讲者在问答里给的例子是监看 Slack。你可以设成每 10 分钟看一次自己的 Slack，只有当某件事真的重要到该把你从手上的工作里拉走时，它才在 Slack 里 @ 你或发一封邮件通知你。

4.5　动态工作流 ultracode：一个 loop 装不下的时候

• 它是什么它是一段编排子代理的 JavaScript 脚本。你描述任务，Claude 写出这段脚本，再由运行时执行它。
• 计划由谁掌握计划由这段脚本掌握，不是由 Claude 一轮一轮地掌握。
• 什么时候用它当一件事需要几十到几百个代理时才用它，例如整个代码库的审查、大规模迁移、需要交叉查证的跨领域研究。
• 怎么启动它你用「use a workflow to ⋯」这样的说法要求它，或在提示里的任何位置加上 ultracode 这个词。这是一个必须由你明确开启的选项，Claude 不会自己去用。

讲者解释了这样设计的关键好处：几十个子代理各自去查资料、做事，最后只把结论回传给中央那个 Claude，所有中间过程留在脚本的变量里，不会涌进中央的上下文。中央拿到的是一批答案，可以直接在上面做推理。

演示的规模值得留意。这是一个审查所有路由处理器有没有漏掉认证检查的工作流，分成 discover、audit、verify、report 四个阶段，audit 与 verify 各出动 24 个代理并行处理，而会话本身依然可以响应。最后有 3 项发现被负责反驳的验证代理推翻、没有写进报告，剩下 6 个漏掉认证检查的路由处理器，每一条都附上了查出它的那次审查。

ultracode 这个词做的事情，是把策略从「把这件事做完」翻转成「务求穷尽，成本不是约束」。所以讲者提醒要克制使用，并且给了一个判断框架：

成本和回报是两件事。回报是这笔投入换回了什么，成本是你为它付了多少。如果你的注意力永远只放在压低成本上，那么你压低的往往也包括回报。

问答里有人问这段脚本是否透明可改，讲者的回答是你可以看到脚本内容，也可以和 Claude 一起决定要改什么。

他自己动用它的时机有两个。第一个是在一个产品的开头做全面调研，目的是确保没有漏掉什么。第二个是遇到极难的问题，例如竞态条件，或者合并请求看起来没有问题但部署就是出错。/deep-research 是内建的一个工作流，用法像是「/deep-research compare Postgres vs Mongo for our workload」；跑过一次觉得好用，可以把那次运行存下来变成你自己的命令。运行期间随时可以输入 /workflows 查看进度。

下面这张表是简报第 18 页的中文整理，是全场最适合单独存下来的一页。

讲者用一个非技术的例子开场。假设你是律师，每天要把工时填进事务所的系统；你手边有随手记下的笔记，写着哪个案子花了多少分钟。你可以设一个每 12 小时跑一次的 routine，让它读这份笔记，再把工时填进报时系统。在这件事上，瓶颈是你本人。

三个问题里，讲者在第一题上补的那句判断法，是整场我认为最实用的一句：

你能不能把这件事讲给同事听懂。人们用 AI 最常见的失败模式，是把它当成能读心的对象。你应该把 Claude 看成一位很聪明、很能干、但对你的处境一无所知的同事；只要你能把工作讲清楚并写下来，它就会做得更好。

如果这件事写不出量化的检查，讲者也给了办法：不是所有工作都有可验证的结果，这时候改成描述「一份合格的成品长什么样」。他举的例子是写报告——报告本身无法量化，但你可以要求它逐条查证报告里的事实，并且确认每一个引用都指向一个真实存在的网页、而且那个网页的内容确实支持报告里的说法。要求写得越具体越好。

还有一个用法上的建议：不要独自把 /goal 的提示一次写完。你可以先对 Claude 说「我要写一个目标来完成某份报告，我应该考虑哪些事」，让它反问你篇幅、要包含哪些内容，两边来回把这个目标定下来，再拿去启动。

1. 破坏性动作一律留人工复核。讲者在问答里被问到该设哪些硬性停止条件与人工复核关卡，他的回答是：只要涉及破坏性动作就需要人工复核，删除是最典型的一种；退款也算，可以设成超过某个金额就必须由人来批。
2. 保守起步，再逐步放松。他建议一开始一律保留人工复核，之后再慢慢减少它来问你的次数，凭实际效果调整。
3. 无人值守的 loop 一定要设回合上限。他给的具体写法是在提示里直接写明「只做五个回合」。任务描述得越具体，它越可能停在你要的那个判准上。

4. 上云之后你看不到它。让它把结果送到 Slack 或邮件，否则它跑了十周你也不会知道。
5. ultracode 会大量消耗额度。在不必要的场合使用它会消耗大量 token，所以要选在真正值得的场合，例如项目开头的全面调研，或是长期未能解决的疑难问题。

一句总结前面五种模式让你不必在场，这五条护栏决定的是「你不在场的时候，出错了谁来拦」。讲者的立场是宁可一开始设得紧，再按实际情况放松。

8.1　模型怎么选

讲者给的方法是从中间起步：先用 Sonnet 跑这个 loop，如果它没做到你要的、而且原因看起来是智能不够，就换 Opus，还不行就换 Fable；如果 Sonnet 跑得很好而你想节省预算，就试试 Haiku 能否达到同样效果。他强调这整件事是经验性的，只能靠实测。

两端的判断依据是任务性质。需要在一堆记忆里推理、决定哪些值得留下哪些可以丢掉，属于要用强模型的一类；「每小时看一次收件匣，有账单类邮件就通知我」这种是非题式的判断，用 Haiku 就够。

8.2　怎么接进现有的工作流程

• 组织内部的例行事项只要你自己就能验收、而且知道该多久跑一次，这类事项就适合，例如每天一次的用户研究。
• 接进持续集成他见过做编程工具的客户自己做了一个 bug bot，在合并请求进入人工审查之前先跑一遍，把明显的问题挡掉。
• 日常琐事前面提过的 Slack 监看就属于这一类。

他给的通用方法是：花一天观察自己的行为，问自己「我现在做的事情里，有哪些其实不需要我做、可以自动化，好让我专心在工作的其他部分上」。他说一旦养成留意自己工作方式的习惯，就会开始看见机会。

8.3　要不要把 loop 做进自己的产品里

讲者的回答是可以，并且举了两个例子。第一个是定期回头看用户在你的应用里的使用情况——最近还在用吗、如果不用了是为什么、哪些功能被反复使用，把这些产品分析结果主动送到你这个产品负责人手上。第二个是二手商品交易的场景，定期抓取网络上的新挂牌，比对自己算出来的市场价，挑出低于市价的标的；这件事本身就可以发展成一个产品。

8.4　loop 和 cron job 有什么不同

讲者的回答是 loop 可以把 cron job 包进来。Cron job 是软件里按排程运行的机制，概念上很接近；loop 的差别在于它把同一件事变得在 Claude Code 的终端里更容易使用。如果你已经在自己的软件产品里用 Agent SDK 触发动作，那样做也完全可以，loop 只是一种更省事的封装。

8.5　对个人产能的实际影响

他说过去可能要花几周的工作，现在一天就能做完，常见的做法是把任务定成「做到完成为止」。他还提到自己和同事的一个习惯：把睡觉的时间当成跑 loop 的机会，睡前启动，醒来就有一批结果在那里。