在 Claude Code 里执行一条普通 git 命令，回复中却出现与自己无关的裁员信息——这类「会话串台」并不只发生在中转服务上，官方订阅也有报告。本文梳理可能原因（服务端缓存、记忆文件残留、外部内容注入、模型幻觉、代理链路），给出可执行的排查步骤、缓解做法与需要自行验证的边界。
在 Claude Code 里让模型帮忙整理文件，执行了一条普通的 git 命令，回复里却突然冒出一段关于某公司裁员的分析——不是自己输入过的内容，也不是当前任务的上下文。账号是官方个人订阅，没有接过第三方中转。这种体验足够让人背后发凉：如果对面真的能看到别人的对话，那自己的代码和业务信息又流到了哪里？
从反馈来看，这不是孤例。有人表示遇到过两次完全不相关的内容插入会话；有人遇到模型跑着跑着去执行无关任务，让它复述指令时，结尾确实多出了自己没写过的提示词；还有人只是频繁看到模型突然切换成日语、韩语输出。这些现象看起来相似，成因却可能完全不同，需要分开判断。
现象归类：先分清是哪一种「串台」
把描述放在一起看，大致可以分成四类，处理方式差别很大：
| 表现 | 可能成因 | 危险程度 |
|---|---|---|
| 突然出现陌生业务内容、他人对话片段 | 服务端缓存/会话路由异常，或链路中转污染 | 高，涉及数据隔离 |
| 模型执行了没被要求的任务、指令末尾多出内容 | 项目文件或记忆中的残留文本、外部内容注入 | 中高，可排查 |
| 输出语言漂移（日语、韩语）、答非所问 | 模型幻觉、上下文向量偏移 | 低，但干扰工作 |
| 反复出现同一段无关内容 | 记忆文件、CLAUDE.md、历史会话被复用 | 中，可自查 |
关键区别在于：内容是否可复现、是否与本地文件有关。如果换一个新会话、换一个目录仍然出现同样的陌生内容，问题更可能在请求链路或服务端；如果只在某个项目里出现，优先怀疑本地配置与记忆。
逐项排查：从本地到链路
1. 确认请求是否真的直达官方
「我没有用中转」这句话需要用配置来验证，而不是凭印象。检查以下几处：
# 环境变量里是否有自定义端点或代理
env | grep -i -E "anthropic|claude|proxy"
# 客户端配置中的 base url / 网关设置
cat ~/.claude/settings.json 2>/dev/null
常见遗漏包括：为图便宜装过的第三方客户端、公司统一配置的网关、某些「加速」插件自动改写的端点。只要 ANTHROPIC_BASE_URL 指向的不是官方域名，服务端是否做会话隔离就完全取决于中间方，风险不可控。
2. 检查记忆与项目级配置
这一项排查成本最低，收益也最直接：
- 查看用户级与项目级的
CLAUDE.md，以及记忆目录里是否有来路不明的文本； - 在会话里直接让模型复述它当前看到的系统提示与记忆内容，比对是否有多余段落；
- 如果不需要跨会话记忆，先关闭记忆功能，观察问题是否消失。
有用户就是通过关闭记忆显著减少了异常插入。这一步不能解释所有情况，但能快速排除一类原因。
3. 检查会话引入的外部内容
提示词注入不一定来自攻击者，也可能来自你自己喂进去的东西：README、issue 正文、网页抓取结果、依赖包的说明文件、git 提交信息、日志片段。这些内容里只要藏着一段「忽略之前的指令」，模型就可能照做，表现出来就是「它自己跑去干别的了」。
排查方法：回溯异常发生前模型读过哪些文件、调过哪些工具，尤其是网络抓取和 MCP 工具返回的内容。对不可信来源的材料，先落盘、人工过一遍，再让模型处理。
4. 复现与取证
要做判断，得先有可比对的样本：
- 新开一个空会话，重跑同一条命令，看是否复现；
- 换一个网络出口（不同节点、不同线路）再试一次；
- 记录异常发生的时间点、模型标识、账号类型，保留截图和会话日志；
- 用
claude --debug之类的调试输出观察请求是否被改写。
如果换网络后现象消失，问题大概率在链路上；如果稳定复现且与网络无关，则更可能是服务端问题，值得带上时间戳向官方反馈。
5. 区分幻觉与真实串台
模型「声称自己被注入了提示词」「声称看到了别人的数据」，本身也可能是幻觉的一部分。判断标准是有没有可验证的痕迹：会话日志里是否真的多出那段文字、复述指令时是否真的带出多余内容。只有截图和日志都指向同一段陌生文本，才算比较可靠的证据；仅凭模型自述，不足以定论。
缓解与防护：把影响控制在可接受范围
排查之外，日常使用可以按下面的习惯降低风险：
- 异常即止损：一旦发现回复中混入无关内容，立刻结束当前会话重开，不要继续在同一上下文里处理敏感任务；
- 按敏感度分会话：涉及密钥、客户数据、未公开业务的工作，单独开会话，不与日常杂活混用；
- 收紧自动执行：关闭「自动批准所有工具调用」这类免确认模式，让写文件、执行命令、发请求等动作必须人工确认；
- 最小化输入：不要把密钥、完整数据库导出、内部文档原文直接贴进会话，改贴脱敏片段；
- 定期清理记忆：记忆越长越容易夹带无关内容，长期项目建议阶段性重置。
在网络层面，尽量保持单一、稳定的出口。频繁切换节点、多层代理叠加、共享出口 IP，都可能让缓存与会话归属变得更难判断。如果 Claude Code 需要长时间挂着跑任务，而本地网络或机器本身不稳定（休眠断连、性能吃紧、出口 IP 频繁变化），把运行环境放到一台长期在线的远程机器上是可选做法之一——例如整台 Mac mini 放在机房的独享远程 Mac，按月租用、远程连接使用，网络出口相对固定，适合需要持续在线跑 AI 工具的場景。这只是降低变量的一种方式，并不能解决服务端本身的问题。
需要保留的怀疑
几个结论在讨论中并没有形成共识，读者不宜直接采信：
- 「官方存在缓存 bug」：有用户表示查到了相关说明，但这一说法没有可公开核对的来源，只能作为待验证假设；
- 「同一出口 IP 会共享缓存」：听起来合理，但没有官方文档支持，也无法排除是巧合；
- 「换个节点就能改善」：对链路问题有效，对服务端问题无效，值得试但不该当成定论；
- 不同模型版本表现不同：有人观察到某些版本更容易出现异常，样本量太小，无法得出可靠结论。
另外，个人订阅与团队订阅都有人报告过类似现象，说明这不是某一类账号的专属问题；而是否与账号、地区、时段相关，目前没有足够数据支撑。涉及账号共享、买卖账号或规避地区限制的做法，本身违反服务条款，且会显著放大数据泄露风险，不建议尝试。
小结
会话里冒出别人的内容，最值得警惕的不是那段文字本身，而是它意味着「你以为的私有上下文可能并不私有」。可行的处理顺序是：先验证请求链路是否直达官方，再清理记忆与项目配置，然后回溯会话引入的外部内容，最后通过换会话、换网络做对照复现。能复现的，带证据反馈；不能复现的，按敏感度调整使用习惯。至于这类现象究竟是缓存缺陷、注入还是幻觉，目前仍缺少权威结论，遇到时保留日志、保持怀疑，比急着下判断更有用。