凌晨三點，你的 MacBook 闔著，充電燈慢慢呼吸。同一時間，Claude 正在雲端讀你 repo 裡昨天開的三個 PR，逐一 review、留下 comment、標記需要改的地方。你早上起來打開 GitHub，review 已經做完了。

這不是 cron job，也不是 GitHub Actions。這是 Routines。

先搞懂一件事：為什麼需要 Routines

你家的洗衣機有定時功能。設好時間、丟進衣服、按下開始，出門上班。洗衣機不需要你站在旁邊盯著它轉。

Claude Code 以前的自動化工具——/loop 和 /schedule——比較像是你站在洗衣機前面，手動按「再洗一次」。terminal 一關，任務就死了。/schedule 雖然跑在雲端，但它的設計是一次性的：「幫我做這件事」，做完就沒了。

Routines 是洗衣機的定時功能。設定一次，它自己會每天跑、每週跑、或在特定事件發生時跑。你的筆電不用開著。

功能 跑在哪 筆電關了會怎樣 適合什麼
/loop 你的 terminal 死掉 短期輪詢：盯 build、等 deploy
/schedule Anthropic 雲端 活著，但只跑一次 單次遠端任務
Routines Anthropic 雲端 活著，而且會自動重複 持續性自動化

這三個不是互相取代的關係。/loop 處理「接下來五分鐘」，/schedule 處理「今天晚上」，Routines 處理「從今天開始，每天」。

Routine 的組成：三個東西打包成一個

一個 Routine 就是三樣東西綁在一起：

Prompt——你要 Claude 做什麼。跟你在 terminal 裡打的指令一樣，只是這次它會被反覆執行。「Review 所有 open 的 PR，針對安全性和效能留 comment」「檢查 package.json 的 dependency 有沒有已知漏洞」「掃描 _posts/ 目錄，確認所有文章的 frontmatter 格式正確」。

Repos——Claude 要存取哪些 repository。可以掛一個，也可以掛多個。Routine 執行的時候，Claude 會 clone 最新版本到雲端環境裡操作。

Connectors——Claude 需要的外部連接。GitHub token、Slack webhook、環境變數。這些會在每次執行時注入到雲端環境。

把這三個打包好，你就得到一個可以反覆執行的自動化單位。

等等，先釐清一個常見的誤解。

很多人第一次看到 Routines 會想：「這不就是 GitHub Actions 嗎？」

不一樣。GitHub Actions 是你寫好 YAML workflow，定義好每一步要做什麼——checkout、install、test、deploy。每一步都是你預先規劃好的。如果 CI 失敗了，Actions 只會告訴你「Step 7 failed」，你得自己去看 log 找原因。

Routines 給 Claude 的是一個目標，不是一個腳本。「Review 所有 open PR 的安全性」——怎麼 review、看哪些檔案、留什麼 comment，Claude 自己決定。CI 失敗了？你可以設一個 Routine 說「分析失敗的 CI log，找出根本原因，如果是 flaky test 就自動 re-run，如果是真的 bug 就開 issue 並附上修復建議」。

Actions 是確定性腳本。Routines 是智慧型代理。兩者搭配用最強——Actions 處理標準化流程，Routines 處理需要判斷力的工作。

三種觸發方式

Routine 建好之後，你要告訴它「什麼時候跑」。有三種觸發器，可以混用。

Scheduled：固定排程

最直覺的一種。每小時、每天早上九點、每週一凌晨兩點——選一個頻率，它就會自己跑。

適合的場景：

  • 每天早上 review 所有 open PR
  • 每週一跑 dependency audit
  • 每天晚上整理今天的 commit log 寄到 Slack

API：外部觸發

每個 Routine 建好後會拿到一個專屬的 HTTP endpoint 和 bearer token。你可以從任何地方用 POST 打它。

1
2
curl -X POST https://api.claude.ai/routines/{routine_id}/trigger \
  -H "Authorization: Bearer YOUR_TOKEN"

