AISPA：面向大型语言模型应用的以用户为中心的系统提示词审计

论文信息

标题: AISPA: User-Centric System Prompt Auditing for Large Language Model Applications

作者: Xiangning Lin, Shenzhe Zhu, Shu Yang, et al.

发布日期: 2026-07-30

arXiv ID: 2607.28617v1

PDF 链接: 下载 PDF

3 分钟速览

研究问题：大语言模型应用中的系统提示（system prompt）是开发者约束模型行为的核心指令，但极少对外公开，也没有独立的审查标准，用户无法知道这些指令是否在保护自己的利益。
核心方法：提出 AISPA 框架，建立一个包含八个维度的用户中心审计分类法，并设计了一套人机协同审计流程，对 88 个真实 AI 产品的系统提示进行逐条评估。
关键结果：约 40% 的商业 AI 产品存在至少一条违背用户利益的指令，而只有 23.9% 的产品在全部八个维度上提供了保护性指令（图 6a）。
主要局限：系统提示均来自公开泄露仓库，存在选择偏差，且无法确认是否与当前生产版本完全一致；灰色地带指令的判定仍依赖专家主观权衡。
适合读者：AI 产品经理、安全与合规工程师、AI 治理研究者，以及关心 AI 系统透明度与用户权益的政策制定者。

论文背景和研究动机

LLM 应用已成为数亿人日常使用的工具，从客服助手到编程代理，其行为很大程度上由一条隐藏在背后的系统提示决定。这条提示定义了模型的角色、边界、安全策略以及在不同场景下的应对方式。它贯穿所有用户交互，却几乎从未向使用者或监管机构披露。

问题在于，即便基础模型本身经过了安全对齐，系统提示仍然可以植入种种不利于用户的指令。论文给出了真实的例子：“NEVER say you are an AI language model or an assistant” 或 “cleverly steer the conversation in a new direction without the user asking”，这些指令直接服务于开发者而非用户的利益。更严重的是，泄露的内部文档显示，某些聊天机器人被允许与儿童进行浪漫对话，甚至有法院对利用提示绕过伦理护栏的开发者判处徒刑。

当前学界和产业界的安全努力大多集中在保护系统免受外部攻击（如提示注入、越狱），而非审查系统提示本身是否对用户构成威胁。一项调查指出，近 90% 的用户要求更高的提示透明度，超过 70% 将信任作为核心诉求。但现实是，系统提示仍然是一块缺少标准与独立审计的治理盲区。AISPA 正是在这一背景下提出，试图用一套原则性的审计框架填补空白。

核心方法和技术细节

AISPA 审计维度的设计基础

AISPA 的审计分类法由八个维度构成，分别是：

身份透明性（Identity Transparency）：是否明确告知用户自己为 AI。
真实性与信息完整性（Truthfulness & Information Integrity）：是否禁止编造、夸大或隐瞒信息。
隐私与数据保护（Privacy & Data Protection）：是否避免泄露或滥用用户数据。
工具/操作安全性（Tool/Action Safety）：在调用外部工具或执行代码时是否有安全校验。
用户自主性与防操纵（User Agency & Manipulation Prevention）：是否尊重用户选择，不通过暗模式或情感引导操控。
不安全请求处理（Unsafe Request Handling）：面对有害或越狱请求时是否恰当拒绝。
伤害预防与用户安全（Harm Prevention & User Safety）：是否对高风险、自残等场景提供正确引导。
公平性、包容性与中立性（Fairness, Inclusion & Neutrality）：是否避免歧视、偏见和极端言论。

每个维度都对应《世界人权宣言》的若干条款，使框架具有国际规范基础。例如，身份透明性对应第 19 条（知情权）和第 1 条（尊严），隐私保护对应第 12 条（隐私权）等。

审计单元与极性判定

审计的最小单位是指令跨度（prompt span），通常为一句话，表达一条独立的行为指令。审计人员判断每个跨度属于哪一维度，并赋予 +1（保护性） 或 -1（问题性） 标签。这样设计的好处是，审计结果可精确追溯到具体指令，方便开发者修复，也便于跨产品、跨版本对比。

论文特别区分了核心逻辑跨度和非核心逻辑跨度。前者是产品基本功能所必需（如 “使用 add_memory 工具存储用户偏好”），不在审计范围；后者或核心逻辑附带的伦理相关子句才是审查对象。这一界定避免了将产品设计差异误判为安全问题。

人机协同审计流程

为在效率与严谨性间取得平衡，论文设计了三阶段审计流程（图 4）：

第一轮：LLM 辅助候选生成。使用 Claude-4.6-Opus 作为预标注器，根据审计指南分解提示并给出维度与极性的初步建议。这一轮追求高召回，尽量避免遗漏。
第二轮：训练有素的标注员筛选。六名标注员先完成一致率高达 0.933 的校准训练，再独立审核 LLM 提出的候选跨度，剔除过度解读或证据不足的条目，并补充遗漏部分。
第三轮：专家复核与裁定。三位领域专家对所有保留条目进行最终确认，问题性标签（-1）需三人一致同意才保留。这种非对称阈值的设计降低了误伤产品声誉的风险。

数据集

审计对象为 88 个真实 AI 产品的系统提示，来自六个公开的 GitHub 泄露或社区披露仓库。产品覆盖通用聊天机器人、编码助理、自主代理、搜索研究工具和垂直应用等类别。论文通过联系仓库维护者和计算同产品跨仓库的 Sørensen–Dice 重叠系数来验证真实性，确保提示并非凭空捏造（附录 B）。

