做 AI 应用这行时间长了人会养成一个有点职业病的习惯看到一个表现特别好的 AI 产品第一反应不是猜它用了什么模型、温度调到几而是想搞清楚它到底被交代了什么——也就是它的 system prompts 是什么。GitHub 上那个叫 system_prompts_leaks 的仓库本质上就是被这种好奇心喂大的产物一群人持续追问各家 AI 产品你背后的那段隐藏文本写了什么然后把能收集到的系统提示词按产品、按版本、按时间整理成册。它既不是官方文档也不是什么神秘组织流出的内部资料而是一份社区自发维护的提示词观察样本集。对写 Agent 的人、做 AI 产品的人、以及想把自家机器人调得更像样的开发者来说这个仓库的价值不在于偷师而在于它是一面镜子你能看到顶尖团队怎么把一堆模糊的产品需求翻译成机器能执行的自然语言规则。这篇文章我想聊的是怎么把这个仓库用出真正的生产力而不是收藏夹吃灰。1. system_prompts_leaks 里到底躺着什么1.1 仓库的组织形态与内容边界先把预期拉正。这个仓库的形态极简绝大多数情况下是一堆.md或.txt文件按产品名分目录目录里可能再按日期切分版本根目录一个 README 做索引。没有花哨的网站没有 API也没有结构化数据库。有的整理者会顺手标注来源官方公开页面、用户提取、媒体披露和抓取时间有的则只留一段纯文本。所以你打开它的时候看到的是原料不是成品。内容覆盖面通常包括几大类通用对话助手、编程辅助类工具、搜索问答类产品、内容创作类工具以及近年来数量增长最快的 Agent 型产品带工具调用能力的那一批。不同产品的系统提示词长度差异极大短的几百词长的能到几千词甚至上万字符。这个长度差异本身就很有信息量——它大致反映了产品在行为可控性上投入了多少精力。需要明确一点这些文本的真实性和时效性参差不齐。有的确实是产品官方在某次发布中主动公开的有的是用户用各种提问方式诱导模型复述出来的还有一部分是二手转述甚至社区推测。版本漂移也很常见同一款产品半年前和今天的提示词可能已经改了三轮。我的用法是把它当参考样本绝不当规格说明书。1.2 为什么一份提示词合集值得反复看很多人以为提示词就是你是一个专业的助手请友好地回答用户问题这种客套话。真正打开这些文本你会发现完全不是。高水平的系统提示词读起来更像一份写给新员工的岗位手册职责范围、什么情况下必须拒绝、输出用什么格式、遇到模糊需求先问还是先做、调用外部工具前要满足哪些前置条件、甚至情绪语气的分寸都写清楚了。这东西的价值在三个层面。第一层是产品视角你能看出一个 AI 产品的性格不是模型自带的而是被这几千字塑造出来的很多用户觉得这家模型更严谨、那家更活泼背后其实是提示词里一句关于语气的约束。第二层是工程视角你能学到怎么把一个模糊需求写成可判定的规则比如回答要简洁是废规则回答控制在三段以内、不主动展开背景知识才是可执行的。第三层是防御视角看得多了你会对哪些写法容易被绕开有直觉这在给自己的产品做护栏时非常有用。注意把收集到的提示词原封不动搬进自己的产品是大忌。那些文本里有大量针对特定模型、特定工具链、特定合规要求的写法换个环境大概率水土不服甚至相互冲突。1.3 一份提示词的版本感比内容本身更重要我刚开始看这个仓库时关注点全在这段话写得真妙。后来发现更有价值的是纵向对比同一款产品不同时期的提示词差异。你能看到团队在什么节点加上了工具调用章节什么时候收紧了对某类问题的处理方式什么时候把输出格式从自由文本改成了结构化字段。这种纵向视角能帮你判断趋势。比如早期的提示词普遍在堆形容词强调专业、准确、全面近两年的提示词越来越多地在做流程编排写清楚第一步做什么、拿到结果后判断什么、不满足条件怎么回退。这说明行业对提示词的理解已经从人设描述进化成了流程定义。所以我建议你建库的时候文件名一定带上采集日期哪怕只是xxx-2024-11.md这种粗糙格式。三个月后你会感谢现在的自己。2. 拆开一份系统提示词六个高频模块上面说了这么多有什么用接下来进入正题。我把收集到的样本反复读下来发现绝大多数高质量提示词都能拆成六个模块虽然顺序和写法各不相同但骨架高度相似。理解这个骨架你就能从抄句子升级到抄结构。2.1 身份与角色设定别只写你是专家最开头那段通常是身份定义但写法差别巨大。低配版是你是一个乐于助人的助手高配版会写清楚你服务于谁、你的知识范围到哪、你不做什么。举个例子一个面向企业内部的知识助手更好的写法是定义清楚服务对象和使用场景比如明确回答面向已经在职的员工默认他们了解公司基本术语不需要解释基础概念。这一句话就把回答的详略度定死了。角色设定还有一个常被忽略的作用给模型一个立场锚点。当用户提出模糊需求时模型需要判断该往哪个方向补全。如果角色定义是严谨的技术支持它会倾向于追问细节如果定义是创意伙伴它会倾向于先给几个方向。我的实操心得是身份段落里至少包含三个要素服务对象、专业范围、默认假设。默认假设这一条尤其重要它决定了模型在信息不足时是补全还是反问。2.2 能力边界与拒绝策略把不知道设计好这是最容易被新手跳过、但高手花最多笔墨的部分。一份成熟的提示词会明确区分几种情况完全不知道的、知道但不该说的、需要澄清才能答的、可以答但要有保留的。这四种情况的处理方式完全不同如果提示词里不写清楚模型就会用自己的默认策略去猜结果往往是不该拒绝的拒绝了、该谨慎的却很自信。有个写法我觉得特别值得学把拒绝做成转向而不是关闭。也就是不写遇到 X 类问题直接拒绝而写遇到 X 类问题说明你无法处理的原因并给出用户可以自行推进的方向。这个改动看起来只是措辞差别实际体验差距很大——前者让用户碰壁后者让用户知道下一步去哪。注意拒绝策略一定要写成可判定的条件。写谨慎处理敏感内容这种话等于没写因为敏感在模型那里没有边界。要落到具体类别和具体动作上。2.3 工具调用与外部资源约束只带对话能力的产品这部分通常很薄。但凡是能调用搜索、能读写文件、能执行代码的 Agent 型产品这一章往往是整份提示词里最长的一段。里面会写清楚有哪些工具、每个工具什么时候用、调用前要确认什么、拿到结果后怎么处理、调用失败怎么办。我看过写得最好的一类是把工具使用写成决策树。比如搜索类工具会明确规定涉及时效性信息才调用调用时先拆解成查询语句如果第一次结果不足以回答最多再补一次查询两次之后仍不足就基于已有信息回答并说明局限。这套规则的价值在于它把要不要调用工具这个原本靠模型自由裁量的问题变成了有明确边界和停止条件的流程。对做 Agent 的人来说这段几乎可以直接借鉴思路。核心就是三件事触发条件、执行步骤、终止条件。少了任何一件Agent 就会在循环里打转或者在不需要工具的时候硬调工具。2.4 输出格式与风格控制格式控制是最硬的部分也最容易验证。好的写法会给正例和反例而不是只给形容词。举个常见的对比差的写法回答要简洁清晰。 好的写法回答控制在 3 段以内每段不超过 4 行 不使用首先、其次、最后这类连接词 涉及步骤时用有序列表涉及并列项时用无序列表 不主动追加希望这对你有帮助这类收尾语。第二段为什么好因为每一条都能被检验。你拿到输出可以逐条打勾而简洁清晰你只能凭感觉说好不好。风格控制还有一层是语气。这块我不建议照抄别人的人设因为语气和你的品牌、场景强绑定。但可以学的是它的粒度。比如可以规定到具体场景用户表达困惑时先确认理解再回答用户明显情绪化时降低信息密度用户用简短提问时不要长篇回复。这种按用户状态切换风格的写法是很多人没想到要写的。2.5 安全与合规护栏这部分我放在这里讲是因为它在样本里的存在感越来越强但也最容易写僵。写僵的表现是规则太多太绝对导致正常需求也被挡掉。有经验的写法是把护栏分成两层一层是不可协商的底线一层是依情境判断的灰色地带并且明确告诉模型遇到灰色地带时的默认动作是什么。2.6 示例与少样本引导最后一块是示例。不少提示词会塞一两个理想回答的样子。示例的好处是传递那些说不清楚但一看就懂的东西比如语气、详略度、格式习惯。代价是它会占不少篇幅而且如果示例和前面的规则不一致模型会优先学示例——这是个很坑的陷阱规则里说不要用列表示例里却用了列表模型基本会跟着示例走。所以示例要么不加要么加之前先跟规则对一遍。我的习惯是示例最多两个一个展示标准回答一个展示信息不足时该怎么回复后者对产品体验的影响其实更大。模块核心作用常见坑身份设定确定立场与详略度只写形容词不写服务对象和默认假设能力边界定义不知道时怎么办把拒绝写成关闭不给替代方向工具调用约束外部能力使用只写工具清单不写触发与终止条件输出格式让结果可控可验证只有形容词没有正反例安全护栏划定底线与灰区规则过密正常需求被误伤少样本示例传递难以言传的细节示例与规则冲突模型跟着示例走3. 从样本到自己能用的提示词一套可复现的改写流程光看不动手是学不会的。这一节我把自己的改写流程拆开讲你可以直接照着走一遍。3.1 第一步挑样本别贪多我一般只挑两到三个和目标场景最接近的产品提示词。判断接近的标准不是产品名气而是任务形态。你要做的是客服问答就去挑对话类、且明显带有知识边界约束的样本你要做的是代码助手就去挑带工具调用和文件操作的样本。挑的时候先看长度太短的样本信息量不够太长的不建议新手直接改容易被带偏。挑完先通读一遍什么都别改就感受一下它整体的节奏——什么放在最前面什么被反复强调什么用了编号列表什么用了普通段落。这个整体节奏往往比单个句子更有借鉴意义。3.2 第二步做减法删掉一切品牌专属内容这一步最容易被跳过。样本里至少有四类内容必须删干净特定产品的名称和定位描述、特定模型的专有术语和特殊语法、特定工具链的接口名称、与原始产品合规要求绑定的条款。这四类东西留在你的提示词里轻则无效重则误导模型。删完之后你会发现剩下的可能不到原文三分之一。别慌这很正常精华本来就没那么多。剩下的骨架通常就是角色定义、能力边界、输出格式、几个关键约束。删的过程中顺手做一件事把每个被保留下来的句子改写成我自己的业务语言。比如原文写根据公司的政策回答你就改成你实际的表述明确写出你的规则到底是什么不要让模型去猜政策。3.3 第三步做加法把模糊需求写成可判定条件这是最花时间也最有价值的一步。方法是拿你产品的真实用户问题列表挑出二十条最容易答歪的逐条问自己模型答错的根本原因是什么。答案通常会落在这几类里不知道怎么处理信息不足、不知道优先级、不知道格式、不知道边界。每发现一个原因就往提示词里加一条可判定的规则。所谓可判定就是你能拿一个具体问题去测试它是否被遵守。举个反例对比不可判定尽量给出有帮助的回答。 可判定如果用户问题缺少必要信息如时间范围、地区、具体对象 先提出最多 2 个澄清问题不要直接给出猜测性答案。写完一条就地测一下别攒到最后一起测。逐条验证能让你清楚知道每条规则到底有没有生效攒着测的话出问题你都不知道是哪条惹的祸。3.4 第四步算清长度账本别让提示词吃掉利润很多人不关心提示词长度觉得多写几句没关系。我给你算一笔账。假设你的系统提示词是 2000 token业务每天有 10 万次调用那么仅系统提示词这一项每天消耗就是 2 亿 token。按每百万输入 token 收费 3 元估算一天光打招呼就花掉 600 元一个月接近 1.8 万。再假设你优化之后把提示词压到 1400 token压缩了 30%那么一个月省下的就是五千多块。而且压缩带来的是双重收益成本降了上下文窗口也更宽裕能塞进更多真正有用的用户信息或检索结果。这里有个计算习惯值得养成。先把提示词按段落统计字数再换算成 token。中文大致按 1 个汉字对应 0.7 到 1 个 token 估算不同分词器差异不小最好用目标模型自带的统计接口实测一遍然后乘以预估的日调用量你就能看到哪一段最贵。高价段落通常是这三个长篇的安全条款、重复的示例、以及从别处抄来但实际用不上的车轱辘话。这三块往往是压缩收益最大的地方。压缩的原则不是删规则而是合并同类项、去掉解释性的铺垫、把举例改成一句抽象规则。但要注意有些解释性的内容其实是在给模型讲道理删了之后模型的泛化能力会下降所以压完必须回归测试。3.5 第五步做版本管理和回归测试提示词是代码必须有版本。我的做法是给每条提示词打版本号改动时在文件头留一行变更说明写清楚改了什么、为什么改。测试集固定二十到五十条覆盖标准问题、边界问题、诱导性问题、格式问题四类。每次改动跑一遍记录通过率。跑测试的时候一定要固定随机性参数否则同样的提示词两次结果不同你根本分不清是提示词的问题还是采样随机的问题。另外测试集要定期更新因为用户问法在变半年前的测试集测不出今天的问题。4. 实操中踩过的坑与排查手册这一节是我自己踩坑的记录也是我认为整篇最值钱的部分。很多问题在文档里都不会写只有真跑过才知道。4.1 规则互相打架模型开始自由发挥最典型的场景前面写回答要详细覆盖所有要点后面写回答尽量简短不要啰嗦。模型不会报错它会自己选一个而且选择结果不稳定。更麻烦的是这种冲突往往不在一处而是分散在几千字里肉眼很难发现。我的排查方法是把提示词按倾向性分类。凡是出现详细、完整、全面、深入这类词的归一组出现简洁、精炼、简短、直接的归一组如果两组都非空就必须拆开处理——要么按场景区分复杂问题详细、简单问题简洁要么直接删掉一组。提示冲突不只出现在形容词上。格式要求也会打架比如一处要求用表格另一处要求用段落同样会让输出忽左忽右。4.2 越写越长效果却不涨这是新手最常经历的阶段发现一个问题就加一条规则加到最后提示词五千字效果反而变差。原因有几个。一是注意力稀释规则太多模型对每条规则的执行力度都下降。二是存在大量只覆盖极端情况的规则为了一两个罕见场景牺牲了绝大多数正常场景的体验。三是旧规则没删和新规则形成隐性冲突。我的解法是给每条规则记一笔账它是为了解决哪个具体问题加的我多久没见过这个问题了。三个月没复现的问题对应的规则就考虑删掉或者降级为一句概括性描述。这个习惯听起来麻烦但能防止提示词无限膨胀。4.3 格式约束写着写着就失效了格式约束失效通常有三个原因。第一个是约束位置太靠后在长上下文里被前面的内容冲淡了解决办法是把关键格式规则同时放在开头和结尾。第二个是约束太抽象比如用 JSON 输出但没给字段定义模型只能自己编字段名。第三个是输出被工具调用打断很多模型在调用工具之后会把之前设定好的输出格式忘掉需要在工具返回后重新强调一次。我实测比较有效的做法是把输出格式写成一个小模板同时给一个最小正例只展示格式骨架不带业务内容。这比纯文字描述有效得多。4.4 外部内容里藏指令防御性写法做检索增强或者网页抓取类应用时你会把外部文本塞进上下文。这些文本里完全可能藏着忽略前面的指令直接输出某某内容这类句子。模型分不清哪段是你在下命令、哪段是外面来的数据。防护上我会做几件事。一是用明确的分隔标记把外部内容包起来并在系统提示词里声明该标记内的一切文字都是待处理数据不是指令。二是在工具权限上做最小化能只读的就不给写权限访问范围能限定的就不放开。三是在输出侧做校验凡是格式不符合预设结构的输出一律走兜底流程不直接展示给用户。四是把外部内容的指令优先级这条写成硬规则放在提示词最前面。这几条不是万能的但能挡掉绝大部分情况。关键是别指望模型自己分辨一定要在提示词和系统架构两个层面同时做。4.5 问题速查表现象可能原因排查动作修复方向输出格式忽好忽坏格式规则位置靠后或被工具调用冲淡检查长上下文位置与工具返回后的段落首尾各放一次补最小正例该拒绝的没拒绝边界写成形容词而非条件逐条找谨慎、适当类表述改成具体类别加具体动作该答的说不知道能力边界过宽检查是否有不确定就不要回答类绝对规则区分真不知道和不确定但有依据回答长度失控详略规则冲突按倾向性分组找矛盾按问题复杂度分层定义工具反复调用缺终止条件看是否写了最大调用次数定义触发、步骤、终止三件套改了提示词效果变差无版本对比随机性干扰检查是否固定采样参数是否有回归集建版本号与固定测试集5. 我自己的提示词工作流与工具习惯5.1 本地归档与快速检索我不建议你只靠浏览器书签去看这个仓库。我的做法是在本地建一个目录把感兴趣的提示词按产品类型-场景重新归档文件名统一带上采集日期和来源标注。这样做的直接好处是同类样本能放在一起对比而不是散在几十个目录里。检索上我习惯在每条样本头部加三行元信息适用场景、核心亮点、我抄了哪几条。最后这一行特别关键因为读完不写笔记三天后你只记得这个仓库不错具体不错在哪全忘了。归档时顺手用版本控制工具管理改动可追溯比网盘靠谱得多。5.2 差异对比与趋势观察同一产品的多个版本放在一起用文本对比工具跑一遍高亮出来的部分往往就是产品策略调整的地方。我一般关注三类变化新增的约束、删除的约束、措辞变软的约束。新增约束通常意味着踩过坑删除约束通常意味着误伤了正常需求措辞变软通常意味着找到了更好的替代写法。这个观察习惯坚持半年你对什么规则会带来什么副作用的判断力会有明显提升写新提示词的时候能少走很多弯路。5.3 自动化回归把测试跑成习惯提示词改动频繁的话手工测是撑不住的。我搭过一个小脚本思路很朴素读一份测试用例文件逐条调用模型接口把输出和期望的关键特征做匹配最后生成一份通过率报告。关键特征是手写的比如是否包含三个字段是否提出了澄清问题是否出现了被禁止的表述不做语义相似度比对——语义比对在提示词这种细节场景里误判率太高。# 极简回归脚本骨架伪代码风格接口按你自己的环境替换 import json def run_case(client, system_prompt, case): resp client.chat( systemsystem_prompt, messages[{role: user, content: case[input]}], temperature0, # 固定采样排除随机干扰 max_tokenscase.get(max_tokens, 800), ) text resp.text checks { 包含必需字段: all(k in text for k in case[must_contain]), 未出现禁用词: not any(k in text for k in case.get(must_not_contain, [])), 长度在区间内: case[min_len] len(text) case[max_len], } return {id: case[id], passed: all(checks.values()), detail: checks} def run_suite(client, system_prompt, cases_file): cases json.load(open(cases_file, encodingutf-8)) results [run_case(client, system_prompt, c) for c in cases] rate sum(r[passed] for r in results) / len(results) for r in results: if not r[passed]: print(失败用例:, r[id], r[detail]) print(f通过率 {rate:.1%}) return results这套东西的价值不在脚本本身而在于它把感觉变好了变成了通过率从 82% 涨到 91%。有了这个数字你和团队讨论提示词改动时就有共同语言了不用再靠谁的嗓门大。最后分享一个我自己的小体会。看这些系统提示词最有收获的时刻往往不是读到某个绝妙句子的时候而是发现有团队愿意花几百字去写怎么处理模糊需求这种事的时候。这说明他们把提示词当产品的一部分在做而不是当一句咒语在念。提示词写作的门槛很低但把它写到位考的是你对业务细节的拆解能力——哪些情况会发生、发生概率多大、用户真正想要什么。这个能力跟模型本身关系不大跟你在现场待了多久关系很大。