Lionel · 李豪个人兴趣、文章、摄影、视频和音乐
Article · 文章

解放生产力--Claude Code \loop & \workflow 实战

Lionel
2026/06/22 · 17 min read

Loop 让 AI 按节奏自己一直干，Workflow 让它写脚本调度上百个分身在后台干，把你从守着终端“催它、盯它”里解放出来。配实战例子讲清两者区别、用法和该用哪个。

你让 Claude 改一个 bug。它改完了，停下来，光标闪着，等你说下一句。可部署还在跑、测试还没绿，于是你就守在终端前，每隔几分钟敲一句"好了吗"“继续”“再看看”，像在催一个干一下就要确认一次的实习生。

换个大点的活更尴尬。你想让它把整个项目从一个框架迁到另一个，几百个文件。它做着做着就"忘"了前面：一个对话框装不下那么多东西，越往后它越糊涂。

再换个要紧的活。一处牵一发动全身的改动，你既不放心让它一把写完，又没精力逐行复核。卡住。

这三件事，要你一直催、一个脑子装不下、不敢让它一把过，其实是同一个问题的三个侧面：你在用一个"一问一答"的助手，去干那些"需要自己跑起来"的活，结果时间和注意力全耗在"盯着它"上。

Claude Code 最近补上的两个命令，正好对着这两个缺口，把你从"盯着"里捞出来。一个叫 Loop，让 AI 在时间上自己一直干下去；一个叫 Workflow，让 AI 在规模上自己调度一群分身一起干。这篇就把这俩从头到尾讲透：是什么、怎么用、配上实战例子、什么时候用最划算，以及在真实开发流程里怎么把它们串起来。

上手前提：Loop 需要 Claude Code v2.1.72 以上；Workflow 是今年 5 月 28 日正式发布的，需要 v2.1.154 以上，所有付费档都能用（Pro 档在 /config 里打开"Dynamic workflows"那一行）。claude --version 查一下你的版本。

先分清三个词：subagent、Workflow、Loop

聊具体命令之前，得先拆一个最容易搅在一起的疙瘩。很多人把 subagent、Workflow、Loop 当成一类东西，其实它们根本不在一个层面上。

  • subagent（分身）：Claude 临时派出去干一件活的一个"分身"，是最小的零件。
  • Workflow（工作流）：一段脚本，把一大群 subagent 编排起来按计划干。它管的是规模，也就是空间这条轴。
  • Loop（循环）：一个闹钟，让某件事按时间反复发生。它管的是时间这条轴。

并排放一起，区别就清楚了：

subagent（分身） Workflow（工作流） Loop（循环）
一句话 派出去干活的一个分身 一段脚本，调度一群分身按计划干 一个闹钟，让某事按时间反复发生
它管哪条轴 无，它是基本零件 规模：一次铺开几十上百个分身 时间：让事情重复、持续
"计划"在谁手里 Claude 临场一轮轮指挥 脚本，写进了代码、能复跑 你给的那句 prompt，每轮重来
打个比方 一个临时工 一个工头加一张施工调度表 一个定时器

它们的联系也藏在这张表里：subagent 是 Workflow 的零件，Workflow 本质上就是"批量调度一群 subagent"。而 Loop 跟它俩压根不在一个维度，它只管"时间上重复"，所以你完全可以让一个 Loop 每隔一段时间就去跑一个 Workflow。一个管规模，一个管时间，一个是它们共同的原子。

还有第四种多分身的玩法叫 agent teams，像一个组长带着一队同事各干各的。它和 Workflow 最大的区别是：它没把计划写成脚本，还是组长在临场指挥。这篇不展开，知道有这么个东西、别和 Workflow 搞混就行。

下面就重点上手你能直接驱动的两个：先讲简单的 Loop，再讲压轴的 Workflow。subagent 你平时一般不直接碰它，它是 Workflow 在底下用的零件。

Loop：让 AI 在时间上自己跑起来

Loop 解决的就是开头那个"催"的问题。一句话：给 AI 设一个会自己醒来的闹钟，让一句话按节奏反复执行，你不用守着。

它的命令是 /loop，三种用法，给不给参数决定它怎么跑：

/loop 5m 检查生产部署完成没，完成了把版本号发我

给一个间隔（5m 是 5 分钟，单位有 s/m/h/d），它就按固定节奏重复跑，到点就醒、跑一遍、再睡下。注意它会把间隔转成 cron 表达式，所以像 7m、90m 这种不整的，它会四舍五入到最近的整点并告诉你它选了几分钟。

/loop 看 CI 过了没，有新的 review 评论就处理掉

不给间隔、只给任务，它就自己掂量节奏。

/loop

