专题：Undercover Mode 深度解读

编辑说明：Undercover Mode 的完整分析已合并至第 6 章：System Prompt 工程的第 6.8 节。

Undercover Mode 本质上是 Context Engineering 的一个应用——通过 Feature Flag 条件加载的提示词段落控制模型的身份暴露行为。将它放在 System Prompt 工程的语境下讨论，比作为独立专题更有助于理解其技术本质和设计定位。

快速概要

技术实现：纯提示词为主，但配合四层纵深防御机制——机械层/系统提示词层/指令层/UI 层独立防护，没有代码级别的身份隐藏。建议性而非强制性，SDK 调用方可覆盖。

编辑说明：Undercover Mode 遵循”无法强制关闭”的安全设计原则——工程师可以强制开启，但无法强制关闭它。这防止了”误操作”和”图方便”导致的安全疏漏。引用源码注释：“There is no force-off. This guards against model codename leaks.”

一处必须并列阅读的对照：v2.1.299（2026-10-14）起，官方确实给了一个移除 attribution 的开关——CLAUDE_CODE_ATTRIBUTION_HEADER=0，设在 Claude apps gateway 的 code policy 的 env 里，可移除 Claude Desktop 的 Code tab 与网关后 Claude Code 会话中的 attribution block。它与上面的”无法强制关闭”不是同一件东西，差别有三层：① 前者是管理员在网关策略层的开关，后者是源码层没有 force-off 路径；② 前者管的是展示用的 attribution block，不是 Undercover Mode 的 getAttributionTexts() 机械层；③ 前者可以被关掉这件事，恰恰说明”强制不可关”不是 attribution 这一类东西的普遍属性，而是 Anthropic 为模型代号泄漏这一个特定风险所做的选择。

换句话说，补上这条之后，本章”无法强制关闭”的论证不是被削弱，而是变硬了——它从”做不到”变成了”选不做”。

适用场景：Claude Code 作为 B2B 基础设施被嵌入其他产品时，终端用户不应知道底层实现。

伦理争议：白标商业实践 vs AI 透明性原则。核心分歧在于”不暴露技术细节”和”不承认自己是 AI”是否是同一件事。

影响边界：需先明确一个前提——Undercover Mode 只存在于 Anthropic 的内部构建中，在公开构建里会被 dead-code-eliminate 掉，对外部用户没有任何影响。这与下文的构建时隔离原则（process.env.USER_TYPE 而非运行时配置）是一致的：不是”开关默认关闭”，而是这段代码在公开产物里根本不存在。读者阅读本章时不必担心自己的 Claude Code 处于某种”身份隐藏”状态。

来源说明：「dead-code-eliminated from public builds」的表述来自第三方源码分析（claudefa.st，2026），本书未能取得 Anthropic 官方对该措辞的直接确认；但书中既有的构建时隔离与”仅 25 个内部仓库在白名单内”两处描述与之互相印证，故予采纳。

16.3.1 四层纵深防御架构

Undercover Mode 的设计遵循四个原则——强制开启（工程师可开启但无法强制关闭）、最小必要信息（只移除 Anthropic 内部信息，保留必要功能）、纵深防御（机械层/系统提示词层/指令层/UI 层四层独立防护）、构建时隔离（内部功能通过 process.env.USER_TYPE 而非运行时配置隔离）。

四层架构：

层级	实现机制	作用
机械层	getAttributionTexts() 返回空字符串，commit trailer 在物理上不存在（不是 CSS 隐藏）	物理层面的身份标识移除
系统提示词层	模型身份信息从上下文中移除	模型层不知道自己是 Claude Code
指令层	在 commit 任务提示词中明确禁止各类泄漏行为	行为层约束
UI 层	状态标识告知用户当前模式	用户知情权保障

编辑说明：四层架构基于掘金文章源码分析（2026）。

激活逻辑：Undercover Mode 的激活实现了三段式状态机：

条件	状态	行为
USER_TYPE !== 'ant'	OFF	外部用户，不启用
USER_TYPE === 'ant' && CLAUDE_CODE_UNDERCOVER	ON	内部用户显式启用
USER_TYPE === 'ant' && 无显式设置	Auto	自动检测仓库分类

Auto 状态下，系统检测仓库归属：内部仓库（‘internal’）→ OFF（内部开发不需要隐藏身份），其余 → ON。值得注意的是，白名单采用逐仓库枚举而非按组织级别判断——只有 25 个内部仓库允许显示真实模型代号，因为 anthropics 和 anthropic-experimental 组织下也有公开仓库，按组织级别判断会误伤。

16.3.2 监视门：当隐蔽性工程变成信任危机

2026-07-01，Reddit 用户 LegitMichel777 逆向分析 Claude Code v2.1.196 发现了一套独立于 Undercover Mode 的隐蔽 Unicode 隐写检测机制。这起事件与 Undercover Mode 形成了一种“黑暗镜像”关系——同样的工程 DNA（Feature Flag 条件注入 + 提示词级别的运行时标记），但应用方向完全不同。

技术实现：三层隐蔽链路——

1. 时区检测：检查系统时区是否为 Asia/Shanghai 或 Asia/Urumqi
2. 域名黑名单：匹配包含 147 个中国域名（百度、阿里、字节、美团、MiniMax、月之暗面、阶跃星辰等）的 XOR 加密黑名单（密钥 0x91）
3. Unicode 隐写回传：通过系统提示词中的 Unicode 字符变体回传标记——日期分隔符从 ”-” 变 ”/“（命中中国时区），引号从 ASCII 变 U+2019/U+02BC/U+02B9（区分普通用户/AI 实验室关联/两者均命中）

函数名经混淆：Crt, Rrt, e0t, Zup, edp, Vla。Anthropic 工程师 Thariq Shihipar 回应称”这是一项实验，明天就删”，代码于 7/2 在 v2.1.197 中回滚。

