Claude Code /loop 完整教學：把 Claude 變成定時自動執行 agent 的方法、應用場景與限制

下午三點，你按下 deploy。CI 大概要跑 12 分鐘。你想在這段空檔處理別的事，又怕中間出錯沒人盯。你開了第二個分頁，每兩分鐘切過去刷一次——刷到第七次發現自己什麼都沒做完。

Claude Code 的 /loop 就是針對這種「我想專心做事、但又有件事需要定時看一眼」的情境設計的。簡單講，它是 Claude Code 內建的 session 級排程 skill，讓你給 Claude 一個 prompt 加一個間隔（或讓模型自己決定間隔），它就會在背景定時跑那個 prompt，把結果丟回對話視窗，等於把你的 AI 助理從「對話模式」升級成「會自己做事的排程器」。

這篇文章把 /loop 的三種模式、跟 /schedule 與 cron 的差異、五個實戰場景、以及最容易燒錢的三個坑全部講完。DevOps 2026 趨勢報告 提到一個關鍵數字：高成熟度組織把 deployment 自動化比例壓到 61% 以上的機率比一般組織高 36%——「會把重複事情自動掉」這件事正在拉開團隊跟團隊的差距。/loop 是這條路上最容易、最便宜的起點。

Claude Code /loop 是什麼？三句話講清楚

第一，/loop 是 Claude Code 內建的 skill，不需要安裝、不需要 API key，輸入 /loop 就能用。第二，它的本質是「定時把某個 prompt 丟回 Claude 自己」——也就是讓 Claude 用排程的方式對自己下指令。第三，它是 session-scoped——關掉終端機、退出對話，所有排程都會消失。

這三個性質決定了 /loop 的甜蜜點與盲點。Anthropic 官方文件把它定位成「session 內的短期自動化」，明確區隔於需要持久運行的場景。要真正理解何時用、何時不用，先把這張全景圖記住：

/loop 的價值在於最短間隔可以到 1 分鐘、而且會繼承當前對話的所有 context。這兩件事傳統 cron 做不到——cron 知道時間，但不知道你 30 分鐘前討論到哪、改了哪些檔案、想要看的是哪個指標。/loop 知道。

/loop 的三種模式：固定間隔、自我節奏、自然語言

/loop 接受三種寫法，差異很大，搞錯會浪費 token 也達不到效果。一個個拆開講。

固定間隔模式：寫死頻率

最直接的用法。給一個間隔加一個任務：

/loop 5m 檢查目前部署是否完成，如果失敗告訴我錯誤訊息

# 也可以寫成尾隨子句：
/loop 檢查 PR #142 是否有新 review，每 10 分鐘

單位支援 s（秒）、m（分）、h（時）、d（天）。最短 1 分鐘。MindStudio 的整理提到，固定間隔模式會持續跑直到你手動停止，或滿 7 天自動到期——這個 7 天上限是為了避免你忘記停掉的 loop 偷偷一直跑。

自我節奏模式：讓 Claude 自己決定多久跑一次

這是 /loop 最有意思的功能，也是 cron 永遠做不到的事。不給間隔，只給 prompt，Claude 會自己決定下次什麼時候醒來：

/loop 監看 GitHub Actions 的部署狀態，跑完跟我說

# Claude 會：
# - build 還在跑時，每 60 秒輪詢一次
# - 卡住不動時，拉長到 5 分鐘
# - 任務完成時，直接結束 loop

背後機制是這樣：每跑一次，Claude 根據觀察結果，挑一個 1 分鐘到 1 小時之間的延遲當作下次喚醒時間。MindStudio 的解析給的例子很傳神：build 進行中的時候每 60 秒查一次，沒事發生時拉長到 20–30 分鐘。這節奏邏輯跟人類「重要的事盯緊一點、沒事就少看」一樣，但不會累。

更猛的是Claude 可以自己決定結束 loop。當它判斷任務「可證明已經完成」（例如 build 顯示 success、PR 已 merge），就不會排下一次喚醒，loop 自動終止。這是傳統排程器完全沒有的能力——它們永遠跑下去，要你親自關掉。

自然語言模式：說人話

最寬鬆的寫法：

