企业官网建设流程全解析

1. 从“盯着它干活”到“关电脑它还在跑”：Claude Code Routines 到底解决了什么

Claude Code 这个工具，用过的人大概都有同一个感受：它确实能写代码、能改 bug、能跑测试，但前提是你得坐在终端前面，一句一句地跟它对话。你输入指令，它执行；你关掉终端，它就停了。本质上，它还是一个“你在场才动”的交互式工具。

Routines 改变的就是这个前提。它把一整套工作打包成一个可以自动触发的“任务包”，里面包含三样东西：一段指令（prompt）、一个代码仓库、一组连接器（比如 GitHub、Slack、Linear、Google Drive）。然后你给它设一个触发条件——定时触发、API 触发、或者 GitHub 事件触发。设好之后，你关电脑、断网、睡觉，它在云端服务器上继续跑。

我第一次看到这个机制的时候，脑子里冒出来的类比是扫地机器人。扫地机器人改变家务，不是因为它比你扫得干净，而是因为你不用在场。你上班，它扫地；你睡觉，它充电。Routines 做的是同一件事，只不过场景从“扫地”换成了“代码维护”。

具体到 PR 场景，这个变化尤其明显。以前有人提了一个 PR，你得手动去看改动、跑测试、写 review 意见。现在你可以设一个 GitHub 事件触发的 Routine：有人提 PR，它自动读 diff、跑测试、生成 review 评论。整个过程不需要你打开电脑。

这篇文章会拆解 Routines 的自动化机制，给出可复制的配置片段，说明如何通过 TaoToken 统一 Key 和 API 通道接入，最后用实际请求验证整个流程能不能跑通。如果你正在用 Claude Code 做日常开发，或者想搞清楚“AI 值夜班”这件事到底怎么落地，下面的内容可以直接跟着操作。

2. 前置准备：用 TaoToken 统一 Key 和 API 通道接入 Claude Code

在配置 Routines 之前，需要先把 Claude Code 的 API 通道准备好。这里我用 TaoToken 来做统一接入，原因是它把 Key 管理、模型调用、额度查看放在了一个控制台里，配置一次之后，后面写 Routine 的时候不用再反复换 Key。

2.1 获取 API Key 和 Base URL

打开 TaoToken 官网（https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite），注册或登录之后，进入控制台的 API Keys 页面。路径是：

https://taotoken.net/console/api-keys

在这个页面创建一个新的 API Key，复制出来。注意 Key 只在创建时显示一次，建议先存到密码管理器里。

Base URL 统一用：

https://taotoken.net/api

这个地址不加任何 UTM 参数，直接作为 Claude Code 的 API 端点使用。

2.2 配置 Claude Code 的 settings 文件

Claude Code 的配置通常放在用户目录下的.claude/settings.json。如果你用的是项目级配置，也可以放在项目根目录的.claude/settings.json。我建议先用用户级配置，这样所有项目都能复用。

文件路径（macOS/Linux）：

~/.claude/settings.json

Windows 下对应：

C:\Users\你的用户名\.claude\settings.json

配置内容如下，把sk-开头的 Key 替换成你刚才创建的那个：

