提示词语法：LLM 代码生成的一个安全控制面

这是什么？

大型语言模型编写了大量生产代码，而其中相当一部分已被充分记录会带有安全缺陷：缺失输入校验、不安全的反序列化、弱加密、可注入的查询。先前的研究表明，提示词工程可以降低这种不安全代码的比例，但大多数工作停留在粗粒度策略层面——「添加一个角色设定」「让模型考虑安全性」「给一个示例」——并且大多在专有的闭源模型上测量。

2026 年 7 月 17 日发布在 arXiv 上的一篇论文——The Language of Security: How Prompt Syntax Shapes Secure Code Generation in Open LLMs（arXiv 2607.15937，作者 Matteo Cicalese、Antonio Della Porta、Stefano Lambiase、Emanuele Iannone、Torge Hinrichs、Riccardo Scandariato 与 Fabio Palomba；已被 ICSME 2026 接收）——收窄了视角。它追问：提示词的细粒度语法形态，而不仅仅是其高层策略，是否会改变所生成代码的安全性；并且专门在开放、可自托管的模型上开展实验——这些正是团队出于隐私、合规与部署控制而采用的模型。

工作原理

作者选取与安全相关的代码生成提示词，采用一种由语法解析器驱动的方法，系统性地为每个提示词生成语法变体。他们并非手工改写提示词，而是操纵其语法成分——表达约束、守卫、条件的从句，以及某个具名概念与其要求之间的绑定关系——并同时改变这些成分在提示词中所处的位置。每个变体在功能上请求的是同一个程序，只有语法不同。随后在多个开源 LLM 和多种编程语言上对生成的代码进行安全评估。

结论是：这些细粒度成分确实重要，而且是持续地重要。安全要求是被表述为显式的守卫或条件，约束是否与其保护的概念紧密绑定，以及该从句在提示词中出现得早还是晚——这些都以可测量的方式改变了模型生成漏洞代码的概率。换言之，两个在开发者看来等价的提示词，仅因语法形态不同，就可能导致明显不同的安全结果。作者据此将提示词语法确认为一个真正的控制面——团队可以有意地对其加以标准化，而不必听任其偶然。

为何重要

对任何交付 LLM 辅助代码的人而言，这把一个模糊的问题变成了可工程化的问题。「为安全而写提示词」是空泛的建议；而「将安全约束表述为显式守卫、把它绑定到所保护的工件、并置于模型可靠关注之处」则是代码助手集成或内部提示词模板可以强制执行的东西。它也提醒不要把闭源模型的经验直接搬到开源模型：在托管的前沿模型上验证过的指导，未必适用于企业实际运行的自托管开源模型——而本研究正是直接构建在开源模型之上。

另一面则是威胁模型。如果措辞能把模型推向安全代码，它同样能把模型推离安全代码。一个悄悄删除或重排守卫从句的提示词模板、共享代码片段库或自动补全脚手架，就成了在不留明显篡改痕迹的情况下，提高经其生成的一切代码漏洞率的隐蔽手段。因此，提示词模板本身也值得作为安全开发流水线的一部分加以审查。

防御

把提示词当作会交付的代码。对助手和流水线使用的模板进行版本管理、评审与测试，就像评审它们产出的代码一样。修改一条守卫从句就是一处与安全相关的变更。

让安全要求显式且有绑定。研究指出，约束、守卫与条件是高杠杆的成分。把安全需求表述为具体条件（「校验并拒绝任何不在允许列表中的输入」），并绑定到它所保护的具体函数或数据，而不是在末尾附上一句含糊的「保证安全」。

统一位置。既然在提示词中的位置会影响结果，就为安全约束出现的位置确定一套统一的结构，并在各团队间保持一致，而不是任由每个人各自发挥。

绝不仅凭措辞就信任生成的代码。提示词卫生降低了漏洞的基础发生率，但并不能消除它们。对所有 LLM 生成的代码，持续保留静态分析、依赖扫描与人工评审，并把语法层面的提示词方法与既往安全提示词研究所系统评估的更高层策略结合起来。

状态

项目	参考	日期	备注
论文发布	arXiv 2607.15937	2026-07-17	Cicalese、Della Porta、Lambiase、Iannone、Hinrichs、Scandariato、Palomba；cs.CR / cs.SE
发表	同上	2026	被 ICSME 2026 接收；arXiv 非独占许可
范围	同上	2026-07	多个开源（可自托管）LLM；多种编程语言
发现	同上	2026-07	约束、守卫、条件、概念绑定及其位置持续影响不安全代码的出现概率

诚实的解读是：提示词的措辞既非灵丹妙药，也非噪声。它是 LLM 生成代码安全性中一个可测量、可控制的因素——这意味着它值得像任何其他安全控制一样被认真对待，也值得同样的审慎：单一控制是否足够。