Unicode 标记叠加映射表：

Unicode 替换	原字符	标记含义
' → ʼ (U+02BC)	ASCII 单引号	命中中国域名（147 条目）
' → ʹ (U+02B9)	ASCII 单引号	命中 AI 实验室关联域名
' → ʼ+ʹ 叠加	ASCII 单引号	两者都命中
- → /	ASCII 连字符	命中 Asia/Shanghai 或 Asia/Urumqi 时区

影响范围：v2.1.91 ~ v2.1.196（2026-04-02 至 2026-06-29），近三个月。

官方回应时间线：Anthropic 技术人员 @trq212 在 X/Twitter 承认代码存在，用于”反滥用、反蒸馏”实验，自 2026 年 3 月启动，已合并回滚 PR，“次日发布版本中回滚”（v2.1.197，7/2）。

企业封禁潮：工信部 NVDB（2026-07-08）定性”危害严重”，建议立即卸载或升级。中国主要科技公司采取了一致行动：

企业	行动	时间
阿里	内部禁用 Claude 全系 → 全员卸载，推荐自研 Qoder CLI 替代	7/3→7/10
美团	通知程序员收敛外部 AI 模型调用	7 月初
京东	通知程序员收敛外部 AI 模型调用	7 月初
腾讯	将 Claude 移出大模型选择池	2025 年 11 月（提前）

社会影响持续：Hacker News 讨论 2400+ 分（罕见于编程工具安全事件），8 月仍有新文章讨论（2026-08-07 头条号），从技术事件升级为国家层面安全警告的案例。

黑暗镜像视角：Undercover Mode 的设计哲学是”工程师可开启但无法强制关闭”——这防止了模型代号泄露。但同样的哲学反转视角是”用户无法关闭被监视”——4/2 到 7/1 之间的所有用户都在不知情下被标记。拥有文件系统读写权限和 Shell 执行权限的代码代理，在用户不知情时用恶意软件级技术（XOR 混淆 + Unicode 隐写）采集环境信息——这不只是隐私问题，而是权限不对等导致的信任崩塌。

16.4 与反蒸馏机制的互补关系

编辑说明：本节为新增内容，基于腾讯新闻和头条文章源码分析（2026）。

Undercover Mode 与第 23 章讨论的反蒸馏机制（Anti-Distillation）共同构成 Claude Code 的完整信息泄露防护体系：

机制	防护场景	攻击向量
Undercover Mode	开源贡献中的身份隐藏	防止在公开代码提交中暴露 Anthropic 内部信息
反蒸馏机制	防止输出流被用于模型训练	在模型输出中注入伪造工具调用、抽象化真实调用

两者互补——Undercover Mode 面向”输出内容的身份标识”，反蒸馏机制面向”输出内容被用于训练”。

2026 年 5 月，Anthropic 发布官方博文《Detecting and Preventing Distillation Attacks》，公开指控 DeepSeek、MiniMax、月之暗面使用数千虚假账户进行 1600 万次蒸馏交互。披露的技术细节包括：hydra cluster 架构（单个代理网络管理 20,000+ 虚假账户）、chain-of-thought 诱导检测、跨平台情报共享。

同时，反蒸馏水印技术也在发展——在模型输出中嵌入近不可见的”逻辑指纹”，若蒸馏模型出现在互联网且带有这些指纹，可溯源并激活 Kill-Switch。

⚠️ 事实修正：原文将 Project Glasswing 描述为”反蒸馏水印技术”，这是不准确的。Project Glasswing 是 Anthropic 于 2026 年 4 月发起的安全漏洞发现计划，核心驱动模型为 Claude Mythos Preview，用于自主发现关键软件高危零日漏洞。已发现数千个高危漏洞，包括 27 年的 OpenBSD 漏洞和 16 年的 FFmpeg 漏洞。联合 AWS、Apple、Google、Microsoft、NVIDIA 等十余家巨头。Project Glasswing 与反蒸馏无直接关联，属于安全研究范畴。

反蒸馏联盟的实际机制：2026 年，OpenAI/Anthropic/Google 通过 Frontier Model Forum 进行反蒸馏合作，核心措施包括：(1) 情报共享——共享异常流量模式检测和蒸馏行为标识；(2) 流量风控——检测自动化克隆请求，Anthropic 已完全封锁中国公司使用 Claude，公开点名 DeepSeek、Moonshot、MiniMax 使用 hydra cluster 架构（单网络管理 2 万+虚假账户）进行 1600 万次蒸馏交互；(3) 技术防御——假工具注入 + 推理链摘要（章节已覆盖）。水印技术仍处于发展阶段，尚未标准化。

16.4.1 服务端侧：Preserved thinking 与反蒸馏的运营化

上一节讨论的反蒸馏手段都是客户端侧的——在 Claude Code 里注入假工具定义，污染竞品采集到的训练数据。2026 年 9 月，Anthropic 把反蒸馏做进了 API 协议层，这是两条相互独立、目标也不完全相同的防线。

Preserved thinking：官方对这一机制的命名，定义为”较新 Claude 模型的一项属性，用于防范蒸馏”。它决定模型能否使用调用方在后续轮次里回传的某个思考块。自 Claude Fable 5.1 起，当请求中带回 thinking 或 redacted_thinking 块时，API 会校验该块的 signature，执行两项彼此独立的检查：

检查	校验内容	生效范围
模型检查（model check）	该块是否由当前模型或更早的模型产生。Fable 5.1 能读 Opus 5 的思考块，Opus 5 读不了 Fable 5.1 的	所有账号
前缀检查（prefix check）	该块之前的顶层 system、tools、messages（合称”前缀”）是否与产生该块时一致	2026-08-31 00:00 UTC 及之后创建的账号默认强制

