博客日志

Claude Code最近被频繁讨论的一个关键词是 **Loop**。更准确地说，它指的是 Claude Code里的 `/loop` 命令，以及围绕它形成的“循环式 AI工作流”：你不再反复手动提示模型，而是把任务目标、检查频率、验证条件和下一步动作写清楚，让 Claude在同一个会话里周期性回来看、判断、执行和复盘。对开发者来说，这件事的价值不在于“少打一行提示词”，而在于把 PR看护、CI故障排查、部署确认、反馈整理这类重复工作变成可持续运行的自动化流程。

这次讨论来自 Claude Code创建者、Anthropic工程师 Boris Cherny在公开访谈中提到的工作方式。网上传播中有人把它概括成“我不再提示 Claude，我写 Loop”。这句话容易被误读成完全放手给 AI。真正该关注的是：Loop不是魔法，而是把目标、环境、工具权限和验收标准组合成一个可迭代系统。

Loop到底是什么

用人话说，Loop就是“让 Claude过一会儿再回来检查一次，并根据结果继续做事”。

在 Claude Code的语境里，`/loop` 是一个会话内的定时循环命令。你可以给它一个间隔和一段任务说明，例如每5分钟检查部署是否完成；也可以不给固定间隔，让 Claude根据当前情况自己选择下一次检查时间。它适合那些状态会变化、但你不想一直盯着终端的任务。

它和普通定时任务的区别在于，普通 cron多半只是执行一条固定脚本；`/loop` 运行的是一个 Claude Code会话中的提示，它可以读上下文、查看代码、运行命令、理解测试结果，再决定下一步。这也是为什么它会被称为“Loop Engineering”：重点从“写一句好提示”转向“设计一个能自我检查的工作循环”。

Claude Code官方文档对底层模式的解释也很直观：Claude Code通常会在“收集上下文、采取行动、验证结果”之间循环，直到任务完成。`/loop` 则把这个循环放到一个可重复触发的时间表里。

使用前要先确认三件事

第一，确认版本。官方文档显示，定时任务需要 Claude Code v2.1.72或更新版本。可以先在终端运行：

claude --version

第二，明确 `/loop` 是会话级能力。也就是说，它依赖当前 Claude Code会话存在。关闭终端、结束会话或开启新会话，都会影响循环任务继续运行。官方文档也说明，恢复会话时可以恢复尚未过期的任务，但 `/loop` 不是长期无人值守的后台服务。

第三，先准备可验证条件。Loop最怕任务描述太虚，例如“帮我优化项目”或“持续改进代码”。更好的写法是“检查 PR #1234的 CI状态；如果失败，读取失败日志，只修复导致失败的最小变更；修复后运行对应测试；无法判断时给出原因并等待人工确认”。

最基本的写法：固定间隔加任务

最容易上手的方式，是给出时间间隔和任务说明：

/loop 5m check if the deployment finished and tell me what happened

这里的 `5m` 表示每5分钟运行一次。Claude Code支持秒、分钟、小时、天等单位，但由于底层调度以分钟为粒度，秒级间隔会被向上取整到分钟。对于不规则间隔，Claude会转换成合适的 cron表达式，并在会话中说明它选择了什么节奏。

在实际项目里，建议把这类命令写得更具体：

/loop 10m check the GitHub Actions status for the current branch. If CI is red, read the failing job log, identify the smallest likely fix, apply it, run the related test locally, and summarize what changed. Do not push unless I explicitly approved pushing in this session.

这个提示比“修 CI”更可靠，因为它限定了检查对象、失败处理方式、验证步骤和权限边界。Loop的质量往往取决于这些边界是否清楚。

不指定间隔：让 Claude自己决定什么时候回来

另一种写法是不写时间间隔：

/loop check whether CI passed and address any review comments

这时 Claude会根据当前观察结果选择下一次运行时间。比如构建正在进行，它可能短时间后再查；PR一段时间没有新动态，它可能拉长间隔。这个模式更适合状态不稳定、但又不需要精确分钟级控制的工作。

需要注意，动态间隔并不代表无限运行。官方文档对会话级循环设置了到期边界，循环任务最长会在一定时间后自动过期，以避免遗忘的循环持续消耗资源。对生产环境来说，这是合理的保护机制：AI循环越自动化，越需要停止条件。

空 `/loop` 和 loop.md：把默认维护任务写成规则

直接输入：

/loop

在支持的环境中，Claude会使用内置维护提示，大致处理三类事情：继续当前会话中未完成的工作、照看当前分支相关 PR、在没有待办时做有限的清理或简化。这个模式适合你已经在一个任务上下文里工作，希望 Claude在你离开一段时间后继续维护现场。

如果团队有自己的默认规则，可以在项目里创建：

.claude/loop.md

文件内容就是默认循环提示。例如：

Check the release branch PR. If CI is failing, inspect the failing job log and make the smallest safe fix. If reviewers left comments, address them one by one and summarize each change. If everything is green and quiet, reply with a one-line status. Do not delete files, rotate secrets, or push to protected branches without explicit approval.

项目级 `.claude/loop.md` 会优先生效；如果没有项目级文件，也可以使用用户级 `~/.claude/loop.md`。这对团队协作很重要：把“循环怎么跑”写进仓库，比每个人临时输入一长串提示更容易统一质量标准。

