Claude Code Routines 實戰：indie maker 如何用雲端排程取代 cron job

每天早上花 30 分鐘整理「昨晚的 mess」——看 CI log、整理 PR、掃 Sentry 錯誤、更新 Linear tickets。這些事情需要判斷力，不是純資料轉發，Zapier 做不了。以前你只能親自坐在電腦前做，或者建一個複雜的 GitHub Actions 工作流，但每次出錯就要人工介入。

2026 年 4 月 14 日，Anthropic 推出了 Claude Code Routines：讓 Claude Code session 在 Anthropic 雲端持續執行，你的筆電可以關著。這是市場上第一個「把 AI Agent 本身變成排程任務」的功能，不需要 server，不需要 DevOps 背景。

zh-TW 市場幾乎沒有 Routines 的實戰教學。這篇文章帶你從零建立第一個 Routine，釐清三個最常見的誤解，並提供三種 indie maker 可以直接套用的模板。

TL;DR

• Routines 是「有排程的 Claude Code session」，在 Anthropic 雲端執行，遇到問題會自行推理繞過，不是固定 script 的 cron job
• 三層選擇：Cloud Routines（雲端、無本機存取）/ Desktop tasks（本機）/ /loop（當前 session）—— 90% 的情境從 /loop 開始就夠
• Pro 方案 5 次/天夠用：高頻事件（PR open）用 Webhook trigger，不計入 daily cap；固定排程才用 Schedule trigger
• 最佳組合：Routines 負責「需要 AI 判斷的重複工作」，Zapier/Make 繼續負責「機械式資料搬運」
• 建立 Routines 前，先確認你已設定好 Claude Code 的 CLAUDE.md 和 Skills 架構，這是讓 Routine prompt 有效運作的基礎

Routines 到底是什麼？不是智能 cron job，是 AI Agent 排程器

很多人看到「自動排程執行」就想到 cron job，但 Routines 和傳統 cron job 有根本性的差異。

傳統 cron job 的限制：執行固定的 shell script，遇到意外錯誤就停住，等人工介入。你只能告訴它「每天早上 8 點跑這個 script」，但 script 遇到不預期的狀況（repo 結構改了、API 回傳格式變了）就失敗，通知你去修。

Routines 的不同：每次觸發實際上是啟動一個完整的 Claude Code session，在 Anthropic 的雲端基礎設施上執行。Claude 有完整的推理能力——遇到錯誤時，它會嘗試替代方案、繞過問題、或在無法繼續時留下清楚的說明。The Register 稱之為「動態 cron job」，這個描述精確：它執行的是「目標」，而不是「固定步驟」。

設計 Routine 的關鍵認知：傳統 cron job 你給它「要做的步驟」；Routine 你給它「要達到的目標」，讓 Claude 自行決定路徑。

# ❌ 步驟導向（cron job 思維）
Review each PR by:
1. Run git diff on the PR
2. Check for lint errors
3. Post a comment with format X

# ✅ 目標導向（Routine 思維）
Review all open PRs in this repo.
For each PR, assess code quality and potential issues.
Post a concise review comment. Do NOT approve or merge. Keep comments under 150 words.

第一種方式讓 Claude 依賴固定步驟，某個步驟失敗就卡住。第二種方式讓 Claude 自主判斷路徑，更能應對意外。

三層排程方案決策框架：你真的需要 Cloud Routines 嗎？

Anthropic 官方文件提供了三種排程選項，但媒體報導幾乎都聚焦在 Cloud Routines，讓很多人誤以為這是「唯一選項」。實際上，90% 的 indie maker 從更簡單的方案開始就夠了。

方案	執行環境	本機存取	筆電需開機	適合場景
Cloud Routines	Anthropic 雲端	❌ 不行	❌ 不需要	筆電關機時仍需執行的任務
Desktop scheduled tasks	本機	✅ 可以	✅ 需要	需要讀本機檔案、本機資料庫的任務
/loop	當前 session	✅ 可以	✅ 需要	session 開著就夠、實驗性任務

決策樹：

1. 這個任務需要在我睡覺、筆電關著時執行嗎？

   • 是 → Cloud Routines
   • 否 → 繼續往下

2. 這個任務需要存取本機檔案或本機環境？

   • 是 → Desktop scheduled tasks
   • 否 → /loop 就夠了

Persona 場景：