前缀检查封堵的攻击面值得单独说明：攻击者在思考块之前编辑对话内容（系统提示、工具定义或历史消息），诱导 Claude 把先前的推理以明文重新打印出来，从而规模化抽取推理轨迹。这是公开记录过的蒸馏手法，也恰好是客户端侧投毒覆盖不到的一侧——投毒只能让采集到的数据变脏，协议层校验则让数据根本产不出来。

两种失败模式：前缀不一致时，该块及其后的所有思考块失效，API 按调用方的选择处理——

• "error"（新账号默认）：返回 400，错误信息形如 messages.1.content.0: Invalid signature in thinking block. The block is bound to a different conversation.
• "drop_block"：请求照常成功，受影响的思考块被移除，模型在看不见自己上一轮推理的状态下继续作答。

选择字段为 thinking.block_binding.prefix_mismatch_behavior，需配合 beta header thinking-binding-controls-2026-08-01 使用。

⚠️ 工程陷阱：未带该 beta header 时，丢弃是静默的——响应里没有任何提示。加上 header 后，每个响应都会带一个顶层 input_transformations 数组，逐条列出被丢弃的块（"type": "thinking_dropped"，reason 为 prefix_binding_mismatch 或 model_binding_mismatch，并给出该块在 messages 中的路径）。这是本机制最难排查的一面：集成方只会感到”模型突然变笨了”，而拿不到任何报错。Anthropic 官方也提示，遇到生产环境 400 时用同样的 body 重试必然同样失败，正确的处置是带上 header 与 "drop_block"，再回头修掉导致不一致的那处编辑。

这道保险自己也会失效：上面讲的是调用方主动选择降级，还有一种是被迫的。v2.1.282 修复了一个更严重的失效模式——某些会话会因 Invalid data in redacted_thinking block 的 API 错误每一轮都失败。注意它的形态：不是丢几个块，而是整个会话无法继续。修复后的兜底动作是丢弃该会话的 thinking 块并重试一次。

这行值得单独记住，因为它标出了这套机制的降级方向：保护 thinking 的手段失败时，被牺牲的是 thinking，不是会话。上表里 "drop_block" 是调用方主动选的降级，这里是系统被迫做的降级，两者指向同一个结论——在协议层的取舍中，thinking 块是那个可以让出去的量。把它与 Undercover Mode 的”无法强制关闭”放在一起看，你会发现 Claude Code 的安全设计里有一贯的优先级：可用性让位于不泄露，但可用性本身不轻易让位于别的任何东西。

而且失效不止于 bug——修复本身也会被主动回收。 v2.1.318（2026-11-04）的官方条目是「Removed the 2.1.288 fix that kept the model’s earlier thinking when resuming a conversation started on 2.1.286 or earlier; that thinking can now be dropped」：2026-10 修的保护（v2.1.288，2026-10-02），2026-11 被官方自己撤掉，间隔约一个月。上表那行 v2.1.288 已按此加注。这给「在协议层的取舍中，thinking 块是那个可以让出去的量」补上了最直接的实证——「保留 thinking」在官方的取舍里始终是可让渡项而非承诺，不仅会在故障中被动失效，还会在版本迭代中被主动舍弃。上一段那句结论的适用范围，从被动失效扩大到了主动取舍。

两个附带成本：被丢弃的块不计费；prompt cache 会从编辑点重启。这与提示词缓存的稳定性要求是同一约束——改动前缀既让思考失效，也让缓存失效。反过来，把 system 与 tools 在会话内固定、把 messages 当 append-only 处理，两个问题一并解决。官方建议现在就把集成改造成 append-only，理由是后续模型会把前缀检查推到全部账号。

thinking 稳定性与 prompt cache 是同一条因果链：上面第二个成本（缓存从编辑点重启）不只是”编辑了前缀”才会发生。2026 年 9—10 月连续多个版本修复了十余类 thinking 被静默丢弃的场景。原表四行的共同点是”用户执行了某个命令”，但按触发源重新分组后，这个论断不再成立——新增的大多数路径里，用户既没编辑也没执行命令。

触发源	触发动作	版本
用户动作	Claude 正在工作时执行 /model、/rename、/artifacts 等即时 slash 命令	v2.1.282
用户动作	用省略了早先某个内置工具的 --tools 列表重启并继续/恢复会话	v2.1.282
用户动作	--resume / --continue 时，会话启动阶段的某个内置工具被服务端 flag 关闭	v2.1.275
用户动作	执行 /login、/upgrade、/extra-usage	v2.1.273
系统动作	resume 一个起始于 v2.1.286 或更早的会话（v2.1.288 修复；该修复已被 v2.1.318 撤销，此类会话的早期 thinking 现在可再次被丢弃）	v2.1.288 → v2.1.318 撤销
系统动作	中途 API 超时（非交互会话与子代理从 partial response 继续，thinking-only 响应重试）	v2.1.288
系统动作	API 输出内容过滤器在 Claude 仍在 thinking 时停止回复（现重试一次再报错）	v2.1.290
系统动作	恢复的子代理与 teammate 在运行中途收到消息，同时丢 thinking 与 prompt cache	v2.1.290
系统动作	云会话在容器重启后忘记客户端选的 thinking 设置	v2.1.292
模型侧动作	Opus 5.5 ↔ Sonnet 5.5 切换（/model、opusplan）重写较早的 MCP 工具公告	v2.1.287
模型侧动作	Amazon Bedrock Guardrails 在回复以 thinking 开头时中途拦截	v2.1.287

最后一行原表的官方措辞把后果写得很直白：这些命令会丢弃会话较早的 thinking，迫使下一次请求做一次完整的 prompt cache 重写。也就是说，丢 thinking 从来不只是丢内容——它连带打掉缓存，下一轮按全价重新写入。对一个跑了几百轮的长会话，一次 /model 切换要付两笔账：看得见的是上下文里少了一段推理，看不见的是缓存命中率。

