📌 本文重點
- 用程式碼定義 routine，讓 Claude 自動跑開發流程
- 支援排程、API、GitHub webhook 等多種觸發方式
- 適合 CI、PR 初審、重構、錯誤偵測等自動化場景
- 建議先從「只讀建議」開始，逐步放權到自動修正
一句話先說清楚：Claude Code routines 就是「用程式碼把 Claude 變成你的自動化開發助理」，幫你在雲端自動跑修 Bug、審 PR、開 issue 等重複工作。
官方文件：https://code.claude.com/docs/en/routines
核心功能：用程式碼定義多步驟任務
routines 的概念很簡單：你先用程式碼把「要怎麼用 Claude 做事」寫成一個流程，之後就讓它自動在雲端重複跑。
典型一個 routine 可以長這樣：
- 拉特定 repo（支援 GitHub 等連接器）
- 用 Claude 分析程式碼變更或錯誤
- 修改程式碼、產生 patch 或直接開 PR
- 把結果回報到 GitHub、Slack 或你的 CI 系統
根據官方說明和社群分享（Reddit）：
- ✅ 多步驟流程可程式化：你不是丟一句 prompt 就結束，而是用程式碼描述整個 pipeline，例如：
ts
// 偽程式碼示意：定義一個 routine
const routine = defineRoutine({
name: 'lint-and-suggest',
repo: 'github://my-org/my-repo',
steps: [
cloneRepo(),
runESLint(),
askClaudeForFixes(),
commentOnPullRequest(),
],
})
- ✅ 三種觸發方式（都在雲端跑，電腦可關機）：
- 固定排程：例如每天凌晨跑一次重構建議
- API 呼叫：每個 routine 會有一個 endpoint，你可以從自家服務打 API 觸發
- GitHub webhook：例如「新 PR 建立時就讓 routine 自動跑審查」
💡 關鍵： routines 把「一次性的 prompt」變成「可重複觸發的程式化流程」，而且全部在雲端執行，不綁你的電腦在線。
你可以馬上做的事：
- 想一個你最常重複做的開發流程（例如「每次 PR 都要跑 lint + 給建議」），把它拆成 3–5 個步驟，列成清單，等等在「怎麼開始」直接照這份清單寫成 routine。
適合誰用：4 個典型場景
1. CI 流程自動跑靜態分析 + 修正建議
場景：你現在的 CI 只會跑 lint / type check，但錯誤一堆，只丟紅燈不給解法。
用 routines 可以：
- 在 CI 裡呼叫一個 API routine
- routine 拉 PR 的 diff，跑 ESLint / mypy 等工具
- 把錯誤丟給 Claude，讓它：
- 用自然語言解釋錯誤來源
- 產生建議修正（甚至 patch）
- 把結果直接貼回 PR comment
可執行動作：
- 選一個語言（例如 TypeScript），從你現有 CI 裡加一個步驟：呼叫 routines API，把 PR 編號、branch、diff 傳給它，讓 routines 回傳「修正建議文字」或「patch 檔」。
2. PR 自動初審：先讓 AI 篩一輪
場景：團隊 PR 多，但 Reviewer 不想浪費時間在命名、註解、重複邏輯這種「低階問題」。
routine 可以幫你：
- 透過 GitHub webhook，在 PR 開啟時觸發
- 讀取 diff + 相關檔案
- 按你定義的規則檢查：
- 是否有測試
- 是否破壞既有 API
- 命名 / 註解 / logging 是否符合約定
- 自動在 PR 下面留一串初步 review comment
可執行動作：
- 先在文件裡列出你希望「PR 初審」檢查的 checklist（3–7 項就好），之後在 routine 的 prompt 中直接貼入這份 checklist，讓 AI 依此審查。
3. 例行重構 / 格式化：排程交給 AI 擬方案
場景：技術債知道很多，但沒空系統性整理。
排程 routine 可以：
- 每週固定拉主分支
- 掃特定目錄（例如
/legacy/**） - 讓 Claude：
- 找出重複程式碼、過長 function、潛在性能瓶頸
- 產出「重構提案」文件，列出建議與風險
- 適度產生小 patch（例如只做格式、抽小 function）
可執行動作：
- 挑一個最頭痛的模組，設定一個每週 routine，讓 AI 每週只做一件事：產出一份 markdown 報告
docs/refactor-suggestions.md，你每週開會時直接打開看。
4. Crash 時自動開 issue + 初步定位
場景：線上服務 crash，Log 一堆，沒人第一時間看。
你可以：
- 在監控系統（如 Datadog、Sentry、自家 APM）裡，當發生特定錯誤時，呼叫 routines API
- routine 取得：錯誤訊息、stack trace、關聯 log
- 讓 Claude：
- 用固定模版在 GitHub / Jira 開 issue
- 附上「可能原因、優先查看檔案、建議排查步驟」
可執行動作：
- 把你目前手動開 issue 的模版貼出來，照樣套到 routine：把欄位（背景、重現步驟、log、可能原因）寫進 prompt，讓 AI 自動填。
進階玩法：多代理 + DevOps 工具鏈串接
多代理平行工作：一個負責測試、一個負責安全
Anthropic 在桌面版 Claude Code 已經支援多代理平行工作（Reddit 範例），在 routines 概念上，你可以照抄這個思路：
- routine A：專門寫測試
- 拉 PR diff
- 找出新增 / 修改的 function
- 為這些 function 產測試檔 / 測試 case
- routine B：專門做安全檢查
- 用「安全檢查 prompt」掃過相同 diff
- 找 SQL injection、硬編 API key、不安全的反序列化等
你在 CI / webhook 流程裡：
- 對同一個 PR 同時觸發 routine A 和 B
- 兩邊結果都留言回 PR，Reviewer 一次看完
可執行動作：
- 先從「拆成兩個 routine」開始：複製一份 PR 初審 routine，一份改成只談測試、一份改成只談安全。兩個端點都掛在同一個 GitHub webhook 上平行觸發。
💡 關鍵： 把不同責任拆成多個 routine 平行跑，比讓一個超大 prompt 包山包海更穩定、也更好維護。
和 GitHub Actions / 自家 CI 組合
根據官方說明，每個 routine 都有自己的 API endpoint，你可以：
- 在 GitHub Actions 新增一個 step：
yaml
- name: Call Claude routine
run: |
curl -X POST "$ROUTINE_ENDPOINT" \
-H "Authorization: Bearer $ROUTINE_TOKEN" \
-H "Content-Type: application/json" \
-d '{"pr_number": "${{ github.event.pull_request.number }}"}'
- 在自家 CI（GitLab CI、Jenkins 等）同樣用
curl/ http client 呼叫
可執行動作：
- 挑一個已存在、每次都必跑的 workflow（例如
ci.yml中的lintjob），在最後加上一個 step 呼叫 routines，把 log 或 diff 丟給它，先從「只產出建議、不寫檔」開始。
怎麼開始：從一個「最小可用」 routine 起步
1. 在哪裡開啟 Claude Code routines？
前提：需要 Claude 付費帳號（根據 官方公告）。
步驟概念（介面可能會隨時間微調）：
- 登入 https://code.claude.com
- 在側邊欄找到
Routines或類似入口 - 點
Create routine或New routine - 選擇：
- 要連接的 repo（GitHub / 本地鏡像等）
- 要用的 connector（例如 Slack、GitHub）
- routine 的觸發方式（排程 / API / GitHub webhook）
可執行動作：
- 現在就登入 Claude Code，看你的帳號是否已開 routines，確認你公司 repo 是否能被安全地接入（先選一個 side project 測試）。
2. 寫一個「最小可用」 lint & 建議 routine
目標：對指定 repo 做 lint，請 Claude 用自然語言給建議，不動任何程式碼。
流程示意（概念層級）：
- 新建 routine：
ts-lint-advisor - 設定：
- Repo：
github://your-org/your-repo - 觸發：API（先手動呼叫）
- 在 routine 腳本中：
- Step 1：
git clone對應 branch - Step 2：跑
pnpm lint或npm run lint，把輸出存成文字 -
Step 3：呼叫 Claude，把 lint log + 相關檔案片段丟給它，prompt 約略：
你是一位 TypeScript 專案維護者。根據以下 ESLint 輸出，請：
1. 依錯誤類型分組
2. 解釋造成這些錯誤的程式風格 / 設計問題
3. 提出 3–5 條優先修正建議（包含具體檔案與規則） -
回傳結果：只輸出 markdown 報告，不修改 repo
可執行動作：
- 先做一版「只讀不寫」的 lint 報告 routine，確定你喜歡它的輸出風格，再考慮讓 routine 產 patch 或自動發 PR。
💡 關鍵： 先用「只讀報告」驗證 routine 的品質與風格，比直接讓它改碼、開 PR 安全得多。
3. 設定 GitHub webhook：新 PR 自動觸發
當你有一個穩定的 PR 初審 routine 之後，可以這樣接 GitHub：
- 在 routines 介面確認此 routine 的 API endpoint
- 到 GitHub 專案
Settings → Webhooks： - Payload URL：貼上 routines endpoint
- Content type：
application/json - Which events：勾選「Pull requests」
- 在 routine 的程式裡解析 GitHub webhook payload：
- 取得
pull_request.number、head.ref、base.ref - 用這些資訊去抓 diff + 檔案內容
可執行動作：
- 先對「一個測試 repo」開 webhook，不要直接上 production monorepo；等確認 routine 不會亂刷 comment、沒權限問題，再複製設定到正式專案。
風險提示與 Best Practices
1. 權限控制：不要讓 Agent 直接推到 main
routines 能改程式碼，也能開 PR。建議：
- 對 routines 用的 GitHub Token：
- 禁止直接 push 到
main/master - 只給「開 PR」和「留言」的權限
- 在 Org Policy 中明定：AI 開的 PR 一律需要人審核才能合併
可執行動作：
- 立刻確認你準備給 routines 用的 GitHub PAT / App 權限，把
push to protected branches關掉。
2. 改動記錄與審計：每一個 AI 動作都要有跡可循
為了避免「不知道是哪個 routine 改了什麼」：
- 統一規範 AI 開 PR 的 branch 命名，例如：
ai/routine-name/feature-x。 - PR 描述固定包含：
- 使用的 routine 名稱 & version
- 執行時間、輸入參數（例如針對哪個 issue / PR）
- 可以在 routine 程式裡主動把自己的輸出寫入一個 log 檔或 S3 / DB，供日後查詢。
可執行動作：
- 寫一個簡單規範：所有 routines 在 PR 描述最上方都要加一段固定訊息，例如：
[Generated by routine: pr-initial-review v0.3]，方便日後搜尋、回溯。
3. 慢慢放權：先從「建議」再到「自動修改」
導入策略可以分三層：
- 只讀模式：只產報告 / 建議，不動任何檔案
- Patch 模式：產生 patch 檔、開 PR，但不自動合併
- 半自動修正：對低風險項目（格式化、註解）允許自動合併，高風險項目仍需人工
可執行動作：
- 先列出「允許 AI 自動處理」與「必須人工審核」的改動類型（例如：格式化、註解 vs. 核心業務邏輯、資料庫 schema），在 routine 的 prompt 裡明寫清楚。
小結：從一個 routine 開始，把最煩的事交給 Claude
你可以把 Claude Code routines 當成「可編程的 AI Bot 平台」：
- 把你每天重複做的開發流程拆成步驟
- 用程式碼和 prompt 變成 routine
- 用排程、API 或 GitHub webhook 觸發
最實際的下一步：
- 選一個最討厭但規則清楚的工作（例如 PR 初步檢查命名和註解）。
- 在 Claude Code 裡建一個 routine，先只產出文字建議。
- 跑一週，觀察輸出品質，再決定要不要進一步讓它產 patch、開 PR。
從一個小 routine 開始，你就能感受到「用程式碼把 Claude 變成你的自動化開發助理」的威力。
🚀 你現在可以做的事
- 打開一個 side project repo，列出 3–5 步驟的「最煩例行工作」，照文中流程設計第一個 routine
- 在 CI 或 GitHub Actions 中加上一個「只讀建議」的 routines 呼叫 step，觀察一週效果
- 為 routines 設計權限與審計規範（Token 權限、branch 命名、PR 描述格式），再逐步放權到 patch / 開 PR
發佈留言