10 分鐘。這是 /loop 沒指定間隔時的預設值——每 10 分鐘它會把你交代的任務重跑一次。

聽起來像 cron，但 cron 不會「理解」任務。/loop 在 Claude Code 的 session 裡跑，意思是它每次重跑時都帶著完整的對話脈絡。

打個比方就懂了。傳統的 cron 是個鬧鐘——時間到了它響，響完它不管事；/loop 是個記得你昨天交代什麼、今天問你「上次那件事好了沒」的助理。差別就在這。

這篇講怎麼用 /loop 跟 /schedule 把 AI 變成會自己排程的工程助手——從最簡單的「每 5 分鐘檢查 CI」到「指定時間跑部署」，把實務上會踩的坑一次列清楚。

先搞懂三個東西的差別

/loop、/schedule、Desktop scheduled tasks——這三個東西常常被搞混，先把它們的定位拉開：

/loop 是 session 內的重複觸發。你在當前對話裡叫它每 X 分鐘做一件事，session 還開著它就會跑。關掉 terminal、關電腦、session 結束，它就沒了。

/schedule 是 session 內的一次性定時觸發。在指定時間（例如下午 3 點）跑一個指令，跑完就結束。一樣，session 結束它也沒了。

Desktop scheduled tasks 是 Claude Desktop App 裡的功能，這個會「跨 session 持久化」——你關掉 terminal、關電腦、明天打開，它還會在排定時間執行。

打個比方。/loop 跟 /schedule 像是手機上的鬧鐘 app——你出門前設定，回家前要繼續響的話手機不能關。Desktop scheduled tasks 像是 IFTTT 或 Zapier——你設定完之後手機關著它也照跑。

混用是常態：白天用 /loop 處理 session 內的迴圈任務（盯 CI、跑測試、輪詢狀態），晚上用 Desktop scheduled tasks 設定隔天早上自動跑的東西。

/loop 的最小範例

最簡單的用法：

1
/loop 5m /code-review

意思是「每 5 分鐘執行一次 /code-review 這個 slash command」。間隔的格式是「數字 + 單位」：m 是分鐘、h 是小時、d 是天。

不指定間隔的話：

1
/loop /code-review

預設是 10 分鐘。

/loop 還接受自然語言：

1
/loop every 30 minutes review uncommitted changes

或者：

1
/loop every 2 hours summarize git log

這時候 /loop 會把後面那段話當成「任務描述」，由 Claude 自己決定要做什麼。這就是 cron 完全做不到的事——任務描述本身可以是模糊的，因為 Claude 會去理解。

/loop 的隱藏限制（一定要知道）

這幾條限制官方文件有寫，但很多人沒注意：

任務上限 3 天。 每個 /loop 任務從建立的那一刻起，最多跑 3 天就會自動過期。這是刻意的安全閥——避免你忘了關掉一個任務，結果它在背景一直燒你的 API 額度。三天到了它會自己停。

一個 session 最多 50 個排程任務。 不管是 /loop 還是 /schedule，加起來最多 50 個。要更多就要分到多個 session 跑。

Session 結束就死。 這個前面講過，再講一次因為太多人踩這坑：你把 terminal 關了 /loop 就沒了。要長期排程一定要用 Desktop scheduled tasks。

最大間隔 1 週。 單一 /loop 任務的間隔最多 7 天。超過 7 天的需求，要用 Desktop scheduled tasks 或 GitHub Actions。

重啟筆電會中斷。 即使 session 還在，筆電進入 sleep 狀態 /loop 也會暫停。要「筆電睡了也要跑」的需求，再次：Desktop scheduled tasks。

這幾條限制看起來很煩，但反過來想——它們是設計來阻止「忘記關掉的迴圈任務一直燒錢」。三天的硬上限相當於告訴你：任何超過三天的自動化都應該用更可靠的工具（cron、Desktop scheduled tasks、CI/CD），不是塞在 Claude Code 的 session 裡。

三個實用情境

情境一：盯 CI 跑完

1
/loop 2m check if the GitHub Actions workflow on my current branch has finished, and if so, summarize the results

每 2 分鐘問一次 GitHub Actions，跑完了給你摘要。比你自己每 2 分鐘切到 browser 看快多了。

情境二：等遠端服務上線

1
/loop 1m curl -sf https://staging.example.com/health || echo "still down"

每分鐘 ping 一次 staging 環境，掛掉就回報。部署完等服務暖機的時候特別好用。

情境三：盯 PR review 進度

1
/loop 30m show me any new comments on PR #1234

每半小時看一次 PR 有沒有新留言。比每 5 分鐘自己滑一次 GitHub 健康。

注意這些情境的共同點：都是輪詢外部狀態。/loop 真正強的地方不是「重複做一件事」，是「重複『檢查』一件事，看狀態變了沒」。這跟 cron 的「固定時間做固定動作」是不同思路。