维护动作会搬动不该被搬动的东西：这一组还有两条例外，值得与上面同列——v2.1.287 修复了 commit attribution reminder 在压缩之后被塞进工具结果里投递（投递位置本身会随压缩漂移）；v2.1.295 修复了 claude plugin test 传给 session.append hook 的内容会移除真实会话保留的 tool call / tool result / thinking blocks。两条都不在用户动作里，而都是”系统自己做了一次维护，顺手把状态挪了位置”。

需要修正一句此前的论断。原文写这类场景”用户什么都没编辑”，在只有前四行时成立；扩表之后更准确的说法是：多数新增路径里，用户既没编辑也没执行命令——触发发生在模型切换、容器重启、中途拦截与超时重试上。这个差别不是措辞问题：它决定了你能不能靠”规范操作”来规避。前四行可以靠纪律避开（别在 Claude 工作时切模型），后七行不能——它们发生在系统自己的时间线上。

这与 §16.3.1 的四层纵深防御形成一处有意思的对照：那里的每一层都在防止身份信息漏出去，这里的每一处修复都在防止推理链在不经意间被扔掉。同一套系统里，“不该留的”和”不该丢的”用的是两套完全不同的工程力度——前者有死代码消除和”无强制关闭”，后者只有事后逐个版本打补丁。

生效范围：2026-08-31 00:00 UTC 及之后创建的账号；Claude API 与各云平台（Amazon Bedrock、Google Cloud、Microsoft Azure）适用同一个”新账号”定义。既有账号暂不受影响。

⚠️ 日期分歧已澄清：中文二手报道对生效日期存在 2026-08-31 UTC 与 2026-09-01 两种写法。官方文档明确为 August 31, 2026, 00:00 UTC，本书以官方为准。

⚠️ 「Claude Code、Claude Cowork、claude.ai 网页端及第三方产品用户不受影响」这一条在二手报道中流传很广，但本书未能在 Anthropic 官方文档里找到对应表述——官方只写了”既有账号暂不受影响”。此处存疑，不作断言。

配套定价：同一份 Fable 5.1 发布说明中，缓存读取价格降至 $0.25/MTok（降 75%），典型负载的整体成本降约 25%，复杂编码与高 agentic 负载最高降约 45%。

⚠️ 该降幅的适用范围为”按 token 计费的场景（如 API）“，官方原文即带此限定；订阅制与云平台的计费方式不同，降幅不可直接套用。

⚠️ 口径标注（）：$0.25/MTok 是 Fable 5.1 的口径，不是全系统一价。2026-09 官方 changelog 新增的两个默认模型——Opus 5.5（v2.1.280，$4/$20 per Mtok）与 Sonnet 5.5（v2.1.284，$2/$10 per Mtok）——标价写的是 $0.20/MTok cache reads。两个数不属于同一代模型，彼此不构成”涨了”或”降了”的关系。跨章阅读时若把它们并排看，请先确认各自指的是哪个模型。

运营侧：2026-09-10，Anthropic 发布威胁情报报告《Detecting and countering misuse of AI: September 2026》，覆盖 2025-12 至 2026-08 期间处置的活动，首次公开其运营侧反蒸馏手段：① 代理网络归因（proxy network attribution）；② 更新提取分类器（extraction classifiers）；③ 对可疑账户强制身份验证；④ 在 Fable 5.1 中引入 preserved thinking（即上文协议层校验）。

⚠️ 来源与立场提示：该报告一并包含对多家中国实验室的蒸馏指控。这些属 Anthropic 单方面的商业与安全指控，截至本书写作时未见独立司法认定或第三方技术验证，本书不予采信亦不作转述。 上文只采纳其公开的自述反制手段清单。

这一保留不是修辞。本章的主题是透明性：当一家公司既充当”谁在滥用模型”的指控方，又充当”如何检测滥用”的技术供应方，还是”检测是否向用户披露”的决定方时，它的自述需要比普通技术文档更高的证据门槛。

执行成本下降：同期 Anthropic 放宽了 Fable 5.1 的网络安全类保障——模型现在可以发现软件漏洞（但仍不能编写利用代码）。官方在发布说明的两处分别给出了两个数字，主语不同：

• 保障总述段：「In cybersecurity, our newest safeguards block 60% fewer false positives than before.」——主语是判定准确率（误报）。
• 网络安全保障段：「Claude Code users can expect an average of around 60% fewer interventions per session from our cyber safeguards, relative to the previous safeguards on Fable 5.」——主语是用户可感知的干预频次，且明确写的是 Claude Code 用户。

两者都出自同一篇官方发布说明，量的是同一件事的两个面：保障判定更准（误报少）→ 用户被打断的次数变少（干预少）。引用时应写清自己引的是哪一个。

⚠️ 数字口径校正（对本轮一次过度校正的再校正）：本轮早前版本曾断言部分第三方日报（cadb.info，2026-09-02）的”Claude Code 会话干预次数下降约 60%“是误读，并称”官方也未提及 Claude Code”。回官方发布页原文核对，该表述并非误读——上引第二句官方原文本就写了 Claude Code 用户与 per session。真正的差异只是口径（干预频次 vs 误报率），不是真伪。本版已按官方两句原文并列呈现，撤回此前的「误读」定性。

编者判断（非原文表述）：从客户端投毒，到协议层硬校验，再到放宽误报过高的保障，这三件事指向同一条趋势——把约束固化进基础设施，而不是在每次调用时重新判断。

信任成本：2026-07 监视门事件揭示了反蒸馏措施的一个未讨论成本——当防御手段在用户不知情的情况下修改输出内容（假工具注入）或采集环境信息（隐写标记），开发者信任会遭受不可逆的损害。Anthropic 对 The Register 关于”是否在服务条款中披露”的沉默加剧了这一问题。一个关键问题是：反蒸馏应该在哪个层面实施？ 在 API 服务端做流量检测（不接触用户设备）vs 在客户端做隐写标记（利用用户授予的文件系统权限），二者的信任含义完全不同。

