Claude Code 跑 3 小时长任务的 4 个关键技巧

一句话结论

Claude Code 是长任务编程体感最稳的工具，但「甩手让它跑 3 小时」目前还不现实。核心是节奏管理：每 30 分钟 /compact 一次压上下文、每完成一个子目标 commit、用 NOTES.md 当外部记忆、失败用 git reset + /rewind 恢复。这套节奏能把 3 小时长任务成功率从约 50% 拉到 85%+。

延伸阅读：Claude Code 深度评测 里的 30 分钟 / 1 小时 / 3 小时三档实测。

技巧 1：/compact 节奏

上下文接近上限时，模型开始「忘约定、跑偏」。社区共识：

| 信号 | 动作 | |---|---|---| | 对话已超过 ~20 轮 | 主动 /compact，或 /clear 开新会话 | | AI 开始重复、忘前面约束 | 立即 compact | | 准备切换大任务 | /clear 开干净会话 |

/compact 会压缩历史但保留关键决策；/clear 彻底清空，适合「上一任务和下一任务毫无关系」。

经验值：长任务里每 20-30 分钟压一次，比「等它崩了再救」省一倍时间。

技巧 2：任务拆解（3 小时 = 6×30 分钟）

把 3 小时任务显式拆成 6 段，每段独立可验证、独立 commit：

我要把 Nuxt 3 升级到 Nuxt 4，请帮我拆成任务清单：
1. 依赖升级 + config 迁移
2. 路由 / pages 适配
3. 服务端 server/ 迁移
4. 组件 <script setup> 改造
5. 测试 + build 验证
6. 收尾 + 文档
每段完成后停下来让我确认，不要一口气全做。

关键：每段完成就 commit，绝不攒到最后。这样任一段翻车，git reset --hard 回上一段即可。

技巧 3：上下文管理

Claude Code 默认读项目文件，但长任务里「跨会话记忆」靠三个东西：

1. CLAUDE.md：写死的项目约定（结构 / 命令 / 禁忌），每次启动自动加载。写法见 CLAUDE.md 最佳实践。
2. @file 引用：长任务里显式 @src/config.ts 把关键文件拉进上下文，避免它猜。
3. 临时 NOTES.md：在根目录放一个 NOTES.md 记录「当前进度 + 下一步 + 已踩坑」，长任务里让它读这个文件当外部记忆——比塞进对话上下文更稳。

NOTES.md 示例

# 升级进度
- [x] 依赖升级
- [x] config 迁移
- [ ] pages 适配（卡在动态路由）
- 下一步：处理 [id].vue 的 params 迁移
- 已踩坑：Nuxt 4 的 nitro 配置路径变了，别用旧文档

技巧 4：失败恢复

# 代码回滚到上一个干净 commit
git reset --hard <commit>

# 或 Claude Code 内用 /rewind 回到任意 checkpoint（代码 + 对话）
/rewind

# 长任务跑偏时，用 checkpoint 提示词让它从断点续
"上次在『路由适配』这步失败，原因是 X。请从这步重来，注意避免 X。"

AI 之家 观点：/rewind + git 双层回滚是长任务的保命组合。Claude Code 的 checkpoint 能回对话，git 能回代码，两者互补。永远在长任务前确保工作区是 clean commit。

技巧 5：自动压缩与并行子代理——两个默认值要先改（2026-10-18 一手核对）

前面四条技巧的前提是「你自己控制节奏」。而 2026 年下半年的 Claude Code 把两件事变成了默认自动，长任务场景必须先看清楚这两个开关：

① 空闲自动压缩（v2.1.299 起，默认开启）

它做什么：会话 ≥200K token 且空闲约 54 分钟后自动压缩——卡在一小时提示缓存过期之前，这样你回来发第一条消息时不必把整段历史按全价重算。

长任务场景下的判断：建议关掉。 理由与本方案技巧 1 直接冲突——技巧 1 的核心是「由你决定什么时候压、压之前先把关键决策写进 NOTES.md」。而空闲压缩触发时你不在场，无法先确认保留什么。压缩是有损的（见 上下文压缩），长任务恰恰是最依赖会话内原始产出（踩坑记录、已试过的错误路径）的场景。

// settings.json
{ "idleCompaction": false }

v2.1.302 起 /config 里新增了 Idle compaction 一行，不用再手改配置文件也能关。升级到 2.1.302 后到 /config 里把它关掉，是长任务使用者最该做的第一件事。

② fork 子代理默认开启（v2.1.302 起，扩大到 claude -p / Agent SDK / 桌面端 / VS Code）

它做什么：fork 子代理（subagent_type: "fork"）此前只在终端默认开启，2.1.302 起在全部入口默认开启；同时主会话的子代理一律后台运行（不再由 Claude 自己决定），而子代理自己发起的 Agent 调用默认前台运行。

长任务场景下的判断：这是利好，但要改两处习惯——

• 后台化意味着「主会话在等你」这件事不再直观。技巧 2 的「每段完成停下来让我确认」在后台子代理下会失效，需要显式要求「完成后回到主会话报告，不要继续下一步」。
• claude -p 脚本化长任务升级后必须回归一次：等待逻辑如果假设了串行，升级后会直接跑偏。

关掉它：CLAUDE_CODE_FORK_SUBAGENT=0。

口径说明：以上两条取自 Claude Code 官方 CHANGELOG 一手原文（v2.1.299 / v2.1.302 条目）。官方 CHANGELOG 版本标题下不标注发布日期；v2.1.302 的 2026-10-16T20:53 UTC 取自 GitHub Releases 的 tag 时间戳，非厂商公布发布日。详见 v2.1.302 资讯。

真实案例：Nuxt 3 → Nuxt 4（3 小时）

最终 build 全绿，2 处需人工收尾（第三方插件未兼容 Nuxt 4）。整体比「人肉迁移」快约 3 倍。

常见问题

Q：长任务能完全放手吗？ A：目前不能。建议每 30 分钟看一眼，确认没跑偏。全自动 3 小时零干预还不现实。

Q：/compact 会丢信息吗？ A：会压缩，但关键决策通常保留。重要约束写进 CLAUDE.md / NOTES.md 就不怕丢。详见 上下文压缩——里面讲清了「压什么、不压什么」以及压缩会让 prompt 缓存失效这件事。

Q：上下文越大是不是就不用压了？ A：不是。以 Claude Opus 5 的 1M 上下文为例，1M 既是默认值也是最大值，没有「再开大一点」这个选项；而且 Context Rot 在远未到上限时就已经开始拖质量。长任务照样要压。

Q：用 Max 订阅跑长任务划算吗？ A：重度长任务（8h+/天）Max 20x $200 比纯 API 烧钱稳且便宜（见 Claude Code 深度评测 成本核算）。

相关阅读

• 工具卡：Claude Code
• 评测：Claude Code 深度评测
• 方案：CLAUDE.md 最佳实践 ｜ AGENTS.md 协议 ｜ 子 Agent 用法
• 概念：上下文压缩 ｜ Context Rot ｜ 长上下文
• 对比：Claude Code vs Codex CLI

来源说明：本文基于 code.claude.com 官方文档、第三方 cheat sheet 及 AI 之家 编辑部长任务实践归纳。命令与功能以最新官方文档为准。