1. 先把问题拆开：AI文本的隐形水印到底藏在哪里

最近不少同行在讨论一个问题：AI 生成的文本里被埋了隐形水印，那么把内容改写一遍，还能不能查出来。这个问题的答案不是简单的“能”或“不能”，它取决于水印埋在哪一层、改写动了哪一层、检测端手里握着什么。我自己在这块做过一段时间的实验，从采样阶段的可控生成，到后处理阶段的词替换，再到检测端的统计检验，整条链路都踩过坑。这篇就把我理解的技术细节、可复现的最小实现、以及改写攻击下检出率怎么变化，一次性说清楚。

先明确讨论对象。这里说的文本隐形水印，指的是在生成过程中或生成之后，往文本里嵌入一段人眼不可见、但检测算法可以统计出来的标记信息。它要解决的核心问题是：一段文字到底是不是某个模型产出的、是不是某次特定会话产出的。适合谁来参考？如果你在做内容平台的内容溯源、在做学术诚信辅助判断、或者单纯想知道“AI检测工具给出的百分比靠不靠谱”，下面这些内容都能直接对上你的疑问。

需要提前说明一个前提：水印和“AI文本检测器”不是一回事。前者是主动埋标记，后者是根据文风、困惑度、词汇分布做概率猜测。两者经常被混为一谈，但对“改写一遍还能不能查出来”这个问题，它们的表现完全不同。我后面会分开讲，避免你把两种技术的失效条件搞混。

1.1 水印不是往文本里插一串看不见的字符

很多人第一反应是：水印是不是像图片那样，在文本里藏了零宽字符、特殊空格、或者不可见的 Unicode 控制符。这条路线确实存在，叫零宽字符水印，做法是把二进制信息编码成零宽连接符、零宽非连接符的组合，插在词与词之间。它实现简单，解析也简单，但弱点非常明显：任何一次复制粘贴到纯文本编辑器、任何一次格式清洗、任何一次经过会剥离控制字符的接口，水印就没了。改写工具更是不用费劲，光是规范化处理就能把它清干净。

真正让行业重视的，是统计型水印，也叫生成式水印。它不改文本外观，而是在模型逐 token 生成的时候，对候选词的概率分布做一点微小偏置，让某些词被选中的概率略高于正常情况。单看一个词完全看不出异常，但整段文本统计下来，被偏置的那些词出现频率会显著高于随机预期。检测方拿到文本，重新按同样的规则划分词表、统计命中比例，就能算出一个显著性分数。

这个思路的关键在于：偏置规则依赖一个密钥。密钥参与哈希，决定每一步哪些词属于“被偏置集合”。没有密钥的人，看到的就是一段正常文本，无法反推规则；有密钥的检测方，可以逐 token 复现划分，做统计检验。这也是为什么水印检测通常需要“模型方或授权方”来做，而不是随便一个第三方工具就能验。

所以回答最初的问题：如果水印是零宽字符型，改写一遍基本必死，因为它连复制粘贴都扛不住；如果是统计型水印，改写会不会破坏它，要看改写有没有打乱 token 序列的统计特征。这就引出下一节的核心矛盾。

1.2 为什么“改一个词”就可能让统计水印失效

统计水印的检测依赖一个假设：文本的 token 序列还是原始生成的那一串，或者至少高度接近。检测方要做的是，对每个位置，用前一个 token 的哈希去划分词表，然后看当前 token 落在哪一侧。一旦你改写了某个词，这个位置的判定就错了；更麻烦的是，它还会影响下一个位置的哈希输入，因为很多实现是用前一个 token 作为哈希种子。一个词被替换，等于污染了两个位置的统计。

这就形成了一个连锁反应。假设一段 200 词的文本里，你替换了 20 个词，看似只动了 10%，但受影响的判定位置可能是 40 个，占 20%。如果替换的词恰好落在被偏置的那一侧，检测分数会掉得更快。我实测过一个粗略规律：轻度同义替换下，显著性分数大概按替换率的 1.5 到 2 倍速度衰减；替换率超过三成，分数基本就回到随机水平了。