详见第 23 章”反蒸馏机制”。

16.5 透明性困境：从 Undercover Mode 到监视门的完整光谱

将 Undercover Mode、反蒸馏、隐写检测放在同一张”透明性光谱”上比较，会发现它们共享相同的工程 DNA（Feature Flag 条件注入 + 提示词级别的内容修改），但伦理位置完全不同。补上 2026 年新增的第四种机制之后，这张表才真正配得上”光谱”二字——前三种都在隐藏，第四种在声明。

机制	方向	隐藏/声明什么	对谁	用户是否知情	信任影响
Undercover Mode	隐藏	模型身份 / Anthropic 内部信息	终端用户	SDK 调用方可控	低（B2B 白标常规操作）
反蒸馏（假工具注入）	隐藏	输出中的伪造工具调用	蒸馏模型训练者	❌ 未披露	中（输出被修改但目的正当）
Unicode 隐写检测	隐藏（并回传）	用户环境信息（时区 / 域名关联）	Anthropic 服务端	❌ 从未披露	极高（利用用户信任采集信息）
统计水印 + 检测 API	声明	”这段文本可能由 Claude 参与写作”	监管机构、公众	✅ 有公开发布说明	低（但见下文”声明给谁看”）
远程行为规则注入（tengu_heron_brook 游戏复刻禁令，2026-10-27）	隐藏	行为边界（“不复刻特定现有游戏”两句指令）	全体 Opus 5.5 用户	❌ 未在 changelog 披露，但官方事后确认	中

第五行填补了光谱上「隐藏」一端的一个新位置：它不藏身份（Undercover 藏的是”我是谁”）、不改输出内容（假工具注入改的是”我给你看什么”）、也不回传信息（隐写检测偷看的是”你在哪”），而是静默注入行为约束——只改”我不做什么”。它落在反蒸馏（灰色地带）与 Undercover（B2B 常规）之间：比反蒸馏透明（官方承认），比 Undercover 影响面大（所有 Opus 5.5 用户的行为边界都被画了一次）。披露形态也与前四行都不同——「可被追问确认、但不会主动出现」：Anthropic 工程负责人 10-30 公开确认了改动，但 changelog 304~319 无记载、无用户开关、无任何会话内提示。行为样本（majormatters 五个新会话实测，单源标注）：拒绝改名克隆、放行类型游戏与本人资产的原创游戏、仍放行合法持有的 decompilation 与 SM64 社区移植——注入的规则按字面执行，未外扩。对「透明性是一条连续轴」的论点，这一行补的是轴上最难归类的一点：正当目的 + 隐蔽手段 + 事后可确认，三样占全。

核心论点：Undercover Mode 是 B2B 场景下的预期行为；反蒸馏是灰色地带（目的正当但手段隐蔽）；隐写检测跨越了红线——它利用用户授予的工具权限采集用户信息并回传。统计水印站在光谱的另一端：它的目的不是让 AI 的参与更难察觉，而是让它事后可验证。

四者并置才能看清本书的主张：透明性不是一个开关，而是一条从”对用户隐藏”到”对公众声明”的连续轴；同一家公司完全可以在这条轴的两端各做各的——一边在客户端隐藏身份标识，一边在服务端给输出打上可检测的水印。这两件事在 Anthropic 内部并不矛盾，因为它们服务于不同的对象（B2B 客户 vs 监管者），而不是同一个”用户”。

透明机制自身也是攻击面：这张光谱讨论的是”对谁透明、透明到什么程度”，还有一种情况它没覆盖——用来实现透明的工具自己在泄漏。v2.1.285 修复的正是这样一例：redacted 日志与 transcript 会泄漏 URL 密码的一部分（当密码里含 @ 时），或者全部（当 URL 把 @ 写成 %40 时）。Anthropic 未给该问题定严重级别，也未分配 CVE。

日志脱敏存在的理由，恰恰是让你能安全地分享 transcript——一个为”可分享”而生的机制，在 URL 密码这个特定输入上把该藏的东西露了出来。@ 与 %40 的差别尤其能说明问题：脱敏规则按字面匹配分隔符，转义写法就绕过去了。

它与 §16.4.1 那处失效是一对：保护 thinking 的机制会失效，脱敏日志的机制也会失效。 把这两条与本章开头那句”没有强制关闭”放在一起，读者会得到比”某家公司的某个 bug”更一般的东西——每一层防护都有它自己的输入空间，而防护规则通常只覆盖输入空间里最常见的一部分写法。

16.5.1 统计水印：唯一一个反向机制

合规来源：EU AI Act 的《Code of Practice on Transparency of AI-Generated Content》。Anthropic 于 2026 年 7 月与约 190 个签署方共同签署该准则；自 2026-08-02 起，欧盟要求服务其市场的 AI 提供方对生成内容做标记。Anthropic 在发布说明中明确，该义务适用于2026-08-02 之后发布的模型。

⚠️ 数字口径：签署方数量在 Anthropic 的两份官方材料里写作 “around 190 total signatories” 与 “190 other signatories”，一为总数、一为”其他签署方”。本书取”约 190 个签署方”这一稳妥表述。

技术方法：Claude 的文本水印是 Google DeepMind 于 2024 年发表在 Nature 上的 SynthID-Text 方法的一个版本；其设计原则可追溯到 Scott Aaronson 2022 年的提案。这类方法的共同点是只改变随机性的来源，不改变候选集合——模型在多个同样好的候选词之间做选择时，原本由随机数决定，现在改由”密钥 + 前面几个词”决定。模型不会选出一个它本来不会考虑的词，只是这次选中的那个是可复现的。持有密钥者可以事后检查词序列是否与”使用该密钥时会做出的选择”一致，从而给出一个概率判断。

