Grok API 文本默认加水印：开发者要改的不是代码，是流程

chunmiao3032

194人浏览 · 2026-11-08 09:41:04

chunmiao3032 · 2026-11-08 09:41:04 发布

11 月 7 日起，xAI 给 Grok 系列 7 款模型的 API 文本输出默认加上了隐形水印。官方开发者文档列出的范围是 grok-4.7、grok-4.6、grok-4.5、grok-4.3、grok-4.20-reasoning、grok-4.20-non-reasoning、grok-4.20-multi-agent，覆盖普通回复、结构化输出和工具调用参数，全球所有端点都生效，不只是欧盟区域的流量。理由写得很直白：遵守欧盟《人工智能法案》第 50 条关于合成内容透明度（机器可读标记）的要求。

这条新闻在技术圈没掀起多大水花，但对真正把 Grok 接进业务系统的人来说，有几个点值得拎出来说清楚。

一、水印加在哪：不是字符，是"选词概率"

先把最容易误解的地方讲明白。文本水印不是加一串看不见的 Unicode 字符，不是塞在元数据里，也不是文末加个隐藏标记。

按官方文档的描述，水印是在模型生成的过程中，轻微影响它选哪个 token —— 在采样阶段做一点偏置。带来的结果是：

文本长度不变，肉眼和编辑器都看不出差异；
- 复制粘贴、清空格、过滤不可见字符，都去不掉；
- 但因为它寄身在"用词选择"这个统计特征上，改写、翻译、换同义词之后会衰减。
  检测端也是统计式的：据文档，检测方给出的是"有水印 / 无水印 / 不确定"三档结论，文本越长信号越强，检测 API 需要提交申请才能拿到。

这就决定了一件事：它不是一个判定器，是一个概率信号。 以前"这段字是不是 AI 写的"只能靠猜，现在多了一个有厂商背书的参考值，但参考值不等于答案。

二、三家做法不一样，别按同一套假设写代码

厂商	覆盖范围	默认状态	开发者能不能关
xAI（Grok）	7 款模型，全球所有端点	默认开启	团队管理员在控制台按模型关闭
OpenAI（textGrain）	欧盟区 ChatGPT / Codex 文本	欧盟默认开启	全球 API 为"选择加入"
Anthropic（Claude）	8 月起新模型，全球所有产品线	默认开启	未见对外开关

据报道，OpenAI 在 10 月 5 日公布 textGrain 时给过一组实测数字，我觉得比任何宣传语都有价值：1% 误报率下，400 token 的段落检出率约 95%，200 token 降到约 80%，数学类答案更低；把 400 token 段落里 10% 的词换成同义词，检出率从约 92% 掉到 66%，换到 25% 就只剩 17%。

Anthropic 那边的口径也类似，8 月的说明里明确写了：检测到水印只说明这段文本"经过 Claude 处理"，不代表 Claude 是作者——润色、翻译、摘要都会带上；反过来没检测到，也不代表人写的。

这三家放在一起看，方向是一致的：水印的作用不是抓抄袭，是压缩"我没用过 AI"这句话的辩解空间。

三、真正要动手的三件事

1. 把 `x-watermark` 记进日志

Grok 的每个 Responses API / Chat Completions API 响应都会带一个 x-watermark 响应头，true 表示本次输出带水印。这个成本最低，先做：

curl -sS -D - https://api.x.ai/v1/responses \
  -H "Authorization: Bearer $XAI_API_KEY" \
    -H "Content-Type: application/json" \
      -d '{"model":"grok-4.7","input":"写一句关于海的短句"}' \
        -o /dev/null | grep -i "^x-watermark"
        ```
Python 里同理，把响应头落库，出问题时能自证哪些输出是加标之后产生的：

```python
import requests

resp = requests.post(
    "https://api.x.ai/v1/responses",
        headers={"Authorization": f"Bearer {API_KEY}"},
            json={"model": "grok-4.7", "input": "写一句关于海的短句"},
                timeout=30,
                )
marked = resp.headers.get("x-watermark", "").lower() == "true"
print(marked, resp.json()["output"][0]["content"][0]["text"])

注意别把整段输出直接 print 到生产日志里，脱敏和体积控制是另一件事。

2. 跑一遍快照测试和缓存逻辑

文档里明确写了，水印覆盖结构化输出和工具调用参数。这意味着同一个 prompt 拿到的 JSON，加标前后的字节内容可能不完全一致。

如果你的流水线里存在这几类逻辑，上线后必须重新验证一遍：

用输出原文算 hash 当缓存 key；
- 拿 JSON 做逐字节比对的金标准测试；
- 对 tool call 参数做去重、比对、变更检测。
  顺带说一句：拿模型原始输出算 hash 当缓存 key，本身就是个坏设计——模型输出本来就不稳定。正确的做法是归一化后再算，或者直接用语义 key。这次水印只是把这个老问题提前暴露出来。

3. 弄清楚关水印的口子有多窄

控制台的开关不是给普通开发者准备的：

只有团队管理员能关，拿 API key 的人在代码里关不掉，也没有请求参数可传；
- 一次只能关一个模型，混用 4.7 和 4.20 系列的要逐个确认；
- 生效大约 5 分钟，每次开关都写进团队审计日志；
- 部分模型可能被锁定，控制台里也关不了；
- 关闭时要勾选确认"适用法律例外"，并承担本该由自己履行的标注和披露责任。
  所以"这是内部系统，不想带水印"这种理由基本站不住。真要走这条路，先让法务出结论，别让开发自己在控制台点。