1. 從“盯著它干活”到“關(guān)電腦它還在跑”Claude Code Routines 到底解決了什么Claude Code 這個工具用過的人大概都有同一個感受它確實能寫代碼、能改 bug、能跑測試但前提是你得坐在終端前面一句一句地跟它對話。你輸入指令它執(zhí)行你關(guān)掉終端它就停了。本質(zhì)上它還是一個“你在場才動”的交互式工具。Routines 改變的就是這個前提。它把一整套工作打包成一個可以自動觸發(fā)的“任務(wù)包”里面包含三樣?xùn)|西一段指令prompt、一個代碼倉庫、一組連接器比如 GitHub、Slack、Linear、Google Drive。然后你給它設(shè)一個觸發(fā)條件——定時觸發(fā)、API 觸發(fā)、或者 GitHub 事件觸發(fā)。設(shè)好之后你關(guān)電腦、斷網(wǎng)、睡覺它在云端服務(wù)器上繼續(xù)跑。我第一次看到這個機制的時候腦子里冒出來的類比是掃地機器人。掃地機器人改變家務(wù)不是因為它比你掃得干凈而是因為你不用在場。你上班它掃地你睡覺它充電。Routines 做的是同一件事只不過場景從“掃地”換成了“代碼維護”。具體到 PR 場景這個變化尤其明顯。以前有人提了一個 PR你得手動去看改動、跑測試、寫 review 意見?，F(xiàn)在你可以設(shè)一個 GitHub 事件觸發(fā)的 Routine有人提 PR它自動讀 diff、跑測試、生成 review 評論。整個過程不需要你打開電腦。這篇文章會拆解 Routines 的自動化機制給出可復(fù)制的配置片段說明如何通過 TaoToken 統(tǒng)一 Key 和 API 通道接入最后用實際請求驗證整個流程能不能跑通。如果你正在用 Claude Code 做日常開發(fā)或者想搞清楚“AI 值夜班”這件事到底怎么落地下面的內(nèi)容可以直接跟著操作。2. 前置準備用 TaoToken 統(tǒng)一 Key 和 API 通道接入 Claude Code在配置 Routines 之前需要先把 Claude Code 的 API 通道準備好。這里我用 TaoToken 來做統(tǒng)一接入原因是它把 Key 管理、模型調(diào)用、額度查看放在了一個控制臺里配置一次之后后面寫 Routine 的時候不用再反復(fù)換 Key。2.1 獲取 API Key 和 Base URL打開 TaoToken 官網(wǎng)https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite注冊或登錄之后進入控制臺的 API Keys 頁面。路徑是https://taotoken.net/console/api-keys在這個頁面創(chuàng)建一個新的 API Key復(fù)制出來。注意 Key 只在創(chuàng)建時顯示一次建議先存到密碼管理器里。Base URL 統(tǒng)一用https://taotoken.net/api這個地址不加任何 UTM 參數(shù)直接作為 Claude Code 的 API 端點使用。2.2 配置 Claude Code 的 settings 文件Claude Code 的配置通常放在用戶目錄下的.claude/settings.json。如果你用的是項目級配置也可以放在項目根目錄的.claude/settings.json。我建議先用用戶級配置這樣所有項目都能復(fù)用。文件路徑macOS/Linux~/.claude/settings.jsonWindows 下對應(yīng)C:\Users\你的用戶名\.claude\settings.json配置內(nèi)容如下把sk-開頭的 Key 替換成你剛才創(chuàng)建的那個{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的TaoToken密鑰, ANTHROPIC_MODEL: claude-sonnet-4-20250514 } }這里三個字段分別對應(yīng) Base URL、Key、Model ID。Model ID 可以根據(jù)你實際需要換成其他可用模型但建議先用一個穩(wěn)定的版本跑通流程。2.3 驗證 Claude Code 能正常調(diào)用配置寫完之后打開終端進入任意一個 git 倉庫目錄運行claude --version確認 Claude Code 已經(jīng)安裝。然后運行一個最簡單的對話測試claude -p 用一句話說明這個倉庫是做什么的如果返回了正常的文本結(jié)果說明 Base URL 和 Key 都配置成功了。如果報 401說明 Key 有問題如果報連接超時檢查 Base URL 是否寫成了https://taotoken.net/api而不是其他路徑。這一步跑通之后Routines 的 API 通道就算準備好了。接下來進入實際配置環(huán)節(jié)。3. 可復(fù)制的 Routines 配置PR 自動 review 的完整片段Routines 的配置方式有三種網(wǎng)頁端、命令行、桌面客戶端。這里我用命令行方式來做因為配置片段可以直接復(fù)制到項目里方便版本管理。3.1 Routine 配置文件的結(jié)構(gòu)一個 Routine 本質(zhì)上是一個 JSON 或 TOML 描述文件包含觸發(fā)條件、執(zhí)行指令、倉庫信息和連接器。Claude Code 的命令行工具會讀取這個文件然后把它注冊到云端。我建議在項目根目錄建一個.claude/routines/目錄里面放具體的 Routine 文件。比如項目根目錄/ .claude/ routines/ pr-review.json3.2 PR 自動 review 的 JSON 配置下面是一個完整的 PR review Routine 配置可以直接復(fù)制修改{ name: pr-auto-review, description: 當(dāng)有新的 PR 提交時自動讀取 diff、跑測試、生成 review 意見, trigger: { type: github_event, event: pull_request, actions: [opened, synchronize], repository: your-org/your-repo }, prompt: 你是一個代碼審查助手。請完成以下步驟\n1. 讀取當(dāng)前 PR 的完整 diff\n2. 檢查是否有明顯的邏輯錯誤、邊界條件遺漏、安全問題\n3. 運行倉庫中的測試命令如果存在 package.json 則運行 npm test如果存在 Makefile 則運行 make test\n4. 根據(jù)測試結(jié)果和代碼改動生成一段結(jié)構(gòu)化的 review 意見包含改動概述、潛在問題、測試結(jié)果、建議修改點\n5. 將 review 意見以評論形式提交到該 PR。, connectors: [ { type: github, repository: your-org/your-repo } ], model: claude-sonnet-4-20250514, max_tokens: 8192 }幾個關(guān)鍵字段說明trigger.type設(shè)為github_event表示由 GitHub 事件觸發(fā)。event設(shè)為pull_requestactions包含opened和synchronize意思是 PR 新開或者有新提交時都會觸發(fā)。prompt是核心指令我把它寫成了分步驟的形式這樣 Routine 執(zhí)行的時候不容易漏掉環(huán)節(jié)。你可以根據(jù)自己的倉庫情況調(diào)整測試命令。connectors里聲明了 GitHub 連接器需要提前在 TaoToken 控制臺或者 Claude Code 的授權(quán)頁面完成 GitHub 授權(quán)。3.3 注冊 Routine 并確認狀態(tài)配置文件寫好后在項目根目錄運行claude routines register .claude/routines/pr-review.json如果注冊成功會返回一個 routine ID。你可以用下面的命令查看當(dāng)前所有已注冊的 Routineclaude routines list輸出里應(yīng)該能看到pr-auto-review的狀態(tài)是active。如果狀態(tài)是pending說明連接器授權(quán)還沒完成需要去控制臺補授權(quán)。3.4 定時觸發(fā)的配置變體如果你不想用 GitHub 事件觸發(fā)也可以改成定時觸發(fā)。比如每天凌晨 3 點跑一次依賴巡檢{ name: dependency-check, description: 每天凌晨檢查依賴安全漏洞并嘗試升級, trigger: { type: schedule, cron: 0 3 * * * }, prompt: 檢查當(dāng)前倉庫的依賴列表對比已知安全漏洞數(shù)據(jù)庫如果有高危漏洞嘗試升級到安全版本并運行測試。如果測試通過提交一個 PR如果測試失敗生成一份報告。, connectors: [ { type: github, repository: your-org/your-repo } ], model: claude-sonnet-4-20250514 }cron字段用的是標準 cron 表達式0 3 * * *表示每天凌晨 3 點執(zhí)行。這個配置適合做那種“不需要人盯著、定期跑一次”的任務(wù)。4. 驗證請求與成功結(jié)果確認 Routine 真的在跑配置注冊好之后不能只看狀態(tài)是 active 就完事得實際觸發(fā)一次確認整個鏈路是通的。4.1 手動觸發(fā)一次 RoutineClaude Code 提供了手動觸發(fā)命令方便調(diào)試claude routines trigger pr-auto-review這個命令會立即執(zhí)行一次 Routine不管觸發(fā)條件是否滿足。執(zhí)行過程中終端會輸出日志包括它讀取了哪些文件、跑了什么命令、生成了什么結(jié)果。如果一切正常你會在輸出里看到類似這樣的內(nèi)容[info] Routine pr-auto-review triggered manually [info] Fetching PR diff for your-org/your-repo#123 [info] Running test command: npm test [info] Test result: 42 passed, 0 failed [info] Generating review comment... [info] Review comment posted to PR #123 [done] Routine completed in 38s4.2 在 GitHub 上確認 review 評論觸發(fā)完成之后打開對應(yīng)的 PR 頁面應(yīng)該能看到一條新的評論內(nèi)容是 Routine 生成的 review 意見。評論通常會包含改動概述、測試結(jié)果、潛在問題幾個部分。如果 PR 頁面沒有出現(xiàn)評論先檢查 GitHub 連接器的授權(quán)是否包含了repo權(quán)限。權(quán)限不夠的話Routine 能讀到 diff但沒法寫評論。4.3 用 API 觸發(fā)驗證除了手動觸發(fā)也可以用 API 方式觸發(fā)模擬外部系統(tǒng)調(diào)用curl -X POST https://taotoken.net/api/routines/trigger \ -H Authorization: Bearer sk-你的TaoToken密鑰 \ -H Content-Type: application/json \ -d {routine_id: pr-auto-review, payload: {pr_number: 123}}返回結(jié)果里會有一個run_id可以用它查詢執(zhí)行狀態(tài)curl https://taotoken.net/api/routines/runs/run_id \ -H Authorization: Bearer sk-你的TaoToken密鑰如果返回的status是completed說明整個流程跑通了。如果返回failed看error字段里的具體信息通常是測試命令失敗或者連接器權(quán)限問題。4.4 查看執(zhí)行日志和消耗TaoToken 控制臺里可以查看每次 Routine 執(zhí)行的詳細日志和 token 消耗。路徑是https://taotoken.net/console在控制臺的調(diào)用記錄頁面能看到每次 Routine 觸發(fā)的模型調(diào)用、輸入輸出 token 數(shù)、耗時。這個對于排查問題和估算成本很有用。5. 常見報錯排查401、local proxy failed、reading choices、OAuth配置過程中最容易踩的坑集中在幾個報錯上下面逐個說明原因和解決方法。5.1 401 Unauthorized報錯信息Error: 401 Unauthorized {error: {type: authentication_error, message: invalid api key}}原因通常是 Key 寫錯了、Key 過期了、或者 Base URL 和 Key 不匹配。檢查步驟第一確認settings.json里的ANTHROPIC_API_KEY是完整的sk-開頭字符串沒有多余空格。第二確認ANTHROPIC_BASE_URL是https://taotoken.net/api沒有多寫路徑或者少寫/api。第三去 TaoToken 控制臺的 API Keys 頁面確認這個 Key 的狀態(tài)是 active沒有過期。如果以上都沒問題重新生成一個 Key 再試一次。5.2 local proxy failed報錯信息Error: local proxy failed: connection refused這個報錯通常出現(xiàn)在你本地設(shè)置了代理但代理服務(wù)沒有啟動或者端口不對。Claude Code 會讀取環(huán)境變量里的HTTP_PROXY和HTTPS_PROXY如果這兩個變量指向了一個不可用的地址就會報這個錯。解決方法檢查環(huán)境變量把不需要的代理設(shè)置清掉。unset HTTP_PROXY unset HTTPS_PROXY然后重新運行命令。如果你確實需要通過代理訪問確認代理服務(wù)已經(jīng)啟動端口和地址寫對了。5.3 reading choices 相關(guān)報錯報錯信息Error: reading choices: unexpected end of JSON input這個報錯一般出現(xiàn)在模型返回的響應(yīng)格式不符合預(yù)期的時候。常見原因是 Model ID 寫錯了或者請求參數(shù)里max_tokens設(shè)得太小導(dǎo)致響應(yīng)被截斷。檢查settings.json里的ANTHROPIC_MODEL字段確認寫的是有效的模型 ID。然后檢查 Routine 配置里的max_tokensPR review 這種任務(wù)建議至少設(shè) 4096復(fù)雜倉庫設(shè) 8192。如果還是報錯把max_tokens臨時調(diào)大然后重新觸發(fā)一次看是否恢復(fù)正常。5.4 OAuth 授權(quán)失敗報錯信息Error: OAuth authorization failed: invalid redirect_uri這個報錯出現(xiàn)在配置 GitHub 連接器的時候。原因是你在 GitHub 上創(chuàng)建 OAuth App 時填的回調(diào)地址和 Claude Code 實際使用的不一致。解決方法去 GitHub 的 Settings - Developer settings - OAuth Apps找到你創(chuàng)建的那個 App把 Authorization callback URL 改成 Claude Code 提示的地址。通常格式是https://taotoken.net/api/oauth/callback改完之后重新執(zhí)行連接器授權(quán)命令claude connectors authorize github按照提示完成授權(quán)流程。5.5 Routine 注冊成功但從不觸發(fā)如果claude routines list顯示狀態(tài)是 active但 GitHub 上提了 PR 之后沒有任何反應(yīng)先檢查觸發(fā)條件里的repository字段是否和實際倉庫的org/repo格式完全一致。大小寫敏感寫錯了就不會觸發(fā)。然后檢查 GitHub 連接器的授權(quán)范圍確認包含了repo和pull_request權(quán)限。權(quán)限不夠的話事件推送會被 GitHub 拒絕。最后檢查 Routine 的觸發(fā)日志claude routines logs pr-auto-review日志里會顯示最近幾次觸發(fā)嘗試和結(jié)果根據(jù)具體報錯再定位。6. 把夜間自動化跑起來從配置到持續(xù)運行Routines 這個機制真正有意思的地方不是它能讓 AI 寫代碼而是它把“人在場”這個前提去掉了。你設(shè)好規(guī)則它在云端跑你關(guān)電腦它還在跑。這個變化對于 PR review、依賴巡檢、issue 分診這類重復(fù)性工作來說省下來的不是幾分鐘而是“必須有人盯著”這件事本身。如果你打算長期用這個流程有幾個實際操作上的建議。第一先用一個低風(fēng)險的倉庫試。不要一上來就在核心生產(chǎn)倉庫上開自動 review先找一個個人項目或者內(nèi)部工具倉庫跑幾天看看生成的 review 質(zhì)量怎么樣再決定要不要擴大到主倉庫。第二Routine 的 prompt 要寫得足夠具體。我試過把 prompt 寫得太泛結(jié)果它生成的 review 意見也很泛沒什么參考價值。后來改成分步驟、帶具體檢查項的形式輸出質(zhì)量明顯提升。第三定期看 TaoToken 控制臺里的調(diào)用記錄。Routines 跑起來之后token 消耗是持續(xù)發(fā)生的尤其是定時觸發(fā)的任務(wù)?？刂婆_里能看到每次執(zhí)行的消耗明細方便你估算成本、調(diào)整觸發(fā)頻率。第四把 Routine 配置文件納入版本管理。.claude/routines/目錄直接提交到倉庫里這樣團隊成員可以復(fù)用同一套配置改了什么也有記錄可查。整個流程跑通之后你晚上關(guān)電腦第二天早上打開 GitHub看到的是已經(jīng)生成好的 review 評論、已經(jīng)跑完的測試結(jié)果、已經(jīng)分好類的 issue 列表。這件事本身不復(fù)雜但它是“AI 從對話工具變成自動化工具”的一個具體落地。