用 Claude Code 做复杂重构做了 40 分钟,突然冒出一个念头:"换个思路试试会怎样?"可是已经积累起来的上下文 — 读过的文件、做过的判断、讨论过的取舍 — 谁也不想白白扔掉。这时候,一行 /fork 就够了。
这是什么?
/fork 是复制当前对话的完整历史、生成一个独立新会话的命令。概念上和 Git 的 git branch 完全一样。原始分支(对话)保持不变,从分叉点出发可以朝不同方向推进。
在 CLI 里,--fork-session 参数也能实现同样效果。用 --resume 或 --continue 加载已有会话后,再加上 --fork-session,就会生成一个带有截至该时点对话历史、且拥有全新会话 ID 的独立会话。
重点:核心类比
--continue = 在同一本笔记本上继续写(会话 ID 相同)--fork-session = 把笔记本复印一份,在新的那本上写(会话 ID 不同,内容相同)
根据官方文档,分叉出来的会话不会继承原始会话的权限设置(session-scoped permissions)。这是出于安全考虑的有意设计。意思是:在新会话里做敏感操作时,会再次要求确认。
有什么不同?
在 Claude Code 中,"想试另一种思路"的场景出现的频率比想象中高。以前只有两个选项:要么开个新会话从头开始积累上下文,要么在当前会话里硬着头皮推下去。两种代价都不小。
| 开新会话 | 使用 /rewind | 使用 /fork | |
|---|---|---|---|
| 已有上下文 | 全部丢失 | 部分回滚 | 完整保留 |
| 原始会话 | 单独保留 | 被回退 | 完整保留 |
| 实验安全性 | 安全(隔离) | 有风险(难以恢复) | 安全(隔离 + 保留原始) |
| Token 成本 | 高(重新构建) | 低 | 中等(复制历史) |
| A/B 对比 | 困难 | 无法进行 | 自然流畅 |
Trigger.dev 博客介绍的"Context Pre-Warming(上下文预热)"模式很能说明这个差距。把架构文档、API 规范、编码约定等超过 4 万 token 的重上下文先一次性加载到主会话里,之后每做一个功能任务就从主会话分叉一次。可以彻底省掉每次重新构建上下文的成本。
上手指南
- 创建主会话
启动 Claude Code,给它充分加载项目的核心上下文。让它读架构文档,让它浏览主要文件,设定好编码规则。然后用/rename master-context给会话起个名字。 - 交互式分叉:/fork
在会话里用/fork refactor-attempt这样带名字的命令分叉。原始对话原封不动,在分叉出来的会话里可以放心实验。 - CLI 分叉:--fork-session
用claude --resume master-context --fork-session可以直接从终端分叉。开几个新终端标签页,对同一个主会话多次分叉,就能做并行实验。 - 对比结果后选择
每个分叉里尝试不同思路,之后对比结果。选中心仪方向的那个会话继续推进,其余的丢掉就行。
注意:禁止同时使用同一会话
如果在多个终端里 --resume 同一个会话 ID,两边的消息会互相混杂。等下次 resume 的时候,对话会乱成一锅粥。需要并行工作时,务必使用 --fork-session。
实战应用模式
我整理了一些社区里实际在用的 /fork 使用模式。
模式 1:实现方案 A/B 测试
把同一个主会话分叉两次,各自尝试不同的实现方式。比如一边用 Redis 缓存、另一边用内存缓存实现后对比性能。上下文完全一致,所以差异纯粹来自不同的实现思路。
模式 2:恢复 PR 评审应对场景
把提交 PR 时所用的会话分叉出来处理评审意见,就能保留当初写代码时的全部脉络 — 为什么这么决定、考虑过哪些替代方案 — 在完整保留这些上下文的前提下进行修改。
模式 3:Skill 中的 context: fork
在 Claude Code Skills 中配置 context: fork 的 frontmatter,该 Skill 就会在独立的子智能体(sub-agent)上下文中运行。既不会扰乱主对话,又能执行复杂的分析任务。
重点:/fork vs /btw vs /rewind — 什么时候用哪个?
• 不打断节奏问个小问题 → /btw(不留在历史里)
• 尝试不同思路 → /fork(保留原始,生成新会话)
• 撤销刚做的操作 → /rewind(在当前会话里回滚)