/loop 提醒我下午 6:30 提交今天的進度
/loop 每天早上 9 點檢查昨晚 cron job 有沒有跑成功

如果你的指令本身不夠明確（例如「每天早上 9 點」但沒講要一次性還是循環），Claude 會反問你「這是一次性提醒，還是每天循環？」Better Stack 的指南特別提到，自然語言模式對「我想要某時某刻發生某事」這種時刻型任務特別好用，不需要學 cron 語法。對非工程背景的使用者門檻特別低。

/loop 跟 /schedule、cron、N8N 到底差在哪？

這是最容易搞混的部分。wmedia 的整理文講得很白：「/loop 是看門犬，/schedule 是雲端管家，cron 是無腦復讀機。」三者都有存在價值，差別在於你需要的「智能程度」與「持久度」。

先看持久度。/loop 跟 session 共存亡，這是它最大的特性也是最大的限制。如果你關掉終端機就消失，那為什麼還要用它？答案是因為短期任務的最快路徑——你不需要為了一個「等 PR 跑完 review」設定什麼雲端 cron job，講一句話就解決。

再看智能程度。cron 跟 N8N 都不知道「狀況」，它們只知道時間到了該跑什麼。/loop 不一樣，它跑的是 AI 對話，所以可以做條件式決策：跑出來的結果不對就再試、發現是依賴問題就先處理依賴、看到完成就自己停。這是傳統排程器補不上的差距。

最後看 Cloud Routines。Anthropic 2026 年 4 月推出 Cloud Routines，把 /loop 的精神搬到雲端——同樣是 AI 排程，但跑在 Anthropic 的伺服器，你的電腦關機也照跑。代價是最短間隔變成 1 小時、每次都是新 session 沒有歷史 context、有每日次數上限（Pro 5 次、Max 15 次、Team 25 次）。

五個真正用得上的 /loop 場景

講太多理論不如直接給能用的東西。以下五個場景，是我們團隊在 Claude Code 內部工作流裡實測過、真的會節省時間的用法。每個都附 prompt 模板。

場景一：等部署完成不切 tab

/loop 每 90 秒 用 gh run list --limit 1 看最新一個 workflow run，
如果結束告訴我成功還是失敗，失敗就把錯誤 log 摘要給我

這比手動切到 GitHub Actions 看快很多。失敗時 Claude 還會幫你看 log 抓重點——傳統 cron 做不到這件事。實測一個 12 分鐘的 CI，原本要切 6 次 tab，現在零次。

場景二：盯著 PR review 不錯過

/loop 檢查 PR #142 是否有新 review 或 comment，有就把內容摘要給我

特別適合 reviewer 比較被動的情況。這個 prompt 我們團隊用過實際省下兩小時等待時間——以前是每隔 30 分鐘自己刷一次，現在能繼續寫程式，有東西自動 ping 過來。

場景三：長任務的自動 progress check

/loop 用 自我節奏 監看 data-migration 腳本（PID 12345）的進度，
讀 /var/log/migration.log 的最後 20 行，跑完跟我說

資料庫遷移、ETL 跑批這種「會跑很久但你想知道有沒有卡住」的任務最合適。自我節奏模式讓 Claude 在「明顯有進度」時拉長間隔、「卡住超過 5 分鐘」時提前喊你。比死板的「每 10 分鐘看一次」聰明得多。

場景四：把 /loop 串其他 skill

/loop 30m /review-pending-prs

這招很多人沒發現：/loop 後面接的不一定是自然語言，也可以是另一個 slash command 或 skill。plainenglish.io 的教學把這個用法稱為「composable automation primitive」——/loop 不只是計時器，是把任何 skill 變成定時 agent 的黏合劑。如果你已經寫了 /review-pending-prs 這個 skill，套上 /loop 就立刻變成 30 分鐘自動 review 一次。

場景五：定時提醒（最便宜的用法）

/loop 提醒我下午 5:50 提交今天的 daily standup

這個用法 token 成本最低，因為每次 loop 觸發只是輸出一句提醒文字，不需要 AI 做複雜判斷。比 macOS 的 Reminders 好用的地方是它能直接跳在你工作的終端機裡——不用切 app、不會錯過。

