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