• Leo（SaaS 創辦人）的晨間 PR 摘要：需要在他睡覺時跑，早上起來就看到結果 → Cloud Routines
• Leo 的 Sentry 警示分析：需要讀本機 .env.local 連接私有 Sentry 端點 → Desktop scheduled tasks
• Mei（技術 YouTuber）測試一個新的週整理流程：先用 /loop 跑一次，確認邏輯對了再升級到 Cloud Routines → 先 /loop

重要：Cloud Routines 每次執行都是 fresh clone——Anthropic 雲端的乾淨環境，無法讀取你的本機 .env.local 或本機資料庫。需要本機狀態的任務，必須用 Desktop scheduled tasks。

前置條件與第一個 Routine：從零到第一次執行

官方宣傳 Cloud Routines 是「零維護、零 DevOps」，這是真的——但有一次性的設定成本（約 15-30 分鐘）。理解這個「一次投資」的本質，比被「零運維」說法誤導更重要。

前置條件確認

1. Claude Code on the web 啟用：進入 claude.ai/code，確認你有 Claude Code 的 web 存取權限（Pro 方案以上）
2. GitHub repository 連接：在 Claude Code on the web 設定中，授權 Anthropic 讀取你的 GitHub repository
3. Environment Variables 設定：如果你的 Routine 需要連接外部 API（Slack、Linear、Sentry），在 Routine 設定的 Environment Variables 區塊填入對應的 API keys——這是 Cloud Routines 唯一能「記住」跨次執行資訊的地方

建立第一個 Routine（以晨間 PR 摘要為例）

步驟 1：進入 claude.ai/code/routines → 點擊 New Routine

步驟 2：選擇觸發類型

• Schedule：設定 cron 時間（例如每天 08:00 台灣時間 → 0 0 * * * UTC）
• Webhook：GitHub PR/issue 事件觸發
• API：外部系統呼叫觸發

步驟 3：選擇 repository，設定 Routine 需要的 permissions（讀取、寫入 PR comments 等）

步驟 4：填寫 Routine prompt（見下方模板）

步驟 5：儲存並測試（點擊 Run now 觸發一次手動執行，確認輸出符合預期）

第一次看到 Routine 在你沒有觸發的情況下自動出現執行記錄，會有一種奇特的感覺——那是 Claude Code session 真的在跑，只是不需要你在場。

/schedule CLI vs Web UI：兩種建立方式的實際差異

Routines 支援兩種建立方式，功能相同但體驗不同：

Web UI（claude.ai/code/routines）：適合 Mei 這類不熟 CLI 的用戶，或需要視覺化確認設定的情境。點選介面填寫，直覺易用。

/schedule CLI：適合已有 Claude Code terminal 工作流的開發者，或 Chris（接案者）需要批次管理多個客戶 repo 的 Routine。

# 以下為示意語法，實際 flag 名稱請以官方文件為準
# 建立一個每天 08:00 執行的 PR 摘要 Routine
/schedule create \
  --name "morning-pr-digest" \
  --cron "0 0 * * *" \
  --repo "your-org/your-repo" \
  --prompt "Review all open PRs opened in the last 24 hours..."

# 列出所有現有 Routines
/schedule list

# 手動觸發一次（測試用）
/schedule run morning-pr-digest

注意：CLI /schedule 目前官方文件側重 Web UI 建立流程，上方 flag 語法為示意格式。建立前請先以 /schedule 觸發 in-session 說明，或使用 Web UI（claude.ai/code/routines）確認最新 CLI 語法。

相較於手動建立，CLI 的優勢在於可以腳本化批次操作。Chris 的場景：5 個客戶的 repo，每個都需要一個 nightly PR review Routine，用 CLI 可以一次腳本化完成，不用在 Web UI 重複點選 5 次。

對於排程語法（cron expression），可以參考 OpenAI Codex CLI 的排程設計——雖然是不同工具，cron 語法本身是通用的，也可以看到兩種 AI coding agent 在排程設計上的哲學差異。

三種 Indie Maker 必備 Routine 模板（含完整 Prompt 範例）

Routine prompt 設計的核心原則：給目標 + 給 output 格式 + 給「不要做」的邊界。缺少任何一項，Claude 可能過度積極（幫你 push 到 main）或過度保守（做了一堆分析但沒有任何行動）。

