Anthropic 推出了一項功能，但幾乎沒人在討論它。
快點收藏並儲存這篇 :)
它叫做 Claude Code Routines。
這可能是 Anthropic 今年推出最重要的功能。
原因如下。
到目前為止，每個 Claude Code 自動化都需要你的筆電保持開機。你可以用 /loop 來輪詢變更，也可以用 /schedule 設定週期性任務。但一旦你關閉終端機或闔上筆電，一切就會停止。
Routines 完全解決了這個問題。
Routine 是一種 Claude Code 自動化功能，你只需設定一次——一個提示詞、一個儲存庫、一組連接器——然後它就會在 Anthropic 的雲端基礎設施上執行。按照排程、透過 API 呼叫、或由 GitHub 事件觸發。
你的筆電可以關機，終端機可以關閉，Routine 仍然會執行。
這就是從「你使用的 AI 工具」到「為你工作的 AI 系統」的轉變。
以下是如何設定一個 Routine 的詳細步驟，即使你從未用過 Claude Code。
為什麼 Routines 與其他功能截然不同
Claude Code 原本就有排程功能。那到底有什麼改變？
差別在於基礎設施。
舊的 /schedule 和 /loop 指令是在你本機的 Claude Code 工作階段內執行。它們依賴於你的電腦開機、終端機開啟、以及網路連線穩定。只要其中任何一項出問題，自動化就會中斷。
Routines 則是在 Anthropic 的雲端上執行。它們是持久化的自主 Agent，能夠在重新啟動、終端機關閉、以及隔夜運行後繼續存活。它們可以直接存取你的儲存庫和連接器——Slack、Linear、Google Drive、GitHub——你完全不需要管理這些東西。
你可以把舊系統想像成手機上的提醒。它會響，但你還是得自己動手做。
Routines 則像是那個在你睡覺時完成工作、等你醒來後給你摘要的員工。
第一步：決定要自動化什麼
最好的 Routine 自動化任務具備以下特點：
- 重複性——它們按照可預測的排程發生（每日、每週，或由事件觸發）。
- 定義明確——你可以毫不含糊地描述「完成」的樣子。
- 低判斷需求——任務不需要你獨特的創意思考或決策，只需要執行。
以下是早期用戶目前正在運行的模式：
- 待辦事項管理——每天午夜，Routine 從 Linear 拉取新的問題，按類型和嚴重性分類，指派標籤，並將摘要發佈到 Slack 頻道。工程主管醒來時看到的就是一個乾淨、有條理的專案。
- 文件漂移偵測——每週五，Routine 掃描過去一週合併的 Pull Request，找出任何變更 API 或介面的 PR，與文件進行交叉比對，並為過時的文件開啟更新 PR。
- 部署驗證——每次部署後由 Webhook 觸發，Routine 對新版本執行冒煙測試，掃描錯誤日誌以找出回歸問題，將任何問題與最近的程式碼變更關聯起來，並在發佈頻道中發佈「通過/不通過」的判定。
- 每日程式碼審查——每天早上 9 點，Routine 選取最舊的未審查 PR，檢查安全性問題、邏輯錯誤和程式碼風格違規，並發表內嵌評論。
那些設定三到四個這類 Routine 的人，其運作效率遠高於仍把 Claude 當作聊天工具的人。
第二步：建立你的第一個 Routine
建立 Routine 有兩種方式。
- 從網頁介面：前往 claude.ai/code/routines 並點擊「New routine」。這裡提供完整的設定選項——排程觸發、API 觸發和 GitHub 事件觸發。
- 從 CLI：如果你已經在終端機中使用 Claude Code，輸入 /schedule 並加上描述。例如：
1/schedule daily PR review at 9am
CLI 只能建立基於排程的觸發。API 和 GitHub 觸發需要透過網頁介面。
當你建立 Routine 時，需要設定四項內容：
- 提示詞——這是最關鍵的部分。由於 Routine 會自主執行，提示詞必須完全自足。Agent 需要知道的一切都必須寫在提示詞中。沒有「來自對話前文的上下文」。每次執行都是從頭開始。
- 儲存庫——Routine 要處理的程式碼庫。它擁有完整的讀取權限，並且預設可以推送到以
claude/為前綴的分支。 - 連接器——Routine 可以存取的外部服務。Slack 用於發佈更新，Linear 用於讀取和管理問題，Google Drive 用於讀寫文件，GitHub 用於監控事件和開啟 PR。
- 觸發條件——Routine 何時以及如何執行。可以是排程（每小時、每晚、每週）、API 觸發（你以程式方式呼叫），或 GitHub 觸發（當儲存庫中發生特定事件時觸發）。
第三步：撰寫一個無懈可擊的提示詞
這是大多數人失敗的地方。
Routine 在你不在場的情況下執行。如果提示詞含糊不清，Agent 每次都會以不同方式解讀，導致結果不一致。
最好的 Routine 提示詞遵循以下結構：
- 角色定義：「你是一位專注於安全性和效能的資深程式碼審查員。」
- 任務定義：「審查此儲存庫中最舊的未審查 Pull Request。」
- 逐步流程：「首先，閱讀 PR 描述。然後檢出該分支。閱讀變更的檔案。分析安全性漏洞、邏輯錯誤和效能問題。針對每個發現的問題撰寫內嵌評論。」
- 輸出規範：「在 PR 上發佈摘要評論，內容包括：發現的問題總數（按嚴重性分類）、一段整體評估、以及明確的 approve/request-changes 判定。」
- 錯誤處理：「如果沒有未審查的 PR，請在 Slack 的 #engineering 頻道發佈『今天沒有需要審查的 PR。』如果 PR 變更的檔案超過 50 個，則跳過該 PR，並發佈該 PR 需要人工審查。」
- 限制條件：「絕不批准含有 Critical 嚴重性問題的 PR。絕不直接修改任何程式碼——只發表評論。每個檔案最多三條內嵌評論，以避免雜訊。」
提示詞越精確，Routine 就越可靠。
第四步：了解限制
Routines 功能強大，但也有一些限制需要了解。
- 每日執行次數上限：在研究預覽期間，每個帳戶每天有 15 次 Routine 執行次數。如果需要更多，可以在組織設定中啟用額外用量——額外執行次數會按量計費。
- Token 消耗：Routines 與互動式 Claude Code 工作階段共用相同的訂閱限制。一個讀取大量檔案並進行多次 API 呼叫的複雜 Routine，會比簡單的 Routine 消耗更多 Token。
- 分支安全性：預設情況下，Claude 只能推送到以
claude/為前綴的分支。這是一項安全措施——一個寫得不好的 Routine 不會意外推送到 main 分支。除非下游有完善的審查流程，否則請勿停用此功能。 - GitHub 事件上限：在預覽期間，GitHub 觸發的 Routine 有每小時的執行次數上限（每個 Routine 和每個帳戶）。如果你的儲存庫非常活躍，請過濾哪些事件會觸發 Routine，以避免浪費執行次數在雜訊上。
- 排程依賴性：排程的 Routine 會在指定時間執行，但在高需求時段可能會有時間差異。請不要建立依賴於精確秒數的工作流程。
第五步：建立 Routine 堆疊
一個 Routine 很有用。一組 Routine 堆疊就是一個系統。
以下是一個小型工程團隊的完整 Routine 堆疊範例：
- 早上 9 點——每日 PR 審查：Claude 審查所有未審查的 PR，發表內嵌評論，並將摘要發送到 Slack，列出今天需要優先處理的事項。
- 部署後（Webhook）——部署驗證：每次部署到 Staging 環境時，Claude 執行測試套件、掃描日誌中的錯誤，並在幾分鐘內將「通過/不通過」結果發佈到發佈頻道。
- 凌晨 2 點——待辦事項分類：Claude 處理當天提交的所有新問題，新增標籤、指派優先級分數，並建立一份晨間簡報文件。
- 週五下午 5 點——文件檢查：Claude 掃描本週合併的 PR，找出需要更新的文件，並為每個文件開啟草稿 PR。
- 週一早上 8 點——技術債報告：Claude 掃描程式碼庫中的 TODO 註解、已棄用的依賴項和測試覆蓋率缺口。產生一份按預估工作量排序的技術債項目清單。
每個 Routine 需要 10-15 分鐘設定。整個堆疊只需一個下午。而節省的時間每週都在累積。
第六步：監控並改進
每次 Routine 執行都會產生日誌。請檢視它。
尋找模式：
- Routine 是否 consistently 產出良好的結果？如果不是，提示詞的哪個部分不明確？
- 某些執行是否花費太長時間？你可能需要縮小範圍。
- 是否遇到錯誤？在提示詞中加入明確的錯誤處理。
- 是否產生太多雜訊？收緊限制條件。
新的「Dreaming」功能——在 5 月 6 日的 Code with Claude 活動中宣布——更進一步。啟用 Dreaming 後，Claude 會在執行間隔中回顧自己過去的 Routine 工作階段，識別哪些方法有效、哪些無效，並在下次執行時自我改進。
你的 Routine 會隨著執行次數增加而變得更聰明。
這適合誰（以及不適合誰）
Routines 是為開發人員和具備技術能力的操作者設計的，他們：
- 已經在使用 Claude Code，或願意學習
- 工作流程中有遵循明確模式的可重複任務
- 希望自動化每週耗費數小時的營運 overhead
- 使用託管在 GitHub 上的程式碼庫
如果你是非技術用戶，正在尋找 AI 自動化，那麼 Claude Cowork 搭配排程任務是更好的起點。Routines 是進階用戶工具。
但如果你是開發人員、工程經理、DevOps 工程師或技術創辦人——Routines 將比 Anthropic 推出的任何其他功能為你節省更多時間。
Routines 與 GitHub Actions 的差異
許多開發人員會問：既然 GitHub Actions 是免費的，為什麼要付費使用 Claude Routines？
答案是：GitHub Action 是一個腳本。你必須撰寫每一步、定義每個條件、自行處理每個邊緣情況。它只會執行你編寫的內容，不會多做任何事。
Claude Routine 是一個 Agent。你給它一個目標，它會決定如何達成，適應意外情況，推理問題，並驗證自己的工作。
GitHub Action 執行 linter 並告訴你哪裡失敗。Claude Routine 讀取錯誤、理解失敗原因、提出修復方案，並開啟包含修正內容的 Pull Request。
這是完全不同的類別。腳本遵循規則，Agent 解決問題。
對於簡單的自動化——執行測試、檢查格式、發送通知——GitHub Actions 就夠了。但對於需要判斷、分析或適應性的任務，Routines 的等級完全不同。
你可以立即複製的常見 Routine 配方
以下是五個你可以在接下來一小時內設定好的 Routine 配置：
配方 1：早晨站會機器人
- 排程：每天上午 8:30
- 提示詞：「檢查 GitHub 儲存庫中昨天推送的所有提交。檢查 Linear 中新增和更新的問題。檢查 Slack #engineering 頻道中任何提及阻礙的訊息。編譯一份站會簡報，包含三個部分：已完成的工作、進行中的工作、以及受阻礙的工作。將簡報發佈到 Slack 的 #daily-standup 頻道。」
配方 2：依賴項稽核員
- 排程：每週一上午 6:00
- 提示詞：「掃描 package.json 和 requirements.txt 中的所有依賴項。使用網路檢查每個依賴項是否有已知漏洞。找出任何落後目前版本超過兩個主要版本的依賴項。建立一份按嚴重性評級排序的優先報告，如果發現任何 Critical 漏洞，則開啟一個 GitHub Issue。」
配方 3：更新日誌產生器
- 觸發：GitHub 事件——推送新的 Release 標籤
- 提示詞：「當推送新的 Release 標籤時，讀取自前一個標籤以來的所有提交。將每個提交分類為 feature、fix、improvement 或 chore。在 CHANGELOG.md 中產生格式化的更新日誌，並開啟一個 PR。」
配方 4：測試覆蓋率監控器
- 排程：每天凌晨 1:00
- 提示詞：「執行測試套件。按模組計算覆蓋率百分比。與 coverage-config.json 中的覆蓋率基準進行比較。如果任何模組的覆蓋率低於基準超過 2%，則開啟一個 GitHub Issue，註明具體模組、舊覆蓋率、新覆蓋率，以及可能導致下降的提交。」
配方 5：PR 描述強制執行器
- 觸發：GitHub 事件——開啟新的 PR
- 提示詞：「當開啟新的 PR 時，檢查描述是否符合我們的範本要求：必須包含 Summary 部分、Testing 部分，以及如果涉及 UI 變更則需包含 Screenshots 部分。如果缺少任何部分，請發表禮貌的評論，要求作者在審查前更新描述。」
每個配方設定時間不到 10 分鐘。它們加起來每月可以為團隊節省數十小時。
結論
舊方式：醒來、開啟終端機、啟動 Claude Code 工作階段、輸入指令、等待結果、繼續下一個任務。明天重複。
新方式：設定一次 Routine，讓它們在 Anthropic 的雲端上執行，醒來直接看到結果。
這不是理論上的改進。已經有人在運行一整套 Routine 堆疊，在夜間處理他們整個營運工作流程。
「把 Claude 當聊天機器人用的人」與「讓 Claude 全天候自主工作的人」之間的差距，每週都在擴大。
Routines 就是你跨越到另一邊的方法。
大多數人讀完這篇文章會想：「我應該找時間設定一下。」而那些今天實際建立第一個 Routine 的人，下週就會有一個每週為他們節省數小時的系統在運作。
追蹤我 @eng_khairallah1 以獲取更多 AI 解析和工作流程。我定期發布這類內容——真正有效的工具、設定和策略。
希望這對你有幫助，Khairallah ❤️
