Goal + Loop + Workflows 三大利器

Goal + Loop + Workflows 三大利器 Goal + Loop + Workflows 三大利器 Modified June 14 你不用每轮都催"继续""再改改"。 怎么用： Code block Plain Text Copy /goal test/auth 下所有测试通过且 lint 全绿 Claude 会反复改代码、跑测试，每轮后让评估模型核对"测试全过 + lint 干净"这个条件，达标才停。 什么场景适合它？有明确验收标准的离散任务。 • 把一个模块迁移到新 API，直到所有调用点编译通过、测试全绿 • 照着一份设计文档实现，直到所有验收标准满足 • 把一个超大文件拆成小模块，直到每个都在体积预算内 • 处理一串标记好的 issue，直到队列清空 这些任务的共同点是：终点是客观的，能被机器验证。你能写出一句"满足 X 就算完"，/goal 就能替你盯着这个 X。 三、/LOOP：定时重复，做轮询和值守 /loop 不关心"做没做完"，它只关心"到点了没有"。 它按一个固定的时间间隔，反复运行同一个 prompt 或命令。时间到，就跑一次；你不喊停，它就一直转下去。 Code block Plain Text Copy /loop 5m 检查部署状态，有变化就告诉我 每隔五分钟，Claude 去看一眼部署，有动静就汇报。这是典型的"值守"模式——盯着一个会变的外部状态，等它发生变化。 适合的场景： • 每隔几分钟看一次 CI 跑完没有 • 轮询一个远程任务队列 • 定时扫一遍 PR 列表，有新的就处理 /loop 和 /goal 最容易被搞混，但它俩的停止逻辑正好相反。 /goal 是"达标即停"——目标达成，任务结束。/loop 是"到点就跑"——只要你不手动停，它就永远转下去，因为时间永远在走。一个有终点，一个没终点。 还有个细节：/loop 如果不指定间隔，可以让模型自己决定下次什么时候醒。这适合那种"我也不知道该几分钟看一次"的情况——让 Claude 根据它在等的东西（CI 大概八分钟、远程队列变化更慢）自己挑节奏。 四、/WORKFLOWS：一群 CLAUDE 并行干活的监控面板 前面两个命令，从头到尾都只有一个 Claude 在跑，只是多跑几轮。/workflows 是另一个维度的东西。 它配套的是 Workflow（多智能体编排） ：一段脚本把一个大任务拆开， 同时拉起几个到几十个子智能体并行干活 ——分头审查不同文件、分头迁移不同模块、分头从不同角度调研——然后把结果汇总回来。 /workflows 本身不发起任务，它是你用来 实时观看这群并行智能体进度 的命令。就像一个调度大屏：哪个智能体在跑哪一步、哪个跑完了、整体到哪了，一目了然。 什么时候需要它？ 当一个任务大到单个 Claude 的上下文装不下，或者需要分头覆盖、交叉验证的时候。 • 一次代码评审，拆成多个维度（正确性、安全、性能）并行跑，再把发现汇总 • 几十个文件的批量迁移，一个智能体管一个文件，互不干扰 • 多路并行调研同一个问题，再做对抗式验证、综合成报告 这种"分头干 + 汇总"的结构，是单线程多轮做不到的——你没法让一个 Claude 同时待在三个文件里。 有一点要提醒： 多智能体编排很烧 token。 一次能拉起几十个智能体，消耗是单线程的好几倍，所以它通常需要你显式要求（比如直接说"用 workflow 来做这个"）才会启动，不会自动触发。而 /workflows 只是看进度的窗口，不花钱也不发起任务。 五、到底该选哪个 把决策简化成三句话： Code block Plain Text Copy 有明确"做完"的判据 → /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 的活 Code block Plain Text Copy ❌ 错误 /loop 2m 把测试都修复了 ✅ 正确 /goal 所有测试通过 修测试有明确终点——测试全过就完事了。用 /loop 等于让它每两分钟无脑跑一次， 测试早就过了它还在转 ，因为定时器不认终点。这种活天生属于 /goal。 判断标准：你能说出一句"满足 X 就算完"，就用 /goal，不要用 /loop。 错误二：给 /goal 一个没法验证的条件 Code block Plain Text Copy ❌ 错误 /goal 把代码写得优雅一点 /goal 让这个功能体验更好 ✅ 正确 /goal 这个函数圈复杂度降到 10 以下，且单测覆盖率超过 80% "优雅""更好"这类词，评估模型没法客观判断达没达成——于是 /goal 要么提前停，要么永远不停。 /goal 的条件必须是机器能验证的：测试、编译、数值阈值、文件状态。 主观目标喂给它，等于没给。 错误三：拿 /loop 当后台监工，盲目压缩间隔 Code block Plain Text Copy ❌ 错误 /loop 30s 看看那个要跑十分钟的 CI 好了没 ✅ 正确 /loop 3m 看看 CI 好了没 一个要十分钟的 CI，你每 30 秒查一次——查二十次才等到结果， 前十九次纯属浪费 token，还把缓存反复打掉。 间隔要匹配你在等的东西变化的真实速度，不是越短越"及时"。 错误四：屁大点事就上 Workflow Code block Plain Text Copy ❌ 错误 "用 workflow 帮我改个错别字" ✅ 正确 直接让 Claude 改，一句话的事 多智能体并行的代价是 token 翻好几倍，只有"单个上下文装不下"或"需要分头覆盖、交叉验证"的大活才值得。 改错别字、加个函数、查一个文件这种，拉起一群智能体是杀鸡用牛刀 ，慢、贵，还没好处。 错误五：以为 /workflows 能发起任务 /workflows 只是 看进度的窗口 ，它本身不启动任何东西。想跑并行编排得先发起一个 Workflow（显式要求），/workflows 是用来盯着它跑的。把它当成"启动并行"的开关，会发现什么都没发生。 把这五条反过来，其实就是三个命令的正确用法： 终点明确且可验证 → /goal；盯外部状态变化、间隔匹配真实节奏 → /loop；活大到要分头干 → Workflow，再用 /workflows 看进度。 写在最后 这三个命令背后，其实是同一个趋势：人和 AI 的交互，正在从"一问一答"变成"交代一个目标，然后走开"。 /goal 让你不用盯着每一轮，/loop 让你不用守着时钟，/workflows 让你不用一个文件一个文件地排队。它们省下的，都是你本来要花在"催促"和"调度"上的注意力。 下次再开一个长任务前，先问自己一句：我到底是缺一个终点判断，还是缺一个定时器，还是缺一群帮手？答案，就是该用哪个命令。 你不用每轮都催"继续""再改改"。 怎么用： Claude 会反复改代码、跑测试，每轮后让评估模型核对"测试全过 + lint 干净"这个条件，达标才停。 什么场景适合它？有明确验收标准的离散任务。 • 把一个模块迁移到新 API，直到所有调用点编译通过、测试全绿 • 照着一份设计文档实现，直到所有验收标准满足 • 把一个超大文件拆成小模块，直到每个都在体积预算内 • 处理一串标记好的 issue，直到队列清空 这些任务的共同点是：终点是客观的，能被机器验证。你能写出一句"满足 X 就算完"，/goal 就能替你盯着这个 X。 三、/LOOP：定时重复，做轮询和值守 /loop 不关心"做没做完"，它只关心"到点了没有"。 它按一个固定的时间间隔，反复运行同一个 prompt 或命令。时间到，就跑一次；你不喊停，它就一直转下去。 每隔五分钟，Claude 去看一眼部署，有动静就汇报。这是典型的"值守"模式——盯着一个会变的外部状态，等它发生变化。 适合的场景： • 每隔几分钟看一次 CI 跑完没有 • 轮询一个远程任务队列 • 定时扫一遍 PR 列表，有新的就处理 /loop 和 /goal 最容易被搞混，但它俩的停止逻辑正好相反。 /goal 是"达标即停"——目标达成，任务结束。/loop 是"到点就跑"——只要你不手动停，它就永远转下去，因为时间永远在走。一个有终点，一个没终点。 还有个细节：/loop 如果不指定间隔，可以让模型自己决定下次什么时候醒。这适合那种"我也不知道该几分钟看一次"的情况——让 Claude 根据它在等的东西（CI 大概八分钟、远程队列变化更慢）自己挑节奏。 四、/WORKFLOWS：一群 CLAUDE 并行干活的监控面板 前面两个命令，从头到尾都只有一个 Claude 在跑，只是多跑几轮。/workflows 是另一个维度的东西。 它配套的是 Workflow（多智能体编排） ：一段脚本把一个大任务拆开， 同时拉起几个到几十个子智能体并行干活 ——分头审查不同文件、分头迁移不同模块、分头从不同角度调研——然后把结果汇总回来。 /workflows 本身不发起任务，它是你用来 实时观看这群并行智能体进度 的命令。就像一个调度大屏：哪个智能体在跑哪一步、哪个跑完了、整体到哪了，一目了然。 什么时候需要它？ 当一个任务大到单个 Claude 的上下文装不下，或者需要分头覆盖、交叉验证的时候。 • 一次代码评审，拆成多个维度（正确性、安全、性能）并行跑，再把发现汇总 • 几十个文件的批量迁移，一个智能体管一个文件，互不干扰 • 多路并行调研同一个问题，再做对抗式验证、综合成报告 这种"分头干 + 汇总"的结构，是单线程多轮做不到的——你没法让一个 Claude 同时待在三个文件里。 有一点要提醒： 多智能体编排很烧 token。 一次能拉起几十个智能体，消耗是单线程的好几倍，所以它通常需要你显式要求（比如直接说"用 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 等于让它每两分钟无脑跑一次， 测试早就过了它还在转 ，因为定时器不认终点。这种活天生属于 /goal。 判断标准：你能说出一句"满足 X 就算完"，就用 /goal，不要用 /loop。 错误二：给 /goal 一个没法验证的条件 "优雅""更好"这类词，评估模型没法客观判断达没达成——于是 /goal 要么提前停，要么永远不停。 /goal 的条件必须是机器能验证的：测试、编译、数值阈值、文件状态。 主观目标喂给它，等于没给。 错误三：拿 /loop 当后台监工，盲目压缩间隔 一个要十分钟的 CI，你每 30 秒查一次——查二十次才等到结果， 前十九次纯属浪费 token，还把缓存反复打掉。 间隔要匹配你在等的东西变化的真实速度，不是越短越"及时"。 错误四：屁大点事就上 Workflow 多智能体并行的代价是 token 翻好几倍，只有"单个上下文装不下"或"需要分头覆盖、交叉验证"的大活才值得。 改错别字、加个函数、查一个文件这种，拉起一群智能体是杀鸡用牛刀 ，慢、贵，还没好处。 错误五：以为 /workflows 能发起任务 /workflows 只是 看进度的窗口 ，它本身不启动任何东西。想跑并行编排得先发起一个 Workflow（显式要求），/workflows 是用来盯着它跑的。把它当成"启动并行"的开关，会发现什么都没发生。 把这五条反过来，其实就是三个命令的正确用法： 终点明确且可验证 → /goal；盯外部状态变化、间隔匹配真实节奏 → /loop；活大到要分头干 → Workflow，再用 /workflows 看进度。 写在最后 这三个命令背后，其实是同一个趋势：人和 AI 的交互，正在从"一问一答"变成"交代一个目标，然后走开"。 /goal 让你不用盯着每一轮，/loop 让你不用守着时钟，/workflows 让你不用一个文件一个文件地排队。它们省下的，都是你本来要花在"催促"和"调度"上的注意力。 下次再开一个长任务前，先问自己一句：我到底是缺一个终点判断，还是缺一个定时器，还是缺一群帮手？答案，就是该用哪个命令。 🔗 原文链接： https://x.com/PandaTalk8/status/206... https://x.com/PandaTalk8/status/206... 有什么区别 你让 Claude 跑一个任务，它干完一轮，停下来，等你说下一句。这是大多数人用 Claude Code 的方式——一问一答，像在跟一个反应很快但没什么主见的助理对话。 但有三个命令能改变这种交互：/goal、/loop、/workflows。很多人把它们混为一谈，觉得都是"让 Claude 自己多干会儿"。 这是个误解。它们解决的根本不是同一个问题。 /goal 回答的是" 什么时候算干完 "，/loop 回答的是" 隔多久干一次 "，/workflows 回答的是" 一次铺开多少个 Claude 一起干 "。一个管终点，一个管节奏，一个管规模。搞清楚这三个维度，你才知道手上的活该交给谁。 一、先看一张表 命令 本质 由什么驱动 智能体数量 /goal 自主跑到目标达成为止 条件满足才停 1 个（当前会话，多轮） /loop 按节奏重复同一件事 时间间隔到点就跑 1 个（当前会话，多轮） /workflows 多智能体并行编排的控制台 看一个已启动 Workflow 的实时进度 多个（几个到几十个并行） 命令 命令 本质 本质 由什么驱动 由什么驱动 智能体数量 智能体数量 /goal /goal 自主跑到目标达成为止 自主跑到目标达成为止 条件满足才停 条件满足才停 1 个（当前会话，多轮） 1 个（当前会话，多轮） /loop /loop 按节奏重复同一件事 按节奏重复同一件事 时间间隔到点就跑 时间间隔到点就跑 1 个（当前会话，多轮） 1 个（当前会话，多轮） /workflows /workflows 多智能体并行编排的控制台 多智能体并行编排的控制台 看一个已启动 Workflow 的实时进度 看一个已启动 Workflow 的实时进度 多个（几个到几十个并行） 多个（几个到几十个并行） 命令本质由什么驱动智能体数量/goal 自主跑到目标达成为止 条件满足 才停1 个（当前会话，多轮） /loop 按节奏重复同一件事 时间间隔 到点就跑1 个（当前会话，多轮） /workflows 多智能体并行编排的控制台看一个已启动 Workflow 的 实时进度 多个（几个到几十个并行） 前两个是"纵向"的——同一个 Claude，多跑几轮，区别只在什么时候停。第三个是"横向"的——一次拉起一群 Claude，各干各的，再汇总。 下面一个一个拆。 二、/GOAL：盯着一个终点，自己跑到达成 /goal 的核心是把"完成"这件事从你手里交出去，交给一个可验证的条件。 平常你怎么知道任务做完了？你看一眼输出，觉得差不多了，就停。/goal 把这个判断自动化了：你先用一句话说清楚"什么叫做完"，然后 Claude 一轮接一轮自己干，每轮结束后，一个轻量评估模型去检查——条件满足了吗？满足，自动收手；不满足，接着下一轮。