Claude Code schedule 云端值班同事

写在前面

很多人对 AI 编程的理解，还停留在“我开着编辑器，它帮我补几行代码”。但 Claude Code 新出的 /schedule，已经把这件事往前推了一步：你不在线、电脑关机、终端退出，它还是会在云端按时把活干完。

这件事真正有冲击力的地方，不只是“多了一个定时任务命令”。而是 Claude Code 正在从一个你随叫随到的编程助手，慢慢变成一个可以在后台持续执行任务的 Agent。你给它一句自然语言，它自己排班、自己跑任务、自己改代码、自己同步外部服务。

如果你平时就有这些重复工作——扫昨天合并的 PR、更新文档、看 CI 状态、同步多语言 SDK、定期做依赖审计——那这个功能跟你就不是“有点意思”，而是很可能会直接改变你的工作流。

不是定时器这么简单：开发流程正在从“人盯着”变成“Agent 值班”

这篇原文里有两个细节特别值得注意。

第一，/schedule 创建的是云端任务。也就是说，这不是本地 shell 里跑个循环脚本，更不是你自己守着终端。任务跑在 Anthropic 的云基础设施上，电脑关了也照常执行。

第二，创建方式极其低门槛。你不需要自己先写 cron，也不需要搭一套 GitHub Actions 或调度平台。直接一句自然语言，告诉 Claude “做什么、多久做一次”，任务就能建起来。

原文给出的演示里，用户输入的是：

> 创建一个每日任务，让 Claude 检查昨天合并的所有 PR，根据代码变更更新文档，然后通过 Slack 把更新内容发到 #docs-update 频道。

Claude 随后返回：

> Scheduled job created, 9am on weekdays

整个过程，原文给出的描述是：也就 10 秒左右。

这意味着什么？

意味着原来很多“值得自动化，但还没值得你专门搭系统”的工作，现在第一次有了足够低的启动成本。以前你会觉得：

• 自动同步文档，值得吗？
• 自动扫 CI，值得吗？
• 自动维护另一门语言的库，值得吗？

现在问题变成了：既然一句话就能排班，那为什么还让人天天重复做？

/schedule 到底能做什么

1. 一句话创建云端定时任务

/schedule 最直接的能力，就是把自然语言需求变成一个云端执行计划。

你在 CLI 里输入 /schedule，后面接一句话描述任务目标和执行频率，Claude 就会帮你创建任务。原文里强调，这一步非常适合开发者日常的重复性工作，因为它不要求你先拆成很多配置项。

换句话说，它不像传统调度系统那样，先让你选触发器、填表达式、绑权限、接通知。Claude Code 在这里做的是更高层的抽象：你描述目标，它来补足执行细节。

2. 真正的云端执行，不依赖你的本地环境在线

这是 /schedule 和很多人熟悉的本地自动化之间最大的区别。

原文专门拿 /loop 来对比：

• /loop 是本地会话里的循环任务
• 终端一关，任务就停
• 适合临时监控或短时间轮询

而 /schedule 是跑在云端的。你关机、断网、合上电脑，它都继续执行。原文用一个很形象的说法，叫“从本地龙虾到云端龙虾”。虽然是调侃式表达，但本质上说的就是托管执行。

对开发者来说，这一点非常关键。因为只要任务跟“每天早上”“每周一次”“工作日 9 点”这种固定节奏相关，本地会话就天然不可靠。你总不可能真的 24 小时挂着终端等它跑。

3. 支持多种创建入口

原文提到，创建定时任务有三种方式：

• 在 CLI 里用 /schedule 命令
• 在 claude.ai/code/scheduled 网页上创建
• 在 Desktop 桌面端的 Schedule 页面创建

CLI 显然是最快的，因为你本来就在命令行里工作，顺手一句话就能建任务。网页和桌面端则更适合后续管理、查看和调整。

这背后的含义是：Anthropic 并不是把 /schedule 当成一个“给高手玩的隐藏命令”，而是在把它做成一个跨入口的正式能力。

4. 频率不止“每天一次”，还能走 cron 精细化调度

原文提到的频率包括：

• 每小时
• 每天
• 工作日
• 每周

此外，CLI 里还可以设置更精确的 cron 表达式。

这就很关键了。因为很多自动化工作并不是简单的“每天执行一次”能覆盖的。比如：

• 工作日上午 9 点发日报
• 每周一早上做依赖审计
• 每隔几小时检查某个仓库状态
• 在固定时区下做跨团队同步

