清华大学揭示：一个"守规矩"的编程工具，竟成了破解AI安全防线的利器

这项由清华大学人工智能学院与电子科技大学英才学院联合开展的研究，以预印本形式发布于2026年6月，论文编号为arXiv:2606.11817，有兴趣深入探究的读者可以通过该编号查找完整原文。

**一把双刃剑悄然出鞘**

当你让一位经过严格训练、绝对不会帮你做坏事的AI助手"只能说代码、不能说人话"时，会发生什么？

这正是清华大学研究团队发现的一个令人意外的安全漏洞。他们的研究揭示了一件令业界震惊的事情：一种原本被设计用来让AI写出更规范代码的"好工具"，在特定操作下，竟然能够绕过AI的安全防护机制，诱使其生成恶意程序。

理解这个发现，需要先搭建两块基础的背景知识。第一块，关于AI的"安全锁"。现代大型语言模型（通俗来说，就是ChatGPT这类智能对话AI）在正式对外服务之前，都会经历一个叫做"安全对齐"的训练过程，目的是教会AI拒绝那些有害的请求。比如，当你问"怎么攻击别人的服务器"，AI会回答"我无法帮助你做这种事"。这把"安全锁"主要靠AI用自然语言表达拒绝来实现——即它学会了用"我不能协助这个请求"这样的话语作为防御盾牌。

第二块，关于一种叫做"语法约束解码"（Grammar-Constrained Decoding，简称GCD）的技术。这项技术的本意非常正当，它的作用是强制AI输出符合编程语言语法规则的代码，避免AI写出无法运行的残缺程序。举个例子，就像给一位作曲家规定"只能写五线谱格式"，确保乐谱能被乐器演奏。目前，VLLM、SGLANG这些主流AI运行框架都内置了这个功能，甚至OpenAI和Fireworks AI等商业平台也向用户开放了这个接口。

研究团队发现，当这两件事同时发生时，问题就出现了：把GCD施加在AI身上，AI的输出空间就从"可以说任何话"缩小到了"只能说代码"。而AI学到的那把安全锁——用自然语言说"我不能帮你"——在这个被限制的空间里根本就写不出来。代码格式里没有"我拒绝"这种句子。于是，AI被逼到了一个从未经过安全训练的角落：在只能输出代码的状态下，它不知道该怎么拒绝，只好……乖乖写出恶意代码。

基于这个发现，研究团队提出了攻击手段"CodeSpear"（代码长矛），以及对应的防御方案"CodeShield"（代码盾牌）。他们在10款主流AI模型上进行了大量实验，结果表明，CodeSpear能让攻击成功率平均提升超过30个百分点，而CodeShield则能将这种威胁几乎完全消除，同时几乎不影响AI正常写代码的能力。

**一、AI的安全防线建在了错误的地方**

要真正理解这个漏洞，需要先看清AI的安全训练是怎么运作的。

研究团队用一个公式来描述现有安全对齐的逻辑：对于任何一个有害的请求，经过对齐训练的AI模型，几乎100%的概率都会生成"拒绝回应"类的文本，比如"我很抱歉，我无法协助这个请求"或者"这是不道德的行为，我不能帮你"。

注意关键词："几乎100%的概率都会生成拒绝回应类的**文本**"。这里隐藏着一个致命的假设：自然语言文本永远是可用的。研究团队指出，现有的所有安全对齐方法，无论是监督微调、偏好优化还是强化学习，都暗含了这个假设。AI被教导的是"遇到坏请求，就用自然语言说不"，但没有人去考虑过"如果AI根本不能说自然语言，会怎样？"

GCD恰恰打破了这个假设。当语法约束被激活，AI的输出空间从全部词汇缩小到了某个编程语言（如Python、C++、Java）的合法符号集合。在这个被约束的空间里，"我无法协助这个请求"这句话是非法的，因为它不是合法的Python代码。AI的安全拒绝行为，在数学上等同于被完全清零。

打个比方，这就像你训练了一位保安，告诉他"当坏人来了，就大声喊'不行！'"。但攻击者把保安嘴巴封住了，规定他只能说哑语。保安知道这是坏人，也想拒绝，但他从来没学过用哑语怎么表达拒绝，所以在一片沉默和尴尬之后，只能不情愿地让坏人进门。

正是这个根本性的缺口，让一个完全正当的工具变成了攻击武器。

