Claude Code Routines：Anthropic 的 24 小時助手上線
昨天（4/14）在 Claude 官方 Threads 帳號看到這則：
Now in research preview: routines in Claude Code. Configure a routine once (a prompt, a repo, and your connectors) and it can run on a schedule, from an API call, or in response to an event. Routines run on our web infrastructure, so you don’t have to keep your laptop open.
看完的第一個反應是：這不就是幫你在雲端養了一個定期跑的 Claude Code session 嗎？
不需要自己開著電腦，不需要串 GitHub Actions，直接在 Anthropic 的基礎設施上排程或事件驅動地跑 Claude——這個方向很清楚。
Routine 是什麼
官方定義很直白：
A routine is a saved Claude Code configuration: a prompt, one or more repositories, and a set of connectors, packaged once and run automatically.
三個元件：
- Prompt：告訴 Claude 每次要做什麼（這是最重要的，因為 routine 完全自主執行，沒有中間的確認提示）
- Repositories：指定要 clone 哪幾個 repo
- Connectors：你設定好的 MCP connectors（Slack、Linear、Google Drive 之類的）
打包好之後，丟給三種觸發器之一去引爆。
執行時是完整的 Claude Code cloud session：可以跑 shell 指令、使用 repo 裡 commit 進去的 Skills、呼叫 MCP connectors。不像某些 CI 環境只能執行有限操作。
WARNING — Routines 以你的身份執行
Routines 屬於你個人的 claude.ai 帳號，不共享給隊友。每次 routine 透過你的 GitHub 身份操作——開的 PR、推的 commit 都掛你的名字，透過 Slack connector 傳的訊息也是你的帳號。設定時要想清楚 scope。
三種觸發方式
1. Schedule：定時排程
最直覺的觸發方式。預設有四個頻率可以選：
| 選項 | 說明 |
|---|---|
| Hourly | 每小時執行一次 |
| Daily | 每天固定時間 |
| Weekdays | 週一到週五 |
| Weekly | 每週一次 |
時區會自動換算，以你設定時的本地時間為準。
如果需要「每兩小時」或「每月一號」這種 preset 沒有的間隔，先選最近的預設值建立 routine，然後在 CLI 下 /schedule update 修改成 cron expression。最小間隔是一小時，比這更頻繁的 expression 會被拒絕——這個場景繼續用 /loop。
執行時間可能比設定的晚幾分鐘（stagger 機制），但每個 routine 的偏移量固定，所以是可預期的。
2. API：程式呼叫觸發
每個 routine 都可以綁定一個專屬的 HTTP endpoint，POST 進去 routine 就會立刻執行。適合接進 alerting 系統、CD pipeline 或任何可以發 HTTP request 的地方。呼叫時可以帶一個 text 欄位，內容會附加到 routine prompt 末尾，用來傳入當次的上下文（例如 alert 內容或錯誤 log）。
因為我是使用訂閱制的 Max 方案，並沒有實際用到 API 觸發這塊，細節包含 endpoint 格式、bearer token 管理、response 結構和 beta header 注意事項，請直接參考官方文件：Automate work with routines — Claude Code Docs。
3. GitHub 事件觸發
最靈活的觸發方式，支援的事件類型：
| 事件類別 | 觸發時機 |
|---|---|
| Pull request | 開啟、關閉、assign、標籤、sync 等 |
| Pull request review | review 提交、編輯、dismiss |
| Pull request review comment | diff 上的留言 CUD |
| Push | commit 推送到分支 |
| Issues | 開啟、編輯、關閉、標籤等 |
| Issue comment | issue 或 PR 的留言 CUD |
| Check run / Check suite | CI 檢查的各種狀態 |
| Workflow run / Workflow job | GitHub Actions 執行狀態 |
| Discussion / Discussion comment | |
| Release | 建立、發布、編輯、刪除 |
| Merge queue entry | PR 進出 merge queue |
| Repository dispatch | 自訂事件 |
Pull request 觸發還有細粒度的 filter，可以組合條件縮小觸發範圍：
| Filter | 用途 |
|---|---|
| Author | 限定特定 PR 作者 |
| Title / Body | 標題或描述的關鍵字匹配 |
| Base / Head branch | 分支名稱條件 |
| Labels | 標籤篩選 |
| Is draft / Is merged / From fork | 狀態條件 |
詳細的設定步驟（包含安裝 Claude GitHub App 和 webhook 設定）請參考官方文件：GitHub trigger 設定 — Claude Code Docs。
如何建立 Routine
三個入口都可以：
Web UI：到 claude.ai/code/routines → New routine，設定 prompt、repo、environment、connectors、triggers。
CLI：在任何 session 裡執行 /schedule，Claude 會互動式地收集需要的資訊然後存到帳號。也可以直接帶描述：/schedule daily PR review at 9am。
Desktop App：Schedule 頁面 → New task → New remote task（選 local task 則是舊的本機排程，不是 routine）。
這裡有個很實用的細節：Desktop App 的 Schedule 頁面是本機排程和線上 routines 的統一儀表板。你在 Web 上建立的雲端 routines 和在 Desktop 上建立的本機排程，會一起出現在同一個清單裡。不用切換到瀏覽器也能看到線上 routine 的狀態、上次執行時間、執行結果，直接從 Desktop 點進去查看 session log 或手動觸發 Run now。
NOTE — CLI 目前只能建立 Schedule 觸發
/schedule 只能設定排程觸發。API 觸發和 GitHub 事件觸發只能在 Web UI 設定。
分支保護機制
這個細節值得特別提：Routine 預設只能 push 到 claude/ 開頭的分支。這防止 routine 意外修改 main 或其他長期存在的分支。
如果你的 routine 需要推送到任意分支（例如自動 backport 到 release branch），要在 repo 設定裡手動開啟 Allow unrestricted branch pushes。
使用限制
Routine 的使用量計入你的訂閱額度，另外還有每日 run 次數上限：
| 方案 | 每日 routine runs |
|---|---|
| Pro | 5 |
| Max | 15 |
| Team / Enterprise | 25 |
超過上限後，如果帳號有開 extra usage，會繼續跑（計費）；沒有的話，新的 run 會被拒絕直到隔天重置。
GitHub 事件觸發另外有每 routine 和每帳號的每小時上限，超過的事件會被丟棄，不會排隊等待。
幾個實際想到的應用場景
Nightly backlog 整理：每天清晨自動掃 Linear/GitHub Issues，補上標籤、指派負責人、把描述不清楚的 issue 加上追問留言。起床就有整理好的 queue。
定時爬蟲：這個是想到之後覺得很有趣的用法。Routine 跑的是完整的 Claude Code session，有 shell 存取權，可以用 curl、Python requests、甚至 Playwright 抓網頁。搭配 Schedule 觸發，就是一個托管在 Anthropic 雲端、不需要你自己管伺服器的定時爬蟲。
舉一個具體例子，假設我想追蹤幾個 AI 工具的更新頁面，每天早上彙整一份摘要推到 Slack：
每天早上 8:00 執行：
1. 用 curl 抓取以下頁面的內容：
- https://code.claude.com/docs/en/changelog
- https://geminicli.com/docs/changelogs/latest/
- https://github.com/openai/codex/releases
2. 比對昨天存在 repo data/last-seen.json 裡的版本記錄，找出新增的條目
3. 如果有更新，整理成繁體中文摘要，透過 Slack connector 發到 #ai-tools-updates 頻道
4. 把本次抓到的版本號寫回 data/last-seen.json，commit 到 claude/daily-update 分支這個 prompt 自給自足：說明了要抓什麼、怎麼判斷「新的」、輸出去哪裡、狀態怎麼持久化。Routine 每次執行都是全新的 session，靠 repo 裡的檔案當作跨次執行的記憶。
TIP — 用 repo 檔案當「記憶」
Routine 的每次執行是獨立 session，session 間不共享狀態。讓 Claude 把上次的結果寫回 repo（commit 進去），下次執行再讀出來比對，是最直接的跨次執行狀態管理方式。
需要注意的是 Environment 的網路存取設定——預設環境有一定的網路存取，但如果要抓特定外部網站，要確認環境設定允許對外連線。Playwright 這類工具則可能需要在 Environment 的 setup script 裡先安裝。
技術債追蹤與優先等級自動更新：在想各種應用場景時，突然想到一個在維護大型專案時特別實用的用法——定期掃描技術債、自動評估優先等級，而且每次跑都會重新排序，不是靜態的清單。
大型專案的技術債通常不是一次性問題。每個 sprint 都會留下幾個 TODO、一些過度設計的地方、幾個因為趕工而妥協的實作。這些東西累積起來，沒有人專門維護就只會越堆越多。而且最麻煩的是哪些是現在最值得修的，這個判斷需要對整個 codebase 有全局視野，偏偏每個人都只專注在自己負責的模組。
Routines 的排程觸發剛好可以解這個問題。設定一個每週執行的 routine，讓 Claude 每次都從整個 codebase 的角度重新評估技術債的優先等級：
每週一早上 9:00 執行：
1. 掃描整個 codebase，找出以下類型的技術債：
- TODO / FIXME / HACK / DEPRECATED 標記
- 複雜度過高的函式（超過 50 行且 cyclomatic complexity > 10）
- 重複率高的程式碼區塊（超過 30 行的相似片段出現兩次以上）
- 無測試覆蓋的核心路徑（比對 src/ 和 tests/）
- 使用了 package.json 中已標記為 deprecated 的 API
2. 讀取 docs/tech-debt.md（上週的報告）
3. 對每個技術債項目，根據以下條件重新評估優先等級：
- CRITICAL：影響正確性或安全性，或被最近 3 個 sprint 的 PR 頻繁觸碰的熱點
- HIGH：效能瓶頸或會阻礙後續功能開發的設計問題
- MEDIUM：明確的 code smell，但不影響當前功能
- LOW：風格問題或可選的改善
4. 比對上週的優先等級，標記哪些項目升等（↑）、降等（↓）或新增（NEW）
5. 將新的優先等級清單寫回 docs/tech-debt.md，commit 到 claude/tech-debt-YYYYMMDD 分支，並開一個標題為「技術債週報 YYYY/MM/DD」的 draft PR這個設計的核心是重新評估而不是單純追加。每週的報告反映的是「現在」最值得動手的順序，而不是按照發現時間排的靜態清單。一個上週是 MEDIUM 的 code smell，如果這週連續有 PR 都在修改同一個模組，Claude 會把它升到 HIGH——因為那個模組變成了熱點，技術債的實際成本上升了。
報告本身存在 repo 裡，下週執行時 Claude 可以讀到，讓優先等級的變化有連貫性。如果某個 CRITICAL 項目在兩週內都沒有被處理，還可以在 prompt 裡加上自動 assign 到對應模組負責人的邏輯。
TIP — 讓 prompt 說清楚「優先等級的判斷標準」
Routine 自主執行，沒有機會中途問你。優先等級的判斷邏輯要寫進 prompt 裡，越具體越好——「最近 3 個 sprint 頻繁觸碰的熱點」比「重要的模組」更容易讓 Claude 一致地判斷。
心得
The Register 的標題是「Claude Code routines promise mildly clever cron jobs」，有點酸，但不是完全沒道理。對於很多使用場景，一個設定好的 GitHub Actions workflow 加上 anthropic/claude-code-action 也能做到類似的事。
但 Routines 省去的是設定基礎設施的摩擦：不需要管 runner、不需要設定 secrets in GitHub、不需要寫 YAML、不需要自己搞 MCP server 的部署。設定好 prompt、選 repo、掛 trigger，就跑了。對於想快速試驗「讓 AI 自動做某件事」這個概念的人，門檻低很多。
比較在意的是 Pro 方案只有 5 runs/day。對於需要 hourly 排程加上偶爾 GitHub 事件觸發的使用情境，很容易在幾個小時內就用完。希望正式發布時這個限制能放寬。
另一個值得追蹤的是 /fire endpoint 的 beta header 問題——既然形狀可能改，接進 production alerting pipeline 之前要考慮好版本遷移策略。
整體來說，這是 Anthropic 把 Claude Code 從「本機互動工具」往「雲端 AI 基礎設施」延伸的一步。配合 Managed Agents、Auto-Fix、/ultraplan 這幾個方向看，脈絡很清楚：讓更多 AI 工作在背景自主完成，人扮演審核而非執行的角色。
留言