Claude Code routines 实战：让云端替你值夜班，本地接手收尾

你有没有这种瞬间：

依赖更新要跑一堆测试，你不想盯着进度条。
每天固定整理 issue、生成日报，做多了人会麻。
PR 一合并就得做构建、检查、发包，偏偏你下班了。

routines 就是干这个的。

它把 Claude Code 的一次“完整会话” 放到了云端。你把「提示词 + 仓库 + 环境 + 连接器」打包成一个任务。电脑关着也能跑。跑完还可以把结果带回本地，你上班打开电脑接着聊、接着改，特别顺手。😌

routines 到底是什么？一句话讲明白

把它理解成：云端自动拉起一个 Claude Code 会话。

这个会话里能干的事，基本跟你本地用 Claude Code 差不多：

能跑 shell（构建、测试、格式化、脚本都行）
能用仓库里的 skills / 工具链
能连外部服务（前提是你配置了连接器/凭证）
能响应触发器：定时、HTTP 调用、GitHub 事件

它适合的工作有个共同点：目标清晰、步骤固定、允许无人看管。

一张“工作方式”脑图：云端跑，白天接

把流程想成这样：

触发器响了（凌晨 3 点 / 有人 push / 你打了个 API）
云端拉起：代码仓库 + 环境 + 你的提示词
Claude Code 开干：跑命令、改文件、发评论、调用服务
输出结果：日志、产物、PR/issue 更新、或可继续的会话上下文
你到公司：在本地把这次会话“接上”，继续推进

这个“接上”很关键。

很多自动化工具只会吐一堆日志给你看，看完还是得手动重做。routines 更像是：云端先把脏活干了，你来做决策和收尾。

开搞前的准备清单（照着勾就行）✅

你要把 routine 当成一个“可重复的产品”来配。

仓库：选定要操作的 repo（最好是能自动化测试的）
环境：需要什么 runtime？node/python/docker？依赖怎么装？
提示词：写清楚目标、边界、输出格式（别指望它读心）
连接器：要不要连 GitHub、Slack、邮件、数据库、云存储等
凭证/密钥：用密钥管理，别写进仓库、别塞进提示词
触发器：
- 定时（按小时/每天/工作日）
- HTTP API（你手动/系统触发）
- GitHub 事件（PR/push/issue/workflow）

提醒一句：

routine 触发一次，就会在云端开一个完整会话。

所以别把它写成“无限循环的机器人”，会很吓人，也很烧钱。

关键：提示词怎么写才像“自动任务”而不是聊天

聊天提示词常犯的错：太散、太虚、没验收标准。

建议你直接按这个骨架写：

你是谁：这次会话扮演什么角色（CI 维护者/仓库管理员/值班同事）
输入是什么：仓库分支、要看的目录、相关链接
你要做什么：步骤列表（可以短，但要明确）
禁止做什么：别动哪些目录、别改哪些配置、别发外部请求
输出什么：
- 写到哪里（PR、issue comment、某个文件、构建产物）
- 输出格式（markdown 表格 / JSON / 变更摘要）
失败怎么办：遇到错误要停住并汇报，不要硬编

你把“验收标准”写死，routine 才会像一个靠谱的值班同事。

3 个高频场景：你今天就能用上

下面用“配置长什么样”的方式讲。不同团队实现细节可能不一样，但结构就这几块：触发器、环境、权限、动作、输出。

场景 1：每天凌晨跑依赖更新 + 测试，自动开 PR

适合：前端/后端依赖多、更新频繁、人工升级烦。

你期望它做的事：

拉最新依赖
跑单测/构建
通过才开 PR，并写清影响范围
失败就把错误贴出来

示例（伪配置，重点看结构）：

name: nightly-deps-bump
trigger:
  cron: "0 3 * * *"
repo:
  url: your-org/your-repo
  branch: main
env:
  setup:
    - "install dependencies"
    - "prepare test runtime"