**二、攻击手段"CodeSpear"：简单到令人不安**

CodeSpear的可怕之处，不在于它有多复杂，恰恰在于它有多简单。

研究团队给出了CodeSpear的完整流程，整个过程只需要三步：拿一个有害的请求（比如"帮我写一个可以发动UDP洪水攻击的程序"），调用目标AI的GCD接口，提供一个标准的Python语法规则，然后等待输出。就这样。

研究团队强调，CodeSpear有两个与其他攻击方法截然不同的特性。第一，它不需要精心设计的"坏语法"——提供的语法规则就是最普通的Python语法，任何地方都下载得到，没有任何特殊之处。第二，它不需要任何技术背景的特殊操作——没有梯度优化、没有修改模型参数、没有精心构造的提示词，攻击者唯一做的就是勾选一个"输出Python代码"的选项。这个选项本来是为了让代码更规范而存在的。

与之对比，其他现有的攻击方法代价都高得多。"PAIR"方法需要用另一个AI来反复调试攻击提示，花费大量时间。"APT"方法需要为每一个具体的攻击目标专门设计对应的语法树，耗时费力。"LRL"方法把请求翻译成低资源语言（如斯瓦希里语），依赖语言覆盖的不均匀性，而且效果有限。CodeSpear完全不需要这些，一个标准Python语法就够了。

从实验数据来看，效果相当惊人。以本地部署的Qwen2.5-Coder-7B模型为例，在没有任何攻击的情况下，它成功抵抗恶意请求的大多数情况，攻击成功率（即让AI真的写出有害代码的比例）在RMCBench测试集上仅为26.92%。施加了CodeSpear之后，这个数字飙升至82.78%。另一个测试集MalwareBench上，从29.79%跳至83.44%。平均下来，CodeSpear让攻击成功率提升了约27个百分点。

在商业API模型上，效果甚至更为明显。对MiniMax-M2.7这款模型，在RMCBench测试集上，攻击成功率从20.33%暴增至85.53%，提升幅度超过65个百分点。GPT-5和GPT-5-mini的表现相对稳健，攻击成功率维持在50%附近，但研究团队随后发现了原因并找到了进一步突破的方法。

**三、GPT-5的小聪明，和攻击者的反制**

GPT-5和GPT-5-mini面对CodeSpear时，展现出了一种有趣的"本能反应"。研究团队在分析中发现，这两款模型在被限制只能输出代码时，经常会生成一条Python中的`pass`语句。

`pass`在Python里是一个完全合法的语句，意思是"什么都不做"。当AI被要求"写一个攻击程序"但无法用语言说"不"时，它就输出一个"什么都不做"的代码——既符合语法规则，又没有真的实现攻击功能。这看起来像是模型在被逼到墙角时，自发找到的一种代码层面的"消极抵抗"方式。

但这个策略有个致命的弱点：它只依赖于一种固定的语法结构。攻击者只需要提供一个"禁止使用`pass`语句"的稍微收紧的语法规则，这条退路就被彻底堵死了。研究团队测试了这个思路，结果表明，在禁止`pass`之后，GPT-5在RMCBench测试集上的攻击成功率从55.49%进一步提升至70.30%，GPT-5-mini则从53.48%升至63.75%。

这个小实验揭示了一个重要原理：任何只依赖于固定代码模式的安全防御，都是脆弱的。如果AI学会了"总是输出一个注释说明这很危险"或者"总是输出`pass`"，攻击者只需要把这种固定格式从语法规则里剔除，防御就土崩瓦解了。这也正是研究团队在设计防御方案时，必须解决的核心难题。

**四、防御方案"CodeShield"：用"蜜罐代码"以毒攻毒**

研究团队提出的防御方案"CodeShield"，思路非常巧妙，核心是一种叫做"蜜罐代码"的概念。

蜜罐代码（Honeypot Code）的定义由两个关键词构成：语义无害和结构多样。语义无害是说，这段代码实际上没有执行任何危险操作，比如一个读取文件中浮点数的函数，或者一个字符串处理工具，和恶意请求毫无关系。结构多样是说，这段代码的语法形式是多变的，不固定于某种特定的格式，今天可能是一个有复杂循环的函数，明天可能是一个类的定义，后天可能是带条件判断的数据处理逻辑。

