用AVL Code验证“Claude Code内置隐藏机制，专门检测中国用户”的传言

近日，Reddit
上一篇关于 Claude Code 的帖子引发关注。原帖称，从 Claude Code 2.1.91
开始，客户端中加入了一套隐藏检测逻辑：当用户配置代理或自定义上游地址时，它会检测系统时区、代理地址以及与中国 AI
服务相关的关键词，并通过系统提示词中的日期格式和 Unicode 字符差异传递检测结果。

这个问题适合用技术方式核验。我们收到
AVL Code 用户反馈：其使用 AVL Code 对本机安装的 Claude Code
样本做了逆向分析。我们结合反馈中的分析过程和截图，对相关结果做了整理，重点确认三件事：相关代码是否存在，检测条件是什么，客户端逆向能够证明到什么程度。

本文中的分析过程和截图来自 AVL Code 用户反馈，我们在此基础上做了梳理和复核。

AVL Code 用户反馈的逆向分析过程截图，围绕 Reddit 原帖中的技术指控逐项核验。

验证结论

本次逆向确认了以下现象：

· 客户端中存在针对 Asia/Shanghai、Asia/Urumqi 的时区判断；

· 客户端会读取 ANTHROPIC_BASE_URL，并解析其中的 hostname；

· 客户端内置了一组中国相关域名和中国 AI 服务关键词；

· 检测结果会影响系统提示词中的日期格式和撇号字符；

· 这些差异不是普通可见字段，而是通过细微的文本变化表现出来。

需要说明的是，客户端逆向主要回答“这套机制是否存在、如何生成标记”这两个问题。至于这些标记在后续链路中如何使用，还需要结合请求样本、服务端行为或官方说明继续判断。

因此，更准确的表述是：Claude Code 客户端中存在一套与中国相关运行环境、代理上游和 AI 服务关键词有关的隐式标记机制。 如果把“专门检测中国用户”理解为检测中国时区和中国相关代理环境，客户端代码支持这一判断；如果理解为完整身份识别、恶意监控或代码窃取，目前没有证据支持。

原帖指控的核心内容

Reddit 原帖的核心说法可以概括为四点：

· Claude Code 从 2.1.91 起加入了混淆后的检测逻辑；

· 检测对象包括中国时区、中国相关域名、中国 AI 服务关键词；

· 检测结果不会以显式字段出现，而是编码进系统提示词；

· 编码方式包括日期分隔符变化和 Unicode 撇号替换。

原帖把时间点指向 Claude Code 2.1.91。无论该机制从哪个具体版本开始出现，更关键的问题是：如果客户端确实在模型请求上下文里附带环境标记，用户和企业安全团队应该能够通过文档或配置项清楚知道这件事。

代码层面看到什么

在用户反馈的分析过程中，AVL Code 先定位与系统提示词、日期注入、环境变量读取相关的代码，再对混淆字符串和调用链做还原。主要发现如下。

时区检测

逆向结果显示，相关逻辑会调用：

Intl.DateTimeFormat().resolvedOptions().timeZone

然后判断系统时区是否为：

Asia/ShanghaiAsia/Urumqi

单独读取时区并不罕见，很多软件都会这么做。这里需要关注的是，时区判断结果进入了后续的提示词编码逻辑，而不只是用于本地显示。

代理上游检测

代码还会读取：

process.env.ANTHROPIC_BASE_URL

如果该变量不存在，相关逻辑会直接返回；如果存在，代码会解析 URL 中的 hostname，并继续与内置域名和关键词列表进行匹配。

这说明该逻辑重点关注的是自定义上游、代理网关或中转服务场景。

内置域名和关键词

AVL Code 解码出的字符串列表中包含一批中国相关域名，以及一组中国 AI 服务关键词。例如：

baidu.comalibaba-inc.combytedance.netjd.comiflytek.comaliyuncs.comdeepseekmoonshotminimaxzhipubigmodelbaichuanstepfun01aidashscopevolces

逆向过程中，AVL Code 解码出一组中国 AI 服务关键词，用于判断代理 URL 是否关联特定服务。

提示词编码方式

验证结果显示，检测结果会影响系统提示词中的日期字符串和撇号字符。可以简化理解为：

条件

系统提示词中的表现

命中中国时区

日期从 2026-07-01 变为 2026/07/01

命中中国相关域名

撇号替换为 ’（U+2019）

命中中国 AI 关键词

撇号替换为 ʼ（U+02BC）

同时命中域名和 AI 关键词

撇号替换为 ʹ（U+02B9）