但这里有个反直觉的点：不是所有改写都会削弱水印。如果改写方式保留了原有的词汇选择，只是调整了语序、加了连接词、把长句拆短句，那么被偏置的词还在，只是位置变了。这时候检测方如果做的是“全文词频统计”而不是“逐位置哈希”，水印反而可能被保留下来。所以“改写一遍还能不能查出来”，答案取决于改写工具的工作方式，也取决于水印算法的设计。这就是为什么不同研究给出的结论差异很大，有的说改写后检出率还有七成，有的说掉到一成以下。

理解了这个矛盾，后面的技术选型和参数设计才有落脚点。你不能笼统地问“水印抗不抗改写”，而要问“在哪种改写强度、哪种水印方案、哪种检测口径下，抗不抗”。

2. 三条主流技术路线与选型逻辑

在自己动手之前，先搞清楚市面上的方案分成几类，各自的强弱项在哪。我把它们归成三条路线：采样偏置型、后处理替换型、模型指纹型。这三类的抗改写能力差别很大，选错了路线，后面怎么调参都是白费。

2.1 采样偏置型：抗轻度改写，怕重度重写

采样偏置型是目前讨论最多的一类。典型做法是：把词表按哈希分成绿名单和红名单，绿名单占比例 γ，生成时给绿名单里的 token 加一个偏置值 δ，让它们更容易被采样到。检测时统计绿名单 token 的数量，用二项分布的 z 检验判断是否显著偏高。

这套方案的优势是不需要改动模型结构，也不需要额外训练，只在解码阶段加几行逻辑，成本极低。文本质量的影响也可控，δ 取得小一点，人几乎读不出差别。缺点是它对抗改写的鲁棒性中等偏下，因为它依赖 token 序列的连续性。任何会替换词汇的操作，都会打乱哈希链。

γ 和 δ 是两个核心参数，选择逻辑很直接。γ 越小，绿名单越窄，单次命中的信息量越大，但文本质量下降越明显；γ 一般取 0.25 到 0.5。δ 越大，水印越强、越容易检出，但文本会变得用词古怪，重复感上升。我的经验是 δ 取 1.0 到 2.0 的 logit 偏置，配合 γ=0.25，在 200 词以上的文本里能拿到比较稳的分数，同时文本可读性还能接受。

2.2 后处理替换型：不碰模型，但怕格式清洗

第二条路线是生成完之后再打水印：用一套规则把某些词替换成同义词，替换的选择由密钥决定。比如“重要”换成“关键”、“方法”换成“途径”，选哪个由哈希决定。检测方按同样规则反查，统计替换命中率。

这条路线最大的好处是与模型解耦，任何来源的文本都能处理，甚至人工写的文本也能打。但它的弱点也很突出：替换会改变文本风格，替换率高了读起来别扭；而且它同样怕改写，因为改写工具很可能把这些同义词又换回去了。更麻烦的是，它怕“规范化”——如果中间环节做了繁简转换、全半角转换、标点统一，替换规则可能对不上。

我在实际项目里更倾向把它当作辅助手段，而不是主力。它的价值在于能给“已经生成好的历史文本”补打水印，这在批量治理场景里有用。

2.3 模型指纹型：本质是识别，不是水印

第三条严格说不算水印，而是模型指纹识别：根据文本的用词习惯、句长分布、标点偏好、困惑度曲线，判断它像不像某个模型写的。它不需要在生成时做任何事，纯靠事后分析。很多商业检测工具走的就是这条路。

它的抗改写能力取决于改写是否保留了风格特征。轻度润色基本不影响，重度重写会削弱，但如果重写用的还是同一个模型，风格特征可能又被带回来，形成一种“洗不掉”的循环。这条路线的根本问题是只能给概率，不能给证据。它没法证明“这段文字一定来自某次生成”，只能给一个“疑似”的百分比，误判率不低，尤其是非母语写作、技术文档、模板化文案，很容易被误判成 AI 生成。

三条路线的对比如下：