什么都不给，它跑一个内置的"维护"任务：接着干上文没干完的、照看当前分支的 PR（回 review、修挂掉的 CI、解冲突）、闲下来就顺手做点清扫。它不会自作主张开新坑，像推送、删除这种不可逆的事，只有在接续你上文已经授权过的动作时才会做。

走一遍：让它替你看护一个 PR

光看命令没体感，我们把第二种用法完整跑一遍。

比方说你刚提了个 PR。CI 要跑十几分钟，同事的 review 也会零零散散飘进来。你不想守着，于是敲一句 /loop 看 CI 过了没，有新的 review 评论就处理掉。接下来大概是这样：

  • 第一轮：CI 还在跑，没有新评论。它说一句"CI 进行中，2 分钟后再看"，睡下。
  • 第二轮：CI 挂了，卡在一条 lint 规则。它把失败日志拉出来，改掉，重新推，并告诉你它干了什么。
  • 第三轮：来了两条 review 评论。它逐条改，在线程里回复，标记已解决。
  • 再往后几轮：CI 绿了，也没新评论。它把间隔从 2 分钟悄悄拉长到 15 分钟，没事就别老醒。
  • 最后：全绿、评论清空，它判断"这活干完了"，自己把闹钟撤掉，停下来。

你全程没敲一个字。这就是不给间隔时的"自定步调"：忙就盯紧点（一分钟），闲就拉长（最长到一小时），完事自己收摊。每轮跑完它都会顺手告诉你这次准备等多久、为什么。顺带一提，遇到这种"盯输出"的活，它有时会直接用一个叫 Monitor 的工具，把一个脚本挂在后台、有新输出就推给它，比傻乎乎地反复轮询更省 token、也更灵。

把团队的看护规则写进 loop.md

如果"看护当前分支"这套动作你天天要用，可以把它固化下来。在项目里建一个 .claude/loop.md，把默认 /loop（不带 prompt 那种）要干的事写进去，以后一句 /loop 就跑这套。比如盯一条 release 分支：

检查 release/next 这个 PR。CI 红了就拉失败日志、定位、推一个最小修复。
有新的 review 评论就逐条处理、解决线程。一切又绿又安静，就用一行话告诉我。

这个文件就是普通 Markdown，怎么顺手怎么写。改它会在下一轮生效，所以你可以一边让循环跑着、一边调它的指令。放 ~/.claude/loop.md 则对所有项目生效。

三个边界，和一个邻居

用之前必须知道，省得踩坑：

  • 它是会话级的。这些循环活在当前这个对话里，一开新对话就清空了（用 --resume 续上能恢复没过期的）。
  • 七天自动过期。一个循环最多跑七天就自己结束，防的就是你忘了关、它在那空转。
  • 按 Esc 停。它在等下一轮的间隙，按 Esc 就把待命的闹钟清掉。

什么时候用 Loop 最对：盯一件你顾不过来、又会不定时变化的事，比如部署、CI、长构建、PR 看护、状态轮询。反过来，一次性的活别用循环（直接问就行），间隔也别设太密，每醒一次都在烧 token。

最后分一个常被混的邻居：要是你要的不是"隔一阵看一眼"，而是想让它"一直干到某个能验证的条件成真为止"（比如"测试全绿之前别停"），那是另一个命令 /goal。一句话记：Loop 管"按节奏跑"，goal 管"跑到达标"。

Workflow：让 AI 自己调度一群分身干

Workflow 对付的是另外两个痛点：装不下和不敢一把过。

一句话：你说要干什么，Claude 自己写一张"施工调度表"（其实是一段 JavaScript 脚本），几十上百个分身在后台照表施工，你该干嘛干嘛。你不用懂那段脚本，它自己写、自己跑。

怎么触发它，有三种姿势：

  • 跑内置的 /deep-research，体验成本最低；
  • 在 prompt 里加上关键词 ultracode，让它把这一个任务当工作流来做；
  • 或者干脆用大白话说"用一个 workflow 来做这件事"。

走一遍之一：/deep-research 是什么样子

最快的体验方式是内置那个。你敲：

/deep-research Rust 的异步运行时现在该选 tokio 还是别的，迁移成本如何

你会看到后台分成几个阶段次第亮起来：一拨分身从不同角度去搜（性能、生态活跃度、迁移踩坑、社区口碑），另一拨把搜到的页面抓下来读、互相对账，看 A 博客说的和 B 官方文档对不对得上；然后对每一条结论投票，站不住的（比如一篇三年前的过时说法）直接筛掉。最后落到你对话框里的，是一份带出处链接的报告，而不是一长串它边搜边想的碎碎念。整个过程你的会话是空着的，能继续干别的。/workflows 命令随时能调出那棵进度树，看每个阶段几个分身、烧了多少 token、跑了多久。

它和"我自己多开几个分身"到底差在哪

这是全文最该讲透的一点。你可能会问：我自己开几个 subagent 并行，不也一样？