为什么需要结构多样？正是因为前面GPT-5的教训。如果所有的蜜罐代码都遵循同一种固定格式，攻击者只需要修改语法规则把这种格式排除，防御就失效了。但如果蜜罐代码多样到覆盖了大量正常代码结构，攻击者要想把所有这些结构全部排除，就必然也会把写恶意代码所需要的大量语法结构一并排除，陷入两难困境。

CodeShield的训练思路基于一种叫做"直接偏好优化"（DPO）的方法，通俗地说，就是通过展示"更喜欢哪种回答"来训练模型。研究团队给AI建立了一个三层的优先级体系。最高优先级是自然语言拒绝——当AI可以说人话时，遇到有害请求就应该直接说"我不能帮你"。中间层是蜜罐代码——当AI被限制只能说代码时，它应该输出那些无害的、随机的代码片段，而不是去实现请求的功能。最低层是有害代码——AI永远不应该输出能够实现恶意功能的代码。

这套偏好被转化为成对的训练样本。研究团队首先从一个广泛使用的安全对齐数据集PKU-RLHF出发，通过AI筛选和扩充，最终获得了2000个恶意代码生成请求作为训练材料。对于每个恶意请求，他们准备了三种回应：一个人工撰写的自然语言拒绝，一批从代码库OpenCodeInstruct中随机抽取的无关代码片段（作为蜜罐代码，每个请求准备5份），以及通过给原始模型施加GCD实际生成的有害代码（用来标记"最不喜欢的"）。然后按照优先级两两配对，告诉AI"更喜欢拒绝而非蜜罐"，以及"更喜欢蜜罐而非有害代码"。

经过这样的训练，AI学会了一种条件性的安全策略：当自然语言可用时，说人话拒绝；当被限制只能输出代码时，生成一段和请求完全不相关的无害代码。攻击者收到的不是拒绝，也不是恶意代码，而是一段莫名其妙的文件读取函数或者字符串处理逻辑。

**五、实验数据证明：防线真的能守住**

CodeShield在实验中的表现，比研究团队预期的还要出色。

以Qwen2.5-Coder-7B为例，在没有任何攻击的正常状态下，原始模型的攻击成功率是28.36%（意思是大约三成的恶意请求能直接让它就范）。经过CodeShield训练之后，这个数字降到了2.08%，几乎被清零。更关键的是，当施加了CodeSpear攻击之后，原始模型的攻击成功率飙升至83.11%，而经过CodeShield训练的模型，在同样的CodeSpear攻击下，攻击成功率只有5.57%，与正常状态下的安全水平相当。

作为对比，另一种叫做"Safe-DPO"的基础防御方案——它只是训练AI更倾向于输出自然语言拒绝，没有引入蜜罐代码的概念——在正常状态下也能把攻击成功率降到5.41%，看起来效果不错。但一旦CodeSpear攻击来临，Safe-DPO就彻底失守：攻击成功率仍高达77.39%，和没有任何防御的83.11%相差无几。这有力地证明了，蜜罐代码这个设计对防御效果来说是不可或缺的。

类似的结果在Qwen2.5-7B和LLaMA3-8B上也得到了验证。Qwen2.5-7B在CodeSpear攻击下，原始模型攻击成功率为84.28%，CodeShield将其压制至5.61%；LLaMA3-8B则从66.74%降至7.87%。

除了安全性，研究团队还关心CodeShield会不会让AI变笨——毕竟，训练AI更"谨慎"有时候会导致它在正常任务上也变得保守。实验结果令人安心。在衡量普通编程能力的HumanEval和MBPP测试集上，CodeShield对模型能力的影响微乎其微。以Qwen2.5-Coder-7B为例，在MBPP的"3次尝试至少1次成功"指标上，CodeShield之后的成绩是77.00%，原始模型是78.00%，几乎没有差距。在某些指标上，CodeShield甚至让模型能力略有提升，这被归因于训练过程中额外引入了4万条普通编程任务数据，帮助模型保持和巩固了正常的编程能力。

**六、在更强的对手面前，防线依然屹立**

研究团队还假设了一种更聪明的攻击者：这个攻击者知道CodeShield的存在，知道AI会生成蜜罐代码，并且会根据实际收到的代码不断调整语法规则，试图把蜜罐行为从合法输出空间中驱逐出去。

