你每天早上打开 Claude,输入一段 prompt,它帮你改了一段代码。你跑了一下测试,报错了。你把错误信息贴回去,它又改了一遍。二十分钟过去了,你发现自己一直在给一个本该自动运行的东西当保姆。
这不是你的问题。这是绝大多数人现在用 AI 的方式。
Anthropic 的工程师 Boris Cherny——Claude Code 的实际构建者——在 2026 年 6 月的一次公开分享中说了一句话,让整个 AI 编程圈炸了:
"我已经不再给 Claude 写 prompt 了。"
他的新工作是什么?写循环。
这句话不是炫耀。它指向的是 2026 年 AI 使用方式最大的范式转变:从 prompt engineer 变成 loop engineer。
你是那个"循环",而不是在"用循环"
先看大多数人现在的典型工作流:
问题出在哪一步?第 3 步和第 5 步——你。你是那个在每次执行后检查结果、决定下一步的人。你在充当循环的控制逻辑。
Boris 说的"不再 prompt",意思就是他不再做这个中间人了。他把"检查→决定→再试"这个循环交给了系统本身。
一个例子说明全部差别
让 Claude 写一篇关于任意主题的一页简报。它会写得漂亮又自信,底部还会附上引用来源。
然后你去看那些引用——有些是假的。Claude 编造了它们,而且完全不知道自己编造了。链接打不开,或者打开了但内容和它说的完全不是一回事。
这是 Claude 最安静的"烧你"方式。而且一次 prompt 永远抓不到这个问题,因为 Claude 在被指出错误之前永远自信满满。
现在用循环的方式跑同样的任务。你加一条硬性标准:
每个论断至少需要三个来源,并且每个链接必须能打开到一个真正支持该论断的页面。
然后看它怎么做:Claude 先写简报,然后逐个检查链接。打不开的扔掉,编造的替换掉,一直找到真实可用的来源为止。检查通过每一个,才会停下来。
它永远不会觉得无聊。永远不会跳过那些枯燥的检查步骤。
这就是 prompt 和 loop 的本质区别:一个是一次性赌它做对,一个是反复检查直到确实做对。
循环的五个节拍
不管多复杂的循环,剥开来看都是同样的五个动作:
1. 找到活。 扫描待办、失败的测试、未读邮件、文件夹里的文件——找到该做的事情。
2. 做。 Claude 一次处理一个事项,就像你手动做一样。
3. 自我检查。 第二遍确认工作完成了且是正确的,不是"产出过了就算完"。
4. 记住。 把做完的记下来,不重复劳动,不丢失进度。
5. 再来。 重复直到没有剩余事项,然后停下来或通知你。
一句话总结:prompt 是干活,loop engineering 是管理干活的工人。
这不是 cron 定时任务
你可能会问:这不就是 cron 吗?每天早上 8 点跑个脚本,几十年前就有了。
不一样。关键区别在于:循环里面有一个决策者。
cron 跑的是固定脚本,同样的步骤,每次一样,不会思考。循环跑的是 Claude,它会看当前情况,选下一步行动,做完,检查结果,然后决定接下来怎么办。继续、重试、回滚、停止。
脚本遇到失败的测试不会自己想办法修。Claude 会。这种能力直到最近才真正变得可靠。
Claude Code 里跑循环的两个命令
大多数人的误区是:在普通聊天里输入"帮我循环做这个"。这不叫循环。
Claude Code 内置了两个专门的命令:
/goal:做到完成为止
你输入 /goal 加上对"完成"的描述。Claude 就开始自主工作,一轮接一轮。每轮结束后,一个更小的模型会悄悄检查:目标达成了吗?没有的话告诉它为什么,继续做。达成立刻停。
这就是真正的循环和"跑一次然后祈祷"的根本区别——每轮之后有独立检查。
适用场景:有明确终点的工作。做到这个条件成立就停。
/goal 写一篇关于[你的主题]的一页简报要求每个论断至少三个来源每个链接必须能打开到支持该论断的真实页面逐个打开链接确认后再算完成替换掉任何死链或不支持论断的来源直到所有来源都通过检查才停止/loop:按节奏重复
适用于"盯某件事"而不是"做完一堆活"的场景。告诉它多久检查一次、做什么,Claude 就按时重跑。
/loop 30m 检查我的线上站点是否恢复,加载首页判断。一旦返回正常页面就通知我,然后停止检查。你的第一个循环,可以直接粘贴
对于复杂任务,给 Claude 一份完整的 charter(任务章程):
class="language-text">你作为循环运行,不是回答单次 prompt。以下是你的章程:GOAL(目标)[用一两句话描述完成状态。具体、可测量。例:"所有 /pages 下的产品页面都更新了新价格,且所有链接可打开。"]WHERE THE WORK IS(活在哪)[告诉 Claude 去哪找活。例:"扫描 /pages 文件夹中使用了旧价格的文件"或"读取 TODO.md,把每个未勾选的项目当作一个任务"]HOW TO WORK(怎么干)- 一次做一件事,彻底做完再做下一件- 匹配现有文件的模式,不要发明新的- 如果某个事项需要你才能决定(花钱、删东西、给人发邮件), 停在这个事项上,加入"需要我"列表,继续下一个HOW TO CHECK YOURSELF(怎么自检)- 每个事项做完之后,证明它确实做完了再标记完成- [选适合的:"跑测试" / "重读文件确认满足目标" / "打开链接确认能加载"]- 检查意味着要证据,不是靠信心- 检查失败就修复再检查。每个事项最多试三次,然后记为阻塞,继续下一个HOW TO REMEMBER(怎么记住进度)- 维护一个 LOOP-STATE.md 文件- 每做完一个事项,写下名称、状态(done/blocked/needs me)、改了什么、下次运行该知道的- 每次运行先读这个文件,绝不重复做已完成的WHEN TO STOP(什么时候停)- 所有事项都完成或被记为阻塞时停止- 或本轮已完成 [N] 个事项时停止- 然后给我一份简短报告:做了什么、什么被阻塞、什么需要我决策开始前先读 LOOP-STATE.md(如果存在),然后去找活。这个状态文件是关键英雄。没有它,每次运行都从零开始。有了它,循环能精确地从中断处继续——即使是在定时调度下。
什么时候不该用循环
Boris 说了三句大实话:
1. 一次性任务不需要循环。 如果只是要一个答案,普通 prompt 更快。循环的搭建成本要在重复或多步骤的工作上才能赚回来。
2. 循环更费 token。 一个带自检和重试的循环,每个事项要跑 Claude 好几次。在 Claude 的套餐下,你会更快地触达用量上限。
3. 模糊的工作不适合循环。"想一个更好的产品策略"不是循环。先把真正的目标搞清楚再说。
本周就可以开始
挑一个你一直在手动做的、包含很多小步骤的任务。粘贴上面的 charter 模板,填好括号里的内容。先跑一次,你盯着每一步看。
当你信任它之后,把它设成定时运行。
第一次你睡醒之后发现工作已经自动完成的那个早上——你就会像 Boris 一样,再也不需要一个一个地敲 prompt 了。
夜雨聆风