常见使用场景：从 PR看护到反馈整理

第一个典型场景是 PR babysitting，也就是看护一个正在等待 CI、Review或合并冲突处理的 PR。Loop可以定时检查状态，发现失败后读取日志、尝试最小修复、运行测试，并把结果留给人审核。这里的关键不是让 AI自动合并，而是让它把“等待—发现问题—初步处理—生成摘要”这段低价值等待时间压缩掉。

第二个场景是部署检查。发布后，Loop可以周期性读取部署状态、日志或 smoke test结果，并在异常时给出诊断。风险较高的生产环境不建议让它直接执行回滚或变更基础设施，除非你的权限、告警、审计和回滚策略已经足够明确。

第三个场景是反馈聚类。Boris在公开分享中提到过用类似方式整理反馈。普通团队可以把这个思路用在 GitHub Issue、Linear、Slack或用户反馈表里：每隔一段时间收集新反馈，按主题归类，标出重复问题和高频痛点，再生成给产品或工程团队看的摘要。这里要特别注意隐私和连接器权限，不要把敏感用户数据交给不必要的任务。

第四个场景是文档漂移检查。比如每周检查最近合并的 PR是否改变了 API行为，找出需要同步更新的 README、SDK文档或部署说明，再开一个草稿 PR。这个场景的成功条件明确，影响范围可控，很适合做成循环任务。

/loop、Routines、Hooks和 Subagents不要混在一起

很多人听到 Boris的工作流后，会把几个概念混在一起。它们有关联，但用途不同。

`/loop` 适合当前会话内的快速轮询。它运行在你的机器和当前 Claude Code会话里，能继承当前上下文，但不适合作为长期云端自动化。

Routines更像云端自动化任务。官方文档显示，Routines可以在 Anthropic管理的云基础设施上运行，可按计划触发，也可通过 API或 GitHub事件触发。它适合电脑关闭后仍要继续运行的任务，但权限和连接器范围要配置得更谨慎。

Hooks是确定性自动化。比如 Claude修改文件后自动运行 formatter，或在需要人工输入时发通知。它解决的是“某个事件发生时必定执行某条规则”，不依赖模型自己想不想做。

Subagents是并行委派。它们适合把大任务拆成多个相对独立的子任务，避免主会话上下文被大量细节污染。Loop可以触发任务，Subagents可以扩大执行能力，Hooks可以加上硬规则，Routines则负责更持久的云端调度。

真正好用的 Loop，需要写清退出条件

Loop工程最容易失败的地方，不是命令不会写，而是没有退出条件。一个坏提示会让 Claude反复检查、反复总结、反复做无效修改。一个好的循环任务至少要包含四类信息。

首先是目标：这次循环到底为了解决什么问题。其次是观察来源：它应该看 CI、日志、PR评论、监控告警，还是某个数据文件。第三是行动边界：能不能改代码，能不能安装依赖，能不能 push，能不能访问外部服务。第四是完成标准：测试全绿、没有新评论、部署完成、异常数低于阈值，还是只生成报告。

可以把模板写成这样：

/loop 15m [观察对象]。如果 [条件 A]，执行 [允许的动作]，然后用 [验证方式] 检查结果。如果 [条件 B]，只汇报，不修改。如果任务完成，说明完成原因并停止继续安排下一轮。禁止 [高风险动作]。

这类提示看起来不花哨，但它更接近工程系统需要的控制面。AI代理越强，越不能只靠一句“你自己看着办”。

安全边界：不要把 Loop当成无人值守工程师

Loop的吸引力在于自动化，但它的风险也来自自动化。尤其在代码、部署、数据库、云资源和密钥相关场景里，循环任务可能把一次判断错误放大成多次错误。

更稳妥的做法是：先在非生产分支试用；默认禁止删除文件、改密钥、改数据库结构、变更云权限；涉及 push、发布、回滚和迁移时保留人工确认；让 Claude每次修改后生成摘要和验证结果；用 Git、checkpoint或手动备份保留回退路径。

对团队来说，还应把 Loop纳入普通工程治理：谁创建了任务，任务能访问哪些仓库和连接器，运行结果写到哪里，失败时谁负责查看。这些问题没有解决前，不建议让它接管关键生产链路。

这对开发者意味着什么

Boris所说的“写 Loop”，本质上反映了 AI编程工具的角色变化：开发者的价值正在从逐行实现，转向目标拆解、验证设计、权限控制和结果审核。Claude Code的 `/loop` 只是这个变化的一个具体入口。

对个人开发者，最实用的起点不是一上来运行几十个代理，而是选择一个低风险、重复性高、成功标准明确的任务，例如检查 CI、跟进 PR评论或整理 Issue。先把一次循环跑稳，再逐步加入 `loop.md`、Hooks、Subagents或 Routines。

对团队，Loop的意义也不该被理解为“让 AI替代流程”。相反，它要求流程更清楚：测试要能自动运行，日志要能被读取，PR规则要明确，权限边界要可审计。只有这些基础设施足够稳定，循环式 AI工作流才会从“酷炫演示”变成真正可复用的工程能力。