Goal + Loop + Workflows 三大利器

🔗 原文链接： https://x.com/PandaTalk8/status/206…

有什么区别

你让 Claude 跑一个任务，它干完一轮，停下来，等你说下一句。这是大多数人用 Claude Code 的方式——一问一答，像在跟一个反应很快但没什么主见的助理对话。

但有三个命令能改变这种交互：/goal、/loop、/workflows。很多人把它们混为一谈，觉得都是”让 Claude 自己多干会儿”。

这是个误解。它们解决的根本不是同一个问题。

/goal 回答的是” 什么时候算干完 ”，/loop 回答的是” 隔多久干一次 ”，/workflows 回答的是” 一次铺开多少个 Claude 一起干 “。一个管终点，一个管节奏，一个管规模。搞清楚这三个维度，你才知道手上的活该交给谁。

一、先看一张表

命令	本质	由什么驱动	智能体数量
/goal	自主跑到目标达成为止	条件满足才停	1 个（当前会话，多轮）
/loop	按节奏重复同一件事	时间间隔到点就跑	1 个（当前会话，多轮）
/workflows	多智能体并行编排的控制台	看一个已启动 Workflow 的实时进度	多个（几个到几十个并行）

命令本质由什么驱动智能体数量 /goal 自主跑到目标达成为止条件满足才停1 个（当前会话，多轮） /loop 按节奏重复同一件事时间间隔到点就跑1 个（当前会话，多轮） /workflows 多智能体并行编排的控制台看一个已启动 Workflow 的实时进度多个（几个到几十个并行）

前两个是”纵向”的——同一个 Claude，多跑几轮，区别只在什么时候停。第三个是”横向”的——一次拉起一群 Claude，各干各的，再汇总。

下面一个一个拆。

二、/GOAL：盯着一个终点，自己跑到达成

/goal 的核心是把”完成”这件事从你手里交出去，交给一个可验证的条件。

平常你怎么知道任务做完了？你看一眼输出，觉得差不多了，就停。/goal 把这个判断自动化了：你先用一句话说清楚”什么叫做完”，然后 Claude 一轮接一轮自己干，每轮结束后，一个轻量评估模型去检查——条件满足了吗？满足，自动收手；不满足，接着下一轮。

你不用每轮都催”继续""再改改”。

怎么用：

/goal test/auth 下所有测试通过且 lint 全绿

Claude 会反复改代码、跑测试，每轮后让评估模型核对”测试全过 + lint 干净”这个条件，达标才停。

什么场景适合它？有明确验收标准的离散任务。

把一个模块迁移到新 API，直到所有调用点编译通过、测试全绿
照着一份设计文档实现，直到所有验收标准满足
把一个超大文件拆成小模块，直到每个都在体积预算内
处理一串标记好的 issue，直到队列清空

这些任务的共同点是：终点是客观的，能被机器验证。你能写出一句”满足 X 就算完”，/goal 就能替你盯着这个 X。

三、/LOOP：定时重复，做轮询和值守

/loop 不关心”做没做完”，它只关心”到点了没有”。

它按一个固定的时间间隔，反复运行同一个 prompt 或命令。时间到，就跑一次；你不喊停，它就一直转下去。

/loop 5m 检查部署状态，有变化就告诉我

每隔五分钟，Claude 去看一眼部署，有动静就汇报。这是典型的”值守”模式——盯着一个会变的外部状态，等它发生变化。

适合的场景：

每隔几分钟看一次 CI 跑完没有
轮询一个远程任务队列
定时扫一遍 PR 列表，有新的就处理

/loop 和 /goal 最容易被搞混，但它俩的停止逻辑正好相反。

/goal 是”达标即停”——目标达成，任务结束。/loop 是”到点就跑”——只要你不手动停，它就永远转下去，因为时间永远在走。一个有终点，一个没终点。

还有个细节：/loop 如果不指定间隔，可以让模型自己决定下次什么时候醒。这适合那种”我也不知道该几分钟看一次”的情况——让 Claude 根据它在等的东西（CI 大概八分钟、远程队列变化更慢）自己挑节奏。

四、/WORKFLOWS：一群 CLAUDE 并行干活的监控面板

前面两个命令，从头到尾都只有一个 Claude 在跑，只是多跑几轮。/workflows 是另一个维度的东西。

它配套的是 Workflow（多智能体编排）：一段脚本把一个大任务拆开，同时拉起几个到几十个子智能体并行干活 ——分头审查不同文件、分头迁移不同模块、分头从不同角度调研——然后把结果汇总回来。

/workflows 本身不发起任务，它是你用来实时观看这群并行智能体进度的命令。就像一个调度大屏：哪个智能体在跑哪一步、哪个跑完了、整体到哪了，一目了然。

什么时候需要它？当一个任务大到单个 Claude 的上下文装不下，或者需要分头覆盖、交叉验证的时候。

一次代码评审，拆成多个维度（正确性、安全、性能）并行跑，再把发现汇总
几十个文件的批量迁移，一个智能体管一个文件，互不干扰
多路并行调研同一个问题，再做对抗式验证、综合成报告

这种”分头干 + 汇总”的结构，是单线程多轮做不到的——你没法让一个 Claude 同时待在三个文件里。

