k-gram 软件胎记检测 LLM 辅助的代码抄袭

当天发生了什么

2026-07-03（UTC 06:49），Nikolay Fedorov 等作者在 arXiv 提交了《Detection of LLM-assisted Code Plagiarism Using k-gram Software Birthmarks》（2607.03014，v1）。论文的出发点是：大模型能在保持行为不变的前提下改写代码结构，可能绕开传统抄袭检测。作者用 k 取 1 到 6 的 Java 操作码 k-gram 作为软件胎记，以 BSD-2-Clause 许可的活跃 Java 项目中可单独编译的文件为素材，让 ChatGPT-5.1-Codex-Mini、DeepSeek-V4-Flash 和 Claude-Haiku-4.5 生成改写版本，并比较五种相似度（余弦、Dice、Jaccard、Simpson、编辑距离）。作者报告 k-gram 胎记仍然有效，其中 ChatGPT-5.1-Codex-Mini 生成的克隆最难检测，且面向编程的模型更擅长这项任务。

对评估 AI 克隆风险意味着什么

“让模型把别人的代码换个写法”已经是成本很低的操作，这篇论文从检测侧给出了一个相对乐观的信号：在作者的设定下，编译后的操作码序列仍保留了可以比对的特征。对独立开发者来说，它的意义主要在取证和维权，而不是预防：胎记比对需要你拿到可疑产品的二进制，并且有自己版本的参照物。边界也要说清楚：实验对象是 Java 字节码、特定许可的开源项目和三种模型，结论不能直接推广到 Swift、Dart AOT 或经过混淆的原生代码；被改写的程度、是否重新设计算法，也会影响结果。它也不是保护措施，代码一旦被复制，检测只能帮你证明，而不能阻止。

可以在自己的项目里做的准备

第一，为每个发布版本归档构建产物和哈希，保留对应的源码提交，这样将来需要比对时有可靠的参照物和时间线。第二，如果你的产品基于 JVM，可以在内部试验类似的操作码相似度比对，先在自己的不同版本之间跑一遍，了解正常演进下的相似度区间，避免误判。第三，保留开发过程的证据，例如提交历史、设计文档和发布记录，它们在争议中往往比单一相似度分数更有说服力。第四，把真正有价值的规则放在服务端，减少可被整段复制的客户端逻辑。第五，关注后续研究是否扩展到其他语言和混淆场景，再决定是否把这类检测纳入长期监测。

行动清单

• 为每个版本归档构建产物、哈希与源码提交
• 先在自己的版本之间测量相似度基线
• 保留提交历史与设计文档作为来源证据
• 不要把检测当作保护，核心规则放在服务端