写给小白的 Claude Code 进阶指南 - /btw 命令

发表于 更新于 分类于 阅读次数： 本文字数： 2.8k 阅读时长 ≈ 3 分钟

cover

上周做一个大重构，改到一半，突然想确认一个函数的返回值。

直接在对话里问？可以，但这个问题会被加到对话历史里，占用上下文，增加 Token 消耗。而且 Claude 可能因为我的”插嘴”偏离了当前任务的方向。

开一个新会话问？更不划算。新会话没有当前的上下文，Claude 什么都不知道，得重新解释一遍。

这就是 /btw 命令要解决的问题。

/btw 是什么？

一句话：**/btw 让你在不打断 Claude 工作的情况下，问一个”顺便问一下”的问题。**

它的全称是 “By The Way”——顺便说一下。

这个命令在 2026 年 3 月 10 日发布的 Claude Code 2.1.72 版本中上线。虽然是个小功能，但用过的人都说：真香。

它的工作原理很简单：

  1. 你输入 /btw 加上你的问题
  2. Claude 生成一个临时的”侧边对话”来回答
  3. 回答完毕后，这段对话不会被保存到主对话历史中
  4. 你的主任务继续运行，不受任何影响

你可以把它理解为”开了个小窗口悄悄问了一句，问完关掉，就像什么都没发生过”。

为什么需要 /btw？

要理解 /btw 的价值，得先明白 Claude Code 的一个核心机制：对话历史决定了 Token 消耗。

每次你在对话里发一条消息，Claude 都需要重新读取整个对话历史来理解上下文。对话越长，每次请求消耗的 Token 就越多。

想象一下这个场景：

你正在做一个涉及 10 个文件的大重构。Claude 已经读取了大量代码，建立了完整的上下文。这时候你突然问了一句：”Python 的 dataclass 默认是可变的还是不可变的？”

这个问题很简单，Claude 一秒就能回答。但它会被永久记录在对话历史中。之后的每一次请求，Claude 都要重新读取这个问答对。10 次请求下来，这个小问题可能消耗了上千个额外 Token。

积少成多，一个长会话中 20% 到 30% 的 Token 消耗，可能都来自这类”顺便问的小问题”。

有用户实测，持续使用 /btw 后，长会话的 Token 消耗降低了将近 50%。

怎么用 /btw？

用法非常简单，但有一个关键细节。

正确用法

在输入框里直接输入 /btw 加上你的问题，一行写完，直接回车：

1
/btw calculate_metrics 函数在这个上下文里返回什么？
1
/btw 这个正则表达式是什么意思？
1
/btw 刚才你为什么选择用 Redis 而不是 Memcached？

错误用法

不要只输入 /btw 然后回车。它不是一个交互式命令，你必须在同一行写上问题。

1
2
3
# 错误！这样不行
/btw
↵ (回车)

一个重要特性：可以在 Claude 工作时使用

这是 /btw 最酷的地方。即使 Claude 正在执行一个长任务（比如在后台跑测试、读取大量文件），你也可以用 /btw 插入一个问题。

Claude 会在后台启动一个临时的”幽灵 Agent”来回答你的问题，完全不影响主任务的进度。

就像你的同事正在认真写代码，你拍拍他的肩膀问了一句，他头也不抬地回答了你，然后继续写代码。

/btw 的三个限制

/btw 设计得很轻量，这意味着它有一些刻意的限制。理解这些限制，才能用好它。

1. 只读模式，不能使用工具

/btw 回答问题时，Claude 不能读文件、跑命令、搜索代码。它只能基于当前对话中已有的信息来回答。

这意味着：

1
2
3
4
5
# 能回答 ✅
/btw 刚才你读的那个 auth.ts 文件里，JWT 的过期时间设置了多少？

# 不能回答 ❌
/btw 帮我看看 package.json 里有没有安装 lodash

第一个问题能回答，因为 Claude 已经在主对话中读过了 auth.ts。第二个问题做不到，因为它需要去读取一个新文件。

2. 答案不持久

关掉 /btw 的回答窗口后，内容就消失了。如果你觉得某个回答很重要，需要后续参考，就不应该用 /btw，而是直接在主对话里问。

3. 只支持单轮对话

/btw 是一问一答，不能追问。如果你的问题需要多轮讨论，请用主对话。

/btw vs 其他方式：什么时候该用什么？

Claude Code 有好几种方式来管理”插入性”的需求，别搞混了。

方式 特点 适合场景
直接在主对话里问 会保存到历史，增加上下文 需要后续参考的重要问题
/btw 不保存历史，不使用工具 快速确认、语法查询、简单解释
Subagent 独立上下文，可使用工具 需要读取新文件或搜索的任务
/fork 分叉对话，可多轮讨论 想探索一个方向但不确定要不要保留

一个简单的判断标准：

/btw 是 Subagent 的反面。**/btw 能看到你的完整对话，但没有工具；Subagent 有完整的工具，但看不到你的对话。**

需要基于已知信息快速确认？用 /btw。需要去获取新信息？用 Subagent。

五个实用场景

场景一：确认 Claude 之前的决策

Claude 在重构过程中做了一个设计选择，你不太确定为什么。

1
/btw 你刚才为什么把 UserService 拆成了两个类？

不影响进度，快速了解思路。

场景二：查看函数签名

你在写调用代码，想确认一个函数的参数。

1
/btw getUser 函数接受哪些参数？返回类型是什么？

场景三：理解某段代码的逻辑

Claude 读过的一段代码你没看懂。

1
/btw 刚才 middleware/auth.ts 里那段 token 刷新逻辑能帮我解释一下吗？

场景四：确认技术细节

编码过程中临时想不起来一个语法。

1
/btw TypeScript 的 Record 类型和 Map 有什么区别？

场景五：验证 Claude 的计划

Claude 在 Plan Mode 里给出了一个方案，你想确认某个细节。

1
/btw 你计划里的第三步，修改数据库 migration，会不会影响到现有的数据？

省钱小技巧：搭配 /cost 使用

Claude Code 有一个 /cost 命令，可以查看当前会话的 Token 消耗情况。

建议你在一个长会话中，定期跑一下 /cost，看看 Token 消耗。然后回顾一下自己的对话记录：有多少问题是”顺便问的”？这些问题用 /btw 来问，能省多少？

MindStudio 的一篇分析文章给出了一个参考标准：如果你的对话中超过 20% 到 25% 的交互属于”附带性问题”，你就有很大的优化空间。

判断标准也很简单：

  • 这个问题的答案我后面还需要引用吗？ 需要 → 主对话。不需要 → /btw。
  • 这个问题是在推进主任务，还是满足一个临时好奇？ 推进任务 → 主对话。临时好奇 → /btw。

写在最后

/btw 是一个很小的功能。它没有 Agent Teams 那么震撼，没有 Plan Mode 那么深刻。

但它解决了一个每天都会遇到的真实问题：在不打断工作流的前提下，快速获取信息。

Anthropic 的工程师 Erik Schluntz 把它当作一个 side project 做出来的。有时候最好用的功能，就是这种”痒了就挠一下”的小工具。

我现在好奇的是：/btw 的”只读模式”限制，是设计上的权衡，还是后续版本会放开？如果能让它调用工具但不写入历史，那才是真正的”幽灵模式”。