【论文精读】CodeWMBench 揭示 AI 生成代码水印的残酷真相

论文地址：# CodeWMBench: An Automated Benchmark for Code Watermarking Evaluation

在 GitHub Copilot、ChatGPT 和 CodeLlama 深度介入开发流程的今天，代码创作正经历一场从“逐行敲击”到“意图生成”的范式转移。然而，这种生产力的飞跃也释放了一个阴影中的幽灵：代码抄袭与学术诚信危机的门槛被降至冰点。 作为开发者，我们曾寄希望于“数字水印”——那层不可见的指纹，来识别并追踪 AI 生成的内容。但问题是，这些所谓的“指纹”真的能经受住 AI 自身的挑战吗？中国科学技术大学的研究团队发布了 CodeWMBench，这项针对代码水印技术的深度“体检”揭示了一个令整个安全圈警醒的现状：在不断进化的 LLM 面前，现有的代码水印防御体系可能只是一层一戳就破的纸外壳。

读前先问

读论文之前首先要问几个问题：

1. 这篇论文大方向的目标是什么？ 提出一个全面的自动化基准测试平台（CodeWMBench），用于评估代码水印方法，从而满足通过水印技术主动检测人机代码、防止版权受到侵犯的需求。
2. 这篇论文要解决什么问题？ 论文主要解决代码水印评估标准不够全面和自动化的缺陷。过去的水印评估方法往往只关注水印容量、加解密速率和破解难度，而没有关注应对现代大模型代码克隆技术时的鲁棒性、代码透明度以及水印嵌入后的代码可用性。因此，论文旨在构建一个多维度的自动化评估框架，来全方位衡量代码水印的无害性（Harmlessness）、透明度（Transparency）和鲁棒性（Robustness）。
3. 为什么会有这些问题？ 编程语言生成（PLG）模型（如 CodeLlama、GitHub Copilot 和 ChatGPT）得到了广泛应用，这大幅降低了代码抄袭的成本。用户即使不懂底层逻辑，也能通过简单的查询复制和修改代码。
4. 为什么要解决这个问题？这个问题为什么难？ 为什么要解决： 为了应对大模型时代日益严峻的版权侵权和学术诚信挑战，必须找到能够有效区分人类代码和机器生成代码的可靠手段 。 为什么难： 第一，代码具有极为精确的语法，传统的文本水印方法（如简单的同义词替换）在代码领域不可行，因为代码缺乏同义结构，随意修改极易导致功能错误 。第二，现有的规则基水印和自然通道水印很容易被大语言模型（LLM）的重写功能识别并擦除 。第三，由于需要保证代码在嵌入水印后依然能够正确编译和执行，寻找既不破坏代码功能（无害性），又难以被人类程序员察觉（透明度），同时还能抵抗LLM代码翻译/重写攻击（鲁棒性）的水印极具挑战性 。
5. 作者是怎么解决这些问题的？ 作者设计并开源了自动化基准测试平台CodeWMBench，通过以下几个核心模块解决评估难题： 构建标准化数据集： 收集并清洗了来自编程挑战、真实世界代码等场景的数据集，确保用于测试的代码具有语法正确性和可执行验证性 。 提出多维度评估指标： 1️⃣ 无害性（Harmlessness）： 提出了定量指标CodeUsability，分为粗粒度测试（通过语法检查即可）和细粒度测试（必须编译运行并输出预期结果），以评估水印嵌入是否破坏了代码 。 2️⃣ 透明度（Transparency）： 引入了CodeBLEU和CodeBERTScore这两个客观指标来自动化评估代码在嵌入水印前后的语义相似度和不可感知性，替代了低效的人工评估 。 3️⃣鲁棒性（Robustness）： 首次引入了基于大语言模型（LLM）的水印擦除技术，利用CodeLlama-7b模型设计了“基于重写的擦除（Rewrite-based Removal）”和“跨语言重翻译擦除（Retranslate-based Removal）”两种新型攻击方式，以此模拟不懂代码的用户如何利用AI擦除水印 。

论文精读

核心发现一：告别“盲盒检测”，主动水印成为版权防线的唯一选择

长期以来，检测 AI 生成内容主要依赖于 ZeroGPT 等“被动检测”工具。但在代码领域，这类工具的表现只能用“灾难”来形容。

为了建立严谨的评估标准，CodeWMBench 团队在 CodeNet (cn) 、CodeSearchNet (csn) 以及 MBXP 等大规模数据集上进行了详尽测试。实验证明，由于代码语法具有极高的严谨性和结构化特征，人与 AI 在实现标准逻辑时往往会产生高度重合。

