详情

首页手游攻略 别再只写 Prompt 了:开始设计 Loop

别再只写 Prompt 了:开始设计 Loop

佚名 2026-07-21 07:37:55

别再只写Prompt了!设计Loop能让AI更自主高效地完成复杂任务,本文为你拆解其核心机制与实战策略。
核心内容:
1. Loop的四大分类维度与适用场景
2. 按轮次触发模式的具体实现与优化技巧
3. 从简单方案开始、按需选用模式的实用建议

最近圈子里很流行讨论"设计 loop"而不是单纯写 prompt 指挥 coding agent。但如果你去 X 上搜一下"loop 到底是什么",会发现说法五花八门。

Claude Code 团队给出的定义是:loop 就是 agent 反复执行一轮工作,直到满足某个终止条件为止

文章按以下几个维度对 loop 进行了分类:

• 触发方式是什么

• 如何终止

• 用到了 Claude Code 的哪个原语(primitive)

• 什么类型的任务最适合用哪种 loop

核心建议是:不是所有任务都需要复杂的 loop,先从最简单的方案开始,按需选用这些模式。

01按轮次触发

触发方式:用户输入一次 prompt

终止条件:Claude 自己判断任务完成,或者需要更多信息

适用场景:比较短、不属于常规流程或排期任务的工作

管理方式:写具体的 prompt,用 skills 改进验证环节,从而减少来回轮次

每次你发一条 prompt,就手动启动了一轮 loop:Claude 收集上下文、执行动作、检查自己的工作(如果需要就重复)、再给出结果。

这个过程就叫做 agentic loop。

举例来说:让 Claude 做一个类似按钮的功能,它会读代码、改代码、跑测试,然后把它"认为"完成的结果交给你,你手动核实、再决定下一步 prompt。

你可以把验证这一步写进 SKILL.md,让 Claude 能更端到端地核查自己的工作,而不需要你介入。

可以在 skill 里包含工具或指令,让 Claude 能自己看、自己交互、自己核实结果。

检查项越量化,Claude 自我验证的能力就越强。

