Claude Code 已经是不少开发者的日常搭档——在终端里提问、让它改代码、跑测试,来回几轮就把活干完了。但每次都得人坐在屏幕前敲指令,效率天花板很明显。Anthropic 最新推出的 Routines 功能,正是要打破这个限制:把重复性的编码工作流配置成可自动触发的任务,按时间表跑、被 API 调用跑、或者因为外部事件跑,人不用盯着。
Routines 解决了什么问题
日常开发里有大量"固定套路":每天早上拉主分支跑一遍 lint 和测试、PR 提交后自动生成变更摘要、监控告警时自动排查相关日志并给出修复建议。这些套路步骤确定、上下文可预期,但每次都要人手动开 Claude Code 对话、描述意图、等结果——本质上是在重复下达同一套指令。
Routines 把这套指令固化下来,配上触发条件,Claude Code 就能在无人值守的情况下自己执行。对团队来说,这意味着 AI 编码助手从"随叫随到"升级到"主动值班"。
三种触发方式
Routines 目前支持三种触发模式,覆盖了最常见的自动化场景:
定时调度(Scheduled)——类似 cron,适合周期性任务。比如每天凌晨自动扫描依赖安全漏洞并生成报告。
API 调用触发(On-demand)——通过 HTTP 请求启动一个 Routine,适合集成到现有 CI/CD 或内部工具链。比如 GitHub Actions 跑完测试后,调 API 让 Claude Code 自动审查失败用例并输出分析。
外部事件响应(Event-driven)——对接 webhook 或消息队列,当特定事件发生时自动启动。比如 Sentry 收到异常告警,推一个事件给 Routine,Claude Code 立刻去翻相关代码和日志,输出初步诊断。
三种模式可以组合使用。一个"每日健康检查"的 Routine 可以是定时调度,同时允许手动 API 调用——方便你在部署后立刻跑一遍。
实际配置示例
下面用一个具体场景演示:项目每天早上 9 点自动跑测试、扫描依赖漏洞、生成摘要报告,同时允许 CI 管道通过 API 手动触发。
1. 创建 Routine 配置文件
在项目根目录的 .claude/ 下新建 routines.yaml:
# .claude/routines.yaml
routines:
daily-health-check:
description: "每天自动跑测试、扫描依赖漏洞、输出摘要报告"
trigger:
schedule: "0 9 * * 1-5" # 工作日早上9点(cron 格式)
api: true # 允许通过 API 手动触发
steps:
- name: run-tests
prompt: |
运行项目全部测试(使用 pytest),收集失败用例列表。
如果全部通过,输出 "All tests passed"。
如果有失败,列出每个失败用例的文件路径、测试名和错误摘要。
tool_policy:
allow: [Bash, Read] # 只允许执行命令和读文件
deny: [Write, Edit] # 不允许改代码——这是检查,不是修复
- name: scan-dependencies
prompt: |
用 pip-audit 或 npm audit 扫描项目依赖的安全漏洞。
输出漏洞等级、受影响包名、建议修复版本。
tool_policy:
allow: [Bash, Read]
deny: [Write, Edit]
- name: generate-report
prompt: |
把前两步的结果合并成一份 Markdown 摘要报告,
包含:测试结果、漏洞扫描结果、建议操作项。
将报告写入 .claude/reports/daily-health-{date}.md
tool_policy:
allow: [Bash, Read, Write]
deny: [Edit] # 可以新建文件,但不改已有源码
output:
format: markdown
notify:
slack_channel: "#dev-health"
说明:上面的 YAML 结构是基于 Routine 功能的合理推演,具体字段名和格式以 Anthropic 官方文档为准。核心思路——把 prompt、工具权限、触发条件声明式地写在一个配置里——是 Routines 的设计方向。
2. 注册并启用 Routine
# 在项目目录下,用 Claude Code CLI 注册 Routine
claude routine register --file .claude/routines.yaml
# 查看已注册的 Routine 列表
claude routine list
# 手动触发一次(测试配置是否正确)
claude routine run daily-health-check
3. 从 CI 管道通过 API 触发
GitHub Actions 里加一步,部署完成后主动跑一遍健康检查:
# .github/workflows/deploy.yml(追加步骤)
name: Deploy
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Deploy application
run: ./deploy.sh
- name: Trigger Claude Code health check
env:
CLAUDE_API_KEY: ${{ secrets.CLAUDE_API_KEY }}
run: |
curl -X POST "https://api.anthropic.com/v1/routines/run" \
-H "Authorization: Bearer $CLAUDE_API_KEY" \
-H "Content-Type: application/json" \
-d '{"routine_name": "daily-health-check", "context": {"trigger": "post-deploy", "commit": "${{ github.sha }}"}}'
CLAUDE_API_KEY需要在仓库 Settings → Secrets 中配置。API endpoint 和请求体格式以官方发布为准。
4. 外部事件触发:Sentry 告警联动
用一个小脚本接收 Sentry webhook,再调 Routine API:
# webhook_handler.py — 接收 Sentry 告警,触发 Claude Code 排查 Routine
from flask import Flask, request
import requests, os
app = Flask(__name__)
CLAUDE_API_KEY = os.environ["CLAUDE_API_KEY"]
@app.route("/sentry-alert", methods=["POST"])
def handle_sentry_alert():
alert = request.json
# 从告警中提取关键信息
project = alert.get("project", "unknown")
error_title = alert.get("title", "unknown error")
environment = alert.get("environment", "production")
# 触发 Claude Code 的 incident-diagnosis Routine
resp = requests.post(
"https://api.anthropic.com/v1/routines/run",
headers={
"Authorization": f"Bearer {CLAUDE_API_KEY}",
"Content-Type": "application/json",
},
json={
"routine_name": "incident-diagnosis",
"context": {
"trigger": "sentry-alert",
"project": project,
"error_title": error_title,
"environment": environment,
},
},
timeout=30,
)
return {"status": "triggered", "routine_run_id": resp.json().get("run_id")}, 200
if __name__ == "__main__":
app.run(port=5000)
# 本地测试 webhook 处理
pip install flask requests
python webhook_handler.py
# 然后用 curl 模拟 Sentry 推送
curl -X POST http://localhost:5000/sentry-alert \
-H "Content-Type: application/json" \
-d '{"project":"my-api","title":"NullPointer in UserService","environment":"production"}'
工具权限与安全边界
Routine 配置里的 tool_policy 是关键安全机制。上面示例中,检查类步骤只允许 Bash 和 Read,明确禁止 Write 和 Edit——确保自动任务不会在你睡觉时悄悄改了代码。只有最终写报告的步骤才开放 Write,且限定写入 .claude/reports/ 目录。
实际落地时建议遵循几条原则:
- 只读优先:绝大多数自动 Routine 应以只读为主,输出报告或建议,不直接改源码。
- 写操作需审批:如果某个 Routine 确实要改代码(比如自动修 lint 错误),应配置为创建 PR 而非直接 push,让人做最终审核。
- 上下文隔离:每个 Routine 应限定工作目录和可访问路径,避免越界操作其他项目文件。
上手建议
| 场景 | 推荐触发方式 | 风险等级 |
|---|---|---|
| 每日依赖漏洞扫描 | 定时调度 | 低(只读) |
| PR 变更摘要生成 | API 触发(CI 调用) | 低(只读) |
| 告警自动诊断 | 事件触发 | 低(只读) |
| 自动修 lint/style 错误 | API 触发 | 中(写操作,建议走 PR) |
| 自动重构迁移 | 手动 API | 高(大规模写操作,需人工复核) |
先从低风险的只读 Routine 开始——日报、扫描、诊断——跑稳了再逐步开放写权限。Routines 的价值不是让 AI 替你做所有决定,而是把那些你已经反复验证过的操作序列交给机器去准时执行,把注意力留给真正需要判断的工作。