夜里十一点我把一个跨了六个模块的迁移任务丢给了 Claude Code设好终端会话去睡了。第二天早上醒来看结果——跑了八个小时中途在第两小时四十分钟的时候就因为上下文被压缩开始“失忆”后面所有步骤都在用错误的前提做修改输出产物看着像那么回事实际上全是白干。这不是段子是我真实踩过的坑。接触 Claude Code 有一段时间之后我才逐渐摸索出“让 AI 通宵干活”的正确姿势。它和普通 AI 编程补全工具最大的不同在于它是一个带工具调用能力的 Agent可以自己读文件、改文件、跑命令、跑测试甚至在没有人类介入的情况下连续执行几个小时的批处理任务。但也正因为如此它的长时间任务执行并没有那么简单会话上下文、权限策略、API 配额、错误恢复任何一个环节没安排好你早上醒来的表情都不会太好看。这篇文章就从我的实操经验出发把 Claude Code 长时间任务该怎么设计、怎么配、怎么防翻车从头到尾捋一遍。涉及 Windows 安装、Ubuntu 服务端部署、VS Code 集成、桌面版安装以及用 CC Switch 把 DeepSeek、Qwen、GLM 等模型接进来还有通过 LM Studio 调用本地模型的思路。无论你是第一次接触还是已经在用了但被通宵任务坑过这套内容应该都能直接拿来用。1. 长时间任务为什么容易跑飞先搞清楚 Claude Code 的会话机制1.1 上下文压缩是“失忆”的根源Claude Code 的会话看表面是一个能无限聊下去的窗口但底层其实一直在做上下文管理。模型能同时处理的 token 是有限的每当你让它读文件、跑命令这些内容都被塞进上下文里。一旦总量逼近上限Claude Code 就会把最早的一部分内容“模糊化”——把完整代码和日志压缩成一段摘要。听起来很智能但对长时间任务来说这就像定时炸弹。我在一次跨目录重构里遇到过特别典型的情况任务跑了两三个小时后Claude Code 突然开始说“根据项目中已有的缓存实现我们采用同步策略”但实际上项目里最早的那个缓存模块已经被早期步骤改掉了。它参考的结论是压缩之后的摘要摘要里没有记录“这个模块已经被我们改成异步了”。结果就是后续所有的改动全部建立在一个错误的前提上代码还能编译逻辑却彻底跑偏。所以结论很反直觉长时间任务的上下文不能靠“让它记住更多”而要靠“让它少记一点”。把大任务拆成若干小任务每个小任务完成立刻把结果写进文件下一个小任务从文件里读结果而不是让一个超长会话从头记到尾。1.2 Agent 循环既能干活也容易“自作主张”Claude Code 和普通 IDE 补全的本质区别是它支持 agentic loop——你给一个目标它自己循环执行“推理 → 调用工具 → 观察结果 → 继续推理”这个过程。这个机制让它能完成多步骤任务但副作用是如果你的任务描述不够收敛它会在某个中间步骤自由发挥。我见过不少朋友第一次上手直接一句话丢过去“帮我优化这个项目的性能”然后挂一夜。第二天进展倒是很“丰富”——它自作主张改了数据库连接池、换了日志库、还顺手重构了一个跟性能完全无关的模块。没有任何一个步骤是错的但合在一起根本不是你想要的东西。长时间任务的正确设计方式是把它当成夜班交接你不需要告诉 AI“把整个工厂管好”而是给它明确的生产线、明确的工序、明确的验收标准以及失败之后的处理预案。把任务拆成 AI 不需要“思考大方向”、只需要“按步骤执行”的颗粒度才能真正放心去睡觉。2. 让任务“无人值守”的三种实践模式2.1 纯文本批量模式-p参数是基础单元Claude Code 命令行的-p参数可以让你把一段 prompt 直接传给它执行完成后自动退出。这是长时间任务最核心的积木它跟交互式会话最大的区别有三点退出码稳定适合写进脚本流程不依赖终端伪终端可以挂后台每个任务独立上下文不会互相污染。我常用的模式是写一个批量脚本把多个独立子任务串起来跑#!/usr/bin/env bash set -euo pipefail for module in auth billing notify; do claude -p 读取 src/${module}/ 下的代码找出所有 TODO 标记并修复修复完后运行该模块测试把变更记录追加到 logs/${module}_changes.md \ --output-format text \ --permission-mode acceptEdits \ --model claude-sonnet-4-20250514 echo ${module} 完成于 $(date) logs/run.log sleep 10 done这里有几个细节值得说。--permission-mode acceptEdits表示允许它直接改文件但执行终端命令仍然会询问——如果改成完全无人值守你还需要配合权限策略来处理命令审批具体我在 2.2 展开。--output-format text适合人读如果后续还要做自动化解析可以换成--output-format json。每次任务之间加 sleep 不是为了装样子是为了给 API 限流留缓冲这个后面第四章会细讲。用-p模式跑批处理我个人的体会是任何一个子任务的 prompt 都要自包含。不要写“按照上一个任务的结果继续”而要写“读取 logs/xxx.md根据其中的修复列表继续”。落盘的文件才是可靠的记忆模型上下文里的记忆睡一觉之后就别指望了。2.2 无人值守脚本模式权限策略决定你敢不敢睡如果你的任务是“全自动跑一整夜”-p模式加上一个精心设计的权限策略才是关键。Claude Code 提供了几个权限档位权限模式行为适用场景default每次工具调用都询问完全不适合无人值守acceptEdits直接改文件命令仍需确认适合代码批量修改bypassPermissions跳过所有确认仅限隔离环境真正常用的其实是 acceptEdits因为多数夜间任务最重的操作就是改代码文件而命令执行这一步可以靠白名单解决在项目根目录建一个.claude/settings.json把允许执行的命令前缀配置进去。比如{ permissions: { allow: [npm run test, python -m pytest, git status, cat logs/*], deny: [git push, rm -rf] } }这样 AI 可以自己跑测试、查看日志但没法执行危险命令。bypassPermissions这个参数存在但我通常只在一次性容器或者虚拟机里才用——不需要跟生产环境、真实数据库、任何花真金白银的云服务放在一起过夜这是底线。我跑过最省心的无人值守脚本大概长成这样nohup bash run_nightly_tasks.sh logs/nightly.out 21 配合上面那个逐模块循环。注意nohup只解决挂断问题不解决“任务逻辑跑偏”的问题。所以脚本里一定要每个子任务结束都打印清晰的进度标记方便第二天早上按图索骥定位跑到哪里了。2.3 会话续跑模式合理使用--continue和/resume不是所有任务都能干净地拆成独立子任务。有时候你就是需要一个长会话让 AI 记得前面几十步的决策脉络。这种场景下不要硬拆用 Claude Code 的会话续跑机制来做检查点。交互式会话会自动记录 session你可以这样恢复# 列出最近的会话 claude --list-sessions # 恢复最近的会话 claude --continue # 恢复到指定会话 claude --resume session-id我实际用得最多的场景是白天做了一部分复杂重构晚上想让它继续。启动一个会话干完一个阶段退出会话把当前状态写进项目里的SESSION_NOTES.mdAI 在哪个文件改到哪一步、下一步计划是什么、有哪些待验证事项然后claude --continue恢复会话时第一句就让它读这个笔记文件。这样做的原因是即便有续跑机制一个会话跨了十几个小时、上下文被压缩过之后记忆的可靠程度依然不如白纸黑字的笔记。会话续跑负责保留“语境”落盘笔记负责保留“事实”两者配合才不会跑偏。3. 从安装到多模型接入不同环境的候鸟方案3.1 Windows 上安装 Claude Code 与 VS Code 集成Windows 上安装本身不复杂一个 npm 命令就搞定npm install -g anthropic-ai/claude-code前提是电脑上有 Node.js 环境建议版本够新一点老版本容易遇到 TLS 或者 fetch 相关的诡异问题。装完在终端敲claude就能进入交互模式。但如果你的日常工作流在 VS Code 里更推荐直接装官方 VS Code 扩展装完以后你能直接在编辑器侧边栏开一个 Claude Code 面板当前打开的文件、所在目录的上下文都是自动带上的。对长时间任务来说VS Code 集成主要好在“看得见”任务在后台跑你可以在同一个窗口继续看其他代码进度输出直接展示在面板里不用切终端文件被修改了会同步高亮方便你早上一眼看出改了什么。Windows 上有个细节要注意Claude Code 执行命令依赖系统 shell如果你日常用的是 PowerShell一些类 Unix 命令写法可能在脚本里跑不通。我的建议是既然要跑无人值守任务尽量在脚本里显式写明解释器比如调 Python 就写python -m pytest不要依赖 shell 的隐式行为。另外如果你只想要一个独立的桌面操作界面可以留意 Claude Code 桌面版官方有对应的桌面应用安装包体验上偏向“把 Agent 当应用用”对不习惯命令行的用户更友好。但底层逻辑和命令行完全一致所以本文讲的任务设计和排查思路照样适用。3.2 Ubuntu 服务器部署让任务真正独立于你在 Windows 桌面上挂机通宵有一个致命问题电脑不能休眠终端不能关。你要是设了自动休眠或者半夜系统更新重启任务直接没了。所以我处理真正长时间的任务通常会扔到 Ubuntu 服务器上。服务器端安装没什么两样curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt-get install -y nodejs sudo npm install -g anthropic-ai/claude-code装完把 Anthropic 的 API Key 配到环境变量里。然后关键一步不要在裸 SSH 会话里跑任务。SSH 连接一断你前台运行的进程就会被挂断信号带走。正确做法是配合 tmux 或 systemdtmux new -s night claude -p 执行项目根目录任务说明.md 中的全部迁移步骤每一步都要更新 progress.md --permission-mode acceptEdits按CtrlB再按D脱离会话SSH 断开也不影响任务。回来的时候tmux attach -t night就能接着看。用 systemd 则是更工程化的方式服务随开机自启、崩溃自动拉起适合那种需要长期挂在服务器上的任务。既然聊到服务器就多说一句如果你在 Ubuntu 上通过终端安装 Claude Code 时遇到过公司策略提示类似 “your organization has disabled claude subscription access” 之类的报错多半不是你本机配置问题而是账号侧的限制。这种情况要么换个人账号的 key要么走自己控制的第三方模型通道来绕开订阅限制这正好引出下一节。3.3 用 CC Switch 接入 DeepSeek、Qwen、GLM 等模型Claude Code 默认用的是 Anthropic 官方模型但第三方模型接入现在也相当成熟。如果你手头有 DeepSeek、Qwen通义千问、GLM智谱等模型的 API key或者想用更低成本的通道来跑夜间批处理可以通过 CC Switch 这样的界面工具来管理多套模型配置。CC Switch 本质上是帮你切换和注入 API 配置的工具Windows、macOS 都有桌面版本。它的核心作用是把各家模型服务商提供的 base_url、api_key、model 名称组织成一套套配置一键切换不用手动改环境变量。切换之后我在命令行里看到的效果就是同一个claude命令后端实际调用的是 DeepSeek 或 Qwen 的模型。对长时间任务来说这有一个非常实际的收益成本分摊。官方模型写代码质量高但遇到那种要跑十几轮循环的体力活换成性价比模型跑也不心疼。不过要提醒的一点是第三方模型虽然能用Agent 的工具调用能力不一定跟官方模型完全一致。我在 5.2 会讲一个因为模型切换导致工具调用失败的排查案例。结论先放这里大规模无人值守任务优先用你已经在单个任务里验证过工具调用正常的那套配置。3.4 通过 LM Studio 接入本地模型做低敏感任务还有一种场景是完全离线代码涉及敏感业务或者你就是不想把全仓库代码传到远程 API。这时候 LM Studio 这类本地推理工具就派上用场了。LM Studio 可以在本机起一个 OpenAI 兼容的服务端点Claude Code 通过自定义 base_url 指向它ANTHROPIC_BASE_URLhttp://localhost:1234/v1 claude需要注意本地模型的上下文长度、推理速度和工具调用能力差异非常大。我今天不说哪个模型一定能完美驱动 Claude Code——这取决于你的显卡和模型量化版本。我只说长期任务里的实际体会本地模型跑简单、步骤明确的任务没问题但如果你要通宵处理几千个文件的改动本地推理的速度大概率撑不起这个规模。它更适合做“低敏感度的验证型任务”比如在不联网的环境里对一批配置文件做格式检查而不是做动辄几个小时的大型重构。4. 睡觉之前的五件事长时间任务的晚间检查单很多人在半夜丢任务之前兴奋点在“我终于可以睡觉了”但真正应该花时间的反而是睡觉前那二十分钟。下面是我每次跑过夜任务前都过一遍的检查点从失败代价最高的开始。4.1 任务拆解把大目标变成可验证的小步伐第一条也是最重要的一条绝对不要直接丢一个“重构整个项目”这种级别的要求。我习惯在项目根目录写一份NIGHT_TASK.md把任务拆成一个个子任务每个子任务都有独立的输入、输出和验证方式## 子任务 1重构 auth 模块 - 输入src/auth/ 现有代码 - 动作将回调函数改为 async/await保留接口签名 - 验证运行 src/auth/tests 下全部测试 - 输出将变更摘要写入 logs/auth_result.md ## 子任务 2根据 auth 结果改 billing 模块的数据依赖 - 输入logs/auth_result.md、src/billing/ - 动作更新 billing 中对 auth 回调的引用方式 - 验证npm run test:billing - 输出将变更摘要写入 logs/billing_result.md这样设计最大的好处是可恢复性极强。假设半夜三点子任务 3 跑挂了第二天早上你只需要看 logs 里哪些任务完成了、哪些没开始然后从断点继续而不是从头再来一遍。4.2 日志落盘没有日志就等于没有跑跑过夜任务最怕的不是失败而是失败了你不知道它死在哪一步。所以你在设计 prompt 和脚本时一定要让它每完成一个阶段就去追加日志。我自己的规范是统一写到logs/目录文件名带模块和日期每条日志前带时间戳进度标记要稳定比如[DONE] auth_refactor方便 grep。查进度的时候一行命令就能看到全局grep -E \[DONE|\[FAIL logs/run.log一个很容易被忽略的细节是把 AI 终端的输出也重定向到文件里不要只让它“写日志”。因为日志是 AI 主观记录的而终端输出里有它实际的工具调用和报错堆栈。tee是个好帮手claude -p ... 21 | tee -a logs/full_output.log这两个文件配合着看一个告诉你“它觉得自己干了什么”一个告诉你“它实际干了什么”。第二天复盘的时候价值极高。4.3 错误恢复与重试策略防止半夜静默失败长时间任务里最容易让人崩溃的不是报错而是“没报错但也没继续”。AI Agent 在某些步骤上可能会陷入重试循环、空转或者因为一次临时网络抖动直接退出。我的应对方案分三层。第一层是脚本层的自动重试针对临时性错误增加退避重试机制retry_count0 until claude -p 子任务 --permission-mode acceptEdits; do retry_count$((retry_count 1)) if [ $retry_count -ge 3 ]; then echo 任务失败退出码 $? logs/run.log break fi echo 第 ${retry_count} 次重试等待 30 秒... sleep 30 done第二层是给 Claude Code 本身加--max-turns参数限制一个任务的最大推理轮数。这样即使它在一堆工具调用里绕圈子也不会无限空转烧掉你一夜的额度。第三层是“失败继续”策略。有些批处理任务里单个子任务失败不应该中断全部。脚本里对非关键子任务用set e放开退出码把错误记录下来让后面的任务继续跑。真正关键的任务失败则停止整个流水线防止出错的前置结果被后面的任务当成基准继续扩散。4.4 API 配额与限流半夜断供的应对这是长任务最常被忽略的一个暗礁。API 服务商给账号设了每分钟请求数RPM和每日用量上限。半夜任务量一旦激增很容易触发限流返回 429 错误。Claude Code 有些错误能自动重试但并不是所有情况都那么美好。我在脚本里给每个子任务之间加 sleep不是随便加的。这里有一个经验值单任务耗时短的sleep 可以设 5-10 秒单任务本身就要跑几分钟的sleep 短一点问题不大。总之别用零间隔连环串给限流留一点缓冲。还有一个技巧把任务错峰执行。如果你有多个模块要处理可以把模块顺序打乱重的任务和轻的任务交错排列避免十五分钟内疯狂请求高成本模型。另一个角度是监控用量一些服务商后台有实时用量面板睡前看一眼当日剩余配额如果明显不够跑完就砍掉部分子任务或者换更便宜的模型配置别让任务在凌晨四点因为额度耗尽而无疾而终。4.5 结果验证别把“跑完了”当“做对了”即使所有任务都正常结束也不能直接相信结果。AI 写代码很流畅写错了也很流畅。我在一次夜间任务后收到一整份代码改动每一处都能编译测试也过了——但第二天 code review 时发现它把某个配置项的默认值记错了完全违反了原始需求里一个容易被忽略的约束。所以睡觉前要设计好验证动作并且让它自动执行。我的做法通常是每个子任务结束时自动跑对应测试Unit Test / Lint测试结果作为“完成”的唯一标准写进日志涉及跨文件改动时额外跑一次全量检查最终产物要做一次人工抽查尤其是那些和约束条件相关的部分。你可以让 AI 在最后汇总一份summary.md列出每个文件的改动理由和自测结果。第二天你复盘时不用从头审代码先看 summary再对可疑的段落抽查效率会高非常多。5. 我踩过的坑四个真实场景和一套排查链路前面都是方法论这一节是我自己真金白银踩出来的。挑四个最有代表性的场景每个都把完整的排查链路复现一遍方便你下次遇到能跟着这个思路走。5.1 场景一跑了八小时结果文件只有一半现象任务正常退出日志里没有任何 error但生成的迁移报告只覆盖了前两个模块后面六个模块根本没出现在结果文件里。我最开始以为是日志写错了检查后发现是上下文截断导致 AI 在某个节点后以为所有模块都已经处理完了于是提前生成了总结报告正常退出。定位思路先查logs/run.log里最后一条[DONE]标记出现在哪个模块然后把对应时段的完整输出full_output.log拉出来看会发现它从某个时刻开始后面的工具调用里不再出现循环体中应该读取的下一个模块路径。修复方案改成强制的逐模块驱动不让 AI 自己决定“要不要继续”。把循环放到 shell 层每个模块都用独立的-p调用模块列表由脚本提供AI 没有机会中途跳过。自那以后我再也没遇到过这个问题。5.2 场景二CC Switch 切换到第三方模型后工具调用全部失败现象白天用官方模型跑单任务一切正常。睡觉前用 CC Switch 切到某个第三方的 DeepSeek 配置启动长任务后前几个回合还挺好突然就开始高频报“工具调用格式无效”之类的错误任务直接秒死。定位思路先用最小复现。我拿同一个 prompt 分别用官方配置和第三方配置跑一次发现第三方配置下Agent 在某个很普通的读文件工具上就出了问题。查 CC Switch 生成的配置后发现它虽然把 base_url 和 key 改了但某些能力参数和模型支持的 functions calling 格式没有完全对齐。修复方案针对第三方模型要额外确认它是否完整兼容 Claude Code 依赖的工具调用协议。如果没有稳妥的办法是让第三方模型干“结果生成”的活把需要高频工具编排的步骤留给官方模型。我的经验是想稳定通宵不要在你的主链路上用未经预先验证的第三方模型。5.3 场景三Ubuntu 服务器上 SSH 一断任务就没了现象从笔记本 SSH 到服务器启动任务合上盖子睡觉。早上起来发现任务在半夜就终止了查日志发现进程消失没有任何报错输出。定位思路第一反应以为是服务器 OOM查dmesg没有发现 kill 记录。后来才想到SSH 会话断开时终端会向它所控制的进程发送挂断信号SIGHUP前台进程虽然被 nohup 挡了一部分但它启动的子进程、特别是通过交互式终端包装生成的伪终端进程没有完整逃过这一劫。修复方案以后所有服务器上的长任务一律在 tmux 会话里启动。tmux 的优势是它在服务器上有独立的守护进程SSH 断不断跟它没关系。tmux new -s night启动CtrlB D脱离想看了再tmux attach -t night。这个坑踩过一次之后我再也没有在裸 SSH 下跑过任何过夜任务。5.4 场景四API 配额耗尽后面的任务全部静默失败现象一觉醒来前三个小时的任务都有产出后面所有任务都标记为“失败”但没有一个像样的报错信息。查 API 后台发现当天配额在凌晨两点左右就达到了上限。定位思路日志里失败任务的共同特征都是网络请求类错误但full_output.log里 Claude Code 的重试逻辑把其中一部分错误吞掉了让我误以为只是偶发波动没有第一时间意识到是配额问题。修复方案这类问题事后补救远不如事前预防。现在我在脚本最开始会检查当日配额用 API 返回的额度字段判断剩余量不够就跑一部分轻量任务或者直接跳过。睡眠时间不够配额心里一定要有数。5.5 一套通用的排查思路这四个场景背后其实是一条可复用的排查链路。如果你哪天早上发现任务结果不对我建议严格按这个顺序来不要跳步先看运行日志的尾部尤其是最后一个[DONE]和[FAIL]标记确认任务死在哪一个阶段对比完整输出看 AI 在死掉之前最后一次工具调用是什么、调用的参数是什么报错往往就藏在它最后“想做没做成”的那一步小规模复现把死掉的那个子任务单独拎出来跑一遍缩小变量范围回看配置变更想想睡前动过什么——网络配置、模型切换、权限设置、或者系统更新80% 的半夜事故都跟当天的某个变更有关系定位后永远要把复现的 prompt 最小化保存下来它比任何描述都有说服力也是下次排查的起点。这一套链路我走了无数次目前还没有失效过。它能极大的节约你第二天早上的反应时间也能最大程度避免因为中午暴躁重跑而浪费更多配额。最后再分享一个我个人的习惯吧现在我的夜间任务统一以“三小时为一个周期”来设计每个周期结束强制落盘一次。如果三小时跑完发现还没完成我会让它休息几分钟重新读进度文件再启动下一个周期。跑通宵这件事追求的不是“一个会话跑一整夜”而是“断了也能自己接上”。这句话等你自己跑完一次成功的通宵任务就会懂了。