適合的場景：

  • deploy 完成後觸發 Routine 跑 smoke test
  • Slack bot 收到指令後觸發 Routine 做分析
  • 串進你自己的自動化 pipeline

GitHub：事件驅動

綁定 repo 事件。PR opened、PR merged、release published、issue created——任何 GitHub webhook 支援的事件都行。

適合的場景：

  • PR 開出來自動做第一輪 review
  • release 發布後自動更新 CHANGELOG
  • issue 建立後自動分析並標記 priority

三種觸發器可以同時掛在一個 Routine 上。一個 review Routine 可以同時被 PR opened 觸發、被每天早上的排程觸發、也可以被你手動用 API 打。

實戰：建立你的第一個 Routine

三個地方都能建，結果完全相同——它們同步到同一個 cloud account。

方法一：Web 介面

打開 claude.ai/code/routines。點「New Routine」。填 prompt、選 repo、加 connector、設觸發器。完成。

最適合第一次使用。介面會引導你填每個欄位，不用背語法。

方法二：Desktop App

在 Claude Code Desktop 裡，打開 Command Palette，搜尋「Routines」。操作邏輯跟 Web 一樣，只是介面在桌面端。

方法三：CLI

在 terminal 裡用 /schedule 指令建立。

1
claude> /schedule "每天早上 8 點 review 所有 open PR，針對安全性和效能留 comment" --cron "0 8 * * *" --repo owner/my-repo

CLI 的好處是可以腳本化——你可以寫一個 shell script 一次建好十個 Routine。

講個冷知識。Routines 跑在 Anthropic 管理的雲端容器裡。每次執行，Claude 會 clone 你指定的 repo 到一個乾淨的環境，做完事情之後環境就銷毀。所以不用擔心「上次跑的殘留物影響這次」——每次都是乾淨的。

這也是為什麼 Connectors 很重要。如果你的 Routine 需要推 commit 回去，它需要有 write 權限的 GitHub token。如果需要發 Slack 訊息，它需要 webhook URL。這些東西不會存在 repo 裡，而是存在 Routine 的 Connector 設定裡，每次執行注入。

五個馬上能用的 Routine 範本

不囉嗦，直接貼。

1. 每日 PR Review

1
2
3
4
5
6
7
8
Prompt: Review 所有 open 的 PR。每個 PR 做以下檢查：
- 有沒有 SQL injection 或 XSS 風險
- 有沒有缺少錯誤處理的地方
- 有沒有 N+1 查詢
- 命名和結構是否符合 CLAUDE.md 裡的規範
在每個 PR 留下 review comment，標記嚴重程度。

Trigger: Scheduled, 每天 08:00

2. CI 失敗自動診斷

1
2
3
4
5
6
7
Prompt: 檢查最近 24 小時內失敗的 CI runs。對每個失敗：
1. 讀取完整 log
2. 判斷是 flaky test、dependency 問題、還是真的 code bug
3. 如果是 flaky test，自動 re-run
4. 如果是 bug，開一個 issue 附上根因分析和修復建議

Trigger: Scheduled, 每天 09:00

3. 每週 Dependency Audit

1
2
3
4
5
6
7
8
Prompt: 跑 npm audit（或 pip audit），列出所有 high/critical 漏洞。
對每個漏洞：
- 確認是否有可用的修復版本
- 評估升級的破壞風險
- 如果風險低，自動開 PR 升級
- 如果風險高，開 issue 說明為什麼需要人工判斷

Trigger: Scheduled, 每週一 02:00

4. PR Merge 後自動更新文件

1
2
3
4
5
6
Prompt: 讀取剛 merge 的 PR diff。如果有改到 API endpoint、
設定格式、或公開介面，自動更新對應的 README 或 docs/ 底下的文件。
推一個 commit 到 main，commit message 格式：
docs: 根據 PR #xxx 更新文件