有一点要提醒：多智能体编排很烧 token。一次能拉起几十个智能体，消耗是单线程的好几倍，所以它通常需要你显式要求（比如直接说”用 workflow 来做这个”）才会启动，不会自动触发。而 /workflows 只是看进度的窗口，不花钱也不发起任务。

五、到底该选哪个

把决策简化成三句话：

有明确"做完"的判据    →  /goal       （达标即停）
要按时间反复盯一件事  →  /loop       （定时轮询）
活太大要分头并行干    →  Workflow，用 /workflows 看进度

再说透一层：

/goal 和 /loop 都是单会话、多轮、一个 Claude，区别只在停止条件——一个看目标，一个看时钟。/workflows 管的是另一码事：它不是让一个 Claude 多跑几轮，而是让一群 Claude 横向铺开同时干。

纵向的深度，和横向的规模，是两个正交的维度。想清楚你缺的是哪一个，就不会选错。

六、用 /GOAL 会自动调用 /LOOP 或 /WORKFLOWS 吗？

不会。这是个常见的误会——很多人以为 /goal 是个”总指挥”，底层会去调度另外两个。其实三者机制完全独立。

/goal 的多轮循环，不靠 /loop。它能一轮接一轮跑，靠的是自己内建的机制：每轮干完，评估模型判断条件达没达成，没达成就续一轮。这套循环和 /loop 的定时器是两码事，不共用。

/goal 也不会自动开 Workflow。多智能体编排很烧 token，按设计必须你显式要求才会启动，不会被 /goal 悄悄拉起来。

但有一层区别要分清——“/goal 调用它们”和”/goal 跑的过程中 Claude 自己决定用某个工具”，是两回事。

/goal 只负责一件事：判断”做完了没有”，没做完就让 Claude 再跑一轮。至于每一轮里 Claude 具体怎么干、用哪些工具，是 Claude 自己的决策。所以如果你在一个 /goal 任务里明确说了”可以用 workflow 并行处理”，Claude 某一轮里确实可能去发起一个 Workflow——但这是它在执行层的选择，不是 /goal 这个命令本身的行为。

/goal 是个裁判，只管吹哨判断比赛结不结束，它不规定运动员怎么踢。/loop 的定时器、/workflows 的并行编排，都是另外的机制，/goal 不会自动替你启动。

七、高频错误用法

知道三个命令各管什么还不够，真正容易踩坑的是”选错了那一个”。下面是最常见的几种误用，几乎每个刚上手的人都犯过。

错误一：用 /loop 干 /goal 的活

# ❌ 错误
/loop 2m 把测试都修复了

# ✅ 正确
/goal 所有测试通过

修测试有明确终点——测试全过就完事了。用 /loop 等于让它每两分钟无脑跑一次，测试早就过了它还在转，因为定时器不认终点。这种活天生属于 /goal。

判断标准：你能说出一句”满足 X 就算完”，就用 /goal，不要用 /loop。

错误二：给 /goal 一个没法验证的条件

# ❌ 错误
/goal 把代码写得优雅一点
/goal 让这个功能体验更好

# ✅ 正确
/goal 这个函数圈复杂度降到 10 以下，且单测覆盖率超过 80%

“优雅""更好”这类词，评估模型没法客观判断达没达成——于是 /goal 要么提前停，要么永远不停。 /goal 的条件必须是机器能验证的：测试、编译、数值阈值、文件状态。主观目标喂给它，等于没给。

错误三：拿 /loop 当后台监工，盲目压缩间隔

# ❌ 错误
/loop 30s 看看那个要跑十分钟的 CI 好了没

# ✅ 正确
/loop 3m 看看 CI 好了没

一个要十分钟的 CI，你每 30 秒查一次——查二十次才等到结果，前十九次纯属浪费 token，还把缓存反复打掉。间隔要匹配你在等的东西变化的真实速度，不是越短越”及时”。

错误四：屁大点事就上 Workflow

# ❌ 错误
"用 workflow 帮我改个错别字"

# ✅ 正确
直接让 Claude 改，一句话的事

多智能体并行的代价是 token 翻好几倍，只有”单个上下文装不下”或”需要分头覆盖、交叉验证”的大活才值得。改错别字、加个函数、查一个文件这种，拉起一群智能体是杀鸡用牛刀，慢、贵，还没好处。

错误五：以为 /workflows 能发起任务

/workflows 只是看进度的窗口，它本身不启动任何东西。想跑并行编排得先发起一个 Workflow（显式要求），/workflows 是用来盯着它跑的。把它当成”启动并行”的开关，会发现什么都没发生。

把这五条反过来，其实就是三个命令的正确用法：终点明确且可验证 → /goal；盯外部状态变化、间隔匹配真实节奏 → /loop；活大到要分头干 → Workflow，再用 /workflows 看进度。

写在最后

这三个命令背后，其实是同一个趋势：人和 AI 的交互，正在从”一问一答”变成”交代一个目标，然后走开”。

/goal 让你不用盯着每一轮，/loop 让你不用守着时钟，/workflows 让你不用一个文件一个文件地排队。它们省下的，都是你本来要花在”催促”和”调度”上的注意力。

下次再开一个长任务前，先问自己一句：我到底是缺一个终点判断，还是缺一个定时器，还是缺一群帮手？答案，就是该用哪个命令。

内容效果不满意？点此反馈