Claude Code 推出云端龙虾 schedule 命令让 AI 自己排班干活

写在前面

很多开发者已经习惯让 AI 帮自己写函数、补代码、改 Bug，但有一个问题一直没真正解决：你一离开电脑，AI 也跟着下班了。

CI 失败了，要等你明早打开终端再看；昨天合并的 PR，要靠人手汇总再同步文档；依赖扫描、安全检查、日报整理，这些活不难，但总在反复占用工程师时间。真正烦人的不是工作量大，而是这些事明明适合自动跑，却总得有人盯着。

Anthropic 这次给 Claude Code 加上的 /schedule，本质上就是在补这块短板：你不再只是“在终端里临时叫它来帮忙”，而是可以直接把任务交给它，放到云端按时执行。问题也随之变成三个：这个功能到底新在哪？它能替代掉哪些重复劳动？以及，Claude Code 是不是已经不只是一个编程助手了？

从“本地帮手”到“云端执行”：AI 编程开始进入下一阶段

/schedule 这个功能本身，并不复杂到让人看不懂。你完全可以把它理解成 Claude Code 版的 cloud cron job：一句自然语言描述任务，再告诉它多久执行一次，任务就挂到云端去了。

但对开发者来说，真正值得注意的不是“多了一个定时命令”，而是工作方式在变。

过去大家对 AI 编程工具的默认理解，大多还是同步模式：

• 你坐在电脑前
• 你发出指令
• 它在当前会话里执行
• 你盯着结果，决定下一步

这当然已经很有用，但它依然要求你在线、在场、在终端前。/schedule 改变的恰恰是这个前提。任务跑在 Anthropic 的云基础设施上，电脑关了、网络断了、你人不在工位，它照样按时执行。

这背后带来的变化，其实比“自动化一点点”更大：Claude 正在从一个响应式工具，变成一个可以被安排工作的后台 Agent。

如果你还在把 AI 编程理解成“问一句、答一句”，那这次更新其实是在提醒你：下一轮效率差距，可能不再只是 Prompt 写得好不好，而是谁先把常规开发工作流拆成了可以异步执行的任务流。

/schedule 到底怎么用：一句自然语言，直接把任务挂到云端

根据演示，/schedule 的使用方式非常直接：在 Claude Code 里输入 /schedule，后面跟一段自然语言，描述你想让 Claude 做什么、多久做一次。

来源里的示例很典型：

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

Claude 会理解这段描述，并直接返回类似：

> Scheduled job created, 9am on weekdays

也就是说，一个工作日早上 9 点自动执行的任务，就这么建好了。整个过程大概只有几秒，创建后还会给出管理链接，方便你后续在网页端查看和调整。

这里最值得注意的一点是：它不是写死参数的传统定时器，而是自然语言驱动的任务创建。这意味着门槛比很多自动化平台都低。对于开发者来说，你不需要先想 cron 语法，也不需要先搭流程图，先把想做的事情说清楚，Claude 再把它转成真正可执行的计划。

从本地龙虾到云端龙虾：它和 /loop 的差别到底在哪

如果你之前关注过 Claude Code，应该见过 /loop。

/loop 做的是本地循环任务：比如每隔 5 分钟检查一次部署状态，或者每小时轮询某个结果。它适合临时监控，适合你当前这台机器、这个会话里正在跑的任务。

但它有个天然限制：终端一关，任务就结束了。

/schedule 则完全不同。它跑在云端，不依赖你本地的终端存活。来源里把这种区别形容成“本地龙虾”和“云端龙虾”，这个说法虽然有点俏皮，但其实挺准确：

• /loop 是你自己养在终端里的小助手
• /schedule 是放到云上、到点自动干活的后台执行体

这就意味着两者适合的场景完全不一样：

如果说 /loop 解决的是“我懒得手动重复点这个动作”，那 /schedule 解决的就是“这件事根本不该再由人守着做”。