{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_API_KEY": "sk-你的TaoToken密钥", "ANTHROPIC_MODEL": "claude-sonnet-4-20250514" } }

这里三个字段分别对应 Base URL、Key、Model ID。Model ID 可以根据你实际需要换成其他可用模型，但建议先用一个稳定的版本跑通流程。

2.3 验证 Claude Code 能正常调用

配置写完之后，打开终端，进入任意一个 git 仓库目录，运行：

claude --version

确认 Claude Code 已经安装。然后运行一个最简单的对话测试：

claude -p "用一句话说明这个仓库是做什么的"

如果返回了正常的文本结果，说明 Base URL 和 Key 都配置成功了。如果报 401，说明 Key 有问题；如果报连接超时，检查 Base URL 是否写成了https://taotoken.net/api而不是其他路径。

这一步跑通之后，Routines 的 API 通道就算准备好了。接下来进入实际配置环节。

3. 可复制的 Routines 配置：PR 自动 review 的完整片段

Routines 的配置方式有三种：网页端、命令行、桌面客户端。这里我用命令行方式来做，因为配置片段可以直接复制到项目里，方便版本管理。

3.1 Routine 配置文件的结构

一个 Routine 本质上是一个 JSON 或 TOML 描述文件，包含触发条件、执行指令、仓库信息和连接器。Claude Code 的命令行工具会读取这个文件，然后把它注册到云端。

我建议在项目根目录建一个.claude/routines/目录，里面放具体的 Routine 文件。比如：

项目根目录/ .claude/ routines/ pr-review.json

3.2 PR 自动 review 的 JSON 配置

下面是一个完整的 PR review Routine 配置，可以直接复制修改：

{ "name": "pr-auto-review", "description": "当有新的 PR 提交时，自动读取 diff、跑测试、生成 review 意见", "trigger": { "type": "github_event", "event": "pull_request", "actions": ["opened", "synchronize"], "repository": "your-org/your-repo" }, "prompt": "你是一个代码审查助手。请完成以下步骤：\n1. 读取当前 PR 的完整 diff；\n2. 检查是否有明显的逻辑错误、边界条件遗漏、安全问题；\n3. 运行仓库中的测试命令（如果存在 package.json 则运行 npm test，如果存在 Makefile 则运行 make test）；\n4. 根据测试结果和代码改动，生成一段结构化的 review 意见，包含：改动概述、潜在问题、测试结果、建议修改点；\n5. 将 review 意见以评论形式提交到该 PR。", "connectors": [ { "type": "github", "repository": "your-org/your-repo" } ], "model": "claude-sonnet-4-20250514", "max_tokens": 8192 }

几个关键字段说明：

trigger.type设为github_event，表示由 GitHub 事件触发。event设为pull_request，actions包含opened和synchronize，意思是 PR 新开或者有新提交时都会触发。

prompt是核心指令，我把它写成了分步骤的形式，这样 Routine 执行的时候不容易漏掉环节。你可以根据自己的仓库情况调整测试命令。

connectors里声明了 GitHub 连接器，需要提前在 TaoToken 控制台或者 Claude Code 的授权页面完成 GitHub 授权。

3.3 注册 Routine 并确认状态

配置文件写好后，在项目根目录运行：

claude routines register .claude/routines/pr-review.json

如果注册成功，会返回一个 routine ID。你可以用下面的命令查看当前所有已注册的 Routine：

claude routines list

输出里应该能看到pr-auto-review的状态是active。如果状态是pending，说明连接器授权还没完成，需要去控制台补授权。

3.4 定时触发的配置变体

如果你不想用 GitHub 事件触发，也可以改成定时触发。比如每天凌晨 3 点跑一次依赖巡检：

{ "name": "dependency-check", "description": "每天凌晨检查依赖安全漏洞并尝试升级", "trigger": { "type": "schedule", "cron": "0 3 * * *" }, "prompt": "检查当前仓库的依赖列表，对比已知安全漏洞数据库，如果有高危漏洞，尝试升级到安全版本并运行测试。如果测试通过，提交一个 PR；如果测试失败，生成一份报告。", "connectors": [ { "type": "github", "repository": "your-org/your-repo" } ], "model": "claude-sonnet-4-20250514" }

cron字段用的是标准 cron 表达式，0 3 * * *表示每天凌晨 3 点执行。这个配置适合做那种“不需要人盯着、定期跑一次”的任务。

4. 验证请求与成功结果：确认 Routine 真的在跑

配置注册好之后，不能只看状态是 active 就完事，得实际触发一次，确认整个链路是通的。

4.1 手动触发一次 Routine

Claude Code 提供了手动触发命令，方便调试：

claude routines trigger pr-auto-review

这个命令会立即执行一次 Routine，不管触发条件是否满足。执行过程中，终端会输出日志，包括它读取了哪些文件、跑了什么命令、生成了什么结果。

如果一切正常，你会在输出里看到类似这样的内容：

[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 38s

4.2 在 GitHub 上确认 review 评论

触发完成之后，打开对应的 PR 页面，应该能看到一条新的评论，内容是 Routine 生成的 review 意见。评论通常会包含改动概述、测试结果、潜在问题几个部分。

如果 PR 页面没有出现评论，先检查 GitHub 连接器的授权是否包含了repo权限。权限不够的话，Routine 能读到 diff，但没法写评论。

4.3 用 API 触发验证

除了手动触发，也可以用 API 方式触发，模拟外部系统调用：

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}}'

返回结果里会有一个run_id，可以用它查询执行状态：

curl https://taotoken.net/api/routines/runs/run_id \ -H "Authorization: Bearer sk-你的TaoToken密钥"

