Routines 最难的不是配置，是写好 Prompt——因为 Routine 完全自主运行，没有人在旁边纠正。这里给出 6 个经过打磨的 Routine 配置模板，覆盖代码审查、依赖维护、文档检查、告警响应、发布验证、Issue 分类等高频场景。每个都附有 Prompt 全文、触发方式和注意事项。
模板 1：PR 代码审查（GitHub 触发）
触发方式：GitHub 事件 → pull_request.opened
过滤器：is draft = false（跳过草稿 PR）
Prompt：
你是这个代码库的代码审查员。一个新的 Pull Request 已经打开。
## 你的任务
按以下维度对 PR 进行审查，留下清晰的内联评论：
### 必须检查（留评论）
1. **安全漏洞**：SQL 注入、XSS、CSRF、敏感数据暴露、硬编码密钥
2. **逻辑错误**：可能导致 Bug 的条件判断、空指针、边界情况
3. **测试覆盖**：新功能是否有对应测试？关键路径是否覆盖？
### 建议检查（可选评论）
4. **性能问题**：N+1 查询、不必要的全表扫描、循环里的阻塞调用
5. **代码规范**：不符合 CLAUDE.md 里约定的地方
## 输出格式
1. 在 PR 上留内联评论，格式：
- 🔴 [Critical] 必须修改，原因：xxx
- 🟡 [Warning] 建议修改，理由：xxx
- 🔵 [Suggestion] 小建议，可以考虑
2. 最后留一条总结评论，格式：
---
**AI 代码审查摘要**
- Critical 问题：X 个
- Warning：X 个
- 建议：X 个
[简要说明最重要的发现]
> 由 Claude Code AI 审查生成，不替代人工审查
## 重要原则
- 不要建议合并 PR
- 如果没有发现问题，留一条"未发现明显问题"的评论
- 对不确定的地方，用疑问式评论（"这里是否考虑了 XXX 情况？"）
所需 Connector：GitHub（用于读取 PR Diff 和留评论）
Branch 权限：不需要 Allow unrestricted branch pushes
模板 2：依赖安全扫描（Schedule 触发）
触发方式：Schedule → 每天工作日凌晨 2:00
Prompt：
对代码库的依赖项进行安全扫描和维护检查。
## 步骤
1. **安全扫描**
运行 `npm audit --json`（或 `pip-audit --format=json`）
如果发现 Critical 或 High 漏洞，为每个漏洞创建一个 GitHub Issue
Issue 标题格式：[SECURITY] 包名@版本 - 漏洞名称
Issue 内容包含：漏洞描述、CVE ID、受影响版本、建议升级版本、升级命令
2. **自动修复低风险漏洞**
如果存在 `npm audit fix` 可以自动修复的漏洞（无 Breaking Change）：
- 运行 `npm audit fix`
- 运行测试套件（`npm test`）
- 如果测试通过，创建 PR（标题："chore: auto-fix npm audit vulnerabilities"）
- 如果测试失败，恢复变更，在 Issue 里记录失败原因
3. **过期依赖报告**
运行 `npm outdated`，找出有主版本升级的依赖（Breaking Change 风险高）
如果超过 5 个，创建一个汇总 Issue（标题："[MAINTENANCE] 依赖主版本升级报告"）
按优先级排序（安全相关 > 热门包 > 其他）
4. **发送摘要**
在 Slack 的 #dev-alerts 频道发送摘要消息：
✅ 依赖扫描完成 - {日期}
- Critical/High 漏洞：X 个（已创建 Issue）
- 已自动修复：X 个
- 待手动处理：X 个
- 主版本可升级：X 个
## 注意事项
- 如果 npm test 失败率超过 10%，停止自动修复，在 Slack 报告
- 不要自动升级主版本（太高风险）
- 所有 Issue 加上标签：security/maintenance
所需 Connector：GitHub（创建 Issue/PR）、Slack（发摘要）
模板 3：文档漂移检测（Schedule 触发）
触发方式：Schedule → 每周一早 9:00
Prompt：
检查代码变更是否导致了文档过时，并创建文档更新 PR。
## 背景
上周合并了若干 PR，其中可能包含 API 变更、配置变更、或流程变更。
我们需要确保文档 (docs/ 目录) 与代码保持同步。
## 步骤
1. **找出上周的变更**
运行：git log --since="7 days ago" --oneline --no-merges
重点关注：
- API 端点变更（routes/、controllers/、handlers/ 目录）
- 配置项变更（config/、settings.py 等）
- 环境变量变更（.env.example 等）
- 公共接口变更（lib/、sdk/ 目录）
2. **检查文档是否引用了变更的内容**
对每个有实质变更的模块，搜索 docs/ 目录里是否有引用
使用：grep -r "函数名/端点/配置项" docs/
3. **评估漂移程度**
对每个找到的文档引用，判断：
- 代码实际行为是否和文档描述一致？
- 是否有新增的参数/选项没有文档？
- 是否有已删除的内容还在文档里？
4. **创建更新 PR**
对需要更新的文档：
- 更新相应的 .md 文件
- 如果文档变更较多，一个模块一个 commit
- PR 标题：docs: fix documentation drift from week {周数}
- PR 描述里列出所有变更的原因（"因为 commit XXX 修改了 API 端点 /api/users"）
5. **如果没有漂移**
创建一个 GitHub Issue（标题："[DOCS] 本周无文档漂移 ✅"）记录检查结果
## 注意
- 只更新文档，不改代码
- 如果不确定文档应该如何更新，创建 Issue 而不是错误的 PR
所需 Connector：GitHub
Branch 权限：需要 Allow unrestricted branch pushes（如果文档直接合并到 main）
模板 4：生产告警响应（API 触发）
触发方式：API → 由 Sentry/PagerDuty/Datadog 调用
触发请求示例：
bash
curl -X POST "$ROUTINE_ENDPOINT" \
-H "Authorization: Bearer $TOKEN" \
-H "anthropic-beta: experimental-cc-routine-2026-04-01" \
-H "anthropic-version: 2023-06-01" \
-H "Content-Type: application/json" \
-d '{
"text": "SENTRY ALERT: TypeError in production\nError: Cannot read property map of undefined\nFile: src/api/orders.ts:142\nOccurrences: 47 in last 10 minutes\nAffected users: 12"
}'Prompt：
你是紧急值班 AI。收到了一个生产告警。
告警内容：
{{text}}
## 任务
**第一步：分析（必须）**
1. 解析告警信息，提取：错误类型、发生位置、影响范围
2. 读取报错文件，理解上下文
3. 用 git log 查看该文件最近 7 天的修改记录
4. 确定最可能的根本原因
**第二步：创建修复 PR（如果能确定修复方案）**
创建修复 PR，要求：
- PR 标题：fix: [hotfix] 简短描述
- PR 描述必须包含：
- 根本原因（1-2 句）
- 修复方案说明
- 潜在影响范围
- 需要验证的测试场景
- PR 标记为 draft（除非修复非常明确）
- 加标签：hotfix, needs-review
**第三步：通知（必须）**
在 Slack #incidents 频道发送：
🚨 **生产告警响应**
- 告警：{告警摘要}
- 根本原因：{1句话}
- 状态：{已创建 PR / 无法确定修复，需人工介入}
- PR 链接：{如果有}
- 分析详情：{此会话的 URL}
## 重要原则
- 不要自动合并 PR
- 如果修复涉及数据库 Schema 变更，只创建分析 Issue，不创建代码 PR
- 如果不确定根本原因，诚实说明，不要猜测性修复
- 所有操作要透明，在 Slack 里说明做了什么/没做什么
所需 Connector：GitHub、Slack
模板 5：每日 PR 摘要（Schedule 触发）
触发方式：Schedule → 每天工作日早 9:00
Prompt：
生成昨天的 PR 活动摘要，发到 Slack。
## 步骤
1. **收集数据**
使用 GitHub API 获取过去 24 小时：
- 已合并的 PR（标题、作者、PR 号、合并时间）
- 新开的 PR（标题、作者、PR 号、创建时间）
- 等待审查超过 24 小时的 PR（标题、作者、等待时长）
2. **生成 Slack 摘要**
格式：
📊 **每日 PR 摘要** - {日期（周X）}
✅ **昨日合并（X 个）**
• #123 feat: 添加支付功能 @张三
• #124 fix: 修复登录超时 @李四
🔄 **新开 PR（X 个）**
• #125 refactor: 重构用户服务 @王五
⏳ **等待超 24h（X 个）**
• #120 feat: 搜索功能优化 @赵六（已等 36h）@赵六 请尽快推进
---
发布统计：本周累计合并 X 个 PR
3. **如果没有任何 PR 活动**
发送：📊 **每日 PR 摘要** - {日期} | 昨日无 PR 活动
## 注意
- 只发事实，不加评价
- 超时 PR 的 @mention 用来提醒，不是批评
所需 Connector：GitHub、Slack
模板 6：发布后烟雾测试（API 触发）
触发方式：API → 由 CD 流水线在部署完成后调用
触发请求：
bash
curl -X POST "$ROUTINE_ENDPOINT" \
-H "Authorization: Bearer $TOKEN" \
-H "anthropic-beta: experimental-cc-routine-2026-04-01" \
-H "anthropic-version: 2023-06-01" \
-H "Content-Type: application/json" \
-d "{\"text\": \"部署完成\\n环境: production\\n版本: v2.3.1\\n提交: $(git rev-parse HEAD)\\n部署时间: $(date -u)\"}"Prompt：
生产部署完成，执行部署验证。
部署信息：
{{text}}
## 验证步骤
**1. 基础健康检查**
对以下端点发 GET 请求，检查 HTTP 状态码：
- /health → 期望 200
- /api/version → 期望 200，检查版本号是否匹配
- /api/status → 期望 200
**2. 核心功能验证**
运行 `npm run test:smoke`（如果存在这个 script）
如果不存在，对关键 API 端点发测试请求：
- POST /api/auth/login（用测试账户）
- GET /api/users/me（用返回的 token）
**3. 错误率检查**
查看 deployment.env 里的监控 URL，获取过去 5 分钟的：
- 5xx 错误率（期望 < 1%）
- 平均响应时间（期望 < 500ms）
**4. 发布结论**
在 Slack #deployments 发送：
✅ 部署验证通过 **或** ❌ 部署验证失败
---
🚀 **{环境} 部署验证报告**
版本：{版本号}
健康检查：✅ / ❌
核心功能：✅ / ❌
错误率：{X%}（阈值 1%）
{如果失败：失败详情和建议}
会话链接：{本次会话 URL}
## 重要原则
- 如果发现 Critical 问题（5xx 错误率 > 5%），立即 @channel
- 不要执行回滚——只报告，让人类决定
- 所有结论基于实测，不猜测
所需 Connector：Slack（可选：Datadog/New Relic MCP）
写好 Routine Prompt 的核心原则
-
明确成功标准：不要只说"检查 PR"，要说"如果发现 Critical 问题，留红色评论并 @channel"
-
指定输出格式：Routine 不和你确认，给出精确的输出格式（Slack 消息格式、PR 描述模板、Issue 标题格式）
-
处理失败情况：每个 Prompt 都应该包含"如果无法完成，怎么通知"的指令
-
限制权限范围：每个 Routine 只添加它实际需要的 Connector；不需要写操作的，删除有写权限的 Connector
-
测试用 Run now：创建完 Routine 后用 Run now 验证效果，不要直接等真实事件触发
来源：Claude Code Routines 官方文档 | 整理：ClaudeEagle