我在 Shareuhack 的 agent fleet 中測試了這些 prompt 邏輯——我們的 reviewer agent（Eno）每天自動 review 內容草稿，和以下的 PR review 模板邏輯相似。VentureBeat 針對企業端 Routines 的實測也顯示，結構良好的 Routine prompt 能把 PR review 循環從平均 2.3 輪降至 1.4 輪（注：企業規模 repo，indie maker 場景可能差異更大）。

---

模板 1：晨間 PR 摘要（Schedule trigger，每天 08:00）

觸發類型：Schedule
Cron：0 0 * * *（UTC，對應台灣早上 08:00）
Repository：{your-repo}

Prompt：
Review all open pull requests in this repository that were updated in the last 24 hours.

For each PR, provide:
- PR title and number
- One-line summary of what it does
- Key concerns or blockers (if any)
- Suggested action: Ready to merge / Needs revision / Needs more info

Format the output as a markdown summary. Post it as a new comment on each relevant PR.

Do NOT:
- Approve or merge any PR
- Leave more than one comment per PR
- Comment on PRs older than 24 hours

---

模板 2：週文件掃描（Schedule trigger，每週一次）

觸發類型：Schedule
Cron：0 1 * * 1（每週一 UTC 01:00，對應台灣週一早上 09:00）
Repository：{your-repo}

Prompt：
Scan the /docs directory for documentation that may be outdated.

Check for:
- References to deprecated APIs or features
- Version numbers that don't match the current package.json
- Broken internal links
- TODO or FIXME comments older than 30 days

Create a GitHub Issue titled "Weekly Docs Audit - {date}" with a checklist of findings.
If no issues found, create a brief issue noting the audit was clean.

Do NOT:
- Edit any files directly
- Delete any content
- Create more than one issue per run

---

模板 3：PR open Webhook trigger（每次 PR 開啟自動 review）

觸發類型：Webhook（GitHub PR opened/synchronize event）
Repository：{your-repo}

Prompt：
A pull request has been opened or updated. Review it for:

1. Code quality: Are there obvious bugs, anti-patterns, or style issues?
2. Test coverage: Does the PR include tests for new functionality?
3. Documentation: Are new functions/APIs documented?

Post a constructive review comment summarizing your findings.
Use this format:
- ✅ What looks good
- ⚠️ Concerns to address
- 💡 Suggestions (optional)

Do NOT:
- Approve or request changes (leave that to human reviewers)
- Post more than one comment per PR update
- Comment on draft PRs

關鍵注意：模板 3 的 Webhook trigger 不計入 Pro 方案的 5 次/天 daily schedule cap。每次 PR 開啟都是獨立觸發，適合高頻場景。

連接外部工具：MCP Connectors 讓 Routine 通知 Slack 和 Linear

Routines 透過 MCP connectors 連接外部工具（Slack、Linear、Google Drive 等），讓 Routine 的輸出可以發送到你的工作環境，而不只是留在 GitHub。

但有一個重要的認知要先建立：Routines 是「AI 判斷層」，不是「整合平台」。

• Routines 擅長：理解語境、做判斷、生成摘要、分析文件品質
• Routines 不擅長：機械式資料搬運（A 服務的資料複製到 B 服務）
• 最佳組合：Routines 做判斷，Zapier/Make 做搬運

硬要 Routines 做簡單的資料轉發（例如「把新的 GitHub issue 同步到 Notion」），不但浪費 token，還比 Zapier 的確定性流程更不可靠。

如果你還沒評估過哪些 MCP servers 最適合 indie maker 的工作流，可以參考 MCP servers 完整指南 作為選型參考。

設定 Slack Connector（以通知為例）

1. 在 Claude Code on the web 設定 → Connectors → 加入 Slack
2. 授權 Anthropic 讀取/寫入指定的 Slack workspace 和 channel
3. 在 Routine prompt 中加入 Slack 輸出指令

# 在 Routine prompt 末尾加入：
After completing the review, send a summary to Slack channel #dev-digest using this format:
"🤖 Morning PR Digest ({date}): {X} PRs reviewed, {Y} need attention"
Include links to PRs that need revision.

務實建議：MCP connector 設定本身相對簡單，但 Routine prompt 中的 Slack 輸出格式需要測試。第一次執行後，觀察 Slack 通知的格式是否符合預期，再決定是否需要調整 prompt。

Pro 5 次/天怎麼用最划算？排程分配策略

Pro 方案每天 5 次 Schedule trigger 看起來不多，但理解計費機制後，5 次其實足夠多數 indie maker 的需求。

關鍵區別：Schedule trigger vs Webhook/API trigger