其实不一样，差别在计划放在哪。普通的多分身，是 Claude 一轮一轮临场指挥，每个分身的结果都塞回它自己的脑子（也就是上下文窗口），分身一多，它先被信息淹了，这正是"装不下"的根源。Workflow 把这套指挥逻辑写成了代码：循环、分叉、谁的结果传给谁，全在脚本里跑，Claude 的脑子最后只接住一个收敛好的答案。官方把这件事概括成一句话：“把计划放进了代码里”。

写成代码之后，还能跑出单纯"多开几个"做不到的套路。这些套路才是 Workflow 真正的价值，挑几个最常用的讲：

  • 分头干再汇总：一批活彼此独立时，拆开并行。比如给 50 个函数补文档，拆成 10 批、10 个分身同时写，十个工人同样时间干十份活。代价是合并和一致性，所以别为并行而并行（后面最佳实践再说）。
  • 流水线：找问题、核验、修复，让每一个发现独立地往下流，不用等其他发现都找完。第一个 bug 在被核验的时候，第二个 bug 可能还在被找，整体快得多。
  • 对抗式核验：一批分身负责找，另一批分身专门负责推翻，投票，过半数推不翻才算数。这是"不敢一把过"的正解，让 AI 自己先互相审一遍。
  • 评审团：一个难拿主意的设计，让几个分身分别从不同立场各出一版（先保最小可用、先扛风险、先顾体验），再打分综合，比一个分身一条道走到黑靠谱。
  • 挖到挖不动为止：事先不知道有多少问题时（比如"找出所有边界 bug"），一直找到连续好几轮都没有新发现才收手，免得漏掉长尾。

走一遍之二：一次接口鉴权审计

把"对抗式核验"那套，配个实际例子。你敲：

ultracode: 审计 src/routes 下每个接口，找出漏掉鉴权检查的

Claude 不会自己一个文件一个文件读过去，而是写一段脚本：先列出所有接口，给每个接口派一个分身去查；任何一个分身报"这里可能漏了鉴权"，脚本不直接信，而是再派几个分身从不同角度专门去推翻它：是不是有上层中间件已经统一管了？是不是测试里其实覆盖了？推不翻，才留下。你打开 /workflows 能看到一棵进度树：Review 阶段十几个分身在扫，Verify 阶段在逐条挑刺。最后给你的，是一份"已确认"的漏洞清单，那些一查就站不住的疑似项，在给你看之前就被筛掉了。

这跟你自己开几个分身去扫的根本区别是：误报在到你手上之前，已经被另一批分身过滤过一轮了。活越要紧，这层自我核验越值钱。

顺便：那张"调度表"长什么样

你可能好奇，Claude 替你写的那段脚本到底是什么样子。把上面这个审计简化一下，它大致长这样。你不用自己写，露出来只是想让你看见"把计划放进代码"是什么意思：

export const meta = {
  name: 'audit-auth',
  description: '审计接口鉴权，核验后只报确认的漏洞',
  phases: [{ title: 'Review' }, { title: 'Verify' }],
}

// 先让一个分身列出所有接口
const routes = await agent('列出 src/routes 下所有接口及其位置', { schema: ROUTES })

// 每个接口走流水线：先查，再把查出的疑点逐个对抗式核验
const checked = await pipeline(
  routes.endpoints,
  ep    => agent(`检查 ${ep.path} 是否漏了鉴权`, { phase: 'Review', schema: FINDINGS }),
  found => parallel(found.suspects.map(s => () =>
    agent(`试着推翻：${s.desc}。拿不准就当它不成立。`, { phase: 'Verify', schema: VERDICT })
      .then(v => ({ ...s, confirmed: !v.refuted })))),
)

// 只留下推翻不掉的
return checked.flat().filter(Boolean).filter(s => s.confirmed)

看不懂每一行也没关系，关键是那个结构：agent(...) 就是派一个分身去干一件事，pipeline 是让每个接口独立走一条流水线，parallel 把"推翻"这步的几个分身同时放出去。找、核验、筛，整套判断逻辑是写死在代码里的，不靠 Claude 临场记着，所以它能稳定复跑，也能在中途停下后接着跑。

几个你会想知道的数和细节

  • 最多 16 个分身同时跑，单次任务最多 1000 个（防脚本失控空转）。
  • 全程在后台，会话不被占；中途停了能断点续跑，已经干完的分身直接返回结果、不白干。
  • 它写的那段脚本会落到 ~/.claude/projects/ 你这个会话的目录下，你能打开读、能 diff、能改了让它重跑。
  • 一个工作流跑顺了，在 /workflows 里按 s 就能存成你自己的 /命令，下次直接调用，比如"每条分支都跑一遍的 review"。

Workflow 的最佳实践

