💻 computer science

PromptMark: A Prompt-Guided Iterative-Feedback Framework for Source Code Watermarking

PromptMark 是一个黑盒、提示词引导的框架，它通过结构化的输入指令和迭代反馈，将可检测的水印嵌入到 AI 生成的源代码中，在不损害代码功能或不需要访问模型内部参数的情况下，实现了强大的归因能力。

原作者： Istiaq Ahmed Fahad, Mridha Md. Nafis Fuad, Kazi Sakib

发布于 2026-06-23

📖 1 分钟阅读☕ 轻松阅读

原作者： Istiaq Ahmed Fahad, Mridha Md. Nafis Fuad, Kazi Sakib

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你是一名面包师，雇佣了一位非常有才华但隐形的机器人厨师，每天烘焙成千上万个面包。你想知道哪一个面包是由你的机器人制作的，哪一个是人类竞争对手制作的，但机器人不会留下签名，而且面包外观看起来完全一样。

这就是 PromptMark 所解决的问题，只不过这里不是面包，而是由人工智能（AI）编写的计算机代码。

以下是该论文如何通过简单的概念来解释其解决方案的：

1. 问题所在：“黑盒”厨师

在现实世界中，大多数开发者并不拥有他们使用的 AI 模型；他们是通过“黑盒”服务租用这些模型（就像一家你看不到厨房的餐厅）。

挑战： 你无法窥视机器人的大脑来改变它的思考方式（这被称为“白盒”访问）。你只能给它一个配方（提示词/prompt），然后等待成品（代码）。
风险： 如果 AI 编写了出错或窃取信用的代码，很难证明那是 AI 写的。此外，如果你试图强迫 AI 以一种奇怪的方式编写代码来做标记，代码可能会停止工作（就像机器人试图用锤子来烤面包一样）。

2. 解决方案：“绿名单”配方

研究人员创建了一种名为 PromptMark 的方法。他们并没有试图破解机器人的大脑，而只是改变了给出的指令。

这就像是给机器人厨师一个特殊的规则：“对于你发明的每一个新食材名称，你必须以这个特定‘绿名单’（例如 A、B 或 C）中的一个字母开头。”

绿名单： 这是一个根据秘密密钥选定的字母秘密列表（例如 A、B、C）。
红名单： 这是告诉机器人要避免使用的起始字母。
诀窍： 机器人会非常严格地遵守这些规则，以至于它开始用“绿字母”来命名变量（例如 apple_count 或 banana_loop）的频率远高于人类自然产生的频率。

3. “迭代反馈”循环：“品尝测试”

有时，机器人可能会忘记规则，或者因为过于努力遵循规则而导致代码无法运行。为了修复这个问题，PromptMark 使用了一个反馈循环：

第一轮： 机器人编写代码。
检查： 人类（或另一台计算机）检查两件事：
- 代码是否真的能运行？（面包是否发酵成功了？）
- 机器人是否足够频繁地遵循了“绿名单”规则？（是否有足够的 A、B、C 名称？）
反馈： 如果代码出错了，机器人会被告知：“修复逻辑。”如果代码可以运行但“绿名单”规则不够强，机器人会被告知：“做得很好，但下次请多用一些 'A' 开头的名字。”
第二轮： 机器人根据新指令再次尝试。

它会一直持续进行，直到代码完美无瑕且水印足够强。

4. 检测：“统计侦探”

你如何知道一段代码是否由 AI 制作？你不需要看到秘密密钥。你只需要观察变量名。

自然代码： 人类命名事物是随机的。如果你观察 100 个变量，可能 10 个以 'A' 开头，10 个以 'B' 开头，等等。这是一个平衡的混合。
带水印的代码： 因为 AI 被迫使用了“绿名单”，你会看到一种奇怪的模式。也许 60% 的名称都以 'A'、'B' 或 'C' 开头。
测试： 一个统计测试（类似于数学检测器）会计算这些字母。如果这种模式强到不可能是巧合，它就会大喊：“这是由 AI 编写的！”

