1. 系统提示词泄露这件事到底在说什么第一次看到system_prompts_leaks这类仓库的时候我其实有点复杂——一方面它确实把很多人摸索半年的东西一次性摊开在桌面上另一方面又很容易让人误以为拿到提示词就等于会做产品。我做了几年对话产品的提示词设计参与过客服机器人、写作助手、代码辅助工具这几类项目的系统提示词维护我的结论是泄露本身不是终点它更像一批公开的设计样本集能不能读出东西取决于你有没有一套自己的拆解方法。System prompts 泄露这个话题在圈子里热度一直没降过因为它直接触及一个问题——大模型产品里最核心的软性逻辑到底藏在哪一层。我把话说明白一点这篇文章写给三类人看。第一类是刚开始做提示词工程、想知道成熟产品怎么写系统提示词的新手第二类是已经在做对话产品、想从公开样本里找灵感或者做竞品分析的老手第三类是做应用安全或稳定性评估、需要理解为什么用户能套出提示词这件事的开发和测试同学。不管你属于哪一类我都建议你带着设计视角而不是猎奇视角来看这批泄露样本收获会完全不一样。下面我会从泄露的成因机理、样本的阅读方法、可复用的写法、防护思路、以及我自己的实操整理流程这几个层面把这件事完整讲一遍。1.1 系统提示词是什么为什么值得单独研究先对齐概念。系统提示词system prompt通常是指模型在收到用户消息之前就先被写入上下文的那段指令文本。它一般由产品方提供用来定义模型的身份、能力边界、回答风格、工具调用规则、安全约束等。和用户输入的 prompt 不同系统提示词是预设的人设与规则用户正常情况下看不到只会感受到它的效果——比如为什么这个助手总是拒绝回答某类问题为什么它回答前总要先确认一遍需求为什么它输出的格式永远是先结论后理由。它值得单独研究的原因在于它是产品体验和用户感知之间最直接的那一层。同一底座模型换一套系统提示词做出来的助手可能完全是两个产品。我见过太多团队把 90% 的精力花在选模型和调参上最后产品差异度全靠系统提示词那一两千字撑着。所以当一批系统性整理的真实系统提示词被公开出来本质上等于把一批产品的设计说明书草稿摆到了台面上这对做同类产品的人价值极高。1.2 泄露不是一次黑客事件而是一个持续现象需要纠正一个常见误解系统提示词泄露绝大多数情况下不是数据库被拖库而是一个交互层面的渐进现象。只要模型要读系统提示词才能工作那么在特定输入下让它把内容复述出来本身就是一个概率问题而不是绝对不可能。产品方能做的是提高门槛、降低完整套取的成功率但很难做到 100% 阻止——这和用户能通过正常对话问出某个隐藏设定是同一类问题。所以system_prompts_leaks这类集合的价值不在于抓到谁了而在于它长期积累了一批不同厂商、不同产品定位、不同时间点的样本。你可以看到同一条约束在不同产品里的措辞差异也能看到某一类约束随着模型能力提升而逐渐消失。这种纵向对比才是最有意思的部分比单看某一个产品的提示词有用得多。2. 泄露是怎么发生的几条常见路径的机理拆解理解了原理你才能理解为什么防护措施是这样设计的。我先把话说在前面这一节我讲的是机理分类目的是让做防护的人知道哪里是薄弱点不会给出可直接复现的具体套取话术。做安全评估的同行应该能理解这种处理方式——知道攻击面在哪比拿到一把现成的钥匙更重要。2.1 直接询问与角色诱导这条老路最朴素的一类情况就是用户在对话里以各种方式询问系统设定。早期的做法比较粗糙随着模型对齐能力提升直接问通常会被拒绝。但角色诱导这条路一直没完全堵死让模型扮演某个不含约束的角色、让模型以讲解另一个AI的实现的身份来输出、或者把请求包装成一个虚构的技术讨论场景。这些手法的共同点是把复述系统提示词这个动作藏进一个看起来无害的任务里。从防护角度看这类路径的抓手是意图识别而不是关键词匹配。因为包装方式千变万化靠关键词黑名单基本没用我实测下来效果最好的还是把是否在尝试获取系统设定当做一个独立的意图分类来做再配合对多轮对话累积意图的判断。单轮看起来无害的提问连起来可能就是一条完整的套取链路这一点做单轮检测的产品几乎都吃过亏。2.2 上下文溢出与指令冲突第二类机理更偏工程层面。当上下文窗口被塞入大量内容时模型对哪条指令优先级更高的判断会出现波动早期模型尤其明显。有些样本之所以能泄露就是因为攻击者用超长文本稀释了系统提示词的影响力或者在长文本里埋入了与系统指令冲突的内容让模型的注意力被引偏。这类问题本质上是指令优先级机制不够稳而不是提示词写得不好。现在主流模型的指令层级system / user / tool已经做了区分抗稀释能力比两年前强很多但并不等于零风险。尤其当你自己在应用层又套了一层 prompt 拼接、RAG 检索内容也一起塞进上下文时你其实是在给模型制造更多指令来源每条来源都可能成为干扰项。我的经验是检索内容一定要明确标注为参考资料而不是指令这个标注习惯能挡掉相当一部分意外。2.3 结构化输出带来的副作用第三类比较隐蔽和产品设计有关。很多产品为了让输出可解析会要求模型输出 JSON、XML 标签或者固定字段。这个设计本身没问题但当字段设计得过于暴露内部逻辑时就给了套取的空间。比如有的样本里系统提示词要求模型先输出一段内部推理再输出正式回答那这段内部推理就很容易被引导说漏嘴。我自己的做法是凡是希望模型内部使用、不对外呈现的内容一律不放进会输出的字段而是通过工具调用或者后处理完成。让模型想和让模型说是两个通道分开以后泄露面能小一大截。这个习惯是从几次线上事故里总结出来的不是理论推导。2.4 多轮对话里的渐进式套取第四类是综合性的也是实际中最难防的。单轮提问看起来都合规但连续几十轮之后模型已经把系统提示词的不同片段以不同形式复述出来了攻击者再拼接就还原得七七八八。这类攻击的特点是单点无害聚合有害对检测的要求很高——你得看会话级别的行为模式而不是单条消息。针对这种情况我参与过的项目里用的是会话级风控统计单位会话内询问自身设定类意图的密度超过阈值就触发降级策略比如切换到更保守的回复模板。这个方案不完美但比什么都不做要好得多。做这类规则的时候一定要留误伤评估环节因为真实的调试型用户问得也很频繁。3. 拿到一堆系统提示词之后怎么读这批样本最大的门槛其实在读上。很多人打开文件看了几段觉得就是一堆你是某某助手你要如何如何看完就关掉了。这是浪费。真正有用的是把它们当数据集来做结构分析你能从中看出一个产品在哪些点上做过取舍。下面分享我自己的一套拆解流程。3.1 先看骨架别急着看细节我读任何一份系统提示词第一遍都是只扫结构不看具体措辞。经验上成规模的商业产品系统提示词大致包含这几块身份定义、能力范围、知识边界、语气风格、输出格式、工具使用规则、安全与合规约束、以及异常情况的兜底话术。有的还会单独拿一段讲当你不确定时应该怎样这一段往往最能体现团队的实际踩坑经历。先扫骨架的好处是你能快速判断这份提示词的成熟度。如果一份样本里只有身份定义和语气风格没有兜底和边界那多半是早期版本或者个人项目如果八个板块齐全还有明确的优先级说明那基本是经过多轮线上迭代的产品。这个判断对做竞品分析特别有用——你能大致推断对方团队在这个方向上投入了多少。3.2 关键字段对照表第二遍我开始做字段提纯把几份样本的同名板块拉到一起比对。我自己常用的对照维度是这几个维度观察点能推断出的信息身份定义是否给出具体角色名、领域范围产品定位的清晰度能力声明是否列举具体能做的事是否做过需求收敛边界约束拒绝方式、拒绝理由合规投入程度输出格式是否强制结构、字段数量下游是否要解析工具规则调用条件、失败处理工程化成熟度兜底话术不确定、超范围时怎么办线上迭代次数冲突优先级多条规则冲突时的取舍是否踩过坑这张表我用了一年多比单纯看文本有用得多。举个例子同样是当用户问到范围外的问题有的样本写礼貌拒绝并引导到相关话题有的写直接说明无法回答并结束这两种写法的产品体验完全不同——前者适合开放式助手后者适合客服工具。你把这两份样本放在一起就能看出背后的产品形态差异。3.3 从措辞差异反推产品定位第三遍我才开始精读措辞。这里有个很多人忽略的点系统提示词的长度和风格本身就是产品定位的信号。偏创作类的助手提示词往往更长、描述性更强、语气引导更细腻偏工具类的助手提示词更短、条件判断更多、格式约束更硬。这不是巧合而是因为创作类体验靠氛围工具类体验靠确定性。还有一个观察点是用词的一致性。成熟产品的系统提示词里同一个概念通常用同一个词比如通篇叫用户就不会突然变成客户。这种一致性看着不起眼但它直接影响模型的行为稳定性——术语混乱的提示词会让模型在不同轮次里表现出不同的理解。我在整理自己的提示词模板时专门加了一轮术语核对就是为了避免这个问题。4. 从泄露样本里提炼可复用的写法读完之后要落地。我把从公开样本和自己项目里积累的写法整理成了几条可复用的规则这些不是抄来的是经过实际验证的。你可以直接参考但要根据自己的产品形态做调整。4.1 角色定义要具体到场景别具体到性格新手最容易犯的错是把角色定义写成一长串性格描述比如你是友好、专业、耐心、幽默的助手。这种写法的问题在于模型对这些形容词的解读差异很大而且它们之间可能互相冲突——又要专业又要幽默输出的稳定性就会下降。更有效的写法是把角色绑定到具体场景和任务上比如你是一个帮助用户整理会议纪要的助手你的输出需要让没参会的同事也能看懂。场景化的写法有一个隐性好处当用户提出范围外的请求时模型更容易识别并拒绝因为它清楚自己的任务边界在哪。我做过对比测试同样一份边界规则附着在场景化角色描述后面执行率明显高于附着在性格化描述后面。这个差异在老模型上尤其明显。4.2 约束的表达说做什么比说不做什么更有效第二点是我踩过坑之后才明白的。系统提示词里大量堆不要做X这种否定约束实际效果往往不好因为模型在处理否定时容易出现忽略否定词只看到关键词的情况。更稳的写法是给出正向替代行为与其写不要编造数据不如写如果数据不在参考资料中就明确说明无法确认并建议用户核实来源。正向写法的另一个好处是可验证。你在做回归测试的时候可以针对每一条正向规则设计一个用例检查模型有没有照做而否定规则很难测因为你不知道它会在什么情况下触发。我现在维护的提示词里正向规则和否定规则的比例大概控制在 7:3否定项只留给真正的红线。4.3 输出格式控制里最容易忽视的两件事格式控制这块我看到很多样本写得很细但普遍漏了两件事。第一是字段缺失时怎么办——如果你的输出要求是 JSON某个字段信息不足时是给空字符串、给 null、还是省略这个不写清楚下游解析就会出问题。第二是长内容怎么截断——当回答超过预期长度时是优先保留结论还是优先保留论据这个也需要明确。这两件事我在项目里都遇到过。第一次是格式解析报错排查半天发现是模型在信息不足时自己发明了一个字段值第二次是摘要功能输出被截断用户投诉看不到关键信息。解决办法都不复杂就是在系统提示词里补两句明确说明。但从没写到写上这一步往往要经历一次线上事故才会想到。4.4 兜底话术把不知道设计成体验的一部分兜底话术是我认为最被低估的一块。很多产品的系统提示词里对不知道的处理只有一句如果不确定就说不确定太单薄了。好的兜底设计应该包含三层如何表达不确定、如何提供替代帮助、如何引导用户完成目标。比如这个信息我暂时无法确认但如果你能提供XX我可以帮你做YY这样的回复比一句我不知道有用得多。我从公开样本里看到过一个处理得很细的设计把无法回答分成几种情况——信息不足、超出范围、需要专业资质——每种情况对应不同的回复模板。这种粒度的设计背后一定是有过线上数据分析的。我个人建议如果你的助手日均对话量上千那就值得做这种细分。5. 防御视角如何降低系统提示词被完整套取的风险讲完怎么写就得讲怎么防。这块我强调一点目标不是绝对防住而是提高完整获取的成本降低风险收益比。任何一个做对话产品的人都应该接受这个前提否则会在无止境的对抗里耗光预算。5.1 分层设计真正敏感的东西别放提示词里最根本的一条原则不要把不该被看到也不会被看到的东西放进系统提示词。具体来说业务规则、风控阈值、内部话术模板这些内容能放在应用层的就不要放在提示词里。提示词只负责如何表达应用层负责表达什么。这个分层做完即使提示词被完整拿到损失也是可控的。我见过的反面案例是把整套客服话术和升级逻辑全写进提示词结果一旦泄露等于把客服培训手册公开了。改成分层设计之后提示词只保留语气和格式要求具体话术从配置中心按场景注入泄露风险一下子就降下来了。这个改造在实现上不算复杂主要是设计观念要转变。5.2 输入侧意图识别比关键词过滤有用得多输入侧的防护我的经验是别过度依赖关键词。原因很简单想获取提示词的人会不断换说法关键词列表永远追不上。更实际的做法是做意图分类把询问自身设定要求复述指令角色扮演脱敏这几类意图单独建模然后配合会话级统计。这样即使单条消息没被抓到累计行为也会触发告警。这里有个平衡点要把握检测太严会误伤正常的调试型用户和技术讨论型用户。我的做法是分级响应——低置信度只记录不干预中置信度给一个更保守的回复模板高置信度才直接拒答。这样既能拦住大部分尝试又不会把正常用户逼走。三级响应的阈值需要用真实流量标定不能拍脑袋定。5.3 输出侧一致性和异常检测是最后一道闸即使输入侧漏了输出侧还能兜一层。具体做法是检查模型输出和系统提示词文本的相似度超过阈值就拦截或改写。这个检测实现起来不难关键是阈值要调好——太低会误伤正常的能力说明类回答太高就形同虚设。我一般会先跑一批正常对话确定基线再往上留出余量。另外可以做的是一致性检查同一个问题问两次如果模型给出的身份说明不一致那就是异常信号。这个检测对多轮套取特别有效因为套取过程中模型的表述往往会漂移。缺点是会增加一定的推理成本所以我只在对安全性要求高的场景开启。6. 实操搭建自己的提示词样本库与对照流程光看别人的分析没有用你得自己动手建一套。我做这个已经两年多了下面把流程完整写出来你可以照着搭。6.1 目录和元数据怎么设计我的样本库结构是这样的按来源类型分一级目录比如公开样本、自研版本、测试版本二级目录按产品领域分比如客服、写作、代码每个样本文件配一个同名的元数据文件.json记录来源、采集时间、模型底座、领域标签、版本号。这个元数据看着麻烦但等到你要做纵向对比的时候它就是最有价值的部分。元数据里我特别推荐两个字段一个是观察到的设计特点一个是疑似的迭代痕迹。前者记录你觉得这份提示词做得好的地方后者记录你推测的版本演进。这两个字段在半年后回看时价值极高因为很多当时的判断和后来的实际演变能对上这种反馈循环才是真正长经验的地方。6.2 版本对比与差异分析单个样本看完就完了真正出东西的是版本对比。我会把同一个产品的多个版本放到一起用文本对比工具看差异。重点关注的不是改了什么词而是新增了哪一类约束删掉了哪一类约束。新增往往意味着踩过坑删除往往意味着老模型的行为已经内置了这条规则。我做过一个统计把十几个产品的版本演进拉出来看发现输出格式约束这块是迭代最频繁的平均每个产品改过三次以上。这说明格式问题在实践中确实最容易出问题。这个结论后来直接影响了我的设计优先级——新项目我现在会先把格式约束写细再补其他部分。6.3 一个整理样本的小脚本如果样本数量超过几十份手工管理就不现实了。我写过一个简单的整理脚本功能是遍历目录、统计各板块关键词出现频率、生成对照表。核心逻辑不复杂import json import os from collections import Counter SECTION_KEYS { identity: [你是, 你是一个, your role], boundary: [不要, 无法, 拒绝, 不能], format: [格式, JSON, 输出, 字段], fallback: [不确定, 如果不知道, 无法确认], priority: [优先, 其次, 冲突时], } def scan_samples(root_dir): stats Counter() records [] for dirpath, _, filenames in os.walk(root_dir): for name in filenames: if not name.endswith(.txt): continue path os.path.join(dirpath, name) with open(path, encodingutf-8) as f: text f.read() hit {} for key, words in SECTION_KEYS.items(): cnt sum(text.count(w) for w in words) hit[key] cnt if cnt 0: stats[key] 1 records.append({file: name, sections: hit, length: len(text)}) return stats, records if __name__ __main__: s, r scan_samples(./samples) print(板块覆盖率:, dict(s)) r.sort(keylambda x: -x[length]) for item in r[:10]: print(item[file], item[length], item[sections])这个脚本我一开始只是想统计覆盖率后来发现排序功能更有用——长度排前几的样本通常设计最完整值得优先精读。脚本本身没什么门槛关键是先跑起来样本管理的习惯比工具的复杂度重要得多。用这个思路能很快摸清一批样本的整体分布。7. 常见问题与排查速查整理和使用这批样本的过程中我遇到过不少典型问题下面按问题—原因—处理的形式列出来方便你对照。7.1 常见问题速查表问题现象可能原因处理建议样本格式混乱无法对比采集时没做清洗统一转成纯文本去除多余换行和标记同一产品样本差异巨大采集时间跨度大先按时间分组再做同组内对比无法判断样本真实性来源单一交叉验证多个来源标注置信度精读效率低没先扫骨架按骨架—对照—精读三遍法抄了写法但效果差忽略了自己的产品形态先明确场景再挑写法版本对比看不出重点只看字面差异关注约束类别的增删防护规则误伤严重阈值拍脑袋定的用真实流量标定分级阈值7.2 几条踩过坑的经验第一别迷信完整版。网上流传的很多所谓完整系统提示词其实是拼接或者推测出来的。我的做法是给每份样本标注置信度高置信度用于参考设计思路低置信度的只用来观察趋势不作为写法依据。这个习惯帮我避免过好几次误导。第二场景不匹配的写法不要硬抄。我早期抄过一份创作类助手的细腻语气引导用在一个工具类助手上结果是模型变得啰嗦用户投诉回答太长。后来明白了提示词写法是和产品形态强绑定的抄之前先问自己我的产品需要这种体验吗。第三一定要建回归测试集。系统提示词每改一次就要跑一遍测试用例看原有行为有没有被破坏。我见过太多团队改一句话结果把另一条约束弄失效了。测试集不用大二三十个覆盖核心场景的用例就够关键是要固定下来长期维护。第四注意术语一致性。同一份提示词里同一个概念至少保证用词统一。这个检查我一般放在最后一遍因为改着改着就容易引入不一致。写个小脚本扫一遍同义词出现情况能省不少事。第五迭代记录要留。每次改动记一句为什么改半年后你会感谢自己。我现在的习惯是在元数据里维护一个变更日志每次调整都记原因。这个记录在做复盘和新人交接时特别有用比事后回忆强得多。7.3 关于样本库后续怎么扩展如果你打算长期做这件事我建议往两个方向扩。一个是纵向做深挑三五个典型产品持续跟踪它们的版本演进这比泛泛收集上百份零散样本有价值。另一个是横向做标签体系给你的样本打上更细的维度标签比如是否使用工具调用是否有分步推理是否有多语言支持标签越细你能做的交叉分析就越多。我自己现在维护的标签体系有二十多个维度看起来繁琐但每次想做某个特定方向的设计调研时能快速筛出相关样本效率差距很明显。这个投入是值得的尤其是在你要连续做多个同类产品的时候。最后分享我自己的一个体会系统提示词这件事看得多不等于写得好真正的差距在于你有没有把自己的产品形态想清楚。公开样本能告诉你别人怎么做但决定不了你该怎么做。我踩过的最大一个坑就是有一段时间沉迷于收集和模仿结果产品做出来处处都是别人的影子反而丢了辨识度。后来我把重心挪回用户反馈和实际数据上样本库只作为参考输出质量才真正稳下来。如果你也在做这块建议把样本当工具别当答案。
