Appearance
Claude Code创始人力荐：/loop一行命令打造24小时专属牛马
这是Claude Code之父认为最强大的两个命令之一，他多次分享推荐。/loop可以帮你定时跑任务，也可以帮你反复试错直到把活干完。大部分人对Claude Code的印象还停留在"一问一答"，但/loop打破了这个模式：它可以自己跑、自己看结果、自己改、再跑一遍，直到任务完成。
/loop解决了什么问题
日常开发里有两类事特别烦人：
第一类：需要反复做的事
- 每隔半小时检查有没有新PR需要处理
- 每天早上跑一遍测试看看有没有挂掉的
- 定时同步项目文档让文档和代码不脱节
这些事不难，但总忘。
第二类：需要反复试错的事
- 修复一个牵扯多个模块的Bug
- 把整个项目从CommonJS迁移到ESM
- 实现一个新功能并确保所有测试通过
特点：一次做不完，中间会出错，出错了要改，改完再验证。
/loop把这两类事都接过去了。
三种调度方案对比
| 维度 | Cloud任务 | Desktop任务 | /loop |
|---|---|---|---|
| 运行位置 | Anthropic云端 | 你的机器 | 你的机器 |
| 需要开机吗 | 不需要 | 需要 | 需要 |
| 需要打开会话吗 | 不需要 | 不需要 | 需要 |
| 重启后还在吗 | 在 | 在 | 不在（会话级别） |
| 能访问本地文件吗 | 不能（重新clone） | 能 | 能 |
| MCP服务器 | 每个任务单独配置 | 配置文件和连接器 | 继承当前会话 |
| 最小间隔 | 1小时 | 1分钟 | 1分钟 |
选型建议：
| 场景 | 选择 |
|---|---|
| 要可靠、不想管机器 | Cloud任务 |
| 要读本地文件 | Desktop任务 |
| 临时轮询、快速用一下 | /loop |
/loop的两种工作模式
模式一：定时调度（Cron模式）
告诉它"干什么"和"隔多久干一次"，到点它自己跑：
bash
# 每30分钟跑一次代码审查
/loop 30m /review
# 每小时检查一次有没有挂掉的测试
/loop 1h "跑一遍单元测试，看看有没有失败的"
# 每5分钟看一眼PR动态
/loop 5m "检查GitHub上开放的PR状态"指定具体时间也行：
bash
# 工作日早上9点自动生成变更摘要
/loop "每个工作日 9:00" "检查昨天的代码变更，生成项目变更摘要"间隔写法：
| 写法 | 示例 | 效果 |
|---|---|---|
| 间隔在前 | /loop 30m 检查构建状态 | 每30分钟 |
| "every"在后 | /loop 检查构建状态 every 2 hours | 每2小时 |
| 不写间隔 | /loop 检查构建状态 | 默认每10分钟 |
时间单位支持s（秒）、m（分）、h（小时）、d（天）。
模式二：自主迭代（Agentic Loop）
这个模式下/loop不再是定时器，而是"自动试错引擎"。你给它一个目标，它自己规划、执行、验证、修正，循环往复直到目标达成。
bash
# 修复认证模块所有失败的测试
/loop "修复auth模块里所有失败的单元测试，直到全部通过"
# 大规模技术栈迁移
/loop "把src/legacy下所有组件迁移到Tailwind CSS，确保页面渲染正常"
# 实现新功能并写好测试
/loop "实现支付宝支付模块，补上单元测试，确保全部通过"普通模式vs /loop模式：
| 模式 | 流程 |
|---|---|
| 普通模式 | 写完代码就交给你了，报错你得自己贴回去 |
| /loop模式 | 自己读报错、自己改、自己重跑测试，全程不用你盯着 |
五个实际场景
1. 自动监控PR状态
每5分钟拉一次开放的PR，检查有没有冲突、能不能安全合并、生成摘要：
bash
/loop 5m "用gh命令检查开放PR的状态，标记有冲突的和可以安全合并的"2. 自动测试看门狗
定时跑测试，发现了失败的测试就尝试修：
bash
/loop 2h "运行测试套件，发现失败的就修复"3. 定时同步项目文档
每2小时让/loop扫一遍代码变更，自动把改动同步到用户文档里：
bash
/loop 2h "检查最近的代码变更，更新对应的公开文档"4. 大规模技术迁移
把整个项目从CommonJS迁到ESM，几十个文件，中间会有报错，/loop能自己处理：
bash
/loop "把项目里所有CommonJS的require/module.exports改成ESM的import/export，确保测试全部通过"5. 批量拉起自动化任务
写一个自定义命令文件，把所有定时任务列在里面，项目启动时一条命令全部拉起来。
运行机制
空闲时才触发
调度器每秒检查一次有没有到期任务，但只在Claude空闲时才触发。如果你正在跟它对话，任务会排队等当前这轮结束再跑。错过的不会补——只触发一次。
时间是本地时区
所有时间都按你本机时区解析。0 9 * * *就是你当地的早上9点，不是UTC。
有抖动机制
防止所有用户任务在同一时刻砸向API：
| 任务类型 | 偏移规则 |
|---|---|
| 循环任务 | 最多延迟周期的10%，上限15分钟 |
| 一次性任务 | 设在整点或半点的，最多提前90秒触发 |
建议：需要精确触发的话，避开:00和:30，写成3 9 * * *比0 9 * * *更准时。
Cron表达式参考
| 表达式 | 含义 |
|---|---|
*/5 * * * * | 每5分钟 |
0 * * * * | 每小时整点 |
7 * * * * | 每小时的第7分钟 |
0 9 * * * | 每天早9点 |
0 9 * * 1-5 | 工作日早9点 |
30 14 15 3 * | 3月15日下午2:30 |
注意事项
| 注意点 | 说明 |
|---|---|
| Token消耗不低 | 特别是自主迭代模式，是比较烧Token的用法。目标要具体，完成标准要明确 |
| 任务有保质期 | 循环任务创建7天后自动过期，会最后执行一次然后自行删除 |
| 只在当前会话有效 | 关掉终端或退出Claude Code，所有任务都没了 |
| 建议加上限 | 目标一直达不到它会一直跑。加一句"最多尝试10次"之类的约束 |
| 可以完全禁用 | 设置环境变量CLAUDE_CODE_DISABLE_CRON=1关掉整个调度器 |
/loop适合什么场景
适合
- 需要反复试错的任务——修复跨模块Bug、大规模重构、迁移
- 需要定时执行的任务——监控PR、跑测试、同步文档
- 完成标准明确的任务——"所有测试通过"、"0个lint错误"
不太适合
- 探索性的任务——比如"帮我调研一下某某框架好不好"，没有明确的完成标准
- 需要人工判断的任务——比如架构选型、需求分析
- 对Token预算敏感的场景——/loop是比较烧Token的用法之一
一句话：如果一件事你手工做也是"跑一下→看报错→改→再跑"这个循环，那它就适合交给/loop。