如果返回的status是completed，说明整个流程跑通了。如果返回failed，看error字段里的具体信息，通常是测试命令失败或者连接器权限问题。

4.4 查看执行日志和消耗

TaoToken 控制台里可以查看每次 Routine 执行的详细日志和 token 消耗。路径是：

https://taotoken.net/console

在控制台的调用记录页面，能看到每次 Routine 触发的模型调用、输入输出 token 数、耗时。这个对于排查问题和估算成本很有用。

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 的状态是 active，没有过期。

如果以上都没问题，重新生成一个 Key 再试一次。

5.2 local proxy failed

报错信息：

Error: local proxy failed: connection refused

这个报错通常出现在你本地设置了代理，但代理服务没有启动或者端口不对。Claude Code 会读取环境变量里的HTTP_PROXY和HTTPS_PROXY，如果这两个变量指向了一个不可用的地址，就会报这个错。

解决方法：检查环境变量，把不需要的代理设置清掉。

unset HTTP_PROXY unset HTTPS_PROXY

然后重新运行命令。如果你确实需要通过代理访问，确认代理服务已经启动，端口和地址写对了。

5.3 reading choices 相关报错

报错信息：

Error: reading choices: unexpected end of JSON input

这个报错一般出现在模型返回的响应格式不符合预期的时候。常见原因是 Model ID 写错了，或者请求参数里max_tokens设得太小，导致响应被截断。

检查settings.json里的ANTHROPIC_MODEL字段，确认写的是有效的模型 ID。然后检查 Routine 配置里的max_tokens，PR review 这种任务建议至少设 4096，复杂仓库设 8192。

如果还是报错，把max_tokens临时调大，然后重新触发一次，看是否恢复正常。

5.4 OAuth 授权失败

报错信息：

Error: OAuth authorization failed: invalid redirect_uri

这个报错出现在配置 GitHub 连接器的时候。原因是你在 GitHub 上创建 OAuth App 时填的回调地址和 Claude Code 实际使用的不一致。

解决方法：去 GitHub 的 Settings -> Developer settings -> OAuth Apps，找到你创建的那个 App，把 Authorization callback URL 改成 Claude Code 提示的地址。通常格式是：

https://taotoken.net/api/oauth/callback

改完之后，重新执行连接器授权命令：

claude connectors authorize github

按照提示完成授权流程。

5.5 Routine 注册成功但从不触发

如果claude routines list显示状态是 active，但 GitHub 上提了 PR 之后没有任何反应，先检查触发条件里的repository字段是否和实际仓库的org/repo格式完全一致。大小写敏感，写错了就不会触发。

然后检查 GitHub 连接器的授权范围，确认包含了repo和pull_request权限。权限不够的话，事件推送会被 GitHub 拒绝。

最后检查 Routine 的触发日志：

claude routines logs pr-auto-review

日志里会显示最近几次触发尝试和结果，根据具体报错再定位。

6. 把夜间自动化跑起来：从配置到持续运行

Routines 这个机制真正有意思的地方，不是它能让 AI 写代码，而是它把“人在场”这个前提去掉了。你设好规则，它在云端跑，你关电脑它还在跑。这个变化对于 PR review、依赖巡检、issue 分诊这类重复性工作来说，省下来的不是几分钟，而是“必须有人盯着”这件事本身。

如果你打算长期用这个流程，有几个实际操作上的建议。

第一，先用一个低风险的仓库试。不要一上来就在核心生产仓库上开自动 review，先找一个个人项目或者内部工具仓库，跑几天看看生成的 review 质量怎么样，再决定要不要扩大到主仓库。

第二，Routine 的 prompt 要写得足够具体。我试过把 prompt 写得太泛，结果它生成的 review 意见也很泛，没什么参考价值。后来改成分步骤、带具体检查项的形式，输出质量明显提升。

第三，定期看 TaoToken 控制台里的调用记录。Routines 跑起来之后，token 消耗是持续发生的，尤其是定时触发的任务。控制台里能看到每次执行的消耗明细，方便你估算成本、调整触发频率。

第四，把 Routine 配置文件纳入版本管理。.claude/routines/目录直接提交到仓库里，这样团队成员可以复用同一套配置，改了什么也有记录可查。

整个流程跑通之后，你晚上关电脑，第二天早上打开 GitHub，看到的是已经生成好的 review 评论、已经跑完的测试结果、已经分好类的 issue 列表。这件事本身不复杂，但它是“AI 从对话工具变成自动化工具”的一个具体落地。