现在可以让 Claude 替你上夜班了

一、额度用不完，是个真问题

用 Claude Max 的人大概都有一个感受：周额度其实最后几天容易用不完。

原因也简单。白天坐在电脑前的时间是有限的，而且人不可能一直盯着 Claude 跑任务。开会、写文档、处理杂事，一天下来真正用 Claude 集中干活的时间可能也就几个小时。到了晚上人要睡觉，Claude 就闲着了。额度是按时间窗口滚动的，前面用得少，后面的5小时窗口在周额度限制下就容易排不开了。

我们设想，如果能让 Claude 晚上自己跑有价值的任务，相当于把一天的产出时间从白天的十几个小时拉长到接近二十四小时。而且夜间没有人在用，额度窗口完全空着，跑大任务反而是最从容的时段。

所以"让 Claude 替我上夜班"这件事，我们想了很久。之前的 ClaudeTerminal 已经做了续跑（撞限后自动继续）和定时任务（到点发一条消息），但这两样东西拼在一起还是差几块。续跑只管一件事撞墙后接着干，定时任务只管到点发一条，发完不管前面那条做没做完。

这次更新，我们把缺的几块全补上了。

二、任务队列：让多个任务按顺序自动跑完

先说第一个问题。晚上想让 Claude 做三四件互不相关的事，怎么安排？

最直觉的做法是同时开三四个标签页一起跑。但 Claude 的 5 小时滚动限额是按账号算的，所有标签页吃同一个池子。三个标签同时跑，额度消耗速度是三倍，很可能第一件事还没做完就撞限了，三件事谁都没做完。

串行反而是夜间最靠谱的策略。一个做完再起下一个，额度利用率最高。而且起下一个之前先查一次当前额度够不够，不够就等恢复再起，不会白白撞墙浪费一次冷启动的 token。

我们做了"任务队列"。把几件事排成一队，设一个启动时间（比如凌晨 1 点），到时间了自动开始跑第一个，跑完了起第二个，以此类推。中间撞限了就等额度恢复再继续，设一个截止时刻（比如早上 8 点），到点没跑完的就不再起新的了。

往深了说一层。AI 自动化的瓶颈往往不在模型"能不能做"，而在多个任务之间怎么调度。谁先谁后、做完没有、额度够不够、失败了怎么办。人坐在电脑前的时候这些都不是问题，因为人在看着，随时能介入。一旦想实现无人值守，每一个问号都变成必须用代码显式处理的工程问题。

三、发进已有会话：很多任务就是要在老对话里接着做

队列里每个任务默认会开一个新标签、新会话。这对很多独立任务来说没问题。但实际使用中我们发现，大量任务天然就是要在一个已有的对话里接着做的。

比如一个对话已经聊了十几轮，里面装着项目背景、架构决策、前面几步写好的代码。这些上下文就是任务能做好的前提。如果开一个新会话，Claude 什么都不知道，要么从头解释一遍，要么做出来的东西跟前面对不上。

所以我们给队列加了一个选项：任务可以选择发进一个正开着的对话，或者恢复一个历史对话再发进去。

这件事听起来直觉上很简单，做起来有几个不太显眼的坑。

会话 ID 会漂移。在 Claude 的机制里，压缩上下文、回撤消息、恢复历史对话，都会产生新的 ID。所以不能只存一个 ID 去匹配，得维护一条 ID 链，只要链里包含目标 ID 就算匹配上了。

缓存有时效。Claude 的 prompt 缓存 1 小时过期。如果一个对话超过 1 小时没动过，再往里发消息就是全量冷读，token 消耗会陡增。恢复的历史会话更是必定冷读。我们加了可选策略：发之前先用便宜模型压缩一遍上下文，把贵的额度留给正事。

还有一条红线：如果会话的转录文件已经不存在了，必须明确报失败，绝不能静默地开一个新会话假装成功。Claude 的 SDK 对不存在的 ID 做 resume 会静默开新会话，不拦住的话，看起来在老对话里接着聊，实际上上下文全丢了，做出来的东西根本不对。

四、会话消息列：在同一个对话里按顺序发好几条