这部分值得单独说清楚，因为 Workflow 的威力和代价都很大。

先小后大。官方把话说得很直白：一个工作流放出去几百个分身，烧的 token 比你在对话里一步步做多得多。所以正确姿势是先拿小切片试水，先跑一个目录而不是整个仓库、先问一个小问题而不是一个大题目。/workflows 里能实时看每个分身的花销，觉得不对随时停，已经干完的不浪费。

跑顺了就存起来复用。上面说的按 s 保存，能存到项目的 .claude/workflows/（团队共享）或你自己的 ~/.claude/workflows/（全局私有）。重复的流程（每次发版前的审查、每条分支的体检）存成命令，以后一句话就跑同一套编排。

给不同阶段配不同模型。一个工作流里机械的阶段（比如格式化、简单分类）没必要用最强的模型。你可以在描述任务时就说"机械的步骤用小一点的模型"，省下不少钱。开跑大任务前也顺手 /model 看一眼当前模型。

长跑前先把权限备齐。工作流里的分身默认能自动改文件，但 shell 命令、网络请求、没在白名单里的 MCP 工具，中途还是可能弹窗问你。一个要跑很久的工作流，最好提前把它要用的命令加进 allowlist，免得跑到一半卡在权限确认上。

并行度要匹配真实的独立性，高风险动作留人工卡点。这是所有自主工作流的通则：别为并行而并行，任务之间其实有依赖、硬拆开只会增加合并的乱子和成本。越是自主、无人盯的流程，越要记住"错误不会在中途被你抓住，只会往后累积"，所以不可逆、影响大的操作（删数据、推生产）该留一个人工确认。

关于 ultracode。如果你把 /effort ultracode 打开，Claude 会对这个会话里每个像样的任务都自动起一个工作流：一个需求可能被它连成好几个，先一个把代码摸清楚，再一个做改动，最后一个验证。它适合"我就要把这件事做到最透、不太在乎成本"的时候。干完回到日常活，记得 /effort high 切回来，不然每个小问题都被它大动干戈。

在真实开发流程里，把它们串起来用

其实这几样不是互相替代的：Loop、Workflow、/goal、/schedule 在真实开发里是组合拳。串一个具体的一天给你看：

早上，你切到正在做的分支，一句 /loop 让它接管 PR 的看护：回评论、修红掉的 CI、解冲突，你去开会。

接了个大需求，要动很多文件的重构。你不在对话里硬刚（装不下），而是分三段用 Workflow：先 ultracode: 摸清 src 下和这块逻辑相关的所有代码、画出依赖（理解阶段），看完它的地图，再起一个工作流做改动，最后起一个工作流跑全量验证。每一段都是独立的工作流，你在中间过目、点头，再放下一段。

改完要把测试推绿，但有些是 flaky 的、得反复试。这时候不用 Loop（它是按时间隔着看），用 /goal 所有测试通过之前别停，盯的是结果，不是钟点。

下班前，有个"每天扫一遍依赖有没有安全更新"的活要无人值守、关了电脑也得跑。这个 Loop 干不了（它是会话级的），交给 /schedule 起一个云端 routine，跑在 Anthropic 的机器上，最短一小时一次。

一个糙但好记的分法：subagent 是单个士兵，Workflow 是把一群士兵编排起来打一仗；Loop 和 /schedule 都是"按时间来"，区别是一个活在会话里、一个跑在云端；/goal 盯的是结果，达标才停。你要做的，是看活儿的形状，派对的那个。

那到底什么时候用哪个

落到你手上，其实就一张表的事：

你要干的活 用什么 为什么
一次性的小问题 直接问 上工具反而是负担
隔一阵看一眼、盯着某件事 /loop 时间轴上的轻量轮询
一直干到"某个条件成真" /goal 盯结果而非钟点
规模大 / 要反复核验 / 一个对话装不下 Workflow 把计划写进代码，分身在后台铺开
要脱离会话、关了电脑也得跑 /schedule 跑在云端，最短一小时一次

Loop 和 Workflow 是同一件事的两个方向：一个让 AI 跑得久，一个让它铺得宽。它们真正帮你省下的，是你守在屏幕前等它、催它、逐行盯它的那些时间。

如果你手边正开着 Claude Code，最低成本的第一步：随手敲一个 /deep-research，去后台看那群分身怎么互相挑刺、怎么把不靠谱的说法筛掉；或者下次等部署时别守着，敲一句 /loop，让它自己醒来告诉你结果。把活交出去一次，你就知道能省下多少。

参考（官方文档与公告）

#文章
留言讨论
Lionel Written by
我叫李豪，来自云南昭通，现居杭州 喜欢摄影、足球 、Vibe Coding 和老婆一起养了两只猫
← 返回文章列表
Scinentistcoldplay