长会话为何需要“驾驭”
短任务在你下达指令、看着结果的那一刻就结束了。但跨十几个文件的重构、新功能这类要花数小时的任务不同，而且你越是往正确方向把握，它甚至可能花得更久。所以长会话需要的是驾驭，而非撒手不管。
驾驭的核心有两个习惯。第一，在 Claude 开始前界定工作范围。第二，在其运行中把握方向。下面六个工具让这两个习惯真正落地——Plan Mode、Compact、Rewind、Goal、Loop 和 Worktree。
开始前先界定范围——Plan Mode
在 Plan Mode 中，Claude 以只读方式调研代码而不改动文件，然后交给你一份“要做什么、怎么做”的方案。方案出来后，务必通读它。方案越周密，执行时出岔子的可能就越小。
想修改方案，只要让 Claude 在你想要的位置加上你想要的内容即可。在方案上迭代几次，比一味期望顺利、直接跳到执行，要快得多也稳得多。
腾空上下文同时保持方向——Compact
Compact 把到目前为止的对话总结为新的上下文，并删掉旧的，从而腾出上下文窗口。当长会话变得臃肿时很有用。但有一个风险：若总结中丢失了要紧的东西，Claude 可能偏向错误方向。
所以运行 compact 命令时，一并说明保留什么、丢弃什么。命令后面的指示会告诉 Claude 如何总结。如果调试早就结束、现在只想专注于 API 改动，就直接这么说——丢掉调试输出，保留 API 改动。
走错时纠偏——Rewind
当 Claude 走上错误路径，你不必用提示硬把它拉回来。Rewind 会带你回到最近的检查点。打开方式是在空提示上连按两下 escape，就会出现 rewind 菜单。你发出的每一条提示都会生成一个可回退的检查点。
你有几种选择：恢复代码、对话，或两者。'Summarize from here' 总结检查点之后的一切——当你岔开聊了一段、只想腾出空间时很好用。'Summarize up to here' 则总结检查点之前的一切——当你想把冗长的准备阶段折叠起来、却保留实现部分时很有用。
把完成条件交出去——Goal
如果说到目前为止都是“亲手驾驭”的方式，那么当你想更自主地交办时，就用 Goal。Goal 设定一个完成条件。描述“完成”是什么样子，Claude 就会持续跨轮工作，直到一个快速评估器确认这些条件已满足，而不是在它自认为完成的第一刻就停下。
例如，你可以设定“src/billing 的所有测试通过，且类型检查器报告零错误”这样的条件。要取消，清空该 goal 即可。有一个约束：评估器只读对话记录（transcript），所以条件必须能从 Claude 产生的输出中核对——比如它实际跑出的测试结果。
盯住外部状态并作出反应——Loop
Loop 在轮与轮之间按间隔重复运行一个提示——间隔可以固定，也可以让它自行调节。用途是把 CI 运行或部署这类外部发生的状态拉进来盯着，一旦状态变化就作出反应。
比如，它可以周期性地轮询待办清单里的新条目，一旦出现严重错误，就创建一个 worktree 并提交修复。想停下，按 escape 即可。
防止多个代理相撞——Worktree
到目前为止的驾驭都假设“一辆车里一个方向盘”。但当多个代理同时在同一个代码库上工作时，一辆车里两个方向盘就不安全了。这时就轮到 worktree。worktree 通过给每个会话一棵独立的文件树，防止两个或更多 Claude 会话争夺同一个仓库里的文件。
当你退出时，没有改动的干净 worktree 会被自动移除。而仓库根目录下的 `.worktreeinclude` 文件，会列出要复制进每棵 worktree 的、被 git 忽略的文件——那些你工作需要却不想提交到版本控制的东西，比如环境变量文件或本地配置。
结论——先界定范围，再去驾驭
处理长时间的 Claude Code 会话时，先界定工作范围，再去驾驭。引导你的压缩（compact），让总结保留要紧的东西，并用 rewind 菜单纠偏。当你更善于描述“完成”而非描述步骤时，就设定一个 goal；并把并行工作放进 worktree 里跑。
这样做，你就能信任一次长时间运行而无需守着它。归根结底，让数小时的会话值得信任的，不是撒手不管，而是驾驭。