Anthropic 最强的 Fable 5 限时免费,就 7 天——7 月 7 号前 Pro / Max / Team 在周额度 50% 以内直接跑,之后转积分。 但国内用户先别急着乐:这两天 Claude Code 刚被扒出偷偷加了识别代码,靠 Asia/Shanghai、Asia/Urumqi 时区加日期格式这些信号,专挑走中转的大陆用户,一批批封号。 一边防得死死的,一边喊最强模型限免——这波挺魔幻。

翻了下 claude code version 191 的源码，感觉从技术角度看，Anthropic 这个反蒸馏机制设计还是挺精妙的。 Claude Code 有段提示词是这样。 return `Today${n}s date is ${r}.`; 他对这句做了隐写，用肉眼分不出的字符，把系统时区和代理端点身份偷偷编码进了系统提示词。 触发条件是当你设了第三方中转 ANTHROPIC_BASE_URL 且不是 时。 所以如果你是官方直连用户，则并不会受到影响。也就是说最近的封号潮与此无关。 它编码了 3 个 bit，来自两个独立维度（时区 1 bit + 撇号 2 bit）： 1）时区，在 Asia/Shanghai 或 Asia/Urumqi 时，日期分隔符从 2026-06-30 偷偷变成 2026/06/30 2）那个撇号 ' 有四种写法，人眼基本看不出区别。 - ' (U+0027 普通)，普通第三方端点 - ' (U+2019)，命中"域名白名单" - ʼ (U+02BC)，命中"国产大模型关键词" - ʹ (U+02B9)，域名 + 实验室都命中 这三个维度是独立编码的。哪怕你的中转域名不在白名单、也不含关键词，只要系统时区是上海/乌鲁木齐，分隔符照样变斜杠——也就是"中国时区 + 任意第三方端点"的用户全员会被打上时区这一维的标记。 匹配逻辑是这样。域名是后缀匹配（host === d || host.endsWith("." + d)），白名单第一个就是 cn，所以任何 .cn 结尾的 host 一网打尽，不是逐个域名去列；关键词是子串包含（host.includes(kw)），host 里只要出现 deepseek 字样就命中，不用精确匹配；时区取的是系统时区（Intl…resolvedOptions().timeZone），不是 IP 地理位置。 更骚的是反混淆，两份名单用 XOR(key=91)+ base64 藏起来，专门躲 strings。解码就是 base64 decode 之后逐字节异或 91，源码里那个 LKi 去混淆后长这样： ```js // 源码里的解码器（去混淆版，就是 LKi） const decode = (b64) => [...Buffer.from(b64, "base64")] .map((byte) => String.fromCharCode(byte ^ 91)) // key = 91 .join("") .split(","); // 逆运算就是打包时的编码器 const encode = (list) => Buffer.from([...list.join(",")].map((c) => c.charCodeAt(0) ^ 91)).toString("base64"); encode(["deepseek", "zhipu"]); // → "Pz4+Kyg+PjB3ITMyKy4=" decode("Pz4+Kyg+PjB3ITMyKy4="); // → ["deepseek", "zhipu"] // 拿真名单开头验一下，key=91 对得上 decode("Pz4+Kyg+PjB3NjQ0NSgzNC93"); // → ["deepseek", "moonshot", ...] ``` 147 个域名白名单:".cn" 顶级域、字节/阿里/百度/网易/快手、 外加一大票 Claude 中转站(anyrouter、88code、yunwu、aihubmix、dmxapi…) 11 个实验室关键词:deepseek / zhipu / moonshot / minimax / stepfun / baichuan / 01ai / dashscope / volces … 选「今天的日期」这句话做载体也很鸡贼。这个标记藏在 system prompt 正文里，不是 HTTP header、也不是 metadata。中转站一般会重写、过滤 header，但几乎没人会去动日期这类的自然语言，所以这是个洗 header 洗不掉的水印。而且 currentDate 是 user context 里和 claudeMd、userEmail 并列的字段，每个请求必带，标记 100% 稳定出现；撇号和分隔符的变化又语义无损，模型读起来一模一样，用户 diff 也基本看不出，隐蔽性拉满。 证据是怎么闭环的，这才是题眼。标记跟着请求走，当一个中转站或蒸馏管道最终回连 Anthropic 官方 API 转售 Claude 时，这条请求带着标记又流回了 Anthropic 自己的服务器。 于是 Anthropic 在自己的日志里就能读到：这条"直连我"的请求，日期是 2026/06/30（斜杠 = 中国时区）+ 撇号是 ʹ（U+02B9 = 域名和 deepseek 关键词都命中），铁证——源头是一个中国时区、配了国产大模型中转的客户端。 它不需要主动探测，让流量自己招供，只要请求最终回到 Anthropic，身份就自证了。这样就能清楚地知道哪些渠道流向了中国、被中转站转售或被大厂蒸馏，并且留下充足证据。 想自己验的话，逻辑都在 cli.js（2.1.191，混淆名每版会变）：检测函数 jqd()（:245688）→ 选字符 Wqd()（:245701）→ 拼日期 MKi()（:245707）；gate 是 Yfn()（:102664）；落点在 currentDate: MKi(eHe())（:250252）；XOR 名单解码器 LKi()，key = 91。