选型建议很明确：如果你要的是可验证、可举证的标记，走采样偏置型，把密钥管好；如果你要的是快速筛查，指纹型够用，但别把它的结果当成定论；后处理替换型适合做补充，不适合当唯一手段。

3. 检测端怎么算：从统计量到判定阈值

水印能不能查出来，一半看埋得怎么样，一半看算得怎么样。检测端的实现细节，直接决定了同一段文本在不同工具下给出不同结论。这一节把计算链路拆开，给出可直接套用的公式和参数。

3.1 检测流程的四步拆解

第一步是重建划分规则。检测方持有密钥，对文本从头到尾逐 token 处理，用“前一个 token + 密钥”做哈希，映射到词表的一个划分上，判断当前 token 属于绿名单还是红名单。这一步要求分词方式与生成时完全一致，分词器版本不同、大小写处理不同，都会导致对不上。

第二步是统计命中数。设文本长度为 T，绿名单比例为 γ，命中数为 |s|_G。这里要注意，标点、数字、特殊符号通常被排除在统计之外，只统计有效词。有些实现会把连续重复的词去重，避免一段复读文本刷高分数。

第三步是计算显著性。标准做法是二项检验：

期望命中数 = γ * T 标准差 = sqrt(T * γ * (1 - γ)) z = (|s|_G - γT) / sqrt(T * γ * (1 - γ))

z 值越大，说明绿名单命中越异常，越像是有水印。通常阈值取 z > 4，对应误报率在万分之一量级。有的实现用 p 值，等价。

第四步是结合困惑度做二次判断。单看 z 值有个漏洞：如果文本本身用词就偏向某些高频词，而这些词恰好落在绿名单里，会误判。所以要引入一个文本质量的参照，比如用参考模型算困惑度，如果困惑度异常低，说明文本过于“顺”，可能是水印偏置把概率分布压平了。两个指标一起看，误判率会低不少。

3.2 参数怎么定：一个算得出来的例子

光说公式不够直观，给一组具体数字。设 γ = 0.25，也就是绿名单占四分之一。一段 T = 200 个有效词的文本，如果完全没有水印，绿名单命中数的期望是 50，标准差是 sqrt(200 × 0.25 × 0.75) = sqrt(37.5) ≈ 6.12。

如果实测命中 78 个，z = (78 − 50) / 6.12 ≈ 4.58，超过阈值 4，判定为有水印。如果实测命中 62 个，z ≈ 1.96，不显著，判不了。如果实测命中 90 个，z ≈ 6.5，非常显著。

再看文本长度的影响。同样 γ = 0.25，不同长度下的分辨能力差别很大：

这张表说明一个很实际的问题：短文本检测不可靠。50 个词要判出水印，命中率得翻倍，这在实际生成里几乎不可能，因为 δ 不会设那么大。所以很多工具对短文本直接拒判，或者给出“置信度低”的提示。我在实际使用中，低于 80 个有效词的文本，基本不看 z 值，只看人工判断。

还有一点容易被忽略：γ 的选择会影响检测灵敏度。γ 取 0.25 时，绿名单窄，单次命中的信息量大，但文本质量压力大；γ 取 0.5 时，绿名单宽，文本更自然，但需要的样本量更大。这是一个质量与灵敏度的权衡，没有统一最优解，要看你的文本长度分布。如果主要处理短文本，就得把 γ 调小、δ 调大，牺牲一点可读性换检出率。

4. 改写一遍还能不能查出来：分强度实测思路

回到标题里的核心疑问。我不给笼统结论，而是按改写强度分四档，说明每一档下水印分数的变化趋势、以及检测方还能不能给出可信判断。下面这些趋势来自公开实验设计里的常见结论，加上我自己用一套自建语料做的小规模验证，你可以按同样方法在自己的数据上复现。

4.1 轻度改写：同义词替换与标点调整

轻度改写指的是替换少量实词、调整标点、加删连接词，句式和段落结构基本不动。这类改写对采样偏置型水印的破坏有限，因为它只污染了被替换词所在位置及其后一个位置的哈希判定，整体统计结构还在。