不只是 CLI 命令：网页、桌面端都能创建，还支持更精细的调度

来源里提到，创建定时任务有三种方式：

1. 直接在 CLI 里使用 /schedule
2. 在 claude.ai/code/scheduled 页面创建
3. 在 Desktop 桌面端的 Schedule 页面创建

这说明 Anthropic 并没有把它做成一个“只给命令行重度用户玩的彩蛋”，而是在把它变成 Claude Code 的正式工作流能力。

频率方面，已经支持：

• 每小时
• 每天
• 工作日
• 每周
• 更精确的 cron 表达式

对开发者来说，这个细节很关键。因为很多自动化需求并不是统一节奏的：

• 文档同步，可能更适合工作日早上
• 依赖扫描，可能一周一次就够
• CI 修复和 Issue 巡检，可能需要更高频

CLI 支持更细粒度的 cron，本质上是在告诉你：这不是“玩具级定时提醒”，而是真的准备让开发者把工程里的例行任务交给它。

真正让人上头的地方：它能直接碰 GitHub 仓库，还能连外部服务

/schedule 最大的价值，不是“会定时”，而是定时之后它能真的去做事。

来源里提到，每次执行时，Claude 会自动 clone 你指定的 GitHub 仓库，从默认分支开始工作，改完之后把代码推到带 claude/ 前缀的分支上。

这句话的信息量其实很大，因为它意味着这不是一个“只会发通知”的机器人，而是一个真正能进入开发流程的执行节点。它可以：

• 读代码
• 看变更
• 改文件
• 同步文档
• 生成摘要
• 提交结果到分支

更进一步，它还支持 MCP connectors。也就是说，Slack、Linear、Google Drive 这类外部服务，也可以被接进这个定时任务里。

这样一来，很多原本要靠工程师人工串起来的事，就有了完整闭环：

• 扫描昨天的 PR
• 生成改动摘要
• 更新文档
• 把结果发到 Slack

这不是“多一步自动化”，而是从代码仓库到协作平台的整段链路都可以被 Agent 接手。

Anthropic 自己怎么用：一个 Python 库在变，Claude 定时维护对应的 Go 版本

来源里最有说服力的一段，不是功能说明，而是 Anthropic 内部自己的真实用法。

Noah 分享说，他们内部有一个定时 Claude 任务，在自动维护一个 Go 版 twin library，对应正在开发中的 Python 库。

翻成人话就是：

• Python 库在持续演进
• API 改动会不断发生
• Claude 定时检测这些变化
• 然后自动把 Go 版本同步跟上

这件事为什么值得注意？因为它证明了 /schedule 不是只能做“日报、提醒、搬运”这类外围工作，而是已经开始进入真正的工程维护场景。

跨语言库同步，本来就是一种很容易积累技术债的活：不做吧，两边越跑越偏；人手做吧，机械、重复、容易漏。Claude 如果能在这个环节持续帮你兜底，那它扮演的就不是“代码建议器”，而更像团队里一个永远不会忘事的维护角色。

开发团队里哪些活，最适合先交给 /schedule

结合来源里的示例，这个功能至少已经很适合下面几类任务：

1. 文档同步

代码改了，文档常常来不及跟。让 Claude 定时检查已合并 PR，再按改动更新文档，是最典型也最容易见效的用法。

2. PR 日报

每天早上自动扫一遍昨天合并的 PR，生成团队可读的摘要，发到 Slack 或其他协作工具里。这个场景几乎没有争议，省事而且稳定。

3. 自动修 CI

CI 失败后，先让 Claude 定时检查失败原因，尝试修复并提出改动建议，至少可以把很多低级、重复的问题挡在人工介入之前。

4. 依赖审计与安全巡检

每周跑一次依赖检查、发现漏洞自动提 issue，这类工作本来就适合固定频率，交给云端任务比交给人脑记忆靠谱得多。

5. 跨语言代码同步