SynthID 生态在 2026 年的扩张：上面说的 SynthID 已经不只是 Google 自家模型的一项可选能力。按 2026-09-01 的状态快照，SynthID 于 2026 年 Q1 以开放许可发布，已标记数十亿条内容，检测能力面向记者与审核者铺开；SynthID-Text 2.0 改用 token 分布的统计偏置，文本被部分改写之后仍可检测。2026 年 9 月又推进了两步：Google 的 Gemini 3.8 文本转语音模型（30 秒样本、在本人录音同意下复刻声音）与 Live Avatar 对音视频输出打 SynthID，覆盖范围从静态图文扩到了流式的音视频；Apple 宣布 iPhone 18 Pro 将在”今年晚些时候”的软件更新中支持 SynthID 标准，覆盖多数编辑过的图片（取决于所做的编辑类型）。

⚠️ 两条限定：① Apple 这一条的官方措辞是”今年晚些时候的软件更新”——不是随 iPhone 18 Pro 首发即生效，本书不写具体日期；覆盖范围是”多数编辑过的图片”，不是全部。② 本章讨论的是文本侧的统计水印，SynthID-Image 与音视频是另一条产品线，攻防形态不同（见下文第四条限制），不要把一侧的结论搬到另一侧。

真正值得记的是方向：统计水印正从”某家模型厂商的可选能力”转向”终端厂商的默认支持”。这条一旦走通，“声明”就不再依赖生成方自觉，而由承载内容的设备与格式来保证——这正是 EU AI Act 透明性义务想要的形态。反过来看，这也把下面第四条限制的分量放大了一档：一件要被默认支持的东西，得先扛得住被移除。

检测侧推进到 2026-10-07：公开门户开放，但不含文本：上面”检测能力面向记者与审核者铺开”是 2026-09-01 的快照，已过期一档。2026-10-07，Google 把 synthid.com 从候补名单制转为面向所有人的公开门户（上线时仅英文，需登录，每日约 10 次额度）。它能读 Google 自家与 OpenAI、NVIDIA、Kakao 的 SynthID 信号，Apple 已宣布但尚未上线。规模数字同步更新：已标记 1,800 亿+ 图像与视频、约 24 万年音频；Search、Gemini app 与 Chrome 内建的验证合计 每天 100 万+ 次请求。官方自己的限定写得很清楚——「This is not a general-purpose AI detector」，阴性结果不排除 AI 生成。

⚠️ 本条对本章论点最关键的一句：公开门户的三类检查是图像、视频、音频——文本不在其中。也就是说，本章讨论的 Claude 文本水印（SynthID-Text）不只”检测 API 只向机构开放”，连这次对公众开放的最开放入口也把文本排除在外。

⚠️ 来源分级：2026-10-07 的公开与三类覆盖范围经五个独立来源一致转述（含 Google The Keyword 的转述稿），规模数字彼此吻合；本书未取得 Google 官方博客原文的直接抓取，故按二手多源交叉记录。

门户的展示层做了取整，社区侧的攻防也开始了。 两条小注：① 公开门户只给二元判定（是/否），不提供置信度分数——水印检测的技术本性是概率判断（见上文检测 API 的讨论），门户把连续值取整成了布尔值；对「阴性不排除 AI 生成」这条官方限定来说，取整让灰色地带在展示层彻底不可见。② 社区证据（Reddit，单源标注）：有用户称轻度降噪即可移除图像水印（“创建水印移除节点非常简单”），也有用户抱怨 Google 自家模型生成的视频上误报率依然偏高——前者为第 4 条限制（MarkNull 的论文主张）提供了社区实践佐证，后者说明误报的方向不止「真人作品被标 AI」一种，还有「AI 作品被漏标」之外的「AI 作品被标错对象」。背景一条：SynthID 已入选 TIME 2026 年最佳发明（Google 官方博客已确认）——一个正在被社区单节点移除的水印拿到了年度发明，这个时间差本身就是本节「可用性声明与安全性声明不能互替」的注脚。

官方声明的五条性质：对输出的质量与内容无实际影响；读者无法分辨加水印与未加水印的文本；不向文本添加任何内容，也没有隐藏字符；不产生额外 token，价格不变；不携带任何识别信息，无法追溯到具体的个人、组织或某次对话；且并非 Claude 独有——其他签署方也会实现各自的水印。

检测 API：处于 private preview。当前开放对象为欧盟法律要求覆盖的合格组织——监管机构、执法部门、媒体、事实核查者、独立研究者、教育机构、欧盟公民社会组织——以及对自身合规负有同等验证义务的企业。Anthropic 表示会逐步扩大访问范围。

官方自述的三条限制（这部分最少被二手报道转述，对读者却最有用）：

1. 水印只能回答”这段文本有多大可能是 Claude 部分参与写作的”。它不能确认文本是否由人类所写，也无法区分其他 AI——即便对方也用水印，密钥不同，方法也可能完全不同。

2. 短样本上检测效果差：可选的词少，可依据的信息就少。文本越长，置信度越高。

3. 事实性段落与代码上水印稀疏。事实性内容没有”等价可选”的余地（“牛顿最著名的著作是《自然哲学的数学原理》“——下一个词没有第二种同样正确的写法）；代码同理——水印主要落在注释这类确有选择空间的地方。校对场景几乎无法附着：如果只让 Claude 改语法和标点，水印能寄托的只有那几处修改。