按前面说的衰减速度，替换率 10% 左右，z 值大概从 6 掉到 4.5 上下，仍然在阈值之上。这时候检测方还能给出“显著”的判断，但置信度下降。如果原文本来就短，比如 120 词，那这 10% 的替换就可能把分数打到阈值以下，变成判不了。

这里有个实操细节：替换词落在哪一侧很关键。如果改写工具倾向于把生僻词换成常见词，而绿名单往往包含更多常见词（因为偏置让它们概率上升），那么替换反而可能提高命中率，出现 z 值不降反升的怪现象。我在一次测试里就遇到过，替换率 8%，z 值从 5.2 涨到 5.6，一度以为代码写错了，排查半天才想明白是这个原因。所以评估改写影响，不能只看替换率，还要看替换方向和词表分布。

4.2 中度改写：句式重组与语序调整

中度改写会重排句子成分、把主动改被动、把长句拆成短句、合并相邻句。这类操作对水印的破坏比同义词替换更严重，因为它直接改变了 token 的先后顺序，哈希链断得更彻底。

破坏程度取决于水印实现用的是前一个 token还是固定窗口做哈希种子。用前一个 token 的方案，一次语序调整会影响两个位置；用固定窗口（比如前三个 token 的组合）的方案，影响面更大，但抗局部扰动的能力也更强。我在实验里对比过，同样 30% 的句式重组，前 token 方案的 z 值平均掉 65%，窗口方案的 z 值掉 40% 左右。

这一档的实际结论是：大概率判不出来，但也不是完全没有信号。z 值通常会落到 1 到 2.5 之间，属于“不显著但也高于随机”的灰色地带。这时候检测工具如果只看单一阈值，会直接报“无水印”，但这个结论其实是有风险的，因为分数虽然不显著，趋势仍在。我的做法是在这个区间加一个二次判断，看文本里被偏置词的分布是否集中在段落开头或结尾，如果是，说明改写只动了中间部分，仍有部分水印残留。

4.3 重度改写：回译与多轮重写

重度改写的典型代表是回译：先翻成另一种语言，再翻回来。这一来一回，词汇、语序、句式全变了，token 序列几乎等于重新生成。对采样偏置型水印来说，这基本是毁灭性的，z 值直接回到随机水平，判不出来。

但这里有个值得注意的例外：如果回译用的翻译模型本身也带水印，或者回译后的文本又被同一个模型润色过，那么新文本会带上新的水印。检测方如果用的是同一套密钥，反而可能检出“有水印”，但那个水印属于润色环节，不属于原始生成环节。这就造成溯源错位：你以为查出来的是初稿来源，其实是最后一环的痕迹。这个问题在实际取证里非常要命，我在帮朋友排查一起内容纠纷时就碰到过，两次检测都报“显著”，但指向的不是同一个环节。

所以重度改写下的正确结论不是“查不出来”，而是“查出来的东西不能直接对应到原始生成”。要解决这个问题，需要在每个环节用不同的密钥，或者在元数据里记录处理链路，光靠文本本身是分不清的。

4.4 混合改写：人工润色的杀伤力

最后一档是人工逐句重写。这一档最彻底，也最难防。人工重写不是机械替换，它会重组信息、改变叙述顺序、增删细节，token 序列跟原文的重合度可能低于三成。任何统计型水印在这种改写下都会失效，因为统计基础已经不存在了。

面对人工重写，剩下的手段只有风格指纹和内容比对。风格指纹给的是概率，内容比对给的是相似度，两者都不能证明“这段文字来自某次生成”。这也是为什么我一直强调：水印的价值在于“能证明是”，不在于“能证明不是”。检出水印，可以作为一条有力证据；没检出，不能反推说这段文字一定是人写的。这个逻辑方向很多人会搞反，包括一些检测工具的宣传口径。

四档改写的对比整理如下：

5. 动手做一个最小可用的水印与检测 Demo