“代码语法的僵化和结构化性质意味着传统方法在代码领域面临重大局限，由于通用人机文本检查的被动检测特征与代码不匹配，往往会导致误报。”

这种低熵的本质让被动检测沦为一场猜谜游戏。相比之下，基于代码水印（Code Watermarking）的“主动检测”——即在生成阶段嵌入可验证信号——成为了目前公认最可靠的替代方案。

核心发现二：LLM 竟是天然的“水印粉碎机”？

CodeWMBench 研究中最令人不安的发现是：LLM 天生具备抹除水印的能力。研究提出了两种杀伤力巨大的“去除攻击”：

• 基于 LLM 的重写攻击（Rewrite-based Removal）： 攻击者无需精通算法，只需通过一个简单的“Easy Prompt”（例如：“使用不同的循环结构重写此逻辑”），要求 CodeLlama 等模型优化代码。
• 基于 LLM 的重翻译攻击（Retranslate-based Removal）： 利用 LLM 将代码在 Java、Python、C++ 等语言间进行往返翻译。

这里涉及到一个深刻的 双通道理论 ：代码由“正式通道”（Formal Channel，如逻辑结构、AST）和“自然通道”（Natural Channel，如变量名、注释、代码风格）组成。

LLM 的训练目标是最大化自然通道的概率，即让代码看起来更符合人类最通用的编写模式。换句话说，LLM 在对抗自然通道的平庸时，会自然而然地将作为“非自然噪声”的水印特征作为冗余优化掉。这种“无意识”的优化，让即便是不懂代码的初学者也能轻松摧毁复杂的防御系统。

核心发现三：水印的代价——当“保护”让代码彻底瘫痪

在安全研究中，我们必须权衡“安全性”与“可用性”。CodeWMBench 引入了无害性（Harmlessness）指标，并从粗粒度（语法检查）和细粒度（单元测试运行结果）两个维度进行了量化。

根据 Table 2 的实验数据，现有技术的代价大得惊人：

• Vanilla-Watermark：虽然在文本水印领域表现出色，但在代码领域，嵌入水印后其可用性得分竟然直接跌至 0。
• SWEET：这种改进方案虽然维持了部分可用性，但在面对即便没有任何移除攻击（No_removal）的情况下，其水印提取率竟然也是 0。
• SrcMarker：作为目前的 SOTA 方案，其可用性高达 0.94，这得益于它基于抽象语法树（AST）的后处理机制。

然而，即便是最强的 SrcMarker 也并非坚不可摧。在 Retranslate 攻击下，其多位准确率（BitAcc/MsgAcc）从 0.931/0.812 显著下降至 0.867/0.667。这证明了在 LLM 的跨语言重构面前，即使是深度的特征嵌入也会受到严重侵蚀。

核心发现四：CodeWMBench——为 AI 代码指纹建立的第一套“度量衡”

过去，代码水印的评估高度依赖人工且维度单一。CodeWMBench 的贡献在于它建立了一套全自动化的体检中心。它通过三个核心维度对水印进行“全方位扫描”：

• 无害性 (Harmlessness) ：确保代码打上水印后依然“好用”。
• 鲁棒性 (Robustness) ：利用 LLM 模拟真实的攻击场景，看水印是否“耐操”。
• 透明度 (Transparency)：通过 CodeBLEU（结构相似度）和 CodeBERTScore（语义等价性）两项指标，量化评估代码在被打上指纹后，其灵魂是否依然保持原样。

目前，这套基准测试已在 GitHub 开源，旨在填补行业在自动化、标准化评估手段上的空白。

结语：双通道博弈与未来的“代码长城”

作为安全研究员，我们必须面对一个残酷的事实：大多数现有的代码水印都寄生在“自然通道”中，而这正是 LLM 的强项。如果我们继续在变量命名、空格或注释上做文章，这些指纹将在 LLM 的优化浪潮中迅速消亡。

未来的突破点在于正式通道（Formal Channel）。我们需要一种静默的、深植于 AST 逻辑结构之中的水印技术。这种水印不依赖于人类可读的风格，而是像基因一样编码在算法的逻辑顺序中。

如果行业不能尽快转向这种更深层次的结构化保护，那么到 2030 年，随着模型优化能力的进一步飞跃，“AI 生成代码检测”这一概念或许将彻底走入历史。当 AI 能够完美优化掉所有“多余”的指纹时，我们该如何证明一段代码的灵魂归属？