标准回答
实现原理（采样时偏置）
以 Kirchenbauer 等的方案为代表：生成第 (t) 个 token 前，用密钥 + 前文哈希作种子，把整个词表伪随机划分为 green-list 和 red-list；然后给 green-list 中每个 token 的 logit 加一个小偏置 (\delta)，使模型在保持流畅的前提下更倾向选择 green token。划分随上文变化，因此水印分布在整段文本中。
检测（统计假设检验）
检测方拥有同一密钥即可：对待测文本逐位置重算 green/red 划分，统计实际落在 green-list 的 token 比例。未加水印的文本期望约一半为 green，加水印文本会显著偏高；用 z 统计量做假设检验，超过阈值即判定为该模型生成。检测不需要原模型，也不需要原始 prompt。
权衡与局限
- 质量 vs 可检测性：(\delta) 越大越易检测，但可能降低生成质量。
- 熵依赖：低熵/确定性输出（如代码、固定模板）可注入的随机性少，水印弱。
- 鲁棒性：改写、回译、增删 token 会破坏划分对齐，削弱或擦除水印——这是主要攻击面。与 C2PA、SynthID 等内容溯源体系 常配合使用。
常见误区
⚠️ 常见踩坑
文本水印不是把可见标记或固定字符串塞进输出，而是统计性地偏置 token 采样、靠密钥事后检验。也别以为它不可破解：同义改写、回译、截断和增删 token 等都能显著削弱甚至擦除水印，因此它是概率性溯源信号而非铁证。
追问
追问 1：为什么 green-list 的划分要依赖前文（上文哈希）而不是固定不变？
若划分固定，攻击者更容易统计推断出 green-list 并针对性规避，且固定划分会系统性偏向某些词、损害文本自然度。用「前文哈希 + 密钥」让每个位置的划分动态变化，既增强抗分析能力，又把水印信号分散到全篇，使检测更稳健、对单点改动更不敏感。
追问 2：为什么低熵文本难以加水印？
水印靠在多个高概率候选间「推一把」选 green token 来嵌入信号。当输出几乎确定（如语法强制的代码、固定格式、事实性单一答案）时，可选候选少、熵低，加偏置要么改不动选择、要么破坏正确性，能注入的水印信息量很小，检测灵敏度随之下降。
追问 3：有哪些手段可以提升水印对改写攻击的鲁棒性？
方向包括：基于语义而非表层 token 的水印（对同义改写更稳）、使用更长上下文窗口的哈希以降低局部改动影响、对编辑距离更鲁棒的检测统计量，以及与 SynthID、C2PA 等溯源/元数据方案叠加形成纵深。但需明确：目前没有对强力改写完全鲁棒的方案，水印应作为概率性证据而非唯一判据。
延伸学习
与本题相关的知识库文章、术语、工具与行业资讯。