理论和参数讲完，落到代码。这一节给一个能跑起来的最小实现，重点不在工程完备，而在于让你亲手看到“打水印—检测—改写—再检测”这条链路里分数的变化。我用的是一个简化的哈希划分方案，不需要改动模型权重，只在采样阶段加逻辑。实际生产环境要考虑分词一致性、密钥管理、批量处理，这些我会在注意事项里点出来。

5.1 环境与依赖的取舍

依赖很简单：一个能拿到 logits 的生成框架，加 numpy 做统计。分词器必须和生成时用的完全一致，这是整个方案的地基，版本对不上后面全白搭。

pip install torch transformers numpy

import torch import numpy as np from transformers import AutoTokenizer, AutoModelForCausalLM # 模型名用占位符，替换成你本地的小型开源 GPT 模型即可 MODEL_NAME = "your-small-gpt-model" tokenizer = AutoTokenizer.from_pretrained(MODEL_NAME) model = AutoModelForCausalLM.from_pretrained(MODEL_NAME) model.eval()

为什么不直接用最大的模型？因为水印实验要反复采样、反复检测，大模型跑一轮太慢，用小型模型验证逻辑足够了。逻辑验证通过，换模型只需要改一行。

5.2 打水印的核心逻辑

核心是三件事：用密钥加前一个 token 做哈希，把词表切成两半，给绿名单加偏置。为了让代码短一点，我用一个简化的哈希函数，生产环境要换成带密钥的加密哈希，避免被反推。

VOCAB_SIZE = len(tokenizer) GAMMA = 0.25 # 绿名单比例 DELTA = 1.5 # 偏置强度 KEY = 20240501 # 演示用密钥，实际要用安全随机数 def green_list(prev_token_id): """根据前一个 token 和密钥，生成绿名单索引集合""" rng = np.random.default_rng((prev_token_id * 2654435761 + KEY) % (2**32)) size = int(VOCAB_SIZE * GAMMA) return set(rng.choice(VOCAB_SIZE, size=size, replace=False)) def watermark_logits(logits, prev_token_id): """对 logits 做绿名单偏置""" gl = green_list(prev_token_id) idx = np.array(list(gl)) logits[idx] += DELTA return logits def generate_with_watermark(prompt, max_new_tokens=120): input_ids = tokenizer(prompt, return_tensors="pt").input_ids out = model.generate( input_ids, max_new_tokens=max_new_tokens, do_sample=True, top_k=0, logits_processor=None, ) return out

上面这段是简化版，真实实现需要在logits_processor里逐 token 调用watermark_logits，因为每一步的prev_token_id都不一样。我故意写成两段，是为了让你看清楚“偏置发生在采样之前”这个时机。如果放错了位置，比如在生成完之后再改，那就退化成后处理替换型，抗改写能力会差一截。

参数取值的经验：GAMMA取 0.25，DELTA取 1.0 到 2.0。我先用 1.5 试，文本读起来还算自然，z 值在 200 词文本上能到 5 以上。DELTA调到 3.0，检出更稳，但文本里会明显出现用词偏好，同一个意思反复用某几个词，读起来有点机械。

5.3 检测端的实现

检测要做的是复现划分、统计命中、算 z 值。注意几个细节：跳过特殊 token、跳过标点、长度不够直接返回“样本不足”。

def detect_watermark(token_ids, min_tokens=80): if len(token_ids) < min_tokens: return {"verdict": "样本不足", "z": None, "count": len(token_ids)} hits, total = 0, 0 for i in range(1, len(token_ids)): cur, prev = token_ids[i], token_ids[i - 1] if cur in tokenizer.all_special_ids: continue gl = green_list(prev) if cur in gl: hits += 1 total += 1 if total == 0: return {"verdict": "无有效token", "z": None, "count": 0} expected = GAMMA * total std = np.sqrt(total * GAMMA * (1 - GAMMA)) z = (hits - expected) / std verdict = "检出" if z > 4 else ("疑似" if z > 2 else "未检出") return {"verdict": verdict, "z": round(float(z), 2), "count": total, "hits": hits, "rate": round(hits / total, 3)}

跑一遍看结果：