比如在 SKILL.md 里可以这样写(核心思路):

    --- name: verify-frontend-change description: Verify any UI change end-to-end before declaring it done. --- # Verifying frontend changes Never report a UI change as complete based on a successful edit alone. Verify it the way a human reviewer would: 1. Start the dev server and open the edited page in the browser. 2. Interact with the change directly. For a new control (button, input, toggle): click it, confirm the expected state change, and screenshot before/after. 3. Check the browser console: zero new errors or warnings. 4. Use the Chrome Devtools MCP, run a performance trace and audit Core Web Vitals.If any step fails, fix the issue and rerun from step 1 — do not hand back partially verified work.

    02目标导向

    触发方式:一次性手动 prompt

    终止条件:达成目标,或者达到最大轮次上限

    适用场景:有明确、可验证成功标准的任务

    管理方式:设置具体的完成标准和明确的轮次上限,比如"跑到 5 次后停止"

    对更复杂的任务,单轮对话往往不够,需要 Claude 能自己迭代。

    做法是明确定义"什么叫成功",让 Claude 自己反复尝试,直到满足条件,或提前触及轮次上限。

    由你来定义判断标准,Claude 不需要自己判断"是否足够好",也不会提前结束。每一轮它会检查是否达到你定义的条件,没达到就继续,直到满足为止。

    正因如此,可量化的判断标准(比如测试全部通过,或者达到某个分数)效果最好。

    举例:

      /goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.

      03按时间触发

      触发方式:设定的时间间隔

      终止条件:你手动取消,或工作本身完成(比如 PR 合并、队列清空)

      适用场景:周期性工作,或需要对接外部环境/系统的工作

      管理方式:设置合适的时间间隔,或者基于事件触发而不是纯粹按时间

      有些 agentic 工作本质上是周期性的:任务内容不变,但输入每次都在变化。比如每天早上总结 Slack 消息。

      也有些工作依赖外部状态变化,只需要在状态变化时检查一下,比如一个可能会因为 CI 通过而收到新 review 意见的 PR。

      对这类场景,可以用/loop命令,让 Claude 在同一个 prompt 上反复运行:

        /loop 5m check my PR, address review comments, and fix failing CI

        /loop是在你本机运行的,所以关掉终端它就停了。如果想把这个 loop 挪到云端持续运行,可以用/schedule创建一个例行任务。

        04主动型

        触发方式:事件或排期触发,全程无需人工实时介入

        终止条件:每个具体任务在达成目标后自动退出,整个例行程序会一直运行,直到你手动关闭

        适用场景:定义明确、反复出现的一类工作,比如 bug 报告、issue 分诊、依赖升级、迁移工作等

        管理方式:把例行任务路由给更小更快的模型,只在需要判断力的地方用最强模型

        05组合起来

        上面提到的几种 loop 类型,再加上 Claude Code 的其他能力,比如auto mode(自动模式)dynamic workflows(动态工作流,研究预览版),可以组合成能长期运行的复杂 loop。

        比如要处理用户反馈,你可以这样组合:

        1./schedule(研究预览版):定期检查是否有新的反馈

        2./goal:定义"完成"的标准,用 skills 记录如何验证

        3.Dynamic workflows:编排多个 agent 分诊每条反馈、修复问题、审查修复结果

        4.Auto mode:让整个流程自动运行,不需要人工授权确认

        组合起来,一条 prompt 大概是这样:

          /schedule every hour: check the project-feedback channel for bug reports. /goal: don't stop until every report found this run is triaged, actioned, and responded to. When fixing a bug, use a workflow to explore three solutions in parallel worktrees and have a judge adversarially review them.

          06代码质量

          loop 输出质量的好坏,取决于你围绕它搭建的整个系统。

          文章给出了几条建议:

          保持代码库本身干净:Claude 会遵循代码库里已有的模式和约定

          给 Claude 一种验证自己工作的方式:用 skills 把"什么叫好"这件事写清楚

          让文档容易被查阅到:框架和库的文档要保持最新的最佳实践

          用第二个 agent 做代码审查:一个带着"新鲜"上下文、不受主 agent 推理过程影响的 reviewer 更客观。可以用内置的/code-reviewskill,或者 GitHub 上的 Code Review 功能

          当某一次结果没达到标准时,不要只是修补这一次的问题,尽量把它沉淀进系统里,让未来所有迭代都能受益。

          07token 消耗

          loop 应该有清晰的边界,具体建议:

          选对原语和模型:简单任务不需要多个 agent 或复杂 loop,也不需要用最贵的模型

          明确定义成功和终止标准:讲清楚"完成"是什么样子,让 Claude 能尽早收敛(但也别太早)

          大规模跑之前先小范围试点:dynamic workflows 可能一次派生上百个 agent,先在一小部分工作上评估用量

          确定性工作用脚本解决:比如一个填表脚本,比每次都让模型重新推导代码更省钱

          不要跑得比实际需要更频繁:检查间隔应该匹配你关注对象变化的频率

          定期查看用量:/usage命令可以查看近期各 skill、subagent、MCP 的使用和 token 消耗;/goal不带参数可查看当前轮次和 token 用量;/workflows可查看每个 agent 的 token 用量,随时可以终止某个 agent

          08入门总结

          Loop 类型交出去的是什么什么时候用用哪个功能Turn-based按轮次检查这一步你还在探索或做决策自定义验证 skillGoal-based目标导向终止条件你清楚完成是什么样子/goalTime-based按时间触发条件发生在项目排期之外/loop/scheduleProactive主动型整个 prompt反复出现且定义明确以上全部 +dynamic workflows

          ▲ 图:不同 loop 类型的适用场景

          想要开始用 loop,可以先看看你手头已有的工作,找一个你自己是瓶颈的任务,问自己:能不能把验证这一步交出去?目标是不是足够清晰?这个工作是不是可以排期?

          一旦有了想法,先跑起来,观察它在哪里卡住或者过度发挥,然后大胆迭代。

          更多信息可以查看 Claude Code 文档中关于"并行运行 agent"以及 loop、schedule、goal、dynamic workflows 相关的页面。

          原文:https://x.com/ClaudeDevs/article/2074208949205881033

          你现在最想把哪一步交给 loop?

          觉得有用 → 点个❤️在看转给朋友

          登录查看剩余 70% 内容

          相关资讯
          点击查看更多
          游戏推荐
          推荐专题
          热门阅读
          推荐下载