Trigger: GitHub, PR merged

5. Stale Branch 清理

1
2
3
4
5
6
7
8
9
Prompt: 列出所有超過 30 天沒有 commit 的 remote branch。
排除 main、develop、release/*。
對每個 stale branch：
- 檢查是否有對應的 open PR（如果有就跳過）
- 列出最後一個 commit 的作者和日期
- 產生一份清理報告發到 Slack
- 不要自動刪除，只報告

Trigger: Scheduled, 每月 1 號 03:00

跟 Kiro 和 GitHub Actions 比一比

既然都在講自動化，順便拉個比較。

GitHub Actions 是 workflow engine。你用 YAML 定義每一步，它按順序執行。強在穩定、可重現、生態系龐大（marketplace 上幾千個 action）。弱在沒有判斷力——遇到預期外的情況就卡住。

Kiro 在 2.0 版推出了 headless 模式，可以在 CI/CD 裡跑。它的設計偏向「spec-centric」——先寫規格再寫 code。自動化能力跟 Claude Code 比還在早期。

Routines 介於兩者之間。它不像 Actions 那樣需要你把每一步都寫出來，但也不是完全放手——你得寫清楚目標和限制。它的優勢在於「理解 context」：Claude 知道你的 codebase 結構、知道 CLAUDE.md 裡的規範、知道之前的 PR 改了什麼。Actions 不知道。

最務實的搭配：Actions 跑 CI/CD pipeline（build、test、deploy），Routines 跑需要判斷力的自動化（review、分析、文件更新）。

注意事項和地雷

在你興奮地建了十個 Routine 之前，幾件事要知道。

方案限制。Routines 需要 Pro 方案（$20/月）以上。免費版沒有。執行次數和時數有上限，看你的方案 tier。

權限要想清楚。Routine 能做的事取決於你給它的 Connector 權限。GitHub token 如果開了 write 權限，Claude 就能推 commit、開 PR、merge。這很方便，但也很危險——上週才有一個新創的 production database 被 AI agent 用一個 scope 太大的 API token 整個刪掉。Connector 的 token scope 越小越好，只給它需要的權限。

Prompt 要寫限制條件。「Review 所有 PR」太寬了。「Review 所有 open PR，只留 comment 不要 approve 也不要 request changes，不要推任何 commit」——這才夠具體。Claude 很聰明，但聰明加上不明確的指令等於不可預測。

監控執行結果。每個 Routine 的執行紀錄都在 Web dashboard 裡看得到。前幾次跑完一定要回去看——確認它做的事跟你預期的一樣。

Research Preview 階段。Routines 在 2026 年 4 月 14 日作為 research preview 發布。功能還在快速迭代中，介面和行為可能會變。

從 Routines 可以延伸到哪裡

學會 Routines 之後，你其實已經站在「AI 自動化」的核心位置了。幾條可以接著探索的路。

往 Agent SDK 走——如果 Routines 的 Prompt 不夠用，你可以用 Anthropic 的 Agent SDK 寫更複雜的 agent 邏輯，然後用 API 觸發器把它串進 Routines。

往 MCP Server 走——自己寫一個 MCP Server，讓 Routine 裡的 Claude 可以存取你的內部系統（資料庫、JIRA、Slack），做更深度的自動化。

往 Managed Agents 走——如果你需要的不只是排程，而是一個長時間運行的 agent（比如一個持續監控 production metrics 的 agent），Managed Agents 可能更適合。

背後就兩條線：你想讓 AI 做的事越複雜，你需要的基礎設施就越多。Routines 是門檻最低的入口——一個 prompt、一個 repo、一個排程，就能跑起來。剩下的複雜度，等你真的需要的時候再加。

參考來源：Automate work with routines - Claude Code Docs
參考來源：Claude Code Routines: Anthropic’s New Cloud Automation
參考來源：Claude Code Adds Cloud Routines for Scheduled AI Tasks - WinBuzzer