watermarks-remover

先说结论：三层，可靠性完全不同

这个项目处理 AI 生成内容里的溯源标记，但三层的能力和代价差别很大，混在一起用会出问题。

覆盖的厂商与生态（按类别）：Claude、Gemini / SynthID-Text、OpenAI 的溯源面、开源模型的 Kirchenbauer 式（green-list）与 keyed-Gumbel / EXP（Aaronson）标记。

实践上的含义：能用 A 层和文件层就别碰 B 层。 下面会说清原因。

A 层：确定性，可以放心用

处理的是那些藏起来的字符：零宽字符、异形空格、双向文本覆盖符、tag 字符。

这些字符的问题是它们会在你复制粘贴、跨软件传输时悄悄改变文本内容，肉眼看不见但影响比对、搜索和渲染。A 层的清理是确定性的——同样的输入给同样的输出，而且不改变可读内容。

这是这个项目里最没有争议、最该优先用的部分。

B 层：先读完这一节再用

它为什么要改写，而不是删除

项目对文本水印的机制说得很直白：

Text watermarks live in the wording itself: the signal is spread across token choices, so nearly every sentence carries a little of it.

信号在用了哪些词里，不是藏在某个字符位置。所以移除它只有一条路：换词。而且项目给了两条具体结论：

1. 移除等于改写，不是重排。 打乱段落顺序、改标题、做轻度润色，几乎不移动信号。要剥离统计标记必须逐句改写相当一部分文本。
2. 改写会让文案退化。 任何改写都会把原措辞换成改写模型的措辞，语气、声音和精确度都会被压平。在 SEO、营销、客户交付的文案上，这种退化是真实存在的，而且对最在意文字的人最明显。

项目用了一个类比：相当于拿顶级模型产出的文本，让一个能力更弱的模型从头重写一遍——结果不可能超过改写模型的上限。

项目自己给的反问

这一段是整个README 里最诚实的地方，原文：

If the plan is to rewrite the text with a cheaper model anyway, why pay for a premium model in the first place? Generating directly with the cheaper model is simpler, cheaper, and produces the same — or better — end result.

翻译：如果你本来就打算用便宜模型重写，为什么一开始要付钱用贵的？ 直接用便宜模型生成更简单、更便宜，结果相同或更好。

所以 B 层的适用场景很窄： 你确实需要那个强模型的思路和起草，并接受之后有一次改写来满足隐私或合规要求。B 层不是一条「低成本拿到无标记文本」的路线。

什么时候该跳过 B 层

项目给的判断很直接：

• 质量比卫生更重要 —— 走无损路线：只要 A 层的 Unicode 清理加文件元数据清理，保留原文。
• 反正要重写 —— 用非原始来源的模型（用来源模型重写可能重新盖章），并且记住残留风险仍然存在。

一条实操提醒

要避开某个来源模型的标记，就不要用那个模型去改写它的输出。项目建议 Layer B 用非来源模型，原因就在这里。

能力边界的诚实声明

这一段必须原样记住：

Until vendors ship public detectors and keys, no tool can honestly certify "this fails the official check." Reports must separate verifiable vs best-effort work.

意思是：在厂商公开检测器和密钥之前，没有任何工具能诚实地担保「这个能通过官方检测」。 所以它的报告会区分「可验证」和「尽力而为」两部分——这个区分本身就是一个负责任的信号，值得信任。

使用边界：这不是免责声明，是使用前提

项目自带一份 ethics 文档，README 里引用的原话：

For privacy and research on your content — not academic fraud or false "human-written" claims.

以及：

Responsible use: This project is for content you own or are authorized to process. Users must adhere to local regulations and use it responsibly. The developers disclaim any liability for potential misuse by users.

翻译成实践上的三条：

1. 只处理你拥有或获授权处理的内容。 这是前提，不是建议。
2. 不要用于学术造假，也不要用于虚假声明「这是人工撰写的」。
3. 遵守当地法规。

第三条经常被跳过，但它最实际： 在某些司法辖区和平台规则下，移除 AI 溯源标记以规避披露义务可能直接违规。工具不违法，用法可能违法。

两处「不毁数据」的设计

这两处设计比功能列表更能说明项目的成熟度，值得单独看。

文本工具拒绝二进制输入

文本工具如果指向 .docx、.pdf 或图片，早期版本会去解码压缩字节，然后报告掉出来的码点——那噪声追踪的是压缩而不是内容，而 clean_text.py 还会把那些乱码写回去，直接毁掉文件。

