当我们审视互联网上流传的系统提示时，一个令人不安的事实逐渐浮现：无论是 ChatGPT、Claude 还是 Gemini，它们精心构建的系统提示都未能逃脱被提取的命运。GitHub 上的 system_prompts_leaks 项目已经收集了超过 25,000 颗星标和 3,900 个分叉，成为安全研究者和开发者观察 AI 系统边界的重要窗口。这个项目的存在本身就揭示了一个根本性的安全困境：我们究竟能否真正保护这些定义 AI 行为的 "最高指令"？
系统提示泄露揭示的攻击面
系统提示是大型语言模型的核心指令集，它定义了模型的角色边界、行为约束、能力限制以及与用户交互的基本规则。当攻击者成功提取这些提示时，他们获得的信息远超表面的指令文本。通过分析泄露的提示内容，研究者可以识别出模型厂商试图隐藏的实现细节、发现尚未公开的功能特性，更重要的是，能够理解模型的行为边界从而设计更精准的对抗性输入。
从 system_prompts_leaks 项目的结构来看，组织者按照不同的 AI 提供商进行分类，包括 OpenAI、Anthropic、Google 和 Perplexity 等主要厂商。这种分类本身就暗示了各厂商在系统提示设计上的显著差异。OpenAI 的提示通常强调对特定工具的使用限制和输出格式规范，Anthropic 的提示则更注重角色扮演的一致性和安全边界，而 Google 的 Gemini 系统提示展现出与自家产品生态深度集成的特征。理解这些差异对于评估各平台的脆弱性至关重要，因为不同的设计哲学往往对应着不同的攻击面。
值得注意的是，该项目持续接收来自社区的贡献。最近的提交记录显示，Claude 4.5 Opus 和 Sonnet 的完整系统提示已经在 2025 年 12 月被提取并提交，同时还有 Google AI Studio 的默认系统指令和 Gemini 2.5 Flash 的提示内容。这种高频的泄露节奏表明，尽管各厂商不断加强防护措施，系统提示提取攻击仍然保持着惊人的成功率。
提示注入攻击的技术演进
提示注入攻击已经发展成为一种成熟的攻击范式，其复杂程度远超最初的简单指令覆盖。根据 2026 年初发表的综合性研究《Prompt Injection Attacks on Agentic Coding Assistants》，安全研究者已经识别出 42 种截然不同的攻击技术，涵盖输入操纵、工具污染、协议利用、多模态注入和跨域上下文投毒等多个维度。这些技术的成功率令人担忧：在采用自适应攻击策略时，针对当前最先进防御系统的攻击成功率超过 85%。
攻击者采用的三维分类法将攻击按投递向量、攻击模态和传播行为进行组织。投递向量包括直接用户输入、间接数据摄取和跨系统消息传递；攻击模态则涵盖了指令覆盖、上下文劫持和工具调用操纵；传播行为描述了攻击效果如何在多轮对话或复杂工作流中扩散。这种系统化的分类帮助研究者理解攻击的全貌，也为防御者提供了需要重点关注的薄弱环节。
间接提示注入是当前最受关注的攻击形式之一。在这种场景下，恶意指令并非来自用户的直接输入，而是隐藏在模型需要处理的外部数据中。例如，一封被策划过的电子邮件、一份包含隐藏指令的文档，甚至是一张带有文本的图片，都可能在模型处理这些内容时被激活并影响其行为。Google DeepMind 的研究团队在《Lessons from Defending Gemini Against Indirect Prompt Injections》中详细描述了他们如何建立对抗性评估框架，通过持续部署自适应攻击技术来测试和强化 Gemini 模型的鲁棒性。这种 "以攻代测" 的思路代表了对安全评估方法的重要演进。
防御机制为何难以奏效
面对提示注入攻击的泛滥，各厂商和研究社区提出了多种防御方案，但效果普遍不尽如人意。对 18 种已有防御机制的系统分析显示，大多数方案在面对复杂自适应攻击时仅能实现不到 50% 的缓解效果。这一数字背后反映的是提示注入攻击的本质特性：大型语言模型的核心功能是理解和生成文本，而提示注入正是利用这一能力在文本层面注入恶意指令，防御机制与模型功能之间的这种内在张力使得传统安全范式难以直接套用。
当前主流的防御思路可以分为几类。第一类是基于输入检测的方案，试图通过规则匹配或分类模型识别潜在的恶意输入，但攻击者可以轻易调整措辞和编码方式来规避检测。第二类是输出过滤方案，在模型生成结果后进行检查以防止敏感信息泄露或有害输出，但这种事后诸葛的方式对于已经产生的行为影响收效甚微。第三类是系统提示加固，通过在提示中加入更多的安全指令来约束模型行为，但这些指令本身也可能被注入的内容覆盖或忽略。
CaMeL 方案代表了从根本架构层面应对提示注入的尝试。这项由康奈尔大学与 DeepMind 研究者共同提出的防御机制，在模型周围创建了一个显式的保护层，将控制流和数据流从用户查询中显式分离。通过这种架构设计，即使底层模型受到提示注入的影响，也无法改变程序的执行流程。CaMeL 还引入了 "能力" 概念来防止私有数据通过未授权的数据流被外泄。这种设计理念的核心认识是：在处理不可信数据时，不应该依赖模型自身的判断来区分指令和数据，而应该通过系统架构来强制执行这种分离。
从泄露项目中获取的防御启示
分析 system_prompts_leaks 项目中的泄露样本，可以为防御策略的制定提供几个关键启示。首先，系统提示的泄露虽然令人担忧，但也为安全评估提供了宝贵的研究材料。通过对比不同版本提示的演变，研究者可以观察厂商如何逐步加强安全边界，以及哪些类型的泄露促使他们做出修改。这种逆向工程的价值在于揭示防御措施的实际效果，而非仅仅是理论上的安全性声明。
其次，该项目展示的泄露来源多样化表明，单一的防护措施难以应对所有攻击路径。某些提取技术依赖于对话轮次的设计，某些利用工具调用过程中的边界条件，还有一些通过特殊的格式编码或字符序列触发提示泄露。这意味着有效的防御体系必须是多层次的，在不同的处理阶段部署针对性的防护机制。任何试图用单一 "银弹" 解决所有问题的方案都将失败。
最后，社区协作在提示注入防御中扮演着越来越重要的角色。system_prompts_leaks 项目的 237 次提交和持续涌入的 PR 表明，对 AI 系统提示的探索已经成为一种集体性的技术努力。类似的，安全社区也需要建立更紧密的合作机制来分享攻击样本、防御经验和评估基准。Google DeepMind 将其对抗性评估框架描述为持续运行而非一次性测试的做法，值得其他厂商借鉴。只有当防御研究与攻击研究保持同步甚至领先的节奏时，AI 系统的安全性才有可能得到实质性的提升。
面向开发者的安全实践建议
对于在应用中集成大型语言模型的开发者而言，提示注入风险是必须纳入安全架构设计的核心议题。最基本的原则是将用户输入视为不可信数据，在模型处理之前进行适当的清理和隔离。当应用场景允许时，可以考虑使用分层提示设计，将关键的业务逻辑指令与用户可影响的部分分离，减少注入攻击能够触及的敏感范围。
在工具调用和工作流编排层面，应该实施最小权限原则。模型只能访问完成特定任务所必需的工具和数据，而非开放整个系统能力。工具调用的参数应该经过严格的模式验证，防止通过注入指令操纵工具行为。对于高敏感度场景，可以考虑在模型输出和实际执行之间增加人工审批环节，尽管这会降低自动化程度，但也是防范高级提示注入的有效手段。
持续的监控和日志记录同样不可或缺。当检测到可疑的输入模式或异常的行为输出时，系统应该能够发出警报并触发相应的响应流程。日志记录不仅用于事后分析，也应该作为反馈信号来动态调整防御策略。值得注意的是，监控本身也可能成为攻击目标，因此监控系统的设计也需要考虑防篡改和完整性验证。
前行之路
系统提示的持续泄露不是技术失败的偶然结果，而是大型语言模型固有架构特性与复杂现实世界交互的必然产物。system_prompts_leaks 项目为我们提供了观察这一现象的独特窗口，也提醒我们 AI 安全的道路仍然漫长。从 Google DeepMind 的对抗性评估框架到 CaMeL 的架构创新，研究社区正在多个方向上探索解决方案，但距离根本性地解决提示注入问题还有相当距离。
真正的进步需要来自多个层面的协同努力：模型层面需要更好的内在鲁棒性，架构层面需要更强的隔离和分离机制，部署层面需要更完善的监控和响应流程，而社区层面则需要更开放的信息共享和协作研究。提示注入攻击的威胁不会消失，但通过系统性的研究和工程实践，我们可以将其影响控制在可接受的范围内，使大型语言模型能够安全地释放其变革性的潜力。
资料来源：system_prompts_leaks GitHub 项目（github.com/asgeirtj/system_prompts_leaks）；arXiv 论文《Prompt Injection Attacks on Agentic Coding Assistants》、《Defeating Prompt Injections by Design》、《Lessons from Defending Gemini Against Indirect Prompt Injections》。