4. 对抗性移除是可能的，而且是模型无关的。前三条讲的是水印在日常处理下会变弱，这一条性质不同——有人可以主动把它去掉。MarkNull: Model-Agnostic Watermark Removal in AI-Generated Images via On-Manifold Latent Manipulation（arXiv:2608.10166，已接收于第 35 届 USENIX Security Symposium）的出发点是：含水印图像，其生成潜表示与嵌入所用的初始噪声之间存在强统计依赖。论文用 NLAS（Noise-Latent Alignment Score） 量化这一依赖，再在保真约束下优化潜表示，使其与水印去相关。它不需要知道水印方案、检测算法或目标生成器的内部：覆盖 post-hoc、fine-tuning-based、initial-noise-based 三类范式共 9 种方案，平均比特准确率降至 53.14%（≈50% 的随机猜测基线），PSNR / SSIM / LPIPS 显示无可感知退化；轻量变体 MarkNull-A 把攻击蒸馏为单次前向推理，0.50 秒/图。论文还给出了一个基于 NLAS 异常检测的防御模块，构成攻防闭环。

   ⚠️ 作用域限定（本条最重要的一句）：MarkNull 的评测对象全部是图像水印（SynthID-Image、SAGE、WATERMARK-LLM 等）。本节正文讨论的 Claude 文本水印是 SynthID-Text，走的是 token 选择偏置这条路，不在该论文的证明范围内。论文没有证明文本水印能被同样方式移除。 把”图像水印被攻破”读成”文本水印也被攻破”，是本条最容易发生的误读，也是错得最远的一种。

   ⚠️ “攻破 SynthID-Image”这一声称存在对立意见：第三方评审（pith.science 对 2608.10166 的 desk verdict）认为，论文对 SynthID-Image 的声称不被它自己所报告的 Gemini 基评测支持；攻击的可迁移性依赖这样一个假设——攻击者的公开替代模型与隐藏的目标模型共享同一套潜参数化、去噪 schedule 与 inversion 过程——而该假设是被假定而非被验证的，对闭源商业系统尤其如此。本书把”53.14% / 0.50 s / 9 种方案”这组数字当作已发表的论文主张记录，不把它当作”SynthID 已被攻破”的既成事实。

5. 水印信号不是分辨率不变的，且阳性不蕴含”AI 生成”。2026-09-17，一起病毒式传播图像的取证争议暴露了这一点：同一张图像的低分辨率版本 SynthID 检测为阴性，高分辨率版本为阳性。两种解释都成立——可能是 AI 生成图被对抗性降采样剥掉了水印，也可能是真实照片在被生成式工具放大时无意中嵌入了标记。取证方必须先确立时序优先性（哪个版本先出现）才能判定来源。

   由此可以提炼出一条比该事件本身更重要的原则：水印阳性只说明”这段内容带有该标记”，不说明”它由 AI 生成”——真实内容经过生成式处理之后同样可以带上标记。对一个把水印放在”声明”一端的光谱来说，这是必须并列呈现的反向案例：声明机制同样会误报，而误报的方向恰好是它最不该出错的方向——把人类作品标成 AI 作品。

   ⚠️ 置信度说明：该事件目前为单一来源（SCAND.Ai 事件记录 SCAND-247885，截至 2026-09-20，noise 34/100），尚无厂商结论。上文的原则不依赖这个具体事件的真伪（“真实内容经生成式处理后可以带上标记”由生成式处理本身的性质即可推出），但案例本身请按单源处理。

6. 水印的适用前提可以被调用方关闭：模型选择与采样参数绕过。2026 年 10 月底，Anthropic 把文本水印回补到旧模型：Claude Mythos 5、Opus 4.7、Opus 4.6、Sonnet 4.6 四款模型加水印（2026-08-02 之后发布的模型自发布即带），理由是 EU AI Act 的 12 月截止期限——这已超出「8/2 后新模型」的最小合规范围，方向上与第 1 条限制（部分参与）相反，是主动扩大覆盖。但 Opus 4.6 与 Sonnet 4.6 上有一个口子：水印只在 temperature、top_p、top_k 三个采样参数全部保持默认值时生效，改动任意一个即不带水印；邮件对 Mythos 5 与 Opus 4.7 未附此条件（推断这两款不受采样设置影响）。Anthropic 自己的合规提醒只有一句：若依赖水印做合规，请保持这些设置为默认值。这一条与前五条性质都不同：不是水印弱，而是水印的适用前提（采样自由度）掌握在调用方手里——统计水印靠”密钥接管候选词选择”工作，参数一旦偏离默认，接管的通道就变了。它与第 4 条（MarkNull，图像侧的主动移除）构成文本侧的对应物：一个靠论文式攻击，一个只需改一个 API 参数。尤其值得注意的是 Opus 4.6 仍是 Anthropic 的最佳写作模型（优于 Opus 5.5）——写作场景恰恰是水印最常被引用的场景，而它恰好是带口子的那一档。

   ⚠️ 来源说明：本条底层为 Anthropic 致 API 客户的邮件（The Decoder 2026-10-31 首报，多家独立媒体一致转述，部分附 Help Center 文章截图），属公司自述的多源一致转述，非 Anthropic 公开文档页；采样参数的具体行为（三个参数、任一即绕过）以这些转述为准，本书未能取得邮件原文或 Help Center 文章直链。机制上与「只改变随机性的来源」的官方描述互为表里，自洽性高。

把第四条与”官方声明的五条性质”放在一起读，会得到本节最需要读者带走的东西：那五条讲的是水印在正常条件下是什么样，第四条讲的是有人专门来破坏时是什么样。前者是可用性声明，后者是安全性声明，两者不能互相替代——一条水印可以完全满足”不影响质量、不可见、不加字符、不额外收费、不可追溯”，却仍然是可以被移除的。

图片与文件走另一条路：生成 .png / .jpg / .svg 等受支持类型时，Claude 会在文件元数据里附一条加密签名的内容凭证，声明该文件由 Claude 生成或处理过。这是开放行业标准 C2PA——与相机制造商、图像编辑软件用来记录图像来源的标准相同，任何支持 C2PA 的工具都能读取。（这一侧的移除攻防，见上文第四条限制。）

