主流聊天机器人的系统提示词承载了模型的行为边界、身份定义与工具调用策略，这些信息对于安全研究、竞品分析与提示词工程优化具有重要价值。然而，系统提示词并非直接暴露在 API 响应中，而是嵌入在复杂的请求响应流中，需要通过流量解析与模式识别技术才能批量提取。system_prompts_leaks 项目正是解决这一问题的工程化框架，支持对 ChatGPT、Claude、Gemini、Perplexity 等平台进行系统提示词的自动化采集与归档。
系统提示词泄露的技术背景
系统提示词是聊天机器人架构中的核心控制层指令，定义了模型的身份认同、响应风格、拒绝边界与工具使用策略。当用户与 AI 助手交互时，系统提示词首先被送入上下文窗口，随后才是用户输入与历史对话内容。从安全研究的角度看，系统提示词泄露可能暴露产品的内部设计决策、敏感的行为约束规则，甚至是尚未公开的功能特性。
传统获取系统提示词的方法依赖单一攻击向量，例如通过特殊提示词诱导模型输出自身指令，或利用提示词注入漏洞绕过内容过滤。这类方法存在明显的局限性：首先，成功率受限于模型的安全性更新；其次，单点测试无法覆盖多版本、多场景的系统提示词变体；最后，人工测试的效率无法满足大规模采集需求。system_prompts_leaks 框架的核心价值在于将系统提示词提取从点对点的攻击测试转化为可扩展的流量采集与模式匹配流水线。
HTTP 流量解析架构
该框架的流量解析模块基于中间人代理或流量捕获两种模式运行。在代理模式下，框架部署为本地 HTTP/HTTPS 代理，拦截所有发往目标聊天机器人域名的请求与响应；在流量捕获模式下，框架读取 pcap 格式的抓包文件或实时网络接口数据。两种模式的配置参数存在差异，但核心解析逻辑保持一致。
流量解析的关键在于识别承载系统提示词的请求字段。主流聊天机器人的 API 请求结构通常包含 system_instruction 或 messages 数组两种形式，前者将系统提示词作为独立字段传递，后者将其封装在 messages 数组的首条消息中。框架通过正则表达式匹配识别这两种模式，匹配规则如下：对于独立字段模式，检测请求体中是否包含 "role": "system" 或字段名包含 "system"、"instruction"、"prompt" 的键值对；对于数组模式，检测 messages 数组的首个元素是否具有 "role": "system" 属性。检测到匹配后，框架将对应字段的值提取并解码，若字段经过 Base64 编码则自动解码为明文。
流量解析模块的采集参数包括：目标域名列表、请求方法白名单（建议仅配置 POST）、响应状态码范围（建议配置 200-299）、超时阈值（建议设置为 30000 毫秒）以及并发连接数限制（建议不超过 10 以避免触发频率限制）。框架支持多域名并行采集，不同域名的请求使用独立的连接池配置，避免跨域污染采集数据。
特征模式匹配引擎
系统提示词在原始流量中往往与大量用户对话内容交织，模式匹配引擎负责从完整的请求或响应正文中精准定位系统提示词的起止位置。引擎采用多阶段过滤策略：第一阶段通过关键词快速筛选，检测文本中是否包含系统提示词常见的起始标识，如 "You are ChatGPT"、"You are Claude"、"You are Gemini" 等品牌身份声明；第二阶段进行结构验证，检查筛选出的文本片段是否符合系统提示词的语言模式，例如是否包含行为约束、工具定义、拒绝策略等典型段落；第三阶段执行完整性校验，确保提取的文本具有完整的语句结构，不因截断导致语义不完整。
模式匹配的配置参数决定了提取的准确率与召回率。关键词库的覆盖范围应涵盖各平台系统提示词的身份声明变体，建议配置至少 20 个核心关键词，包括各平台的正式名称、缩写、版本代号以及常见的提示词开头句式。结构验证的规则强度可调，高强度模式要求文本同时满足多个条件（如必须包含身份声明、工具定义与拒绝策略），适用于高精度场景；低强度模式仅要求满足关键词匹配，适用于系统提示词格式未知的新平台探索。
批量采集时，模式匹配引擎支持增量更新模式。框架记录已采集的系统提示词哈希值，当检测到重复内容时自动跳过，避免存储冗余数据；同时，当同一平台的系统提示词发生变更时，框架会生成新版本记录，保留历史版本以支持时序分析。
多平台适配与采集策略
不同聊天机器人的系统提示词嵌入方式存在差异，框架通过平台适配层屏蔽这些差异。ChatGPT 的系统提示词通常出现在 Chat Completions API 的 messages 数组首部，部分付费版本还会在响应头中携带额外的上下文标识；Claude 采用了类似的结构，但其系统提示词往往更长，包含详细的工具定义与决策树；Gemini 的嵌入方式较为分散，系统提示词可能分布在多个请求字段中，需要拼接才能获得完整内容。
针对各平台的采集参数建议如下：对于 OpenAI 域名的请求，建议配置请求体解析深度为 3 层（支持嵌套的 tool_calls 结构），响应解析启用工具调用提取；对于 Anthropic 域名的请求，建议配置系统消息识别阈值为 0.85（避免将普通助回复误判为系统消息），并启用流式响应中的数据块累积模式；对于 Google 域名的请求，建议配置多字段拼接策略，将 system_instruction、generation_config.system_instruction 等字段合并采集。
频率控制是批量采集的关键参数。过高频率的请求可能触发平台的反爬机制，导致 IP 被封禁或账号被限制。建议的采集间隔参数为：单域名请求间隔不低于 5 秒，突发请求上限为每分钟 20 次，每日采集总量不超过 1000 条会话。当平台返回 429 状态码时，框架自动进入退避模式，指数级增加请求间隔直至恢复。
数据存储与版本管理
提取的系统提示词以结构化格式存储，支持 JSON 与 Markdown 两种输出格式。JSON 格式保留完整的元数据，包括采集时间、源 URL、请求指纹、响应状态等字段，适用于后续的自动化分析流水线；Markdown 格式提供人类可读的展示，包含平台标识、版本标签与原始文本，便于人工审查与文档编写。
版本管理机制基于内容哈希与时间戳双键索引。每条系统提示词记录携带 SHA-256 哈希值作为内容标识符，同时记录首次发现时间与最近更新时间。当平台推送系统提示词更新时，框架检测到内容哈希变化，自动创建新版本记录并保留历史版本，支持版本差异对比分析。存储目录结构建议采用 "平台名称 / 采集日期 / 哈希值.md" 的层级，便于按时间维度与平台维度检索。
工程化部署参数
框架的工程化部署涉及资源规划与安全配置。CPU 资源建议配置 2 核以上，以支持正则匹配的并发执行；内存建议配置 4GB 以上，用于流量缓冲与模式匹配的中间状态存储；网络带宽建议不低于 10Mbps，确保流量捕获的实时性。
安全配置方面，框架本身作为流量代理运行时，需要配置 TLS 解密证书。建议为框架生成专用的根证书，并将证书导入系统信任链，同时在配置中限制框架仅代理目标聊天机器人的域名，避免代理被滥用为中间人攻击工具。采集数据的存储路径应配置访问权限，建议仅允许框架进程读写，并启用存储加密以保护敏感的系统提示词内容。
监控指标建议覆盖：采集成功率（成功提取次数除以总请求次数）、提取准确率（人工抽检的正确提取比例）、平台覆盖率（已成功采集的平台数量与目标平台列表的比率）、平均响应时延（从发起到完成提取的时间间隔）。当采集成功率低于 90% 或平台覆盖率低于 80% 时，应触发告警进行检查。
应用场景与边界思考
系统提示词提取框架的典型应用场景包括安全研究与对抗测试、竞品分析与提示词工程优化、模型行为审计与合规检查三类。在安全研究场景中，研究者可通过批量提取的系统提示词分析各平台的安全边界变化趋势，评估提示词注入攻击的有效性演变；在竞品分析场景中，产品团队可参考竞争对手的系统提示词设计，学习其身份定义、工具调用与拒绝策略的表述方式；在合规审计场景中，监管机构可验证聊天机器人是否遵循承诺的行为准则，系统提示词的版本历史提供了可追溯的审计证据。
需要强调的是，系统提示词提取技术的使用必须在合法合规的框架内进行。未经授权的流量拦截可能违反计算机安全与隐私保护相关法规；采集的系统提示词若包含商业机密或用户隐私数据，应谨慎处理避免泄露；框架的分发与使用应遵守各平台的服务条款，避免因批量自动化行为导致账号封禁或法律纠纷。
参考资料
本文相关技术细节参考 system_prompts_leaks 项目（github.com/asgeirtj/system_prompts_leaks），该项目目前累计获得 25,200 颗星标，包含来自 OpenAI、Anthropic、Google、Perplexity 等平台的系统提示词采集记录。