Anthropic 在 2026 年 4 月 14 日推出 Claude Code 的新功能 Routines，目前還是 research preview 階段。看到「定時執行任務」這幾個字，第一反應大概是：「ChatGPT、Gemini、Grok 不是早就有了嗎？」確實，這幾家從 2025 年開始陸續推出排程功能，每天早上八點幫忙整理新聞、產出日報這類事情都做得到。不過 Claude Code Routines 跟它們的本質完全不同，這邊先講結論：別人是排程一個 Chat 對話，Claude 排程的是一個雲端 coding agent session。差別不只是「能做的事比較多」，而是整個能力層級不一樣。
本文整理官方 docs 跟實際測試的觀察，從 Routines 是什麼開始，比較跟其他 AI 排程功能、跟傳統 cron / GitHub Actions 的差異，三種觸發方式 Scheduled / API / GitHub 各自怎麼用，最後把計費結構與容易踩的坑寫清楚。
Routines 是什麼
Routines 是一份打包好線上版的 Claude Code 設定，內容包含：一段 prompt、一個或多個 GitHub repository、執行環境（cloud environment）、需要用到的 connectors（例如 Slack、Linear、Google Drive 等 MCP connector），以及一個或多個觸發器。設定存好之後，每當觸發條件成立，Anthropic 就會在自家雲端開一個全新的 Claude Code session，按照存好的設定跑一輪。因為跑在雲端，本機不需要開著，筆電蓋上去也照常執行。
換句話說，Routines 等於是把 Claude Code on web 的一次 session 存成罐頭，可以被觸發器叫起來。底層的 runtime 跟我們平常在瀏覽器上開「Run in cloud」用的是同一套，差別只在於沒有人坐在前面打字。
跟 ChatGPT、Gemini 的排程功能差在哪
OpenAI 在 2025 年 1 月推出 ChatGPT Tasks，Google 在 2025 年 6 月跟進推出 Gemini Scheduled Actions，這兩個功能本質上就是「排程一次對話」：時間到了，平台幫使用者跑一次 prompt，把輸出推播到聊天視窗。能做的事情大致等同於每天定時問一次 ChatGPT，所以海外評論者形容是 “glorified reminder app”，因為它跟系統內建的提醒功能差距並不大。Gemini 更進一步綁定 Google Workspace，但只要工具不在 Google 體系內就接不上。
Claude Code Routines 不是在排程一段對話，而是在排程一個 coding agent。差別整理如下：
| 面向 | ChatGPT Tasks / Gemini Scheduled Actions | Claude Code Routines |
|---|---|---|
| 排程的對象 | 一次 chat 對話 | 一次雲端 Claude Code session |
| 能做的事 | 生成文字、推播訊息 | 讀寫 repo、跑 shell、開 PR、呼叫 connector |
| 產出形式 | 一段話 | 程式碼變更、commit、PR、外部副作用 |
| 適合任務 | 每日新聞摘要、提醒 | 過夜 PR review、自動分流、告警分析 |
| 觸發方式 | 排程 | 排程 + API + GitHub 事件 |
關鍵差異是 chat 跟 agent 的差別。chat 是無狀態的問答，問完就結束；agent 是有目標、會用工具、會改變外部世界的執行體。Routines 真正解鎖的是「過夜工作」這件事——下班前掛上去，早上來收結果，這種事 reminder-style 排程做不到。
不過反過來說，如果只是想每天早上收一份新聞摘要，其實 ChatGPT Tasks 更輕量也更便宜，硬上 Routines 反而是殺雞用牛刀，畢竟跑一次 routine 會占掉一整次每日配額。所以選哪個工具，還是得看任務本身需不需要 agent 等級的能力。
跟傳統 cron、GitHub Actions 差在哪
另一個容易拿來比較的對象是 cron job 跟 GitHub Actions。這兩個都是「事件 / 時間到了就跑一段腳本」的工具，差別是腳本內容固定、行為可預測。Routines 也是事件 / 時間觸發，但跑的內容是「對 LLM 下 prompt 讓它判斷該做什麼」，所以同樣的觸發器、同樣的 prompt，每次跑出來的行為可以不一樣。
| 面向 | cron / GitHub Actions | Claude Code Routines |
|---|---|---|
| 執行內容 | 固定腳本 / workflow | 對 LLM 下 prompt，由 AI 判斷 |
| 對情境的反應 | 寫死的 if/else | 依當下狀態動態決定 |
| 觸發來源 | cron、webhook、事件 | schedule、API、GitHub event |
| 執行環境 | 自建機器 / runner | Anthropic 雲端 |
| 適合任務 | 確定性流程（build、test、deploy） | 需判斷的任務（review、分流、分析） |
因此這兩種工具其實不是互斥而是互補。確定性的 build / test / deploy 流程繼續用 GitHub Actions，但需要看內容判斷的事情（PR review、issue 分流、log 分析）就交給 Routines。實務上甚至可以串起來：Actions 跑 CI，CI fail 時呼叫 routine 的 API endpoint 自動分析 log 並回 PR 留言。
三種觸發方式
一個 routine 可以同時掛上多個觸發器，不必擇一。例如一個 PR review routine 可以「每晚自動跑一次 + deploy 腳本可以呼叫 + 每個新 PR 自動跑」三種觸發共存。下面分別說明三種觸發方式的設定與適用情境。
Schedule trigger（排程）
排程選項有以下幾種：
- Every hour：每小時，可指定第幾分鐘執行
- Daily：每天某個時間，例如上午 9:00 GMT+8
- Weekdays：週一到週五同一時間
- Weekly：每週某天的某個時間
- Custom (Cron expression)：完全自訂
時區處理上，排程時間用本地時區輸入，Anthropic 會自動轉換成內部排程時間，所以不論雲端在哪個區域，routine 都會在指定的 wall-clock time 執行。要注意的是 最小間隔是 1 小時，cron expression 寫得比 1 小時短會被拒。另外實際啟動可能會比預定時間慢幾分鐘，這是 Anthropic 為了分散負載做的 stagger，每個 routine 的 offset 是固定的。
適合的場景就是規律性任務：每日 dependency 健檢、每週掃過 merged PR 找 docs drift、每晚整理 issue queue 並貼 label。
GitHub trigger（事件觸發）
GitHub trigger 會訂閱指定 repo 的事件，每當有符合條件的事件發生，就獨立開一個新 session 處理。要注意的是 GitHub trigger 需要先把 Claude GitHub App 裝到目標 repo，CLI 的 /web-setup 只給 clone 權限，不會自動裝 App，這是設定時很容易卡住的地方。
研究預覽階段目前 只支援兩種事件類別：
| 事件 | 觸發時機 |
|---|---|
| Pull request | PR 被開、關閉、指派、貼 label、同步、合併等 |
| Release | Release 被建立、發佈、編輯、刪除 |
不支援 issue events、push、comment 等其他常見事件，這算是 preview 階段的明顯限制。如果想做「issue 自動分流」這種任務，目前只能改用 schedule trigger 定期掃 issue list 達成。
PR 過濾條件相當豐富，可以按 Author、Title、Body、Base branch、Head branch、Labels、Is draft、Is merged、From fork 篩選，operator 包含 equals、contains、starts with、is one of、regex 等。值得提醒的是 regex 是 整個欄位完整比對，要做子字串比對得自己加 .*xxx.*，否則只會比對等於 xxx 的字串。一般情況下用 contains operator 反而更直觀。
幾個實用的過濾組合：
- 外部 contributor 額外把關：from fork is true，所有 fork PR 都自動跑一次安全與風格 review
- 標籤觸發 backport：labels include
needs-backport，只有貼了標籤才觸發 - 跳過 draft：is draft is false，避免半成品被一直 review
另外要留意，研究預覽期間 GitHub webhook 有 per-routine 與 per-account 的每小時上限，超過會被丟棄不排隊，這個額度的具體數字 Anthropic 沒公布，要在 routine 詳情頁自己看當下狀態。
API trigger（HTTP 觸發）
API trigger 大概是三種觸發中想像空間最大的：每個 routine 可以拿到一個獨立的 HTTP endpoint 和 bearer token，任何能發 HTTP request 的系統都能呼叫它。把 Claude Code 變成一個可被任何系統呼叫的 agent endpoint，這意味著 PagerDuty 告警、Datadog 警報、Sentry 錯誤、CI 部署 hook、內部 ChatOps、Slack slash command、自製 dashboard，全都能一鍵掛上 AI 自動處理能力。
設定方式是進網頁版的 routine edit 頁面，加上 API trigger，按 Generate token 拿到一次性顯示的 token（之後只能 regenerate 或 revoke，原 token 不會再出現），然後就可以用 curl 觸發：
# 觸發指定 routine，body 的 text 欄位會作為當次補充 context
curl -X POST https://api.anthropic.com/v1/claude_code/routines/trig_01ABCDEFGHJKLMNOPQRSTUVW/fire \
-H "Authorization: Bearer sk-ant-oat01-xxxxx" \
-H "anthropic-beta: experimental-cc-routine-2026-04-01" \
-H "anthropic-version: 2023-06-01" \
-H "Content-Type: application/json" \
-d '{"text": "Sentry alert SEN-4521 fired in prod. Stack trace attached."}'呼叫成功會回傳 session URL，可以直接打開瀏覽器即時觀看 routine 跑的狀況、review 變更，甚至接手繼續對話。Body 的 text 欄位是純字串、不解析 JSON，就算傳結構化資料進去，routine 也只會把它當成一段文字 prompt 讀。
因為現在還是研究預覽，endpoint 用了 experimental-cc-routine-2026-04-01 這個 beta header，未來可能會改版，不過 Anthropic 承諾會保留前兩版舊 header 一段時間給開發者遷移。另外 CLI 不支援建立 / 撤銷 API token，這部分只能在網頁版做。
在哪裡建立 Routines
官方支援三個建立 / 管理入口，三個入口寫到同一個雲端帳號，CLI 建立的 routine 會立刻出現在網頁版列表：
- 網頁版 claude.ai/code/routines ：功能最完整，三種 trigger 都能設
- 桌面 App（這次同步改版後新增）：Schedule 頁按 New task，會問選哪一種：
New remote task 就是雲端 routine（也就是本文討論的對象）；
New local task 則是 Desktop scheduled task，跑在本機、要 App 開著，是另一回事 - CLI：在任何 session 內輸入
/schedule建立 scheduled trigger，也支援/schedule list、/schedule update、/schedule run管理。要加 API 或 GitHub trigger 得回網頁版 edit
至於行動端，目前 iOS / Android 版 Claude App 還沒整合 Routines 介面。實測下來不只不能建立、不能編輯，連 routine 的執行結果都看不到，這部分的踩雷紀錄後面 QA 會再講細節。
Routine 跟 Desktop scheduled task、/loop 的差別
Claude 的「排程任務」其實有三條獨立的線，名稱很容易搞混，這邊一起釐清：
| 名稱 | 跑在哪 | 需要什麼開著 | 觸發方式 |
|---|---|---|---|
| Routine | Anthropic 雲端 | 什麼都不用 | Schedule / API / GitHub |
| Desktop scheduled task | 本機 | 桌面 App | Schedule |
/loop | 本機 CLI session | CLI session 活著 | Session 內排程 |
桌面 App 的 New task 介面會把 local task 跟 remote routine 混在同一個列表，建立時要看清楚選的是哪一種，不然會以為自己掛了一個雲端 routine，結果筆電一蓋什麼都沒跑。
配額與計費（重點）
Routines 的計費是這篇最該講清楚的部分，因為它有 兩層獨立的限制，兩個都要過關才能執行：
第一層：每日執行次數
| 方案 | 每日 routine 次數 |
|---|---|
| Pro | 5 |
| Max（5x 與 20x 相同） | 15 |
| Team / Enterprise | 25 |
這邊要特別點出來：Max 5x 跟 Max 20x 的 routine 次數一樣是 15。付兩倍錢買 Max 20x，多買到的是 token 池子（5 小時 session 與 weekly limit 都更大），但 routine 啟動次數不會跟著翻倍。對重度使用者來說有點反直覺，畢竟期待付 200 美元的方案能解鎖更高的自動化頻率。Anthropic 應該是把 routine 視為平台層級的服務啟動成本（schedule infra、event dispatch），這跟 token 用量的計費邏輯本來就不同，所以額度沒有跟著放大。先記住這個設計，免得規劃自動化時期待錯了。
第二層：token 消耗
官方原文寫得很清楚：「Routines draw down subscription usage the same way interactive sessions do.」意思是 routine 跑起來會吃掉跟一般互動式 session 同樣的額度——5 小時 session 額度跟 weekly token 額度，全部跟我們平常坐在 Claude.ai、Claude Code 前面打字共用同一個池子。Pro 一個 5 小時 session 大概 44k tokens、Max 5x 約 88k、Max 20x 約 220k。
因此就算今天還剩 4 次 routine 額度，但 weekly token 已經用完，routine 一樣跑不動。這也是為什麼 routine 不能當成「免費背景任務」來掛——它是真的會消耗額度的。建立任務的時候可以挑選要用什麼模型執行，跟平常一樣可以依照任務複雜度挑選不同模型。
在哪查剩餘額度
有兩個網頁可以查目前剩餘的 routine 次數與 token 用量：
- claude.ai/code/routines ：routine 列表頁，能直接看今日剩幾次
- claude.ai/settings/usage ：完整的 usage 頁面
實測手機瀏覽器開這兩頁也能看到剩餘次數，所以雖然手機 App 沒整合 Routines，至少剩餘額度的監控是不缺的。但執行細節跟 session 內容在手機端看仍然吃力，不建議當主要管理介面。
超過次數之後
官方原文：「organizations with extra usage enabled can keep running routines on metered overage.」要先在 Settings > Billing 主動開啟 extra usage，超額才會以計量方式繼續跑；沒開的話超過直接被拒，不會被偷偷扣款。Anthropic 目前沒公布 per-run 單價，這部分要等正式版文件補齊。
容易踩的坑
- Routine 不是免費背景任務，每次都吃 token 池
- Max 20x 不會給更多 routine 啟動次數，自動化頻率受限於每日 15 次
- 過夜跑大型 routine（例如全 repo review）可能燒光隔天的 session quota
- Weekly limit 是硬上限，routine 排程跑不完也救不回來
- Prompt 寫精準、排程錯開主要工作時間、給的 repo 範圍縮到最小，這三點都能省 token
適合做成 Routine 的任務
官方文件給了幾個範例，這邊整理成「觸發類型 + 任務」的對應，幫助評估自己手上的事情適不適合做成 routine：
- Backlog 維護（Schedule）：每晚跑一次，掃過 issue tracker，按程式碼區域指派 owner、貼 label、把整理好的隊列推到 Slack，早上一上班就有 groomed queue
- 過夜 PR review（GitHub）：訂閱
pull_request.opened，依團隊自訂的 review checklist 留 inline 留言，人類 reviewer 隔天只要看設計層面的問題 - 告警分流（API）：監控工具偵測到錯誤門檻時呼叫 routine endpoint，把 stack trace 跟最近的 commit 對照，自動開一個含修補建議的 draft PR，on-call 接手時就不用從零開始
- 部署驗證（API）：CD pipeline 部署完呼叫 routine，跑 smoke test、掃 error log、回報 go / no-go 到 release channel
- Docs drift（Schedule）：每週掃過已 merge 的 PR，找出引用已變更 API 的舊文件，自動開更新 PR 給編輯 review
- SDK 同步（GitHub）：訂閱某個語言版本 SDK 的
pull_request.closed（filter 為 merged），把同一個變更 port 到另一個語言版本的 SDK，開 matching PR
共同特徵是：可重複、需要根據內容做點判斷、結果看得出來。如果任務本身只是「跑一段固定指令」，繼續用 cron 跟 GitHub Actions 比較划算；如果任務需要 LLM 在現場動腦判斷，再考慮 routine。
常見 QA
Q1：手機可以用嗎？
iOS / Android 版的 Claude App 完全沒整合 Routines 介面，無法建立、無法編輯，實測連執行結果都看不到，連個 banner 提示都沒有。不過手機瀏覽器開 claude.ai/code/routines 或 claude.ai/settings/usage 還是可以查剩餘次數與部分管理功能，只是整體體驗很差。想在手機掌握 routine 執行狀況，比較實際的做法是設下游通知：讓 routine 自動開 GitHub PR（用 GitHub App 推播）、寫進 Slack、或寄 email。
但是 Anthropic 開發速度很快，想必再一小段時間後就可以用了。
Q2：Max 5x 跟 Max 20x 的 routines 額度一樣嗎？
一樣，都是每天 15 次。Max 20x 多買到的是 token 池子（5 小時 session 與 weekly limit 都更大），routine 啟動次數沒有跟著翻倍。
Q3：跟 GitHub Actions 該怎麼選？
確定性流程（build、test、deploy）繼續用 Actions，需要看內容判斷的（PR review、issue 分流、log 分析）用 Routines。兩者也可以串起來：Actions 跑 CI、CI fail 時呼叫 routine 的 API endpoint 自動分析 log 並回 PR 留言。
Q4：Routines 會吃我平常的 Claude Code 額度嗎？
會。次數限制與 token 消耗是兩層獨立的限制，兩個都要過關才能執行。
Q5：超過每日次數會發生什麼？
要在 Settings > Billing 預先開啟 extra usage 才能繼續跑（metered overage），沒開的話直接被拒，不會自動扣款。官方目前未公布 per-run 單價。
Q6：Routine 跑起來會用誰的身分？
用建立 routine 的人的身分。Commit、PR 掛建立者的 GitHub 帳號；Slack、Linear 等 connector 的動作也用建立者連結的帳號。Routines 不是團隊共享，每個人都是獨立帳號各自管理。
Q7：可以中途介入正在跑的 routine 嗎？
每次執行會建立一個 session，從 routine 詳情頁進去（或 API trigger 回傳的 session URL）就能即時觀看、review 變更、甚至繼續對話，跟一般 Claude Code session 完全一樣。
Q8：Routine 會不會把我的 main branch 改壞？
預設 只能 push 到 claude/ 前綴的 branch，自動保護 main 與其他長期分支。要解除可在該 repo 開啟 Allow unrestricted branch pushes，但要自己評估風險，畢竟 routine 是無人值守的。
Q9：Routine 沒有 permission mode 嗎？
對。Routine 全自動執行，沒有 approval prompt、不會跳出來問 Y/N。所以連的 connector、給的環境變數、開的網路範圍都要事先 scope 好，只給它需要的權限，不要圖方便把所有 connector 都打勾。
Q10：之前桌面 App 的 Cowork scheduled task、CLI 的 /loop 跟 Routines 是同一回事嗎？
不是，是三條獨立的線，前面表格已經整理過：Routines 跑在雲端、Desktop scheduled task 跑在本機需要桌面 App 開著、/loop 跑在 CLI session 內 session 關掉就沒了。三者的差別是「跑在哪、需要什麼開著」，要選哪一種看任務的情境。
小結
把這篇的重點濃縮成三句：
- 從「排程 chatbot」進化到「排程 coding agent」是質變不是量變，這也是 Claude Code Routines 跟 ChatGPT Tasks、Gemini Scheduled Actions 的根本差異
- 三種觸發方式中，Schedule 補的是 cron 缺的判斷力，GitHub trigger 補的是 PR 流程的自動 review，API trigger 想像空間最大，能讓任何外部系統呼叫 Claude Code agent
- 計費要算清楚：每日次數加 token 消耗的雙層限制，Max 20x 在 routine 次數上不會比 Max 5x 多任何優勢，別把 routine 當免費勞工掛上去
研究預覽階段的功能還會繼續變動，特別是 GitHub event 種類、API 規格、超額計費單價這些細節，建議等正式版前先用實際任務跑幾次，把感覺建立起來。等到 Routines 走出 preview，搭配 Claude Code on web 改版後的 multi-session 體驗，整個 Claude Code 大概會變成第一個真正能「自動化整個開發者工作流」的 agent 平台。
參考資料：