5. 为什么它很特别

论文声称该方法之所以特别，有三个原因：

它是隐形的： 代码看起来仍然正常且运行完美。“水印”只是变量名中一种微妙的模式，就像歌曲歌词中隐藏的信息，只有当你知道这个模式时才会注意到。
它适用于黑盒： 你不需要拥有 AI 或看到其内部代码。你只需像普通用户一样与它交流。
它是安全的： “绿名单”是使用秘密密钥（类似于密码）生成的。只有拥有该密钥的人才知道要寻找哪些字母，这使得他人很难伪造水印。

结果

研究人员在两个著名的编程数据集（MBPP 和 HumanEval）上测试了两种不同的 AI 模型（Gemini 和 Claude）。

成功率： 该方法在不破坏代码的情况下，成功为代码打上了约 90% 到 98% 的标记。
质量： 代码的质量与没有水印的代码一样好。

局限性（论文中承认的部分）

重命名攻击： 如果有人拿走了带水印的代码，并手动将所有变量名更改为其他名称，水印就会消失。论文指出，虽然该方法很出色，但它并非魔法；一个有决心的人可以通过重写代码来抹除信号。
语言特定性： 该研究是在 Python 代码上进行的。论文警告说，具有不同命名规则的语言可能会表现得不同。

简而言之，PromptMark 是向 AI 厨师低声传递一条特殊指令：“用这些特定的字母来命名你的食材，” 从而让你稍后能够通过数学手段证明那道菜是由 AI 制作的，且不会破坏食物的味道。

技术摘要：PromptMark

问题定义

大语言模型（LLMs）在软件开发中的广泛应用，使得代码溯源（即验证 AI 生成源代码的来源和作者身份的能力）成为了一个至关重要的需求。虽然水印技术是数字内容的标准技术，但将其应用于源代码面临着独特的挑战：

结构刚性： 与自然语言不同，源代码具有严格的语法约束；微小的修改可能会破坏编译或改变程序逻辑。
黑盒约束： 大多数开发者通过 API 与商业 LLM 进行交互，其模型内部（logits、解码策略）是无法访问的。现有的水印方法通常需要“白盒”访问权限来操纵 token 概率，这使得它们在实际部署中难以实现。
平衡难题： 有效的水印必须在嵌入可检测信号的同时，不损害代码的功能正确性或可读性。

本文解决的核心问题是设计一种黑盒、提示词引导的水印框架，该框架能够在无需访问模型内部信息的情况下，将隐形的、统计可检测的信号嵌入到源代码中，同时保持代码的功能性。

方法论：PromptMark

作者提出了 PromptMark，这是一个利用 LLM 的指令遵循能力来引导生成特定模式的三阶段框架。

1. 加密绿名单构建

PromptMark 不通过操纵模型 logits，而是通过系统提示词（system prompts）来偏置模型。

绿名单/红名单： 框架定义了一个“绿名单”（标识符/注释的允许起始字符）和一个“红名单”（禁止字符）。
基于频率的分层： 为了确保自然度，绿名单是根据人类编写的代码中标识符首字母的频率分布（使用 MBPP 和 HumanEval 数据集）推导出来的。系统选择前 $K$ 个最频繁的字母（ $K \in [10, 12]$ ）来构成候选池。
加密派生： 为了防止可预测性，绿名单的具体大小和组成是通过使用 SHA-256 哈希函数和 Fisher-Yates 洗牌算法从 12-bit 密钥中确定性地派生的。这确保了检测的可复现性，同时维持了安全性。

2. 迭代反馈循环

由于意识到单一提示词可能无法产生既功能正确又具有足够水印强度的代码，PromptMark 采用了迭代过程：