進階用法：把 /loop 變成 agentic 工作流的核心

如果你只用 /loop 等部署跑完，那就太可惜了。它真正的價值在於把整段工作流自動化——從監看到行動到回報，全部串在一個 prompt 裡。

一個我們在實戰中用過的例子：Continuous Claude（AnandChowdhary 開源專案）把 Claude Code 包成「自動建 PR、等 CI 過、自動 merge」的迴圈。完整流程是：

• Claude 拿到一個任務（例如「修一批 lint warning」）
• 建分支、改檔案、commit、push、開 PR
• 用 /loop 每 2 分鐘檢查 CI 狀態
• CI 過了 → 觸發 merge → 開下一個任務
• CI 失敗 → 讀 error log → 修正後重 push

整個流程不需要人盯。但這也是 /loop 最危險的用法——一個寫壞的自動 merge 迴圈可以在你睡覺時跑出幾十個錯誤 PR。後面會講怎麼避免這種情況。

另一個輕量級的進階用法是把 /loop 跟 hooks 結合。例如設一個 PostToolUse hook 每次 Claude 改檔案就跑 lint，再用 /loop 每 5 分鐘檢查還有沒有未處理的 lint warning。當你看到 /loop 報告「全部清乾淨」就知道可以收工。這套流程的關鍵——把監看跟行動分離——是 agentic 工作流的基本模式。可以參考 別讓 Claude Code 看到你的 .env：四道防線完整守住敏感檔案 學 hooks 怎麼設。

三個會踩到的坑：用之前先看完

用了快半年下來，這三個坑我們踩過、客戶踩過、論壇上每天都有人在踩。先講完才動手。

坑一：runaway loop 偷偷燒 token

Hacker News 上一個被討論很多的案例：有用戶設一個 /loop 每 2 分鐘檢查某個指標，沒寫退出條件，加上 prompt 不夠精準導致 Claude 每次都回幾百個 token 的分析。一個禮拜後發現 API 帳單暴增 4 倍。

解法兩個。第一，給明確的退出條件：「直到看到 success 為止」「最多跑 30 次後停止」「如果連續 5 次結果一樣就停」。第二，prompt 寫得越短越好——告訴 Claude 只要回「成功」或「失敗 + 原因」，不要做多餘分析。每次 loop 多 500 token，跑 100 次就是 5 萬 token 燒掉。

坑二：session 一關全部消失

這個其實是設計，但常被誤解成 bug。/loop 是 session-scoped，意思是你關掉終端機、SSH 斷線、Claude Code 崩潰，所有排程都會在那一刻消失。MindStudio 對比文章特別強調這點：如果你的需求是「電腦關了還要繼續跑」，那 /loop 不是正確工具，要用 Cloud Routines。

實務建議：把 /loop 當成「我接下來這 2 小時內的看門犬」，不要當成「長期排程」。如果你發現自己想用 /loop 跑超過半天的任務，多半是選錯工具了。

坑三：自然語言模式可能誤判時刻 vs 循環

「每天早上 9 點檢查」跟「明天早上 9 點檢查」聽起來像，但意思完全不同。Claude 大多時候會問清楚，但偶爾會猜錯。我們有客戶設了一個「明天早上 9 點寄報表」，結果 Claude 解讀成「每天早上 9 點」——連續寄了一週才被發現。

解法：自然語言模式啟動後，立刻用一個 follow-up 確認——「這是一次性的還是循環的？」如果 Claude 沒主動問，你主動講。寧可多一句話，也不要事後拆 loop 找 bug。

老闆視角：把 /loop 當「24 小時不下班 AI 助理」的真實成本

如果你是技術主管或公司負責人，看到「/loop 可以讓 AI 自動跑事情」第一反應可能是：太好了，等於多了一個免費員工。先別急。三件事必須想清楚。

第一，「免費」是錯覺。每次 loop 觸發都會吃 token，token 就是錢。Anthropic 官方教學提到 Claude Code 的 token 主要花在三件事：初始 context（CLAUDE.md、檔案讀取、bash 輸出）、模型回應、錯誤重試。/loop 每跑一次就重新走一遍這流程。我們內部測過，一個寫得普通的 /loop 跑 50 次大約消耗 25 萬 token——大概等於月費 $20 的 Pro 方案吃掉一兩天的額度。

