做 Agent 开发之后，我越来越在意一件事：上下文的纯净度。Claude Code 在处理一个大型重构任务时，我突然想确认一个之前讨论过的设计决策——如果直接在主对话里问，这个问题和答案会永远留在历史里，影响后续 Claude 的判断。如果开新 session，又要重新铺上下文。

我以前的做法是忍着不问，或者开一个单独的 Claude 窗口。直到我发现了 /btw。

一句话总结

/btw = 不留痕的侧问（有上下文，无工具，答案不进历史）；f to fork = 把这个侧问升级成有完整工具的新主战场。

一、/btw 是什么

/btw 是 “by the way”（顺便问一句）的缩写，在 Claude Code v2.1.72（2026-03-10）引入。

它的核心设计哲学：快速提问，不污染历史。

执行 /btw 你的问题 之后，Claude 会在一个浮层面板里回答，这条问答不会作为 turn 添加到对话历史。主任务继续，上下文保持干净。

与 subagent 的镜像关系

官方文档有一句非常精准的描述：

/btw is the inverse of a subagent: it sees your full conversation but has no tools, while a subagent has full tools but starts with an empty context.

维度/btwSubagent
上下文✅ 完整继承主对话❌ 空白开始
工具访问❌ 无（只能基于已有上下文回答）✅ 完整工具
历史污染❌ 不进入对话历史结果汇报回主对话
适合场景快速澄清、上下文查询后台并行任务

二、结果面板：6 个键盘快捷键

/btw 的答案出现后，浮层面板支持以下操作：

键操作说明
↑ / ↓滚动答案长答案时用
← / →切换历史侧问v2.1.187+，在本 session 的多个 /btw 答案间翻页
c复制为 Markdown推荐方式，原始格式，见下文
fFork 成新 sessionv2.1.161+，见下文
x清除历史侧问列表清掉面板上方显示的之前问答记录
Esc / Enter / Space关闭面板返回主对话提示符

三、c to copy：为什么不用鼠标选？

按 c 会把答案以原始 Markdown 格式复制到剪贴板。

这不是废话——终端渲染文本时会做”硬换行”（hard wrap），鼠标选中复制出来的是被截断的版本，粘贴到 Notion / Obsidian 之后格式全乱。

c 键直接拿的是 Claude 返回的源文本，代码块、标题、列表全部保留，粘贴即用。

四、f to fork：把侧问升级成主战场

这是整个 /btw 功能里最强的一个操作。

按 f 之后，Claude Code 会：

  1. 把完整的主对话历史 + 这条 /btw 问答作为 transcript 继承
  2. 在此基础上开一个新的独立 session
  3. 新 session 有完整的工具访问权限（可以读文件、运行命令、编辑代码）
  4. 原始 session 通过 /resume 可随时返回

典型工作流：

1
2
3
4
5
6
7
8
9
10
# 正在做大型重构，Claude 还在工作
/btw 这个 API 的响应格式对吗？

# Claude 回答：不对，应该是 { data: [], total: number }
# 你觉得需要深入修复，不想打断主任务

f    # Fork 成新 session，继承完整上下文 + 有工具
# 新 session 里：帮我修复这个 API 的响应格式

# 修完之后 /resume 回主任务

Fork vs Branch

/btw + f/branch
原 session继续运行暂停
新 session独立开启，有完整工具你切换过去继续
适合场景侧问后发现需要深入处理主动想探索另一条路径

五、与直接在主对话输入的区别

维度/btw 侧问主对话输入
上下文污染❌ 不进历史✅ 永久写入
工具访问❌ 无✅ 完整
成本低（复用 prompt cache）标准
是否中断主任务❌ 可在 Claude 工作时插入✅ 等当前 turn 完成
适合提问类型澄清、确认、上下文查询新指令、代码修改

关键点：/btw 可以在 Claude 还在处理响应时插入，不需要等它完成。

六、5 个最有价值的实战场景

场景 1：长任务中途确认设计决策

Claude 正在做 30 分钟的大型重构，你突然想想起来一个细节：

1
/btw 我们之前说的是用 React Query 还是 SWR 管理数据缓存？

快速得到答案，主任务继续，历史不受影响。

场景 2：对话已很长，快速找回前面的信息

50+ turns 的长 session，需要确认一个早期决策：

1
/btw 我们在第几步决定不用 Redux 的？原因是什么？

成本低（命中 prompt cache），不会因为问这个让后续对话偏题。

场景 3：上下文检查，防止 Claude 跑偏

1
/btw 目前你对这个项目的技术栈理解是什么？列一下

用来”探针”Claude 当前的理解是否和你一致，不对就及时修正，而不是等出了 bug 再发现。

场景 4：侧问 + fork 的黄金组合

1
2
3
4
5
/btw 这个 SQL 查询有没有 N+1 问题？

# Claude 回答：有，在 getUserOrders 里
f
# 新 session 里处理这个问题，有完整文件访问权限

场景 5：多 subagent 并行时的状态检查

后台跑着几个 subagent，不想打断主对话：

1
/btw 目前正在运行的 subagent 有哪些任务？

七、配合个人工作流的实践建议

我目前在 fwork（飞猪 Cloud GUI Agent）开发中的用法：

  • 任何”确认类”问题优先 /btw，而不是直接问——问完即走，不留污染
  • 每隔 20-30 turns 用 /btw 你对当前任务状态的理解是什么 做一次”探针”
  • 发现侧问答案值得深入时，立即 f fork，不要在主对话里展开
  • 长对话结束前用 /btw 整理关键决策，再用 c 复制到 Obsidian 存档

要不要用 / 我的判断框架

现在就该用：

  • 你经常在长 session 中途想问一个细节，但又担心影响后续上下文
  • 你有”问完发现要深入处理”的场景，f + fork 是完美解法
  • 你在跑多个 subagent，需要快速旁问而不中断主流

注意这些限制：

  • /btw 没有工具——它不能帮你读文件、运行命令。只能基于已在上下文里的信息回答
  • 如果问题本身需要 Claude 去查代码，还是得在主对话问（或者 fork 出去处理）
  • ←/→ 切换历史侧问需要 v2.1.187+，旧版本没有

重点关注：

  • f to fork 是 /btw 价值密度最高的功能，但大多数人不知道——记住这个键
  • 复制答案永远用 c，不要鼠标选，格式更干净