prompt = "关于内容溯源这件事，我的理解是这样的：" out = generate_with_watermark(prompt) ids = out[0].tolist() print(detect_watermark(ids))

正常情况输出类似{'verdict': '检出', 'z': 5.41, 'count': 156, 'hits': 62, 'rate': 0.397}。绿名单命中率 0.397 明显高于 0.25 的期望，z 值超过 4，判定为检出。

再对照一组不打水印的生成，命中率应该在 0.25 附近，z 值在 0 上下浮动。如果两组分数差不多，八成是分词或密钥对不上，先查这个。

5.4 改写攻击的模拟

要验证抗改写能力，得先能自动改写。我一般用两种方式：同义词表替换、以及用另一个模型做回译。前者简单可控，后者更接近真实场景。

SYNONYMS = { "重要": ["关键", "要紧"], "方法": ["途径", "手段"], "问题": ["状况", "疑点"], "理解": ["认识", "看法"], } def light_rewrite(text, ratio=0.1): words = list(text) n = max(1, int(len(words) * ratio)) rng = np.random.default_rng(42) for idx in rng.choice(len(words), size=n, replace=False): w = words[idx] if w in SYNONYMS: words[idx] = SYNONYMS[w][0] return "".join(words)

跑完改写再检测，就能看到 z 值的衰减曲线。我建议你从 5%、10%、20%、30% 四档替换率各跑十次取平均，画一条曲线出来。我自己测下来的形态是：前 10% 缓降，10% 到 20% 陡降，20% 之后基本贴地。这条曲线的拐点位置，就是你这个方案的实际抗改写边界。

5.5 密钥管理这一环别省

代码里密钥是硬编码的，这在演示里没问题，生产环境绝对不行。密钥一旦泄露，任何人都能反推划分规则，水印就变成了公开的标记，失去溯源意义。常见做法是把密钥放在独立的密钥管理服务里，检测接口只返回分数不返回中间结果，同时记录每次检测的调用方，防止被批量试探。这块不是算法问题，是工程安全问题，很多项目栽在这里。

6. 常见问题与排查技巧实录

这一节是我踩过的坑的汇总。水印这套东西，算法本身不复杂，难的是各种边界情况，尤其是分词和长度这两个地方，出问题的概率最高。

6.1 检测分数忽高忽低，同一个文本两次结果不一样

这个现象我遇到过不止一次，原因有三个方向。第一是分词不一致：生成时用的是模型自带分词器，检测时如果先做了文本清洗（比如把全角标点转半角），分词结果就变了，哈希输入跟着变，分数自然飘。第二是采样随机性：如果生成时温度设得高、又没固定随机种子，每次生成的文本不同，分数当然不同，这是正常现象，不是 bug。第三是密钥错位：多实例部署时如果每个实例的密钥不同，检测请求被路由到另一个实例，就会出现“有时检出有时不检出”。

排查顺序建议这样：先固定随机种子重跑生成，确认同一段文本两次检测结果一致；如果不一致，问题在检测端；如果一致，问题在生成端的随机性。然后再核对分词器版本号，两边必须完全一致。最后查密钥分发，看是不是有实例用了默认值。

注意：检测端做任何文本预处理（去空白、转小写、标点归一化）之前，必须确认生成端也做了同样处理，否则等于用了两套分词规则。

6.2 短文本频繁误判，怎么处理

短文本的问题是统计量不够，前面算过，50 词以内根本判不了。但实际业务里短文本占比很高，评论、标题、摘要都是这一类。我的处理方式分三层。

第一层是硬性门槛，有效词少于 80 直接返回“样本不足”，不给结论。这比给一个不可靠的结论要好，至少不会误导人。第二层是放宽阈值但降级表述，80 到 150 词之间，z 值在 2 到 4 之间报“疑似”，不报“检出”，让使用者知道这个结论的强度。第三层是多段合并，如果同一来源有多段短文本，把它们拼起来做一次检测，样本量上去了，判断就稳了。这个思路在批量处理场景里特别有用，比如判断某个账号的一批评论是否来自同一模型。

