system_prompts_leaks 这个词最近在开发者圈子里被反复提起指的是一批把各家对话产品的系统提示词system prompts整理成公开清单的项目。关键词里带着 leaks 很容易让人联想成某种灰色技术但实际打开看多数仓库就是一份 Markdown 档案按产品、按时间、按版本归档的文本文件外加一段来源说明。它的价值不在于“拿到了什么秘密”而在于它把原本零散、不可见的提示词工程实践变成了一份可以横向对读的公开素材库。我自己做对话产品有两三年时间前后手写过几十版系统提示词也带过两个小团队做提示词评审。说实话这类资料对我的帮助不是“抄”而是“校准”——当你写了几版之后会开始怀疑自己的写法是不是太啰嗦、约束是不是太松这时候有一堆别人家的真实文本摆在那里做横向对照判断速度会快很多。这篇内容想聊的就是这类项目到底收集了什么、一份系统提示词能被拆成哪几层骨架、怎么把公开资料变成自己项目里能跑的东西以及阅读过程中那些我看着同事反复踩的坑。适合正在写提示词的产品、后端、算法同学也适合刚接触大模型应用、想找一份结构化参考的初学者。1. system_prompts_leaks 这类项目到底在收集什么1.1 它更像一份公开文本档案而不是漏洞工具先把定位说清楚能省掉很多误会。这一类仓库的组织形式通常很朴素一个目录对应一个产品或一类场景目录里放着.md或.txt文件文件名里带日期或者版本号少数仓库会附一个简单的表格说明“这份文本从哪来的、大概对应哪个时期”。它不做自动化提取不提供任何调用脚本本质上是一个持续更新的资料整理项目和“收集公开演讲讲稿”的性质差不多。这种档案的价值集中在三点。第一是可比性你可以在同一份文档里看到不同团队对“拒答”这件事的措辞差异差异本身就是信息。第二是时效性产品迭代快很多写法在半年后就被淘汰了档案能让你看到“哪一代写法后来被放弃了”这是活教材。第三是结构启发段落怎么切、约束怎么排序、格式怎么固定这些东西看多了会形成直觉。需要提醒的是档案里的文本会被反复转载和二次编辑你看到的可能已经不是原样。所以我一般把它当作“参考样本”而不是“权威原文”用它来找灵感、做对比但不会拿它去论证任何结论。1.2 一份完整的系统提示词通常由哪几块拼起来不管面向什么场景系统提示词的模块构成其实相当稳定。我把常见模块、作用、典型写法和易错点整理成一张表方便对照阅读模块承担的作用常见写法特征容易出问题的地方身份与角色给模型一个稳定的行为锚点一句话说明“你是谁、服务谁”写成小说式人设与后续约束冲突能力边界明确能做与不做正列举 负列举只写能做什么遗漏禁止项工具与函数说明约定调用条件与参数语义每个工具一段写清触发时机只给参数表不写“什么时候该调”输出格式保证下游可解析JSON 字段说明、示例块格式描述与示例不一致拒答与安全策略处理越界请求分类 统一话术条款过严导致正常问题也被拒上下文与变量注入实时数据占位符、插入位置说明占位符命名混乱注入后语义断裂风格与语气控制表达长度、措辞、称呼约定风格要求与格式要求互相打架这张表的用法很直接读别人的提示词时你可以拿它当检查表看看对方在哪个模块上花了最多笔墨。我个人的观察是成熟产品的系统提示词里工具说明和格式约束的篇幅往往远超身份设定而刚上手的人写出来的版本刚好相反七八百字都在讲“你是一位专业、友好、耐心的小助手”。这个差异背后是目标不同前者要对齐工程接口后者只想让模型“更像个人”。1.3 为什么这些东西会持续出现在公开渠道很多人好奇文本是怎么流出来的。从工程角度看原因其实很平淡。系统提示词需要以文本形式参与推理请求只要产品开放了一定的可观察行为使用者在日常交互中就能感知到它的存在同时团队内部会有演示、评审、案例分享等环节文本在协作过程中天然会被复制传播。再加上行业里有相当一批人热衷整理和归档久而久之就形成了这些公开清单。这里有一条我认为应该明确的边界资料是公开的不代表可以随意商用。把这些文本整段搬进自己的商业产品既可能违反原平台的服务条款也会让提示词带上不属于你产品的假设。我在团队里立的规矩是——可以读、可以拆结构、可以借鉴思路但不能整段复制尤其不能连示例数据和字段名一起搬。1.4 打开这类资料之前先建立三个预期第一个预期是版本会过期。提示词和后端代码一样是被持续修改的活物。你在档案里看到的那一版可能对应的是某个已下线的功能。所以我读的时候会先看日期超过半年的只当历史材料看。第二个预期是提示词不等于产品能力。一个对话产品表现好可能来自微调、检索增强、工具链设计、后处理校验等一堆工程手段提示词只是其中一环。把产品的聪明全归给提示词是最常见也最误导的判断。第三个预期是结构可学文案不可抄。结构是通用规律比如“先定角色、再定边界、最后定格式”这个顺序在绝大多数场景下都成立而文案高度依赖具体产品、具体用户群、具体合规要求换一个场景就失效。2. 把一份系统提示词拆到骨架结构比文案值钱2.1 三段式骨架角色、约束、输出我拆过上百份提示词样本发现一个稳定的规律好用的系统提示词几乎都能收敛到一个三段式骨架而且三段的先后顺序很讲究。第一段解决“我是谁”。它不需要长一两句话就够核心是给模型一个行为锚点让后续所有约束有依附对象。我见过写得最啰嗦的一版用了四百多字描述性格结果模型在遇到格式要求时会时不时“出戏”用第一人称抒情这就是锚点太重的副作用。第二段解决“什么情况下做什么”。这是最需要投入篇幅的部分包含能力边界、工具调用条件、异常处理路径。写这一段的诀窍是用条件句而不是祈使句——“当用户询问订单状态且提供了订单号时调用查询工具”比“你可以查询订单”有效得多。前者的触发条件明确后者把判断权交给了模型实际表现就是有时候查有时候不查。第三段解决“输出长什么样”。格式约束要写得能让机器校验字段名、类型、缺失值处理方式都要交代。我通常会在这一段的最后放一个最小示例示例的作用不是教模型说话而是锁死歧义字段名用下划线还是驼峰、时间用字符串还是时间戳一个例子就能定死。顺序为什么是这个顺序因为它对应了模型的注意力分布。靠前的内容更容易被稳定遵守靠后的内容在长对话里容易被冲淡。所以身份和硬边界放前面格式和示例放后面中间放那些需要灵活判断的规则——这个排列在实测里比反过来要稳。2.2 工具调用说明怎么写才不产生歧义工具说明是系统提示词里最容易写废的一块。我见过两种极端一种是只贴了一份参数表模型完全不知道该在什么时机调用另一种是把每个工具写成了三页说明书结果上下文被占满推理成本翻了几倍。我的写法是每个工具固定四行结构工具名query_order 用途根据订单号查询订单当前状态与物流节点 调用条件用户明确询问订单进度且上下文中已获得完整订单号 失败处理订单号格式不符时直接向用户说明格式要求不要重复调用这四行分别回答“叫什么”“干什么”“什么时候用”“用错了怎么办”。第三行是最关键的也是大多数人会漏掉的。没有调用条件的工具模型面对一句模糊提问时只能靠猜猜错的概率取决于你的描述有多含糊。还有一个细节同一批工具的命名要保持同一套动词习惯。全部用query_/create_/update_这种前缀模型在需要组合调用时对语义的区分会更准确。这个经验是我在一次线上问题里总结出来的——当时工具名叫得五花八门模型把“修改地址”和“查询地址”混用过好几次。2.3 拒答条款的写法与“过度拒答”的平衡拒答部分值得单独拿一节讲因为它直接决定用户体验而且极难调。公开资料里能看到各种风格的拒答条款有的写得非常细逐条列举有的就一句话概括原则。两种都能用但适用场景不同。写得细的好处是行为可预测坏处是容易过度拒答。我遇到过一版提示词把“涉及个人隐私信息的请求”列成了禁止项结果用户问“我自己的订单什么时候到”时模型因为上下文里出现了地址信息而拒答了。问题出在条款没有区分“请求他人信息”和“查询自己的信息”。我的修正方式是在拒答条款里加一个判断维度而不是单纯的清单请求对象是谁的信息自己 / 他人 / 不特定请求目的是什么查询 / 修改 / 导出是否可以通过正规流程完成三个维度组合之后模型有了判断依据而不是简单做关键词匹配。实测下来误拒率会明显下降同时该拦的也没漏。另外一点经验拒答话术要固定且简短。给模型自由度去“礼貌地解释为什么不能帮你”往往会导致解释内容本身出问题。统一用一句固定话术加一个替代方案既安全又好维护。2.4 可执行性自检清单写完一版系统提示词我会用下面这份清单过一遍基本上能拦住八成低级问题身份描述是否与后续约束存在冲突比如既说“专业严谨”又要求“用网络流行语”每个工具是否都写了调用条件而不只是参数列表输出格式描述与示例是否完全一致字段名有没有拼写差异拒答条款是否有判断维度而不是纯关键词清单是否存在互相打架的两条规则比如“回答尽量简短”和“给出完整推导过程”所有占位符是否都有明确的注入位置说明通读一遍有没有超过三行的长段落如果有拆掉。这份清单里第 5 条是我吃过亏的。有一次同时写了“回复控制在三句话内”和“详细解释每个判断依据”模型在两条之间反复横跳几分钟里换了三种风格用户体验非常糟糕。规则冲突在长提示词里非常隐蔽必须靠通读发现。3. 我在自己项目里复用这些资料的四个动作3.1 建一个带标签的对照库光看不整理过两周就忘光了。我的做法是建一个本地目录每份样本按“场景 / 产品类型 / 日期”打标签然后在文件顶部加三行自己的批注这份最值得学的一点、最不适用的部分、有没有可复用的片段。这个过程一份样本大概花十分钟但半年后回头看这三行批注比原文有用得多。批注写多了会形成自己的判断框架。比如我现在看到一份新样本第一反应是看它的工具说明占比如果低于整篇的百分之二十我基本能判断它是偏对话类而非任务类的产品。这种直觉不是天赋是标签堆出来的。另外我建议按问题归档而不是按产品归档。把“处理模糊输入的写法”相关的片段集中放一个目录“格式约束的写法”放另一个目录需要什么直接翻对应目录。按产品归档的话同一类问题散落在十几个文件里检索成本极高。3.2 改写而非照搬把句子换成自己的约束这一步是分水岭。照搬的人得到一版看起来很专业、跑起来到处是坑的提示词改写的人得到一版朴素但稳定的提示词。我的改写方法是逐句追问“这句话在我这里成立吗”。举个例子某份样本里有一句“当用户情绪激动时优先安抚情绪再解决问题”。这句话在很多客服场景都成立但如果我的产品是内部工单系统用户是同事那“安抚情绪”就完全没必要反而显得啰嗦。我会把它改写成“当用户重复描述同一问题时先确认已理解的问题点再给出下一步动作”。改写的另一个重点是删掉自己无法验证的承诺。样本里常出现“确保回答准确无误”这类表述听起来很负责但模型做不到写了反而会让它在不确定时强行给答案。我一般会换成“信息不足时明确说明需要补充哪些信息”这是可执行的行为。3.3 用回归用例验证每次改动是否真的有效提示词工程最大的问题是缺少测试。改了一句话感觉好像好了一点但到底有没有变好、有没有引入新问题全靠感觉。我的解决方案是准备一份回归用例集大概三十到五十条覆盖正常流程、边界输入、模糊提问、越界请求四类。每次改提示词跑一遍用例看三件事格式合规率、工具调用准确率、拒答误判率。这三项数据比任何主观感受都可靠。我用这个方法抓出过好几次“看起来变好实际变差”的改动最典型的一次是给输出格式加了更严格的约束格式合规率上去了但因为约束太长模型在长对话后期开始忽略它反而比改之前更不稳定。用例集本身也要迭代。新发现的线上问题处理完之后补一条用例进去用例集会随着产品一起长大。这份资产的价值说实话比提示词本身更高。3.4 版本管理提示词就是代码我用 Git 管理提示词文件每次改动写清楚三件事改了什么、为什么改、回归结果如何。提交信息我习惯写成“调整工具调用条件修复模糊提问下重复调用问题”而不是“update prompt”。半年后你要回溯某次行为变化只有这种提交信息能救你。版本管理还带来一个额外好处可以灰度对比。新版本先给小流量和老版本跑同样的用例集和真实流量指标对比通过再全量。这个流程听着重但比出事之后回滚要轻得多。顺带说一个我踩过的坑提示词里如果有拼接注入的变量一定要把注入逻辑也纳入版本管理。有一次代码里的时间格式改了提示词没动结果模型拿到的日期格式和示例不一致格式合规率掉了十几个百分点排查了半天才发现问题不在提示词本身。4. 看这类资料时最容易踩的坑4.1 照抄长提示词换来的是行为漂移新手最典型的操作是把一份几百上千字的样本整段复制过来改掉产品名就上线。短期看效果好像不错因为样本本身的写法是经过打磨的但跑一周就会发现问题模型在一些你根本没设想过的地方开始出现奇怪行为。原因在于长提示词里藏着大量隐含假设。那几百字是针对特定产品形态、特定用户群、特定工具链写的你把文本搬走了假设没有搬走。比如样本里写了“避免讨论竞品”这在面向消费者的产品里合理搬到 B 端工具里就变成了莫名其妙的限制用户问一句行业对比就被拒了。我的建议是抄结构不抄内容抄顺序不抄句子。结构层面的东西可以放心借鉴内容层面必须逐句重写。4.2 把产品侧工程能力误判成提示词功劳这个坑更隐蔽连做过一段时间的人都容易掉进去。你看到某个产品在多轮对话里记得住很久之前的信息就以为它的提示词里有某种神奇的“记忆指令”。实际情况往往是上下文管理策略、摘要压缩、外部存储检索这些工程手段在起作用提示词只是告诉模型“何时去取”。同理产品能稳定输出结构化数据可能来自输出后的解析校验和重试机制而不是提示词写得多么滴水不漏。判断方法很简单看这份提示词里是不是只有描述、没有机制。如果全是描述那效果一定还有别的来源。理解这一点非常重要因为它决定了你的改进方向。如果你把一个工程问题错当成提示词问题就会陷入无休止地改措辞而真正该做的是加一层校验。4.3 忽略 token 成本与上下文预算系统提示词是要花钱的。它的长度直接进入每次请求的输入 token而且是每一轮对话都要重复计算。一份两千字的系统提示词在一个十轮对话里光提示词部分就要被计算十次。粗估的话中文内容大致上每个字对应零点几个到一个 token 不等具体取决于分词器我一般用工具实测而不是硬算。实践经验是能不写的就不写能合并的就合并。我见过一版提示词里有三段话反复强调同一件事删掉两段之后效果完全没变成本直接降下来。另外一个省成本的做法是分层加载。核心身份和硬边界常驻只在特定意图触发时才把对应的详细规则注入。这个做法牺牲了一点实现简洁性但在长对话场景里收益明显。4.4 合规红线能读不等于能用这条我想说得直白一点。公开资料的可获取性和它的可用性是两回事。原平台的服务条款、内容授权范围、你所在团队的合规要求这三条都必须在动手之前过一遍。我自己的做法是划一条很清楚的线学习结构与思路不复制文本与数据。特别是样本里出现的示例数据、字段命名、内部术语一律不用。这些内容看似无关紧要但恰恰是最容易留下痕迹的部分。还有一点不要把整理这类资料的目的理解成“找到最强提示词去用”。它真正的作用是让你建立一个参照系知道自己在哪个水平线上、哪些写法已经被验证过、哪些写法已经被淘汰。这个认知价值比拿到任何一份具体文本都重要。5. 动手写一版从需求拆解到上线观测5.1 需求拆解与字段定义前面聊的都是“怎么读别人的”这一节我们完整走一遍“怎么写自己的”。我拿一个最常见的场景做例子一个内部工单助手的对话入口用户是公司同事可以通过自然语言查询自己的工单状态、提交新工单、补充信息。先做需求拆解。我会列三张清单第一张是动作清单——用户可能想做什么。查询工单进度、创建工单、追加描述、查询历史记录、询问流程规则。这五个动作里前四个需要调工具最后一个直接从静态知识里回答。分清哪些需要工具、哪些不需要是提示词结构的基础。第二张是信息清单——每个动作需要哪些参数。查询需要工单号创建需要标题和问题分类追加需要工单号和补充内容。哪些参数用户可能不提供、这时候该怎么追问全部写清楚。第三张是异常清单——哪些情况必须拒绝。查询他人的工单、要求删除已归档记录、要求越过审批流程直接处理。这三个是硬边界写进拒答条款。这三张清单做完提示词的骨架其实已经出来了。后面就是把它们翻译成模型能执行的语言。5.2 一份可直接改的提示词模板下面是我实际在用的模板结构去掉了业务细节可以直接替换成你自己的场景# 角色 你是内部工单系统的对话助手服务对象是公司内部同事。 你的职责是帮助同事查询工单状态、创建新工单、补充已有工单信息。 # 通用行为约束 - 使用简洁、直接的表达不使用寒暄和情绪化措辞 - 信息不足时明确说明缺少哪些信息并一次性问清不要多轮追问 - 不确定的事实不要推测直接说明无法确认 # 工具调用规则 工具名query_ticket 用途根据工单号查询工单当前状态与处理节点 调用条件用户提供了完整的工单号且明确表达查询意图 失败处理格式不符时说明工单号的格式要求不重复调用 工具名create_ticket 用途创建一条新工单 调用条件已获取标题与问题分类两项信息 失败处理缺少必填项时列出缺失字段等待用户补充 工具名append_ticket 用途向已有工单追加补充说明 调用条件已获取工单号与补充内容 失败处理工单号无法确认时提示用户核对 # 输出格式 所有回复使用如下 JSON 结构 { action: query | create | append | answer, content: 面向用户的自然语言回复, missing_fields: [] } action 为 answer 时missing_fields 为空数组。 # 拒绝规则 出现以下任一情况时action 固定为 answer content 固定为该操作不在当前服务范围内请通过正式流程处理并附上对应流程入口名称 - 请求查询非本人提交的工单 - 请求删除或修改已归档的历史记录 - 请求绕过既定审批流程直接推进处理 # 上下文注入 工单数据以 ticket_context 标签包裹后插入到本段之后 未获取到数据时该标签为空。这份模板有几个地方值得说明。输出格式用了固定 JSON 结构是因为下游有解析程序不能让模型自由发挥。拒绝话术写死了是为了避免模型在解释原因时说出不准确的内容。上下文注入说明了标签和空值情况是因为注入逻辑由代码控制提示词必须和代码约定一致。我在实际使用中还会加一段“常见追问示例”列三到五条典型的多轮场景每条写清用户可能怎么说、应该怎么回。这一段对稳定性的提升出乎意料地大因为模型在多轮场景里的表现主要取决于它对意图的理解示例能显著减少误判。5.3 上线后的观测指标与迭代节奏提示词上线不是终点。我通常盯四个指标指标观测方式异常信号格式合规率解析失败次数占总请求比例超过千分之五就要查工具调用准确率抽样人工核对调用时机是否正确出现重复调用或漏调用追问轮次平均每单需要几轮对话明显上升说明信息收集设计有问题误拒率抽样统计被拒请求中不合理占比超过百分之二就要调拒答条款迭代节奏我建议固定周期而不是随时改。随时改的问题是你无法判断变化来自哪次修改。我一般两周集中评审一次把这段时间收集的问题案例过一遍能归类的合并成一条规则改动改完跑回归用例通过再上。中间如果遇到严重影响使用的问题走紧急通道单独改但改完必须补用例。还有一个小经验每次改动只调一个维度。同一版里既改拒答规则又改格式约束出了问题根本定位不到。宁可分两次上也不要图省事一次改一堆。这套流程听起来比“改一句话试试”麻烦很多但我在两个项目上对比过有回归用例和版本管理的那个项目平均每次提示词问题的定位时间从半天缩短到了半小时以内。前期多花的那些时间后面全赚回来了。最后分享一个我自己一直在用的小习惯每写完一版提示词隔一天再通读一遍专门找“规则打架”和“说了等于没说”的句子。刚写完的时候脑子里的假设是完整的隔一天再看那些没写清楚的漏洞会自己浮出来。这个方法没什么技术含量但拦下的问题比我用任何工具检查都多。