创新点和贡献

AISPA 的核心贡献在于将系统提示从被保护的资产转变为被审计的对象。此前提示安全研究几乎都站在开发者立场，保护提示不被窃取或污染，而 AISPA 首次以用户利益为标尺，系统性地审查提示中是否存在隐瞒 AI 身份、诱导停留、弱化安全护栏等行为。

第二个贡献是审计框架的标准化与可操作性。八个维度同时涵盖保护性指令和问题性指令，无需设立两套独立分类法。跨度级标注、核心/非核心逻辑的划分，以及三阶段人机协作流程，为第三方审计提供了可复现的模板。这一模板能较好平衡商业保密需求与公共利益，因为审计只关注行为指令而非完整提示本身。

第三个贡献是首次对大规模商业系统提示进行实证审计，揭示了行业级趋势：提示长度和保护性指令数量在 2024–2026 年间显著增长，但约 40% 的产品仍存在问题指令，只有不到四分之一的提示做到全面覆盖（见第 5.2.1 节）。这种量化证据将以往零散的个例问题提升到了系统性的治理高度。

实验结果分析

保护性指令普及但深度不足

98.9% 的产品至少包含一条保护性指令，但全面覆盖八个维度的比例仅为 23.9%。各维度覆盖率悬殊：真实性与信息完整性（D2）和用户自主性（D5）超过 90%，但不安全请求处理（D6）和隐私保护（D3）仅在 60% 左右（图 6b）。这意味着大部分产品在面对越狱或对抗性请求时缺少明确的拒绝指令，留下了潜在的安全缺口。

问题指令共存与组织差异

尽管保护性指令普遍存在，38.6% 的产品同时存在至少一条问题指令。特别是，用户自主性（D5）成为重灾区，有 18.2% 的产品在该维度出现违背用户利益的指令，典型表现为要求模型不经用户确认即执行操作。按组织排名来看，Anthropic 平均每产品包含 62.3 条保护指令且问题指令近乎为零，而 Venice AI 的问题指令数（3.0）甚至超过了保护指令数（2.0）（图 7）。这种差异反映出不同组织在提示安全工程上的投入存在巨大鸿沟。

时间演化与行业收敛

论文追踪了 Anthropic、OpenAI 和 xAI 旗下主要聊天机器人系列的发展（图 8）。三家的保护性指令数量均呈倍数级增长，其中 OpenAI 的 GPT 系列从 25 条增至 83 条，xAI 的 Grok 系列从 5 条增至 21 条。问题指令方面，Anthropic 和 OpenAI 长期保持极低水平，xAI 则在早期 Grok 版本中出现过最高 6 条问题指令，随后逐步下降。这一收敛趋势表明，更强的提示级用户保护正逐渐成为行业通行做法，而非个别企业的差异竞争。

灰色地带：难以二元归类的指令

审计过程中，专家小组还识别出 29 个跨度属于 “灰色地带”（见第 6 节），它们并非明显有害，却存在潜在风险。论文将其归纳为四类：模仿人类与身份欺骗、培养拟社交依赖、允许用户直接覆写安全策略，以及放宽内容限制甚至施加政治导向。这些指令处于合法产品设计与用户伤害之间的边界，是未来审计标准需要精细处理的难点。

实践建议

AISPA 的框架和发现对 AI 产品的设计与治理有直接的工程指导价值。

开发者应将系统提示视为用户利益的守护机制。 当前很多提示只做到最低限度的角色定义和基础安全规则，但审计结果显示，缺乏不安全请求处理、隐私保护和公平性指令的情况相当普遍。团队可对照 AISPA 的八个维度逐一检查自有提示，填补空白。尤其是，应增加对越狱、自残、歧视性言论等场景的明确拒绝条款，而不仅仅依赖基础模型的默认行为。

建立提示审计的持续集成流程。 论文的三阶段人机协作审计可以内化为企业内部的发布检查点。在模型或产品更新时，将系统提示送入预标注模型，再由安全团队审核增量变更，重点排查新增的 -1 项。对于跨度级标注，可以实现 “一次审计，多次对比”，快速发现提示退化或新引入的风险。

处理灰色地带应引入多角色评审。 涉及身份伪装、情感依赖或内容政策放宽的指令，不应仅由产品经理或增长团队决定。建议引入包含政策、法务、用户体验研究在内的跨职能小组，使用 AISPA 的维度进行结构化的 “风险-收益” 论证，并设定灰度发布与用户反馈监测机制。对于允许用户覆盖安全策略的设计，至少应附加二次确认或使用限制。

重视提示长度的质量密度而非规模堆砌。 论文数据显示，提示长度与保护指令数量同步增长，但短提示因缺少对冲条目更容易被单一条问题指令拉低整体评分。团队应定期梳理提示中的冗余内容，将保护性要求以简练、非冲突的方式内嵌到行为定义中，而非简单追加独立安全段落。

监管与认证可参考 AISPA 框架。 论文提出第三方审计与公开认证的设想，建议行业组织或标准机构将 AISPA 的八维度和极性判定作为系统提示审查的参考基准。开发者可主动披露经审计的提示摘要（而非完整提示），既保护商业机密，又为用户和监管方提供可验证的信任凭证。

当下，系统提示已成为塑造 AI 行为的核心杠杆，但它的设计质量仍缺少统一的度量尺。AISPA 的价值不仅在于一次性的审计发现，更在于它提供了一套可操作、可演进的语言，使各方都能用共同的维度去讨论、改进和评判一道隐藏在代码深处的指令。