这几天,AI 圈最热的瓜,不是哪个模型又跑赢了榜单,而是 Claude Code 被曝出“隐藏标记”。
很多人第一反应是:这是不是木马?是不是后门?是不是间谍软件?
先别急着下结论。
这件事真正可怕的地方,不在于它有没有达到传统意义上的“木马”标准,而在于:一个被开发者赋予本地文件读写、代码修改、命令执行权限的 AI 编程工具,居然可以在用户几乎无感知的情况下,对本地环境做识别,并把结果藏进系统提示词里。
换句话说,问题不是“它有没有偷走你的代码”。
问题是:它能不能在你不知道的情况下做这种事。
事情大概是这样
有开发者逆向 Claude Code 后发现,从某个版本开始,Claude Code 内部存在一段隐藏逻辑。
这段逻辑会检查用户的环境,比如系统时区、代理地址、网关域名等信息。如果命中某些条件,它不会直接弹窗告诉你“你所在地区不可用”,也不会明明白白写一条日志。
它做的是更隐蔽的一件事:把一些几乎肉眼不可见的标记,塞进 Claude Code 发给服务器的系统提示词里。
比如日期格式从横杠变成斜杠,或者把一句英文里的撇号替换成视觉上很像、但 Unicode 编码不同的字符。
普通用户看不出来。
模型可能也不在意。
但服务端能识别。
这就是争议的核心:它不是粗暴地上传一个“我是中国用户”的字段,而是用类似“隐写”的方式,在正常文本里藏了一个信号。
更敏感的是,Claude Code 不是普通网页,不是资讯 App,也不是一个只能看看内容的聊天窗口。
Claude Code 是 AI 编程 Agent。很多开发者给它的权限非常高:读项目、改代码、执行命令、安装依赖、跑测试,甚至接触密钥、配置、服务器脚本。
所以开发者炸了。
因为大家给它的不是普通信任,而是接近“把项目钥匙交给它”的信任。
最敏感的,是那句日期
这次风波里,最有代表性的细节,是一句看起来极其普通的话:
Today’s date is 2026-06-30.
正常人看到这句话,不会有任何感觉。
不就是今天日期吗?
但公开技术分析显示,Claude Code 可能就在这句“日期提示词”里做了手脚。
第一层手脚,是日期分隔符。
如果检测到用户系统时区是中国相关时区,比如 Asia/Shanghai 或 Asia/Urumqi,日期格式可能会从:
2026-06-30
变成:
2026/06/30
在人眼里,这只是日期格式不同。
但在机器眼里,这就是一个信号:这个用户可能处在中国相关时区。
第二层手脚,更隐蔽。
它动的是 Today’s 里面那个撇号。
很多人以为英文里的撇号就是一个字符,其实不是。在 Unicode 里,有很多长得几乎一样、但编码完全不同的撇号。
比如普通 ASCII 撇号、右单引号、修饰字母撇号、修饰字母角分符。
你肉眼看,几乎看不出来。
但服务器一读,完全不同。
根据公开逆向分析,这几个符号可以被用来编码不同含义:是否命中特定域名、是否命中 AI 实验室关键词、是否同时命中两类条件。
也就是说,一句平平无奇的:
Today’s date is 2026-06-30.
就可能变成一个“暗号包”。
日期分隔符告诉你:时区是不是中国相关。
撇号告诉你:代理地址、网关域名、AI 实验室关键词是否命中。
更重要的是,这种信息不是通过一个显眼的字段发送的。
它不是:
china_user: true
也不是:
proxy_detected: true
而是藏进了系统提示词里。
它看起来仍然像一句普通英文。
人看不出来。
但服务端可以识别。
这就是所谓“隐写”:把秘密信息藏进正常文本里。
公开分析还提到,这套机制可能从 Claude Code 2.1.91 版本就已经存在,而该版本发布时间是 2026 年 4 月 2 日。逆向者是在 6 月 30 日左右把它扒出来的。也就是说,从 4 月初到 6 月底,这套机制至少存在了将近三个月。
还有技术文章称,相关域名清单包含 147 个条目,另有 11 个 AI 实验室关键词,涉及中国科技公司、AI 实验室、云服务、代理和中转服务等类别。
这些数字放在一起,它就很难再被简单理解成一个“小 bug”。
它更像是一套长期存在的风控识别机制。
Anthropic 怎么解释?
Anthropic 这边的解释也很明确:这不是为了攻击用户,而是为了反滥用。
Anthropic 员工回应称,这是 3 月启动的一个实验,目的是防止未授权转售账号,以及防止“模型蒸馏”。
所谓模型蒸馏,简单说就是:用大量请求去套一个强模型的输出,再拿这些输出训练自己的模型。对于顶级 AI 公司来说,这就是核心资产被“抽血”。
这个背景并不是空穴来风。
就在此前,Anthropic 指控阿里相关操作者在 2026 年 4 月 22 日到 6 月 5 日之间,通过近 2.5 万个账号,与 Claude 进行了超过 2880 万次交互,用于所谓模型蒸馏。
站在 Anthropic 的角度,它当然有理由防。
Claude 在中国大陆本来就不是正常开放服务,Anthropic 也公开收紧过对受限地区、相关公司和实体的访问限制。再加上美国 AI 公司和中国 AI 公司之间,本来就有越来越强的技术竞争和合规对抗。
所以 Anthropic 的逻辑大概是:
“我不是针对普通开发者,我是在防倒卖、防绕路、防大规模蒸馏。”
这个理由能不能理解?
能理解。
但能不能接受?
这是另一回事。
真正让人不舒服的,不是“限制”,而是“隐藏”
如果 Anthropic 明确告诉用户:
“我们会检测代理、网关、地区、异常调用,用来反倒卖和反蒸馏。”
大部分人可能不爽,但至少知道规则。
如果它直接限制地区访问,也可以理解,毕竟这是它的商业和合规选择。
但这次让开发者不舒服的是:它没有用一个透明的产品机制,而是把检测逻辑藏在客户端里,再通过系统提示词的细微字符差异回传信号。
这就很微妙了。
因为从用户视角看,这不是“我被规则限制了”。
而是“我不知道这个工具还在做什么”。
尤其对于开发者工具来说,这个边界非常重要。
浏览器收集一点统计信息,用户已经很敏感了;手机 App 申请多几个权限,大家也会警惕;但 AI 编程 Agent 的权限,比很多 App 大得多。
它能进入你的代码仓库。
它能看你的业务逻辑。
它能改你的文件。
它能执行命令。
它未来甚至可能接管部署、运维、数据库迁移、线上排障。
在这种工具里,任何隐藏逻辑都会被放大。
因为开发者会自然地追问一句:
今天你只是检测时区和代理,那明天呢?
今天你只是改一个系统提示词字符,那明天能不能改我的依赖?能不能影响我的代码生成?能不能在某些地区、某些公司、某些项目里表现得不一样?
哪怕 Anthropic 没有这么做,信任也已经被击穿了一次。
阿里为什么直接禁用?
这件事发酵后,阿里很快按下了禁用键。
据媒体报道,7 月 3 日,阿里内部已将 Claude Code 列入高风险软件名单。自 7 月 10 日起,阿里将全面禁止内部员工在办公环境下使用 Claude Code,并推荐使用自家的 Qoder 作为替代方案。
这个动作其实很有代表性。
对个人开发者来说,这可能只是一个“瓜”。
但对企业来说,这就是合规风险。
企业最怕的不是某个工具今天有没有造成损失,而是它是不是存在不可解释、不可审计、不可控的行为。
尤其是代码工具。
公司代码、内部文档、配置文件、业务数据、API Key、部署脚本,都可能出现在开发环境里。
一旦一个工具被发现存在隐藏检测和隐形标记机制,企业安全团队很难只听供应商一句“这是反滥用实验”就放心。
因为安全部门看的不是动机,而是能力。
动机可以解释。
能力必须约束。
不只是阿里,海外大厂也在收紧
如果这件事只发生在阿里身上,它可能还会被解读成中美 AI 竞争背景下的个案。
但如果把过去几个月的海外消息连起来看,会发现企业对 Anthropic/Claude 工具的谨慎,其实早就开始了。
微软就是一个很典型的例子。
此前有报道提到,微软内部曾大规模试用 Claude Code,但随后开始取消或收紧部分 Claude Code 内部许可,推动工程师转向 GitHub Copilot CLI。这个动作未必是因为“后门门”,更多和成本、工具主导权、内部工程体系整合有关,但它说明一个问题:哪怕是海外科技巨头,也不可能无限制地把研发工具交给外部闭源 AI Agent。
更敏感的是,微软还曾因为 Anthropic 的数据留存要求,限制员工使用 Claude Fable 5。报道称,微软法务团队担心客户数据和机密信息可能因为模型的数据留存政策而产生风险。
金融机构更谨慎。
4 月,高盛移除了香港银行员工对 Anthropic Claude 的访问。报道中提到,员工此前可以通过内部 AI 平台使用 Claude,但后来不再可用,ChatGPT、Gemini 等其他模型仍在平台中。
6 月,摩根大通也被报道停止香港员工访问 Anthropic 的 AI 模型。原因同样与 Anthropic 使用条款、地区支持、数据安全和合规风险有关。
这几件事不是同一个原因,也不能简单说成“海外大厂也因为 Claude Code 后门集体禁用”。
但它们共同指向一个趋势:
AI 工具正在从个人效率工具,变成企业基础设施。
一旦进入企业基础设施,它就不再只接受“好不好用”的评价,而必须接受安全、合规、数据留存、审计、供应链和地区政策的全面审查。
更极端的例子,是美国政府对 Anthropic 高级模型的出口管制。6 月 12 日,Anthropic 公开表示,美国政府曾要求其暂停 Fable 5 和 Mythos 5 对外国国民的访问,甚至包括 Anthropic 自己的外籍员工。虽然相关限制后来有所调整,但这件事说明,前沿 AI 工具已经不只是商业产品,也正在被纳入国家安全和出口管制视野。
所以 Claude Code 这次风波,不只是一个软件安全事件。
它是 AI Agent 时代企业信任体系的一次集中爆发。
这件事给所有 AI 工具提了个醒
过去大家讨论 AI 编程工具,最关心的是三个问题:
好不好用?
能不能省人?
代码质量行不行?
但 Claude Code 这次风波之后,第四个问题会变得越来越重要:
这个工具,值不值得信任?
未来 AI Agent 会越来越强。它不再只是“帮你补全几行代码”,而是能读项目、拆需求、改文件、跑命令、提 PR、查日志、连服务器。
这意味着 AI 工具正在从“软件”变成“协作者”,甚至变成“半个员工”。
那它就不能再只用普通 SaaS 的透明度标准来要求自己。
它需要更高的可审计性。
哪些信息会被采集?
哪些本地环境会被检测?
哪些提示词会被修改?
哪些行为会上传?
哪些功能可以关闭?
企业能不能本地部署?
安全团队能不能审计二进制或关键逻辑?
这些问题,以前可能只有大公司关心。
现在,每个开发团队都要关心。
这不是 Claude 一家的问题
说实话,今天出事的是 Claude Code,明天也可能是任何一个 AI Agent。
因为所有 AI 公司都面临同一个矛盾:
一边,它们要保护模型能力,防止账号倒卖、接口滥用、模型蒸馏。
另一边,它们又希望用户把越来越多权限交给 AI,让 AI 进入代码、文件、终端、数据库、云平台。
这两个目标天然冲突。
你想要更多控制,就必须更透明。
你想让用户交出更多权限,就必须承担更高的信任成本。
不能一边让开发者把项目钥匙交给你,一边在工具里偷偷塞隐藏逻辑,然后说“这是为了安全”。
安全不是遮羞布。
安全更不是绕过用户知情权的理由。
对普通开发者来说,应该怎么做?
第一,不要把 AI 编程工具当成普通聊天机器人。
能读写本地文件、能执行命令的 Agent,本质上已经是高权限软件。安装它之前,就应该按开发工具、运维工具、甚至安全工具的标准去看待。
第二,敏感项目不要直接裸奔。
公司核心代码、生产配置、密钥文件、客户数据,不要随便暴露给任何闭源 Agent。能隔离就隔离,能容器化就容器化,能用测试仓库就别直接上生产仓库。
第三,企业内部要有 AI 工具白名单。
不是哪个工具火就让员工随便装。AI 编程工具未来会变成研发基础设施,越是基础设施,越需要准入、审计和权限管理。
第四,不要迷信大厂。
大厂不等于永远透明,大厂也会为了竞争、合规、风控做激进选择。越是先进工具,越要问一句:它到底在我机器上做了什么?
最后的问题
Claude Code 这次风波,表面上是一个“后门门”。
但更深层的问题是:AI Agent 时代,用户和工具之间的信任关系变了。
以前,一个工具不好用,最多卸载。
现在,一个 AI Agent 不透明,可能意味着它已经进入你的代码、你的业务、你的工作流,甚至你的服务器。
这才是所有开发者真正应该警惕的地方。
AI 公司当然可以反滥用。
当然可以反倒卖。
当然可以反蒸馏。
但有一条底线不能破:
你不能用“安全”的名义,把用户变成被暗中标记的对象。
因为 AI 编程工具最值钱的不是模型能力。
是信任。
一旦信任没了,再强的模型,也会变成企业安全清单上的高风险软件。
夜雨聆风