• Schedule trigger：計入 daily cap（Pro 5次/天，Team 25次/天）
• Webhook/API trigger：按事件觸發，不計入 daily cap（但請確認最新官方文件，計費機制可能更新）

推薦的 Pro 方案分配策略：

Routine	觸發類型	計入 cap?	頻率
晨間 PR 摘要	Schedule	✅ 是	每天（消耗 1/5）
週文件掃描	Schedule	✅ 是	每週一（消耗 1/35 天）
PR open 自動 review	Webhook	❌ 否	每次 PR 開啟
Issue 建立分類	Webhook	❌ 否	每次 issue 建立
緊急警示（Sentry）	API trigger	❌ 否	按需觸發

結論：Schedule trigger 保留給「固定時間點的主動掃描」；即時反應事件（PR、issue、警示）全部改用 Webhook/API trigger，這樣 5 次/天的 cap 幾乎很難用完。

何時考慮升級 Team 方案：如果你管理多個客戶的 repo（Chris 的場景），每個 repo 一個晨間 Schedule Routine，超過 5 個客戶就會觸碰 cap。Team 方案的 25 次/天對接案者更合適。

邊界情況與風險控管 — 當 Routine 做了不預期的事

Routines 是強大的工具，但 token 消耗和不預期行為是真實風險。The Register 的批判視角雖然有點偏頗，但核心擔憂是合理的：Claude 在沒有人監督的情況下，可能過度積極。

Leo 的親身教訓值得借鑒：他之前用 GitHub Actions bot 自動留 PR 評論，結果 bot 對每個 minor typo 都留下 500 字的詳細分析，把整個 PR thread 搞得一團亂，最後被他的 collaborator 投訴。

風險控管 checklist：

• [ ] 明確「不要做」的邊界：每個 Routine prompt 必須包含 Do NOT: 段落，列出 Claude 不應該執行的操作（不要 push to main、不要修改超過 X 個檔案、不要留超過一個評論）
• [ ] 先用 /loop 或 Run now 測試：在設定排程前，手動觸發一次，仔細審查輸出。確認輸出符合預期後再開啟自動排程
• [ ] 設定可審查的 output 格式：要求 Claude 的輸出有固定格式（markdown checklist、bullet points），方便你快速掃描而非重讀全文
• [ ] 本機狀態 → Desktop tasks：任何需要讀本機 .env、本機資料庫、或本機工具的任務，不要放在 Cloud Routines。改用 Desktop scheduled tasks
• [ ] token 消耗監控：複雜的 Routine prompt（要求 Claude 掃描大型 repo）可能消耗大量 token。第一週密切監控 Claude Code 的 usage，確認沒有超出預期
• [ ] 確認失敗通知機制：Routine 執行失敗時，你如何得知？目前官方提供執行歷史記錄可在 claude.ai/code/routines 查閱。如果想要主動通知，需要在 Routine prompt 中明確加入 Slack 失敗通知指令（例如「如果遇到錯誤，向 #dev-alerts 發送失敗摘要」），這不是自動行為

常見誤區：一個常見的錯誤是讓 Routine 的 prompt 太複雜（「掃描所有檔案、分析所有 PR、更新所有文件、通知所有人」），導致每次執行消耗巨量 token 且輸出品質下降。最好的 Routine 做一件事、做得好。

這和 n8n AI Agent 自動化的設計原則 一樣——自動化工具的最大陷阱是「把太多事情塞進一個流程」，反而比手動更難維護。

結論

Claude Code Routines 最大的價值不是「讓你自動化更多事」，而是讓需要 AI 判斷的重複工作不再需要你在線。那些介於「太複雜讓 Zapier 做」和「太瑣碎不值得親自做」之間的任務，Routines 正好填補這個空間。

從這裡開始：

1. 先確認你的 Claude Code CLAUDE.md 和 Skills 設定 已就位——Routine 的 prompt 和你日常 Claude Code 設定共享相同的行為規範基礎
2. 建立第一個最小的 Routine：晨間 PR 摘要（如果你有 GitHub repo），或週文件掃描
3. 用 Run now 手動觸發，審查輸出品質
4. 確認輸出符合預期後，開啟自動排程，觀察一週
5. 如果一週後仍然滿意，再考慮擴展到第二個 Routine

不要一開始就建立 10 個 Routine。一個運作良好的 Routine，比 10 個你需要持續修正的 Routine 更有價值。