/schedule 的用法

/schedule 在指定時間執行一個指令，只跑一次：

1
/schedule 2026-05-27 15:00 /deploy

下午 3 點跑 /deploy。

或者用自然語言：

1
/schedule in 2 hours /run-tests

兩小時後跑測試。

1
/schedule tomorrow 9am /code-review

明天早上 9 點 review code。

/schedule 跟 /loop 共用「session 內」的限制——你不能關 terminal，不能讓筆電進 sleep。但它比 /loop 少了「重複觸發」這層，所以最常見的搭配是：用 /schedule 做一次性「等一段時間後做某事」，用 /loop 做持續輪詢。

實務上 /schedule 比 /loop 用得少，因為「指定時間做一次」這個需求多半要跨 session 才有意義——而要跨 session 就直接用 Desktop scheduled tasks 比較合理。

什麼時候該用 Desktop scheduled tasks

三個訊號出現任何一個，就該升級到 Desktop scheduled tasks：

  1. 要跨天/跨週：每天早上 9 點跑、每週一晚上 11 點跑——這種規律性需求一定用 Desktop。
  2. 不能斷：例如每日工作摘要、每日部落格自動發布——如果筆電中斷它就死，整個排程就斷了。
  3. 要在你不在電腦前的時候跑：你出差、放假、睡覺，但任務還是要跑——/loop 不行，Desktop 才行。

Claude Code session 裡的 /loop 跟 /schedule 真正的甜蜜點是「這個 session 我會開著，幫我盯點事」。一旦你想關電腦它還要繼續跑，就不該再用它們。

容易踩的坑

坑一：間隔太短

/loop 10s 這種短到 10 秒的間隔，雖然技術上允許，實務上是燒錢機器。每次觸發都會花 token。建議最短不要低於 1 分鐘，預設值 10 分鐘對大部分情境就夠了。

坑二：忘了關

session 還開著、/loop 還在跑、你去吃午飯、回來發現 API 額度被燒了一半——很常見。建議：

  • 短間隔的 /loop（< 5 分鐘）跑完手動 Ctrl+C 停掉
  • 長間隔的 /loop（>= 30 分鐘）依賴 3 天自動過期就好

坑三：任務描述太模糊

1
2
3
4
5
# ❌ 不好
/loop 5m check stuff

# ✅ 較好
/loop 5m run pytest tests/integration/ and report any failures with file:line

/loop 越具體越好。模糊的任務每次跑都可能解釋成不同的動作。

坑四：把該用 cron 的事塞進 /loop

「每天早上 9 點生報表」——這要用 cron 或 Desktop scheduled tasks，不是 /loop。/loop 是給 session 內的、輪詢式的、短期的迴圈用的。長期、跨日的排程請用對的工具。

進階：跟其他 slash commands 組合

/loop 跟 /schedule 的真正威力是組合使用。舉幾個例子：

1
2
3
4
5
6
7
8
# 每 5 分鐘 review 一次最新 commit
/loop 5m /code-review --commits HEAD~1..HEAD

# 每小時跑一次 simplify（被改名前叫 /code-review --fix）
/loop 1h /simplify

# 兩小時後跑完整測試套件
/schedule in 2 hours /run-tests --suite all

組合的設計哲學跟 Unix pipe 一樣：每個指令做一件事，靠組合做更複雜的事。/loop、/schedule 是「時間維度的 pipe」——把任何 slash command 接上時間軸。

為什麼這兩個指令值得學

讀到這裡你可能會想：「不就是個排程嗎？」

仔細想一下兩件事。

第一，/loop 跟傳統 cron 真正的差別不是語法，是「執行的東西可以是模糊的指令」。cron */5 * * * * check_ci.sh 你要先寫好 check_ci.sh；/loop 5m check CI status 不用，Claude 會自己判斷怎麼檢查。這把「寫腳本的成本」從『先想清楚再寫』降到『邊用邊修』。

第二，/loop 的 3 天上限不是限制——是設計。它把你逼到去思考：「這件事真的應該在 session 裡跑嗎？還是該用更可靠的工具？」三天到了它自動關掉，省下的不只是 token，是你晚上不會被沒關掉的迴圈任務的 API bill 嚇醒。

最有用的工具往往不是功能最多的，是邊界畫得最清楚的。/loop 跟 /schedule 故意只做「session 內」的排程，剩下的長期、跨日、不能斷的需求，它直接告訴你「請用 Desktop scheduled tasks」。這種「清楚地知道自己不該做什麼」，比任何 feature list 都值錢。

來源：Slash commands — Claude Code Docs、Recurring Tasks in Claude Code: The /loop Skill and Desktop Scheduler (Better Stack)、Claude Code Cheat Sheet 2026