还有一个隐蔽的坑：短文本里如果包含大量专有名词、代码标识符，这些 token 的分布本来就不随机，会干扰统计。我的做法是维护一个停用表，把这类 token 排除在统计之外，宁可少算也不要错算。

6.3 常见问题速查表

这张表里最值得说的是“改写后 z 值升高”这一条，因为它反直觉，容易被当成代码 bug。实际上是词表分布和替换方向共同作用的结果，理解这一点，你在评估改写影响时才不会得出错误结论。

7. 这套技术的边界：能证明什么，不能证明什么

最后聊边界，这部分比技术细节更重要。我见过太多人把水印检测结果当成铁证，也见过有人因为没检出就断言“这是人写的”，两个方向都错。

7.1 检出是证据，未检出不是反证

水印检测的逻辑是单向的：检出显著，说明这段文本极大概率经过了带密钥的生成流程；未检出，只能说明“在当前检测口径下没有发现标记”，不能推出“这段文本不是模型生成的”。原因很直接：改写、截断、格式转换、分词差异，任何一个环节出问题都会导致未检出，而这些环节跟文本来源无关。

这个单向性决定了水印的正确用法是辅助判断，而不是单独定罪。在实际场景里，它适合跟其他证据组合使用：生成日志、会话记录、时间戳、内容相似度。单靠一个 z 值下结论，误判风险不小。我在实际项目里给自己定的规矩是：z 值超过 6 且文本长度超过 300 词，才作为强证据；2 到 4 之间只作参考；低于 2 直接忽略。

7.2 改写攻击的现实威胁与应对

从攻防角度看，改写是成本最低的规避手段，不需要任何技术门槛，一个免费的重写工具就能把大部分水印打掉。这意味着水印不适合作为唯一的防护手段，它更像是增加一点规避成本，而不是建立不可逾越的屏障。

如果要提高抗改写能力，有几个方向可以试。一是多密钥叠加，在不同粒度上埋多层水印，改写破坏一层还有另一层。二是语义级水印，不依赖 token 序列，而是在句子语义层面做标记，这类方案抗改写能力强一些，但实现复杂度高，检测也更慢。三是结合生成日志，把水印当成链路中的一环，而不是全部，服务端记录生成时间、会话标识、模型版本，这些元信息比文本水印可靠得多，只是没法在文本脱离平台后继续生效。

还有个现实问题要提：水印会影响文本质量，这是硬约束。偏置越强，文本越不自然，用户能感觉出来。所以实际部署时，强度往往被压得很低，检出率也就跟着下来。这是一个无法消除的权衡，任何声称“既完全不影响质量又能百分之百检出”的方案，我都持怀疑态度。

7.3 内容合规与数据边界

做这类实验，有两条线要守住。一是不要拿真实用户的文本做测试，用自己生成的语料，或者公开的、已脱敏的数据集。二是检测结果的使用要有边界，它只能用于内容溯源和流程改进，不能用来给个人贴标签。我见过把检测分数直接当成“学术不端证据”的做法，这在方法上站不住脚，因为误判率根本没有被严肃评估过。

另外，密钥和检测接口都属于敏感资产，对外提供服务时要限流、要审计、要防止被批量试探。有人会通过大量提交文本、观察返回分数的变化，反推密钥或划分规则，这类攻击在接口开放的场景下很现实。工程上可以用“只返回分档结果、不返回精确 z 值”的方式来降低信息泄露。

我自己在这块折腾下来的体会是，水印这套东西的价值，八成在“建立可追溯的链路”，两成在“文本本身的标记”。真正靠得住的溯源，从来不是单点技术，而是生成记录、密钥管理、检测口径、使用规范这一整套配合起来。文本水印更像是给这套体系加了一道低成本的辅助线，它能提高一点规避门槛，但撑不起“绝对可查”的期待。所以回到最初那个问题，改写一遍还能不能查出来，我的答案是：轻度改写大概率还能，中度改写看运气，重度改写基本没戏，而你要做的，是让“没戏”的那部分由别的机制兜住，而不是指望水印一个人扛。