补充说明(unicode码位)：这几个撇号肉眼几乎无法区分，但码位各不相同。正常文本用的是ASCII
撇号(U+0027APOSTROPHE）；上表三种替换依次为U+2019(RIGHT SINGLE QUOTATION
MARK)、U+02BC(MODIFIER LETTER APOSTROPHE)、U+02B9(MODIFIER LETTER
PRIME)——形近而码位独立，正是这类标记能被程序稳定区分的前提。

AVL Code 对逆向结果的总结：客户端机制可以确认，相关信号后续如何使用仍需结合更多证据判断。

这意味着什么

从安全分析角度看，这套机制本身不等同于代码窃取或恶意执行。本次验证没有发现它会扫描项目文件、主动上传仓库内容或执行额外命令。

但它确实会标记用户运行环境中的一些特征，包括时区、自定义上游地址以及代理 URL 中的特定关键词。这些信息虽然不是项目源码，但可以反映用户所在地区、访问路径和服务使用方式。

对 Claude Code 这类 AI 编程工具来说，这一点比较敏感。它不是普通网页应用，而是运行在开发者本机、能够读取文件、修改代码、执行命令、接入工具链的高权限软件。此类工具如果在请求上下文中加入环境标记，最好以明确、可审计的方式说明。

Claude
Code 官方文档说明，本地 Claude Code 为了与 LLM 交互，会通过网络发送用户提示词和模型输出；也会连接 Anthropic
记录延迟、可靠性和使用模式等运营指标，并提供关闭普通遥测的配置。本文讨论的机制不同于常规遥测字段，它更像是系统提示词中的隐式标记。因此，问题的重点不是“软件会不会联网”，而是“环境标记是否被清楚披露，用户是否能够理解和控制”。

可能用途与证据边界

这套机制可能有多种用途。比较常见的解释包括滥用检测、违规转售识别、代理中转识别、模型蒸馏风险识别，或合规相关的区域判断。

这些解释都有一定合理性，但都只是可能性。客户端逆向可以确认本地代码逻辑；至于这些标记在后续链路中如何被解析和使用，还需要结合服务端行为、请求样本和官方说明继续判断。

从产品和合规角度看，如果这类检测确实用于风控，较好的做法是写入公开文档：当用户配置第三方网关、代理或自定义 ANTHROPIC_BASE_URL 时，客户端可能收集必要的网络环境特征用于滥用检测。这样用户和企业安全团队才能在知情前提下做风险评估。

给用户和企业的建议

如果你使用 Claude Code，可以做几项基础检查：

· 检查是否设置了 ANTHROPIC_BASE_URL；

· 避免使用来源不明的 Claude 中转服务；

· 对闭源 AI 编程工具保留版本、安装包和配置记录；

· 在高敏感项目中使用隔离环境或受控工作区；

· 对企业环境中的 AI 编程工具做流量审计和供应链评估；

· 如果不需要普通遥测，可按官方文档关闭相应遥测选项，但这不等同于关闭本文讨论的隐式标记机制。

企业用户还应关注一个更大的问题：AI 编程工具已经参与代码读取、修改、测试、构建、提交和发布流程。对这类工具的要求不应只看模型能力，还要看可审计性、可控性、部署方式和数据边界。

为什么用 AVL Code 做验证

这次验证也说明了安全分析能力对 AI 编程工具的重要性。

普通编程助手可以帮助读代码、写代码、跑测试。但当问题变成“一个闭源工具里是否存在某段隐藏逻辑”时，需要结合二进制分析、字符串解码、调用链追踪和证据整理。

AVL
Code 内置了面向安全分析的能力，包括哈希与熵、字符串与 IOC 抽取、PE / ELF / Mach-O 解析、反汇编、反编译、YARA
匹配，以及会话式推理和本地工作区操作。本次分析就是一次典型的使用场景：从外部传言出发，回到本机样本和代码证据上，逐项确认哪些成立、哪些不能下结论。

最后结论

基于本次样本逆向，可以给出三个结论。

第一，客户端机制存在。Claude Code 中确实可以看到针对中国时区、自定义上游、中国相关域名和中国 AI 服务关键词的检测逻辑。

第二，编码方式存在。检测结果会通过日期格式和 Unicode 撇号差异进入系统提示词，而不是以显式字段展示。

第三，后续使用方式仍需更多证据。客户端代码可以说明这些标记如何生成；至于它们在服务端如何被使用，以及是否会影响账号状态或服务策略，还需要更多材料交叉验证。

因此，这件事最值得关注的不是某个单一结论，而是透明度问题。对高权限 AI 编程工具来说，环境检测和请求上下文标记应当清楚披露、可审计、可配置。只有这样，开发者和企业才能在充分知情的情况下使用工具。

我们在 avlcode.cn 等你，骑着驴，可验、可控。