生成： LLM 根据系统提示词生成代码，该提示词指示其在标识符和注释中使用绿名单字符。
评估： 输出结果通过两个指标进行评估：
- 功能正确性 ( $c_i$ )： 通过单元测试执行（通过/失败）来确定。
- 水印保真度 ( $p_i$ )： 一个衡量绿名单字符频率相对于预期基准偏差的统计 p 值。
反馈： 如果代码测试失败，错误日志会被反馈回去。如果代码通过测试但水印较弱，则更新提示词以强制执行更严格的绿名单遵循规则。此循环持续进行，直到满足这两个标准或达到最大迭代限制。

3. 统计检测

检测被视为单侧假设检验：

零假设 ( $H_0$ )： 代码是在不知道密钥的情况下生成的（绿名单频率 $\le$ 基准）。
备择假设 ( $H_1$ )： 代码已被加水印（绿名单频率 $>$ 基准）。
自适应 P 值： 检测器计算一个自适应 p 值，对于短代码（ $N < 30$ ）采用精确二项检验，对于长代码（ $N \ge 30$ ）采用正态近似。只有当代码功能正确且 p 值低于显著性阈值时，才判定为已加水印。

核心贡献

黑盒水印框架： PromptMark 是第一个证明仅通过提示工程即可实现可靠的源代码零比特（zero-bit）水印的框架，消除了对模型内部信息的依赖。
迭代反馈机制： 本文引入了一种自我优化循环，动态平衡水印强度与代码正确性，解决了单次提示中常见的权衡问题。
自适应绿名单策略 (AGL)： 通过从高频人类标识符首字母中派生水印 token，该方法保留了代码的语义自然性，避免了容易被开发者或降低可读性的“强行感”。
加密安全性： 使用秘密密钥来确定性地生成绿名单，确保了水印在验证时的可复现性，同时在没有密钥的情况下具备抗预测性。

实验结果

该框架在 MBPP 和 HumanEval 数据集上使用 Gemini 2.5 Flash 和 Claude Sonnet 4 进行了评估。

有效性 (RQ1)：
- PromptMark 实现了极强的可检测性，在各种配置下的 AUROC 分数范围在 0.90 到 0.99 之间。
- Iterative-AGL（自适应绿名单）变体表现最佳，在 Gemini/MBPP 上达到 0.994 的 AUROC，在 Claude/MBPP 上达到 0.987。
- 在低假阳性率（1%–5%）下，真阳性率超过 90%，在理想设置下甚至超过 95%。
- 基准方法如 SWEET（白盒）显著降低了代码正确性，而没有迭代的上下文内水印（ICW）显示出较差的可检测性（AUROC $\approx$ 0.51）。
代码质量 (RQ2)：
- 功能正确性： PromptMark 保留了高 Pass% 率，在 HumanEval 上达到 ~97%，在 MBPP 上达到 ~99%，与无水印基准相当。
- 结构相似性： CodeBLEU 得分保持稳定，与无水印代码一致，表明水印过程并未扭曲控制流或数据依赖。
鲁棒性：
- 水印对 注释移除 表现出韧性（AUROC 仅下降了约 3.8%）。
- 然而，自动化改写（重命名变量）导致了显著的性能下降（AUROC 降至 ~0.71），凸显了自然度与对抗积极的语义保持攻击之间的权衡。

意义与主张

本文声称 PromptMark 成功地将源代码水印重新定义为一个提示词引导的任务，使其在商业黑盒 LLM 环境下变得可行。

实用性： 它为模型内部不可访问的环境提供了可行的归因方案，填补了仅限白盒研究留下的空白。
平衡性： 迭代反馈机制证明了高水印强度与高质量代码并非互斥；该框架可以通过动态优化同时实现两者。
归因： 虽然目前的实现支持零比特检测（存在/不存在），但作者指出，由于采用了加密密钥分离，通过为不同模型分配不同密钥，可以实现潜在的模型特定归因。

作者总结道，虽然该方法为零比特水印奠定了基础，但未来仍需开发适用于黑盒环境的多比特编码水印，并通过多通道嵌入策略来增强对抗系统性重命名攻击的鲁棒性。