第二，/loop 不取代責任歸屬。AI 自動處理的事情不代表「沒人負責」——當 /loop 跑出來的決策出問題（例如自動 merge 了一個有 bug 的 PR），責任還是在配置這個 loop 的人身上。Stack Overflow 2025 開發者調查顯示 84% 開發者用 AI 工具但實質生產力提升只有 10-30%，原因之一就是「AI 做的事不是真的不用人看」——你得花時間驗收。

第三，/loop 的最大價值是減少 context-switching cost，不是減少工時。一份 Atlassian 的調查指出，工程師平均每天被打斷 13 次，每次回到原本任務要花 23 分鐘。/loop 把「等部署完成」「等 review」這類強制 context-switch 的場景吸收掉，工程師可以保持心流。這個價值換算成 ROI 通常比節省的時間還大。

如果你是找外包工程師的老闆，想知道對方有沒有真的用 AI 工作流，有個直接問題可以問：「你有沒有用 /loop 或類似工具自動化什麼日常檢查？」答得出具體例子的人，大概率比答不出來的人更熟悉現代 AI 開發。可以參考 恆遠內部 AI 工作流揭密 看一個真實接案團隊的用法，或直接 約一次免費 AI 諮詢 討論你自己的案子。

什麼時候該從 /loop 升級到 Cloud Routines？

這是高階使用者最常問的問題。決策框架其實簡單，三個訊號出現任一個，就該考慮升級。

• 訊號一：你發現自己重複設一樣的 /loop。每天早上開 session 就要打一遍同個 prompt，這個 loop 已經是常駐工作流，該變成 Cloud Routine。
• 訊號二：loop 跑到一半你想關電腦。需要持久執行的任務不該綁在你的本機。
• 訊號三：loop 由外部事件觸發（PR opened、issue closed）。這種事件驅動場景 /loop 完全做不到，Cloud Routines 支援 GitHub events。

反過來，以下情境不要升級：短期 session 內看門（/loop 更輕）、需要當下對話 context（Cloud Routines 每次新 session）、頻率高於每小時（Cloud Routines 最短 1 小時間隔）。

Cloud Routines 不是 /loop 的替代品，是 /loop 的延伸。會用 /loop 的人才能寫好 Cloud Routine——因為兩者的核心都是「給 AI 一個 prompt 讓它定時跑」。把 /loop 練熟，自然知道什麼時候該升級。

延伸閱讀（Claude Code agentic 系列）：

• Claude Code Agent View 完整教學：subagent 視覺化監控介面——/loop 跑多個的時候用這個介面管。
• 別讓 Claude Code 看到你的 .env：四道防線完整守住敏感檔案——/loop 自動跑時更需要的安全防線。
• Claude Code Skill 完整教學：10 個讓工作效率翻倍的自訂指令——寫好的 skill 用 /loop 包起來威力翻倍。
• 用 N8N 自動排程發布 Thread 文章——比較完全不靠 AI 的傳統排程方案。

常見問題

結語：把 AI 從對話夥伴變成排程夥伴

/loop 表面上是「一個排程小功能」，但它代表的趨勢比表面深得多。AI 不再只是你問它答的對話介面，而是會自己醒過來、自己做事、自己決定下一步的執行單元。把它當對話用，你獲得的是一個更聰明的 chatbot；把它當排程用，你獲得的是一個會自己工作的 agent。差異不在工具，在你怎麼想像它。

對個人開發者：從一個 /loop 開始，例如「等部署完成」這種低風險場景。對團隊主管：開始制定 token 預算紀律與 loop 退出條件審查標準。對找外包的老闆：問清楚對方有沒有把 AI 排程化的具體案例，這比學經歷更能反映實戰能力。

如果你看完還是不確定哪種排程方式適合你的情境，跟我們約一次 30 分鐘的免費顧問，把實際需求拿出來討論。我們不會強推任何工具，但會幫你算清楚 ROI 與適合度。也歡迎追蹤恆遠 部落格 持續看新工具與實戰文。