现在的行为是拒绝并指名该用哪个工具：

bashpython3 service/scripts/inspect_text.py report.docx
# refusing to treat report.docx as text: it looks like a ZIP container (DOCX, ODT, …).
# Use inspect_file.py / clean_file.py, which route by format,
# or pass --force-text to scan the raw bytes anyway.

判定方式是magic number 加控制字节比例，所以非 UTF-8 编码的文本仍然能用。

无法识别的格式绝不自动清理

匹配不到任何已知文本/图片/容器格式的字节会被标为 unknown，不再回退当成文本。auto 模式下 clean_file.py 对这类文件拒绝执行（退出码 2，不写任何输出），而不是解码成 UTF-8 再写回乱码。

需要强制处理的话，--as text 或 --force-text 是显式开关。

「宁可什么都不做，也不要毁掉文件」——这个默认值是对的。

怎么用

直接跑脚本

bashSCRIPTS=service/scripts

# 统一入口：先看，再动
python3 "$SCRIPTS/inspect_file.py" draft.md
python3 "$SCRIPTS/clean_file.py" draft.md -o draft.cleaned.md

# 文本 A 层
python3 "$SCRIPTS/inspect_text.py" draft.md
python3 "$SCRIPTS/clean_text.py" draft.md -o draft.cleaned.md --stats

# B 层改写钩子：默认只打印提示词，不需要模型
python3 "$SCRIPTS/rewrite_text.py" draft.md --backend print-prompt --tactic paraphrase

建议的顺序：先inspect，再 clean。 inspect 是只读的，看清楚有什么再决定要不要动。

B 层接本地模型

默认 print-prompt 只输出提示词，不调用任何模型。要用本地 Ollama：

bashWATERMARKS_REWRITE_BACKEND=ollama WATERMARKS_REWRITE_MODEL=llama3.2 \
  python3 "$SCRIPTS/rewrite_text.py" draft.md -o draft.rewritten.md

默认只允许 loopback。 远程端点需要显式开 WATERMARKS_REWRITE_ALLOW_REMOTE=1 或 --allow-remote。API key 只从 WATERMARKS_REWRITE_API_KEY 读，绝不从命令行参数读。

HTTP 服务

skill 实际驱动的是一个标准库 HTTP 服务，网页应用也能直接接，不用把代码 vendor 进来。

bashWM="http://127.0.0.1:8765"
curl -s "$WM/health"
curl -s "$WM/openapi.json"

默认只绑定 loopback，按信任网络设计。要设 WATERMARKS_SERVER_API_KEY 才会要求 Authorization: Bearer <key>。

主要端点：

批处理端点有 WATERMARKS_MAX_BATCH_FILES 上限（默认 50）。单个条目出错只标记那一项的 "ok": false，不会中断整批。

检测与清理是分开的两步

这一点很重要：服务不会在你没要求时调用任何厂商 API。

• /detect —— 跑配置好的检测器。文本走厂商检测器加文体分析，图片走 SynthID 像素评分。
• /inspect 可以带 "detect": true，把检测结果附到报告里。
• /clean 支持 "detect_before" / "detect_after"，分别给输入和输出打分，这样你能测出一次清理到底改动了什么。

detect_before / detect_after 是这个项目里最实用的一个设计——它让「我到底消掉了多少」变成可测量的，而不是靠感觉。

检测器也标注了自己的性质：markllm 是研究工具、gumbel 是同密钥重放、claude-text 目前是占位符（等 Anthropic 发布水印检测 API 后才启用）。没有哪个是厂商预言机。 检测是 fail-soft的：未配置、超时或出错的检测器会报告 {"available": false}，不会阻塞清理。

推荐的使用流程

1. 先确认你有权处理这个内容。 这是前提。
2. 先跑 A 层和文件层的无损清理，保留原文。
3. 用 detect_before / detect_after 测一下清理效果。
4. 只有在确实必须做 B 层时才做，并接受文风损失。
5. 做 B 层用非来源模型。
6. 不要指望它担保通过官方检测——项目自己都不这么声称。

什么情况下别用它

• 想冒充人工撰写 —— 项目明确划了这条线，也明确不支持。
• 规避披露义务或合规要求 —— 在很多司法辖区这本身就违规。
• 要「保证通过官方检测」 —— 它做不到，也不声称做得到。
• 正式文案追求文风 —— B 层会压平语气和声音；走A 层加文件层的无损路线更好。