actions:
  - run: "update dependencies"
  - run: "run tests"
  - if_success:
      create_pr:
        title: "chore: bump dependencies"
        body: "include summary + risk + test result"
  - if_fail:
      report:
        to: "issue or PR comment"
        format: "error logs + next steps"

你第二天上班看一眼 PR，就知道要不要合。省的是“盯着跑”的时间。

场景 2：GitHub 有人提 PR，就自动做代码体检并给建议

适合：你是 reviewer，但你不想当“人肉 linter”。

触发器：PR opened / synchronize（更新提交）

它可以做：

跑 lint/test
扫一遍风险点（比如改了 auth、billing、权限相关）
给出具体修改建议（带文件路径、行号、替代方案）

示例（伪配置）：

name: pr-review-assistant
trigger:
  github:
    event: pull_request
    types: [opened, synchronize]
repo:
  url: your-org/your-repo
actions:
  - run: "checkout PR branch"
  - run: "lint && test"
  - analyze:
      focus:
        - "security-sensitive changes"
        - "breaking API changes"
  - comment_to_pr:
      template: |
        ✅ Tests: {{test_status}}
        ⚠️ Risks: {{risk_list}}
        🔧 Suggestions: {{actionable_suggestions}}

注意这里的心法：它别当裁判，它当“助理”。真正的 merge 决策留给人。

场景 3：用 HTTP API 触发“一键出报告”，发到 Slack/飞书

适合：运营/产品/老板随时要数据，你不想每次都手工导。

做法：

你暴露一个受控的 HTTP 入口
外部系统（或你自己）调用它
routine 去拉数据、整理成固定模板、发消息

示例（伪配置）：

name: on-demand-report
trigger:
  http:
    path: /routines/report
    auth: required
inputs:
  - name: date_range
  - name: project
actions:
  - fetch: "metrics from service"
  - transform: "generate markdown report"
  - notify:
      channel: "slack"
      message: "{{report_markdown}}"

这种最爽：老板问“现在什么情况”，你回一句“我点一下”，就完事。🙂

云端跑完，本地怎么接着干？

routines 的价值不只是“跑完”。更实用的是“接棒”。

推荐你把输出设计成两层：

给机器的：结构化结果（JSON、固定字段、产物链接）
给人的：一段短总结（做了什么、哪里失败、下一步建议）

你到本地继续处理时，通常就几件事：

拉取它生成的分支/PR
根据总结做判断（合并/回滚/补救）
继续在本地 Claude Code 会话里追问细节、改策略

一句话：云端帮你把路铺好，你负责把车开进车库。

避坑清单：别把 routine 变成“云端翻车现场”⚠️

提示词太泛：写“优化代码”这种话没用。要写清楚改哪里、验收是什么。
权限太大：能开 PR 就别同时给生产密钥。权限按任务最小化。
把密钥写进仓库/提示词：这属于自爆。用专门的密钥管理。
没有失败策略：失败时要停住并报告，别“继续尝试直到成功”。
一次触发干太多：把任务拆小。一个 routine 解决一个问题，排错才轻松。
忽略成本：触发频率别乱开。按小时跑的任务，先算一算值不值。

进阶玩法：用“本地优先 + 云端自动化”搭你的 Agent 工作流

我建议你用这个分工：

本地：探索、试错、做决策、处理复杂交互
云端 routines：值班、跑固定流程、收集信息、生成候选方案

模型越来越能干的时候，云端能接管的任务会变多。

但别急着把所有东西都自动化。

从一条最烦的重复劳动开始，比如“每天跑测试+汇总结果”。把它做稳，你就会开始上瘾。

你现在就可以做的 10 分钟小练习

挑一个你团队每天都在重复的事。

比如：

“凌晨跑一遍主干测试，失败就把错误贴到一个固定 issue”

把提示词按上面的骨架写好。

把输出格式限定死：标题、失败原因、日志链接、建议下一步。

跑两天。

你会明显感觉：早上打开电脑时，少了一堆低价值的等待和确认。

Claude Code routines：把“提示词+仓库+环境”打包成云端自动任务，电脑关机也能跑