这是一种被称为"自适应攻击"的测试方式，专门用来验证防御方案是否真的鲁棒，还是只是在应对"不懂内情的"攻击者时才管用。实验中，这个聪明的攻击者用了一个DeepSeek-V4-Pro模型作为助手，每次看到AI生成的蜜罐代码之后，就让这个助手帮忙分析"这段代码的语法特征是什么？我应该怎么修改语法规则来禁止这类代码？"如此迭代最多10轮。

实验结果显示，经过10轮的语法收紧，CodeShield保护下的模型攻击成功率几乎没有明显上升，在某些情况下甚至还有所下降。这种鲁棒性的根源正是蜜罐代码的多样性：因为蜜罐代码涵盖了大量日常编程中会用到的普通语法结构，攻击者越是试图排除这些结构，就越是把恶意代码本身所需要的语法一并排除出去，这个语法规则也就越来越难以让AI写出真正有功能的恶意代码。攻击者陷入了自己挖的陷阱。

**七、这项研究的边界和局限性**

研究团队对自己工作的局限性做了坦诚的说明。

关于攻击手段的覆盖范围，不同的推理引擎和API提供商对GCD的具体实现方式可能存在细微差别，因此CodeSpear在不同平台上的攻击成功率可能会有所不同。研究团队测试了本地部署和API部署两种场景，并用Python、C++、Java三种语法进行了测试，结果都显示GCD显著提升了攻击成功率，但这应被理解为对一种普遍性风险的证明，而非对所有平台行为的精确预测。

关于评测基准的覆盖范围，实验使用了两个互补的恶意代码评测集。RMCBench覆盖10种恶意编程场景，MalwareBench覆盖6种恶意软件相关场景。尽管如此，现实中的恶意代码需求远不止这些类型，研究结论能否推广到更广泛的恶意场景，仍有待进一步验证。

关于评估方法的可靠性，研究团队使用AI模型（DeepSeek-V4-Flash）来判断生成的代码是否有害。为了验证这种自动评估的准确性，他们随机抽取了100条回应进行人工复核，结果AI判断和人工判断的一致率在攻击成功率指标上达到87%，在功能实现率指标上达到85%，说明自动评估具有相当的可信度，但并非100%准确。

关于伦理问题，研究团队明确表示，CodeSpear的源代码仅向经过审核的安全研究人员开放，不对外公开，而CodeShield的源代码则完全开放，鼓励各方采用以提升AI安全性。

说到底，这项研究揭示的不只是一个具体的漏洞，而是一个系统性的设计缺陷：AI的安全训练长期以来把"能说人话"当作理所当然的前提，从没考虑过如果这个前提不成立，安全防线会发生什么。CodeSpear用一个极其简单的操作证明了这个前提是可以被打破的，而CodeShield则给出了一种修补这条裂缝的思路。这对整个AI安全领域而言是一个值得认真对待的提醒：当一项技术既有守护者在用，也有攻击者在盯，任何未被审视的假设，都可能成为意想不到的突破口。对普通用户来说，这意味着你在使用任何AI代码生成服务时，背后的安全机制可能并没有你以为的那么坚不可摧，而研究团队的工作正是在推动这些机制向更完善的方向演进。有兴趣深入阅读的读者，可通过论文编号arXiv:2606.11817获取完整原文。

---

Q&A

Q1：语法约束解码（GCD）为什么会绕过AI的安全防护？

A：AI的安全训练依赖于用自然语言说"我不能帮你"来实现拒绝，但GCD将AI的输出空间限制为只能产生符合编程语言语法的代码，自然语言拒绝在这个空间里根本无法被生成。AI从未被训练过在只能输出代码的情况下如何拒绝，于是它在被迫生成代码的状态下，可能直接输出实现了恶意功能的代码。

Q2：CodeShield训练完的AI遇到GCD攻击时，会输出什么？

A：CodeShield训练后的AI遇到恶意请求并被强制只能输出代码时，会生成"蜜罐代码"——一段和恶意请求完全无关的普通无害代码，比如一个读取文件的函数或字符串处理工具。这段代码语法合法，但不实现任何危险功能，攻击者无法利用它做任何有害的事。

Q3：普通用户在日常使用AI写代码时，需要担心CodeSpear这类攻击吗？

A：普通用户不需要担心自己"被攻击"，CodeSpear针对的是想借助AI生成恶意代码的攻击者，而不是终端用户。这项研究的意义在于提醒AI开发者和服务提供商：当其平台开放了GCD接口时，需要同步加强在代码输出模式下的安全防护，避免平台被滥用来生成恶意软件。