其实闭源 Agent 出现安全问题的事已经不是一次两次了，看看过去这几个月都发生了啥吧，很多很严重的信息泄露最终也只是被厂商搪塞过去，所以还是更推荐大家用开源 Agent： 1. Claude Code 这个最离谱，花样最多： (1) 大约从 v2.1.36 起，CC 会往请求里插入动态字段，导致第三方 API 的 prompt cache 全面失效 这个持续时间是最长的，甚至直到今天都有这个迹象：具体是每条发往 /v1/messages 的请求，都会在 system prompt 最前面强行插入一行文本，形式是 x-anthropic-billing-header，里面带个 cch= 参数，而且这个值每条请求都不同。注意，这根本不是 HTTP 请求头，而是直接写进 prompt 正文前缀里的。 这个字段官方 Anthropic 服务端能识别并做特殊处理；但是当用户把 ANTHROPIC_BASE_URL 指到第三方兼容接口时，第三方通常是按整段 prompt 来做缓存的。前缀一轮一变，cache key 就对不上，prompt cache 会直接命中失败，导致响应延迟、费用都大幅上涨。 即使模型厂商和各个开源工具很多自那以后主动做了适配，Anthropic 似乎依然在不断更新这个机制，直到今天将第三方 API 接入 CC 依然会破坏缓存命中。这也是为什么很多第三方评测榜单里，Claude Code 的缓存命中率都是最低的。 (2) 反蒸馏：向上下文偷偷插入根本不存在的 fake tools 时间是 2026 年 3 月 31 日前后，随着 npm 包源码和 source map 泄漏被实锤。 当满足特定条件时，客户端发出的请求会带上 anti_distillation: ['fake_tools']。然后由 Anthropic 服务端往你的模型上下文里，强行写入一堆本地根本不存在的虚假工具定义。 这就导致用官方流量做蒸馏、抓包或搞中转的一方，会把这些假工具一并吃进训练样本，直接被下毒。更恶心的是，客户端本地看不到完整内容，普通用户根本没法按本地规则把它过滤掉。 可能有朋友会说：“打击中转不是好事吗？” 错了，这个 fake tools 甚至会严重影响正常用户的使用。模型在推理时看到上下文里有这些莫名其妙的假工具，有时就会脑抽去调用它们，导致调用失败、陷入死循环报错甚至任务直接拒绝执行。网上经常能看到有人吐槽 CC 突然“逃离原生家庭”“不认主、发神经”，有可能就是这个机制的后果。 (3) 自定义网关场景下搞 Unicode 隐写，偷偷回传你的环境特征（被按后门通报） 时间是 v2.1.91（约 2026 年 4 月 2 日），2026 年 6 月 30 日被社区逆向公开。官方辩解称这是 3 月开始的实验，直到 7 月 1 日版本才移除。 Claude Code 客户端会偷偷读取系统的时区（重点检测是不是 Asia/Shanghai、Asia/Urumqi 等国内时区），去对照二进制里混淆存放的域名和关键词，然后篡改 system prompt 里 Today's date is ... 的写法。比如检测到中国时区，就把日期分隔符从 - 换成 /，或者在几种肉眼和常规模型完全看不出区别、但底层字节编码不同的 Unicode 撇号之间来回切换。 这些字符人眼和模型看都只是一串普通日期，但 Anthropic 在服务端是可以精准判断你是不是在用特定中转、是不是来自特定时区的。这种未经披露、在客户端利用隐写偷传信息的行为，几乎等同于间谍软件，可官方 changelog 同样只字不提。随后阿里等大厂在内部下发了禁用通报，工信部更是直接按“后门程序”通报定性。 这个事件性质极其恶劣。相当于在你的本地里塞了个间谍探针，绕过审查直接把本机信息回传给他们，现在曝出的只是系统时区，你实际上根本没法判断他们还会回传什么。这也是为什么一个看似针对特定区域的后门，却引来全球大厂的警惕。 还有两个非 CC 直接偷传信息，但同样是隐私风险的： (4) 2026 年 9 月蒸馏报告：名为指责非法蒸馏，实则自曝对用户流量的全面监视 2026 年 9 月 10 日，Anthropic 发布了《Detecting and countering misuse of AI》（2026 年 9 月打击滥用报告）。里面七类违规行为之一是非法蒸馏，覆盖了 2025 年 12 月至 2026 年 8 月。 报告表面上是在点名指责蒸馏行为，但 Anthropic 自己公布的监测手段，直接证明了它一直在全方位监控流量： -通过元数据和异常流量特征把代理中转节点归类，直接把一批账号打包封杀。 -直接翻看中转会话里的具体聊天内容。 报告自己大方承认：部分被中转的会话包含真实姓名、邮箱、企业机密数据和开发者密钥凭据。前有客户端在搞隐写打标记，后有服务端全盘审读会话正文，两头对齐，坐实了其深度监控用户信息的事实。 (5) 借安全之名取消“零留存”，英伟达、Palantir 等公司缩紧政策 从 2026 年 6 月起，Anthropic 对旗下主力商用大模型调整了数据留存政策：用户的 prompt 和输出内容默认在服务器保留 30 天用于所谓的“安全审查”，被系统标出异常的保留更久；而且这类模型不再提供原本的 Zero Data Retention（零数据留存承诺）。 这个政策直接导致诸多大厂缩紧对 Anthropic 服务的使用： NVIDIA：直接把 Anthropic 模型的使用范围限制在敏感度较低的任务（比如公开开源项目），而供应链监控等核心内部研发明确“不用或少用 Fable”。NVIDIA 企业 AI 副总裁 Justin Boitano 直言，零数据留存应当是默认必须开启的（别忘了 NVIDIA 还是 Anthropic 的投资方）。 Palantir：态度极度强硬，要求必须给不可撤销的零留存协议兜底，才肯把该模型集成进自己的产品给客户用。 Booz Allen Hamilton：作为网络安全和军工服务商，直接明令禁止员工在涉及专有安全代码的任务中使用 Anthropic 商用模型。CTO Bill Vass 直截了当表示：担心核心代码资产被模型在后台给偷学了。 2. Grok Build：这也是个重量级。只要发一句“OK”，后台直接全量上传代码库 时间是 2026 年 7 月，涉及客户端 CLI v0.2.93，被 Cereblab 抓包发现。 你在对话里哪怕只是让它回复一句“OK”，并明确告知不要读取任何本地文件，客户端仍会另开一条与正常对话完全独立的上传通道（POST /v1/storage），往 xAI 控制的 Google Cloud 存储服务器上直传完整的 git bundle。 它偷的不只是当前文件夹里可见的代码，而是把你的整段 Git 历史提交记录、全部分支打包端走。抓包数据显示：一次正常的模型对话只有 192KB，但这条后台存储上传通道整整偷传了 5.1GB。 最离谱的是，客户端界面上的那些所谓“隐私模式”“不参与改进模型”的开关纯粹是个摆设，根本挡不住上传。是否上传完全由 xAI 云端服务器下发的配置决定。更有开发者随手在系统的用户目录下启动了 Grok Build，日志随后直接开始出现用户的 SSH 私钥和密码库路径。 事后 Musk 出来洗地，轻描淡写说此前上传的数据会删除，并将 Grok Build 以 Apache 2.0 开源。可一个事实是，那段上传代码至今仍留在客户端里，意味着未来他们仍然有恢复这个渠道的可能。 3. 智谱 ZCode：偷家式全盘加密直传，事后打发一张重置卡 时间是 2026 年 9 月 18 日，博主 ferstar 在清理本机的 ~/.zcode 目录时，通过逆向和抓包排查把底裤扒了下来，并有非常多的开发者在本机完成复现。 ZCode 在用户登录后，会在后台把你当前的工作区打包成快照。打包的内容涵盖了完整的 .git 历史记录、大文件存储 LFS 以及本地操作日志 reflog。打包完成后先加密，然后直接回传到阿里云 OSS。最致命的是：解密私钥全在智谱云端，本地设置完全没有提供关闭选项，隐私政策里对此也只字不提。 ferstar 实测抓到的一份快照就包含整整 4.2 万个文件，加密后达到 313MB，其中 .git 目录占了 80% 以上。链路非常清晰：先找 .ai 拿 OSS 上传凭证和 RSA 公钥，本地打包加密后直传对象存储。 智谱的回应更是一次公关灾难：他们辩称这是“代码库索引/Repo Wiki”功能在上线初期默认开启导致的，声称云端生成后立刻销毁绝不留存，目前已修复，并承诺后续开源接受监督。 可事实上直到 v3.14.0 版本才标明推出修复，此前根本没修。 不过好在他们贴心的给用户补偿了一张重置卡。 一张重置卡哦。这么大的数据泄露风险，还是主要做 toB 端的服务，最后就补偿一个重置卡。付费用户真是有福了。 ———————————— 总而言之，大家日常还是尽量使用开源的 Agent，开源 Agent 代码都是人人可查的，相对安全风险低很多——但不意味着等于 0 。只要你还在使用厂商的云服务（比如 API ），你的数据就还得经过厂商，主动权仍在厂商手里。这也是目前 AI 服务中用户和厂商明显不对等的一个体现，希望未来情况能有所改善。

这他妈的努力赚钱努力学习半夜还在学就是为了防止这些人的出现 我现在就憋着一口气 老娘一定要登顶 这种骚扰一定意义上也是说明我太弱了 不过我也是脾气好 😀