专题：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.”

适用场景：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 的安全设计里有一贯的优先级：可用性让位于不泄露，但可用性本身不轻易让位于别的任何东西。

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

thinking 稳定性与 prompt cache 是同一条因果链：上面第二个成本（缓存从编辑点重启）不只是”编辑了前缀”才会发生。2026 年 9 月连续几个版本修复了四类 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

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

这与 §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 参与写作”	监管机构、公众	✅ 有公开发布说明	低（但见下文”声明给谁看”）

核心论点：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 透明性义务想要的形态。反过来看，这也把下面第四条限制的分量放大了一档：一件要被默认支持的东西，得先扛得住被移除。

官方声明的五条性质：对输出的质量与内容无实际影响；读者无法分辨加水印与未加水印的文本；不向文本添加任何内容，也没有隐藏字符；不产生额外 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），尚无厂商结论。上文的原则不依赖这个具体事件的真伪（“真实内容经生成式处理后可以带上标记”由生成式处理本身的性质即可推出），但案例本身请按单源处理。

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

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

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

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

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