如果没有 cron 级别的表达能力，很多任务最后还是得回退到传统调度系统。有了这一层，Claude Code 的适用范围就从“演示型功能”往真正的工程场景走了一步。

5. 执行时会自动处理仓库工作流

原文提到，每次执行时，Claude 会自动 clone 你指定的 GitHub 仓库，从默认分支开始工作，然后把修改推到带 claude/ 前缀的分支上。

这个细节很重要，因为它说明 /schedule 不是只会“看一眼然后发消息”。它是可以进入代码仓库、理解上下文、做实际修改的。

换句话说，定时任务的终点不是提醒，而是行动。

这也是为什么它更像一个值班 Agent，而不是一个 cron 包装器。传统 cron 大多只是触发脚本；而 Claude Code 在这里承担的是：

• 读取仓库状态
• 理解变更上下文
• 执行代码操作
• 产出提交结果
• 把结果发回工作流系统

6. 可以连外部服务

原文还提到，/schedule 能连接 MCP connectors，也就是把外部服务也纳入任务链路里，比如：

• Slack
• Linear
• Google Drive

这意味着一个任务不只是“改代码”，还可以贯穿整个协作流程。比如：

• 检查昨天合并的 PR
• 根据变更更新文档
• 把总结发到 Slack
• 或者发现风险后自动提 issue / 同步到项目管理工具

如果你之前用过纯代码层面的自动化，会知道真正麻烦的往往不是“执行脚本”，而是“把结果送到团队正在用的地方”。MCP connectors 把这一步补上之后，定时任务才更像完整工作流，而不是单点工具。

一个最能说明问题的案例：让 Claude 自动维护跨语言代码库

原文里最值得反复看的，其实不是产品介绍，而是 Anthropic 内部的一个实际用法。

Noah Zweben 提到，他们内部有一个定时 Claude 任务，在自动维护一个 Go 版 twin library，对应的是一个正在持续开发的 Python 库。

这句话信息量很大。

因为跨语言库同步，一直都是开发团队里特别容易拖、特别容易不一致、但又特别花人的事情。Python 侧接口变了，Go 侧要不要跟？什么时候跟？谁来跟？文档和示例要不要一起改？

以前这类工作通常有三种结局：

1. 靠人工同步，容易忘
2. 靠规则脚本，覆盖不了复杂语义变化
3. 干脆不同步，久而久之两套库越走越远

而现在 Anthropic 的做法是：让 Claude 定时检查变更，然后持续维护另一门语言的实现。

这说明 /schedule 不是只适合“发日报”“扫日志”这种外围任务，它已经开始碰真正的工程维护工作了。只要任务具备以下特征，就很适合交给这种云端 Agent：

• 周期性强
• 上下文稳定
• 有明确目标
• 需要读代码、理解变更、再输出结果

跨语言库同步，就是一个非常典型的高价值场景。

这些场景，基本都能直接套上去

原文还列了一批更接地气的例子，基本每一个都很像真实团队里已经存在、但不一定有人愿意长期做的工作。

自动修 CI

CI 挂了，Claude 每天早上自动检查失败原因，尝试修复并提 PR。

这类工作最消耗的不是技术难度，而是频繁打断。你本来正在写别的需求，突然被一个失败流水线拽过去。让 Agent 先做第一轮处理，团队的上下文切换成本会低很多。

文档同步

代码改了，文档自动更新。

这是最容易理解、也最容易落地的一类场景。因为文档经常不是不会写，而是没人记得写。只要 Claude 能定期扫合并记录和接口变化，这件事就能从“靠自觉”变成“靠系统”。

PR 日报

每天早上扫描昨天合并的 PR，生成摘要，发到 Slack。

很多团队想做知识同步，但最后不是没人写，就是写了没人看。日报之所以难，不是难在格式，而是难在稳定产出。/schedule 正好把这个缺口补上。

依赖审计

每周跑一次依赖检查，发现安全问题自动提 issue。

这种任务其实非常适合云端化，因为它天然就是周期性巡检。过去你可能得专门配 CI、再接通知链路。现在可以先用自然语言快速搭起来，再逐步收敛到更标准的流程。

代码“翻译”与多语言同步

也就是原文提到的 Anthropic 内部案例：一个库用两种语言维护，Claude 负责保持同步。

这件事之所以重要，不在于“AI 会写第二门语言”，而在于它开始承担长期维护责任。从一次性生成代码，到定期追踪上游变化并保持同步，中间差着整整一个层级。

这不是单点新功能，而是一条清晰的产品路线

