ai-tools

Claude Code 的隐藏 prompt 标记:为什么一个日期字符串会让人不安

读 Thereallo 关于 Claude Code prompt steganography 的文章后,拆解它发现了什么、触发条件是什么,以及这对开发者工具信任意味着什么。

Jul 01, 2026
Claude CodeAI toolssecurityprivacyprompt

Thereallo 写了一篇关于 Claude Code 的逆向笔记:Claude Code Is Steganographically Marking Requests。它讨论的不是模型回答质量,而是一个更底层的问题:一个拥有文件系统、shell、git、浏览器访问能力的编码 agent,它的客户端本身是否应该有任何“隐蔽但可观测”的行为。

本文是对原文的整理和解读,不是我对 Claude Code 二进制的独立复现报告。

原文发现了什么

作者检查的是 Claude Code 2.1.196。他在本地包里看到一段逻辑,会改变系统 prompt 里“今天日期”那句话的写法。

正常情况下,这句话大概是:

Today's date is 2026-06-30.

可疑点不在日期本身,而在两个很小的字符差异:

  1. Today's 里的撇号可能被换成其他 Unicode 撇号。
  2. 日期分隔符可能从 - 变成 /

肉眼看,这仍然像一句普通英文。对日志、网关、后端解析器来说,它却可以携带分类信息。原文把这种做法称为 prompt steganography,也就是把信息藏进看起来无害的 prompt 文本里。

触发条件

原文里最关键的触发点是 ANTHROPIC_BASE_URL

如果没有设置这个环境变量,或者它指向官方 api.anthropic.com,逻辑会提前返回,日期字符串保持普通形态。真正进入这条路径的是自定义 base URL,例如:

  • 内部 API gateway
  • 本地代理
  • 模型 router
  • reseller 或转发服务
  • 研究环境里的自定义 endpoint

进入这条路径后,客户端会看几类信号:

信号影响
系统时区是否是 Asia/ShanghaiAsia/Urumqi日期可能从 YYYY-MM-DD 变成 YYYY/MM/DD
API base URL 的 hostname 是否命中域名列表Today's 里的撇号会变成特定 Unicode 字符
hostname 是否包含某些 AI lab 关键词撇号会变成另一类 Unicode 字符

原文还提到,域名和关键词列表不是明文保存,而是通过 base64 和 XOR 做了简单混淆。解出来的关键词包括一些 AI 公司或模型平台相关词;域名列表则包括中国互联网公司、AI 公司,以及一些代理、转发、网关服务域名。

这件事为什么让人不舒服

如果只看目标,检测自定义网关并不奇怪。模型服务商当然会关心 API reseller、未授权代理、模型蒸馏链路、异常路由等问题。一个自定义 ANTHROPIC_BASE_URL 本来就是有价值的风控信号。

真正的问题是实现方式。

Claude Code 不是一个普通网页脚本。开发者会给它很高的本地权限:读 repo、改文件、跑测试、装依赖、调用 git,有时甚至操作浏览器或桌面应用。我们接受这些权限,是因为这类工具需要足够上下文才能提高效率。

但权限越高,客户端越应该“无聊”。所谓无聊,不是功能少,而是行为可解释、可审计、可预期。要检测自定义 API 网关,可以用显式字段、清晰文档、release note、遥测开关或策略说明。把分类信号藏进系统 prompt 的撇号和日期格式里,就会让开发者开始怀疑:如果这里可以藏一位标记,别处还会不会有类似行为?

这不等于证明它是恶意功能。它更像是一个信任设计失误:目标可能合理,但表达方式损害了信任。

对普通用户有什么影响

原文的判断是,大多数普通用户不会触发。

如果你没有设置 ANTHROPIC_BASE_URL,或者使用官方 Anthropic API endpoint,这条路径不会改动日期提示。真正需要留意的是那些把 Claude Code 接到自定义服务上的用户。

包括:

  • 公司内部统一网关
  • 本地 debug proxy
  • 多模型 router
  • 第三方 Claude API reseller
  • 研究人员搭的中间层

这些场景本身不一定有问题。问题是,客户端可能会把 hostname 分类结果编码进发给模型的系统上下文。

这个信号本身也不强

从对抗角度看,这种标记很容易绕过。换 hostname、换时区、包一层启动脚本、patch 客户端,都能让信号失效。

所以它对真正有意规避检测的人帮助有限。反而更容易标记到一批“正常但使用方式不标准”的开发者:他们可能只是用了公司代理、调试网关,或者为了成本和延迟接了一个 router。

这也是原文最值得注意的地方:隐蔽标记并没有显著提高安全性,却明显增加了信任成本。

我会怎么判断这类工具

这篇文章给编码 agent 的选择提供了一个很实用的检查角度。

不要只看模型能力,也要看客户端行为:

  1. 它会不会把本地环境信息放进系统 prompt?
  2. 哪些环境变量、时区、hostname、路径会进入请求?
  3. 是否有文档解释这些字段?
  4. 是否有可关闭的遥测和清晰的日志?
  5. 客户端更新后,是否能追踪行为变化?

AI 编码工具正在变成本地开发环境的一部分。它们不只是聊天窗口,而是能读写工程资产的执行器。这样的工具可以有风控,可以保护模型,也可以限制滥用;但这些行为越接近本地权限边界,就越应该明说。

工程信任通常不是靠口号建立的,而是靠那些很小、很普通、很可审计的地方。

这次争议里的“日期字符串”正好说明了这一点:最让人不安的不是日期,而是一个高权限开发者工具选择用不可见的方式表达自己知道了什么。

References

  1. Thereallo, Claude Code Is Steganographically Marking Requests