声明给谁看：本节最后需要补一条编辑判断。水印在方向上确实与前三行相反，但这不等于它把知情权还给了用户——没有检测 API，水印对任何人都是不可见的，而检测 API 目前只向机构开放。也就是说，这条”声明”通道的受众是监管者与合规部门，而不是坐在屏幕前的那个人。把它记在光谱的”声明”一端是对的，但如果据此认为 Claude 的透明性已经补齐，就误读了这条机制的设计目标。下文两条新证据（公开检测门户不含文本、两家厂商的检测开放口径一致）把这句话从”Anthropic 的做法”升级为”文本侧的行业结构”。

Anthropic 还说明，水印目前是全球启用的，原因是”尚无可持久按地区划分的方案”，未来会继续评估其他做法。这与本书在监视门一节提出的质疑形成呼应：一家公司如何界定”用户”，往往比它采用什么技术更能决定这些机制的伦理位置。

⚠️ 这句理由应当按”可证伪断言”来读，而不是按技术定理。它是一条厂商自述理由，不是”划分在技术上做不到”的证明。两个月后，OpenAI 用产品证明了另一条路走得通。

对照：OpenAI textGrain（2026-10-05）。同一部 EU AI Act Article 50(2)（透明性义务 2026-08-02 生效；8/2 前已上市系统宽限至 2026-12-02；违规上限 1,500 万欧元或全球年营业额 3%）之下，OpenAI 的做法是：欧盟境内 ChatGPT 与 Codex 的合规文本输出全档位默认加隐形水印 textGrain（数周内铺开），全球 API 客户可 opt-in，默认关闭。机制与 SynthID-Text 同族——用密钥扰动候选词概率，不插入隐藏字符。

也就是说，按地区划分在产品面与 API 面都已经落地。两家公司面对同一条法律，一家选全球默认、一家选区域默认 + 全球 opt-in。合规驱动下并不存在唯一解，Anthropic 的”无法划分”应被读作选择，而不是限制。

同族的定量刻度：编辑会怎样削弱水印。上面第四条限制（MarkNull）给出的是图像侧的数字，且已限定不适用于文本。文本侧现在也有一组同族的定量数据，来自 OpenAI 对 textGrain 的自评（目标误报率 1%，400 token 心理学类散文）：

条件	检出率
400 token 未编辑	≈95%
200 token 未编辑	≈80%
400 token，替换 10% 同义词	66%（同组对照基线记 92%）
400 token，替换 25% 同义词	17%
数学类文本	显著更低
其他语言（罗马尼亚语 / 西班牙语）	42.2% / 69.0%

⚠️ 三个限定：① 这组数字量的是 textGrain，不是 Claude 的 SynthID-Text，只是同族参照；OpenAI 自评 textGrain “matched or exceeded” SynthID for text，而该比较本身也是厂商自评。② 全部为厂商自评，无第三方复核。③ 本章第五页那句”短样本上检测效果差”在这里得到了跨厂商的印证——200 token 与 400 token 之间差 15 个点。

「无第三方复核」的括号可以更新为「已授权、未出结果」（2026-11）。 据 IEEE Spectrum 报道（经双源转述核验）：Cornell 的 John Thickstun 与布拉迪斯拉发 KInIT 的 Dominik Macko 团队—— watermark 检测方向最活跃的两个独立团队——刚刚获得检测器访问权、尚未开始评估；Macko 团队计划跨学科、跨语言、跨文本长度测鲁棒性。独立验证从「无人能测」推进到「有人能测、结果未出」，本书维持对自报数字的限定，但下轮修订应先查这两个团队是否已发布。

法律豁免线与技术弱点在同一条 200-token 线上相遇。 EU Code of Practice 不要求对短于 200 token 的输出打水印——而 textGrain 自报的 200 token 检出率恰为 ≈80%（400 token 是 ≈95%）。也就是说，合规义务的边界画在了水印技术恰好最弱的地方：短文本既最难检出、又被法律主动豁免。这个重合不一定是立法者有意为之（200 token 更可能是”太短不值得管”的务实线），但效果上，两条线叠加使短文本成为一个既无义务又无能力的双重空白区——引用水印合规性时，这是最不该略过的边界。

熵预算：机制描述多了一个此前没披露的维度。 textGrain 技术报告共同作者 Xiang Li（UPenn 博士后）公开了设计细节：把熵当作可预算分配的资源——开发者指定允许的不可预测性总量，textGrain 据此调节注入强度（原话：“We can think of entropy as a resource, a kind of money”）。这补在「只改变随机性的来源」的旧描述之上：旧描述说的是在哪里动手（随机性来源），熵预算说的是用多大力气（强度可配）。对读者最有用的是它暗示的权衡——水印强度与文本不可预测性共享同一个预算，把熵花在水印上，生成侧的多样性预算就少一分。

⚠️ 罚款档位分歧（登记，不改数字）：上表所引「1,500 万欧元或全球年营业额 3%」是 Article 50 透明度义务的罚档。2026-11 起，部分英文报道（经 IEEE Spectrum 转述链）把违规上限写成「年收入的 7%」——7% 对应 AI Act 禁止性实践条款的罚档，透明度义务档位为 3%/€15M。本书维持 3% 口径，分歧原因疑为二级来源混淆罚档，留此记录供后续对照官方条文核实。

两家在文本检测上的开放口径一致：上面记的 Anthropic 检测 API 处于 private preview、只向欧盟法律覆盖的合格组织开放。OpenAI 的 textGrain 检测器同样是”仅经批准的研究者与专家组织，逐案审批”，并计划开源但无日期。两家在文本检测上的开放口径完全一致。这使”声明的受众是监管者与合规部门，不是屏幕前的那个人”从一家公司的做法，变成一条行业规律——叠加上面”公开门户不含文本”那一条，结论更硬：在文本这一侧，“声明”通道的结构性缺席是全行业的共同形态，不是某一家公司的保守。

详细分析请阅读 → 第 6 章 §6.8 Undercover Mode：当 Context Engineering 碰上伦理