原文最后一部分提到，/schedule 只是 Claude Code 三月密集更新中的一个节点。前后一起看，你会发现这条路线非常清楚。

/loop：让本地会话开始重复执行

3 月 7 日的 /loop，解决的是“当前会话里反复做一件事”。

它适合临时监控，比如每 5 分钟检查一次部署状态。但它本质上仍然依赖本地终端活着。

/remote-control：把控制权从电脑扩展到网页和手机

3 月 18 日的 /remote-control，让你能把本地 Claude Code 会话桥接到网页端，甚至手机上的 Claude App。

这一步的意义是：你不一定非得坐在电脑前，才能继续推进一个 Agent 工作流。

Channels：让外部系统主动推消息给 Claude Code

3 月 19 日的 Channels，则把 MCP 服务器从“被调用工具”往“主动推送消息源”推进了一步。也就是说，CI 挂了，不用你去问，系统可以直接把消息推到 Claude Code 会话里。

/schedule：让 Agent 脱离当前会话，开始在后台独立运转

而 /schedule 则进一步把执行时空解耦了。不是你人在这，它才工作；而是你给出任务，它在后台按计划继续跑。

把这几步连起来看，Claude Code 其实在完成一个很明显的转向：

> 从“你输入一句、它回答一句”的编程助手，变成“能持续接任务、会自己执行、还能接入团队协作系统”的自动化成员。

原文里还有几个更新点被顺带提到：

• 1M context window
• Opus 4.6 默认模型
• /effort 用来调整推理深度
• 输出 token 上限提升到 128K
• Voice Mode 语音模式

再加上一个即将上线的 Task Memory，也就是让任务拥有自己的记忆系统，能记住之前执行过什么、产生过什么结果。

这就不再只是“功能越来越多”，而是 Agent 的基础设施越来越完整。

Claude Code 到底是什么？为什么它和普通补全工具不是一回事

很多人第一次听 Claude Code，会把它理解成“另一个代码补全工具”。但它的定位其实完全不同。

像传统 Copilot 这类产品，更像是你写代码时的即时辅助：

• 帮你补一行
• 帮你补一个函数
• 帮你续写当前文件

Claude Code 则更像一个可以自主完成一段工程任务的 Agent。它能做的事情包括：

• 读整个项目里的多个文件
• 修改和新建代码
• 执行命令
• 跑测试
• 跨文件重构
• 调试报错
• 处理 Git 工作流
• 通过 MCP 连接外部系统
• 现在还能通过 /schedule 在云端定时执行

所以 /schedule 的意义，不是给聊天机器人加了个闹钟，而是给一个已经具备工程执行能力的 Agent，加上了“后台值班”的能力。

官方目前有两条常见使用路径。

一条是直接走 Claude 订阅：根据 Claude 官方价格页和 Claude Code 产品页，Pro 方案月付是 20 美元/月，年付折算 17 美元/月，已经包含 Claude Code；Max 从 100 美元/月 起，更高档位到 200 美元/月；团队版 Team 是 20 美元/席位/月。如果你是通过 API 使用，那就是另一套按 token 计费的开发者价格。

不过说实话，官方订阅对国内用户不太友好——需要海外信用卡，网络环境也得折腾。如果嫌麻烦想找个更省事的渠道，可以看看 Code80，真实订阅帐号转 API，换个 endpoint 就能直接用，体验跟官方一样。详情可以到官网了解：code.ai80.vip

常见问题

1. /schedule 和 /loop 最大区别是什么？

/loop 是本地循环任务，依赖当前终端活着；/schedule 是云端定时任务，电脑关了也会继续执行。

2. /schedule 只能发提醒，还是能真的改代码？

从原文信息看，它不只是提醒。任务执行时会 clone 指定 GitHub 仓库，从默认分支开始工作，并把修改推到 claude/ 前缀的分支上，说明它是可以实际动代码的。

3. 它适合哪些任务？

最适合周期性、重复性、目标明确的任务，比如文档同步、PR 摘要、依赖审计、CI 巡检、多语言库同步这类工作。

4. 能接 Slack、Linear、Google Drive 这些服务吗？

可以。原文提到它支持 MCP connectors，所以外部服务可以直接纳入定时任务流程里。

5. 需要什么版本才能用 /schedule？

原文明确提到：要体验 /schedule，请确保 Claude Code 版本 >= 2.1.81。

6. 国内用户怎么更方便地用上 Claude Code？

如果你已经熟悉 API 方式，国内用户可以通过 Code80 更方便地接入使用。