像来源里提到的 Python / Go twin library，这种双份维护场景，本来就适合交给一个能持续跟踪上下文的 Agent。

这些用法放在一起，你会发现一个共同点：它们都不是创造性最高的工作，但又足够重要，不能不做。这正是 AI 最适合先接管的那一层。

还没完：Task Memory 和 Claude Code 这一轮更新节奏，透露出更大的方向

来源里还提到一个即将上线的能力：Task Memory。

意思是，未来定时任务会有自己的记忆系统，Claude 能记住之前每次执行的上下文和结果。这个东西一旦做好，影响会非常大。

因为现在很多自动化之所以“看着聪明、用着一般”，问题就出在每次执行都是全新开始。它不知道上次做了什么、不知道之前哪里失败过、也不知道哪种修复方式已经试过。

一旦任务有记忆，事情就变了：它不再只是机械地定时执行，而是能逐步积累经验，变成一个更稳定的长期维护者。

而且，/schedule 不是孤立更新。来源里梳理了 Claude Code 这半个月的一串变化：

• /loop：本地循环任务
• /remote-control：本地会话桥接到网页端和手机端
• Channels：MCP 服务器可以主动推送消息
• Voice Mode：开始支持语音交互
• 1M context window、Opus 4.6、/effort、更高输出上限

把这些功能放在一起看，脉络其实已经很清楚了：Anthropic 并不是在给 Claude Code 零散加功能，而是在持续把它从一个“你问它答”的编程助手，推向一个能远程控制、能异步执行、能接外部系统、还能长期记忆的自动化 Agent。

这也是为什么 /schedule 看上去只是一个新命令，实际却很值得重视。它补上的不是一个操作入口，而是 Claude Code 从交互式工具走向后台执行体的关键一块拼图。

Claude Code 到底是什么，普通开发者该怎么理解它

如果你今天才开始关注 Claude Code，最容易产生的误解就是：它是不是就是另一个“会写代码的聊天框”？

不是。

它更准确的定位，是一个运行在终端和工程上下文里的自主编程 Agent。它不只是补全代码，也不只是回答技术问题，而是能围绕一个任务目标去：

• 读取项目文件
• 搜索代码结构
• 修改多处文件
• 执行命令
• 跑测试
• 发现问题后继续迭代修复

也正因为这样，/schedule 才成立。因为被定时调度的前提，不是“模型会说话”，而是“模型真的会做事”。

官方使用方式上，Claude Code 通常跟 Claude 订阅体系一起使用。常见公开档位包括：Claude Pro 约 20 美元/月，Max 5x 约 100 美元/月，Max 20x 约 200 美元/月。

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

常见问题

Q1：/schedule 和传统 cron 的区别是什么？

A：底层逻辑当然也有“定时执行”这一层，但它上面套的是 Claude Code 这个能读代码、改仓库、连外部服务的执行体。你配置的不只是时间规则，而是一个能自己完成任务链的 Agent。

Q2：这个功能最适合什么团队先用起来？

A：最适合已经有稳定工程流程、但还被文档同步、日报整理、依赖检查、例行巡检这些重复劳动拖住的小团队。因为这些任务规则明确、价值稳定、最容易标准化。

Q3：它会不会只是“看起来很酷”，实际不稳定？

A：短期内当然还需要边用边观察，尤其是涉及复杂权限、外部服务连接和仓库写入时。但从来源给出的内部用例来看，Anthropic 自己已经把它用到了跨语言库同步这种真实维护场景，不只是展示功能。

Q4：为什么说这个更新比表面看起来更重要？

A：因为它改变的不是一个命令，而是 Claude Code 的工作形态。过去它更像一个坐在你旁边的助手，现在它开始更像一个可以被排班、被调度、被接入流程的后台成员。

Q5：国内开发者想少折腾一点，怎么更方便用上？

A：如果你只是想尽快用起来、减少账号和网络层面的来回处理，国内用户可以通过 Code80 更方便地使用。