还有一类很常见的场景。一个对话做了一半，上下文都在里面。晚上想让它接着往下做三四步。

举个具体的例子。白天一个对话里已经讨论清楚了架构方案，晚上想让 Claude 在这个对话里继续执行四步："把剩下三个模块的代码写完"、/compact（压缩上下文，腾出空间）、"基于前面写好的代码补测试"、"跑一遍验收脚本，把结果贴出来"。

这四步必须在同一个对话里做，因为后一步依赖前一步的上下文和产出。又必须串行，第二步要在第一步真正做完之后才能发，不然会打断正在进行的工作。

前面做的功能都差了一点。任务队列每个任务开新会话，上下文不共享。发进已有会话能把一条消息发进老对话，但一次只管一条。

我们做了"会话消息列"。在一个对话里预先排好一列消息，可以设一个开始时间，到时间了按顺序逐条发进同一个对话，上一条确认做完了才发下一条。也可以不设时间直接开始跑。/compact 这种斜杠命令也可以作为其中一条排进去，跟普通消息没有任何区别。

操作上有两种方式。可以在界面上打开消息列抽屉，一条一条添加和编辑。也可以直接在对话输入框里用 /at 22:30 把剩下的模块写完 这样的格式快速追加，适合已经想好要做什么的时候。

五、"上一条真的做完了吗"

整个消息列里技术含量最高的一个问题：怎么判断上一条消息的任务已经完成了。

这个问题比表面上看起来要难。引擎报告"空闲"不等于任务完成。可能 Claude 弹了一个确认框在等人点，可能后台有个 shell 脚本还在跑着，可能模型做了一半觉得需要人确认就主动停了。如果这时候直接发下一条消息，上下文会乱掉，后面的步骤全白做。

我们把完成判定拆成了三层。

第一层是机械信号。检查三个条件：引擎是否空闲、有没有挂着的确认卡、有没有后台进程在跑。这三个都是确定性的、可以直接查到的状态，不需要任何判断。只有三个条件全部满足了，才进入第二层。

第二层是模型判断。让一个便宜的模型读会话尾部的内容，判一次："上一条指令是否已执行完毕，不是中途停下，不是在等人回答，不是只做了一半。"判没完成就 60 秒后再判，不急着往下走。

第三层是兜底。引擎空闲、没有子程序、输出连续 5 分钟一字未变。到这个程度，再判多少次结果都一样了，按完成处理往下走，日志里记一笔"按静止判定完成"，事后可以回看。

这套三层判定解决了绝大部分情况。但发版后我们自己复核了几条容易出错的路径，又发现了两个"夜里会卡死"的问题。

第一个：后台任务记录不会自动清理。如果引擎崩溃重启了，有个任务在崩溃前就启动了，永远收不到结束通知，系统就永远认为"有子程序在跑"。更麻烦的是第三层的 5 分钟兜底排在这个判断后面，根本走不到，消息列就彻底卡死了。

第二个：当前正在跑的那条消息，如果对应的标签页被关掉了，系统只会"跳过这一轮检查"，但不会往下推进到下一条。结果就是无限等一个已经不存在的标签。

这些问题也都妥善的解决了。

六、试试看

这几个功能加在一起，"让 Claude 替我上夜班"这件事算是真正跑通了。

睡前把要做的事情排好，可以排成任务队列让几件独立的事按顺序跑，可以在一个对话里排一列消息让几步串行的工作依次执行，中间撞限了会等额度恢复再继续，早上起来看结果就行。

ClaudeTerminal 是我们给 Claude Code CLI 套的一个桌面图形壳。引擎是官方的 Claude Agent SDK，会话数据和终端里的 claude 命令完全互通，随时可以回终端，没有迁移成本。

下载地址：https://github.com/guoy0701/ClaudeTerminal/releases

安装一次，之后有新版本会自动提示更新。目前支持 Windows x64，个人业余项目，闭源。

问题反馈和建议：https://github.com/guoy0701/ClaudeTerminal/issues

也可以在应用内点帮助菜单的"反馈"，或者直接输入 /feedback。

我们还在持续往里面加东西，欢迎一起用，一起提问题，一起把这个工具打磨得更趁手。