/loop/schedule 自動化

Claude Code 把「排程觸發」內建成 slash command——/loop 在本地循環跑(最長 3 天),「/schedule」在中文文章被描述為雲端排程版本但官方來源目前只看到 /loop(待釐清,見 §備註)。

/loop — 本地循環任務

是什麼

把一個 prompt 排成每隔 N 分鐘 / 小時自動重跑的循環,最長 3 天,跑在你的本機上。關掉終端機就停。

啟用方式

> /loop babysit all my PRs. Auto-fix build issues and when comments
  come in, use a worktree agent to fix them
> /loop every morning use the Slack MCP to give me a summary of
  top posts I was tagged in

Boris 的常用 loop

指令用途
/loop 5m /babysit每 5 分鐘自動處理 code review、rebase
/loop 30m /slack-feedback每 30 分鐘把 Slack 上的回饋自動轉成 PR
/loop 1h /pr-pruner每小時清理過時的 PR
/loop 1d morning summary每天早上一次的工作摘要

→ Boris 同時跑 4 個以上的 loop 處理日常雜務。

適合用 loop 的情境

  • PR babysitting(持續 review、fix CI、回 comment)
  • Slack / Asana 摘要(每幾小時 digest 一次)
  • Deploy monitoring(每幾分鐘檢查健康度)
  • Long-running migration 的監督(batch 大規模遷移 的後台)
  • 任何「重複 + 短任務」組合

限制

  • 本機綁定:你關電腦就停
  • 3 天上限:超過要重啟 loop
  • 每次都會吃 token quota:loop 次數要算清楚

/schedule」— 待釐清

中文來源文章描述的「/schedule」:

/schedule 是雲端排程,跑在 Anthropic 的伺服器上,就算你的電腦關機也會繼續跑。支援 cron 表達式排程、GitHub 事件觸發(PR 開啟、合併、release)、還有 API 呼叫觸發。”

howborisusesclaudecode.com(Boris 官方整理頁)2026-03-07 thread 只記錄 /loop沒提 /schedule。可能:

  • (a) /schedule 是文章作者誤把 /loop 的雲端版稱呼包裝成獨立指令
  • (b) Anthropic 在某次更新引入 /schedule 但官方頁尚未補上
  • (c) 是 Scheduled TasksCowork 的功能)跟 /loop 的概念混合

→ ⚠️ 此頁先記下中文來源描述,但實際使用前用 /help 確認 /schedule 是否真的存在於當前 Claude Code 版本。 若不存在,就用 /loop + 雲端 sandbox 模擬。

/loop vs Hooks vs /schedule 對照

機制觸發方式場域持續性
/loop時間間隔本機 Claude session最長 3 天
/schedule(待確認)cron / GitHub event / API雲端永久
HooksClaude lifecycle 事件本機 Claude session與 session 同生命週期
Scheduled Tasks(Cowork)時間 / 事件Cowork appApp 不關就持續

對 PAM 的應用

Use Case 1:每天早上 PR digest

> /loop 1d 把昨天 PAM 系統 GitHub repo 所有 PR 的狀態 digest 給我
  - open 中需要我 review 的(@格甫)
  - waiting on me 超過 24 小時的
  - failing CI
  寫成一段 Slack message 推到 #pam-dev

Use Case 2:等第審核截止前自動提醒

> /loop 6h 檢查所有 status='Pending' deadline 24 小時內的考核單
  ,把 reviewer email 列出

Use Case 3:CI 失敗自動修

> /loop 10m 如果 main branch CI failing:
  1. log
  2. 開新 worktree
  3.
  4. PR
  5. tag

→ 這就是 Boris 的 /loop /babysit 的 PAM 版。

反模式

  • loop 太密集(每分鐘)→ token quota 燒光
  • loop 沒驗證機制 → 連續錯誤被放大;必搭 反饋循環
  • 以為 /loop 跟 cron 一樣可靠 → 本機關機就停,重要任務要 Scheduled Tasks
  • 盲信「/schedule」存在 → 先 /help 確認

相關概念

強連結(原文明確提及)

推斷連結(LLM 認為相關,待確認)

  • Scheduled Tasks ?? — Cowork 的對應機制(可能是「/schedule」的真身)
  • Channels ?? — loop 的結果推播管道
  • Connectors ?? — Slack MCP / GitHub MCP 是 loop 的常見資料源

深入閱讀

← 回到 wiki