1. 这个仓库为什么会在圈子里被反复提起第一次看到system_prompts_leaks这个名字很多人会本能地往机密文件那个方向想。其实它的本质更朴素一个把各家 AI 产品的系统提示词system prompts收集、整理、归类、对比的开源资料库。系统提示词就是模型在见到你第一句话之前就已经读到的那段前置说明书——它规定了模型是谁、能做什么、不能做什么、用什么语气回答、输出格式长什么样。而leaks在这里更像一种江湖说法指的是这些内容通过各种公开交互被外界观察到、被整理出来、被归档成可检索的文本。这个项目的读者画像其实很清晰。一类是做 AI 应用的产品和研发想知道头部产品在提示词层面到底做了哪些约束好对齐自己的预期一类是做提示工程prompt engineering的同学把真实的系统提示词当成教材逆向拆解写法还有一类是安全与合规方向的研究者关注系统提示词里暴露出的边界设计思路。如果你是刚接触大模型的新手这个仓库同样有价值——它比任何提示词模板合集都真实因为它记录的是真正在线上跑着的配置。我接触这类仓库有几年了一个很直观的感受是它的价值不在内容本身有多神秘而在于它把碎片化的观察沉淀成了结构化的资料。没有结构化你今天看到一段提示词截图明天就忘了有了目录、索引、版本记录你才能在半年后回头对比某个产品改了哪些约束。这篇就围绕这个仓库把我自己在类似项目上的设计思路、采集方法、整理技巧、踩过的坑一次性讲透你可以直接照着搭一套自己的版本。1.1 系统提示词到底是一份什么文件先把概念钉死不然后面全是空谈。在大多数对话式 AI 产品的调用链里一次请求大致长这样系统提示词 历史对话 用户当前输入三者拼成一个大字符串交给模型生成回复。系统提示词通常由产品方写死用户看不到也不该被修改。它的内容一般包含四块身份设定你是一个某某助手、能力边界你无法访问实时数据、行为规范拒绝回答某类请求、输出格式用 Markdown列表不超过五项。高级一点的还会塞进工具调用说明、检索结果引用规范、多语言策略等。理解了这一点你就能明白为什么这类仓库值得整理系统提示词是产品意图最直接的表达。一个产品的定位、商业化方向、风险控制偏好往往能在这几百到几千字里看出端倪。比如有的产品会写大量篇幅强调简洁回答说明它把响应成本当核心指标有的会花很多字描述如何引用来源说明它的检索链路是重点。这些判断比看产品官网的营销文案靠谱得多。从工程角度说系统提示词还决定了模型的性格稳定性。同样一个底层模型换一段系统提示词输出风格可以完全变样——一个啰嗦一个精炼一个保守一个开放。所以做 AI 应用的人本质上就是在做系统提示词的不断微调。去看别人怎么写是最省时间的成长路径。1.2 收集类仓库的三类价值我把它拆成三类方便你判断自己需不需要花时间进去。第一类是学习价值。真实的系统提示词里能看到很多教科书不写的写法怎么用少量字符约束输出长度怎么把工具描述写得让模型不容易误调用怎么在拒绝请求的同时保持语气友好。这些细节单看一句话没什么连起来看就是一套工程经验。第二类是对比价值。同一个模型厂商不同时期、不同入口网页版、移动端、开发者 API的系统提示词往往有差异。把版本排成时间线你能看出约束是变严了还是变松了哪些能力被开放了哪些话术被删掉了。这种纵向对比是做竞品分析时很难从外部拿到的材料。第三类是风险参考价值。系统提示词里那些不要做某件事的条款其实是产品方踩过坑之后留下的补丁。你如果正在做类似产品可以顺着这些条款反推它遇到过什么问题提前在自己的设计里规避。注意这类资料库的整理工作前提是内容来自公开可观察的渠道整理目的是学习和工程参考。任何绕过产品访问控制、批量抓取私有接口的做法都不在讨论范围内也不建议尝试。2. 仓库结构怎么设计才不至于三个月就烂掉我见过太多类似的收集仓库第一周热火朝天第三个月就没人维护了。原因几乎都一样一开始没有定结构东西全堆在一个目录里越堆越乱最后自己都找不到。所以如果你真要做这件事先花半天时间把结构想清楚比急着往里塞内容重要得多。2.1 元数据字段先定表头再填内容我的建议是每一条提示词记录都用一个独立的文件承载正文再用结构化的元数据描述它。不要图省事把说明写进正文注释里那样后期根本没法批量处理。元数据字段我一般会定这几个产品名、入口网页/移动端/API 等、模型版本、采集日期、来源类型公开文档/交互观察/第三方整理、可信度等级、内容摘要。下面是我实际用的一份元数据模板用 JSON 存跟正文放同一个目录{ id: product-a-web-2024-11, product: 产品A, surface: web, model_family: 通用对话模型, collected_at: 2024-11-15, source_type: interaction_observation, confidence: B, language: zh, summary: 侧重简洁回答与来源引用含工具调用约束段落, changed_from: product-a-web-2024-08 }这里有个细节值得说confidence字段是整套体系的灵魂。因为这类资料的可信度天然参差有的是官方公开文档里直接写出来的有的是通过多轮交互推断出来的。不做分级读者就不知道哪条能信、哪条只能当参考。我用的分级是 A/B/C 三档具体含义在 3.3 节展开。2.2 目录分层按厂商还是按能力目录怎么切是个典型的两难。按厂商切找起来直观按能力切做横向对比方便。我的做法是主目录按厂商索引按能力两套并存。主目录负责存放索引文件负责检索。这样做的好处是文件归属唯一不会出现同一段提示词在两个目录里各放一份、改了一处忘了另一处的情况。具体长这样repo/ prompts/ product-a/ web-2024-08.md web-2024-11.md mobile-2024-10.md product-b/ api-2024-09.md meta/ product-a/ web-2024-08.json web-2024-11.json index/ by_capability.md by_timeline.md by_product.md tools/ build_index.py diff_prompt.pyby_capability.md是人工维护的一层映射比如把输出格式约束工具调用规范安全边界表述这些主题各自挂上对应的文件路径。它不需要很精确起到导航作用就够了。我试过纯靠脚本自动分类效果一般——因为它判断不了这段约束的真实意图是什么那部分只能靠人。2.3 版本管理把提示词当代码对待这一点我要重点强调因为它是决定仓库能不能长期活下来的关键。提示词的每一次变化都应该是一次可追溯的提交。具体做法是一个产品的一个入口一个文件新版本不覆盖旧版本而是新增带日期的文件同时用changed_from字段串起时间线。这样你随时能跑一次差异对比看某个产品半年里改了什么。为什么不直接覆盖因为覆盖之后就丢了历史。而这类资料的价值一半在现在是什么样另一半在以前是什么样、为什么变。我做类似项目时最喜欢的一件事就是每隔一段时间把同一个产品的两个版本调出来做 diff经常能发现一些有意思的变化——比如某个约束从硬性条款变成了软性建议某个能力描述被删掉了。这些变化背后往往对应着产品的实际调整。提示如果正文里有大段重复的样板文字不要为了保持原样就整段照抄可以在自己的记录里标注此处为重复模板段落略既保留信息又控制仓库体积。3. 内容从哪来采集、还原与可信度分级这一节讲方法。我要提前说明立场一切以公开可观察、不破坏产品访问控制为前提。在这个前提下资料的来源其实比想象的多关键是别只盯着一个渠道。3.1 公开优先原则永远先找官方公开的东西。很多产品会在帮助文档、开发者文档、透明度报告里主动说明自己的行为准则和回答策略这些是最硬的来源。此外还有公开的技术博客、发布会材料、官方示例工程里的配置片段。这些内容虽然不一定是完整系统提示词但属于 A 级来源——可以放心引用。我一般会先建一个官方来源清单把每个产品的公开文档链接和关键摘录列出来作为整个仓库的基准层。之后的交互观察内容都要跟这一层做比对看看有没有矛盾。这样能过滤掉相当一部分不可靠的网传版本。3.2 交互式还原的通用套路剩下那部分只能靠与模型的交互来观察。这里说的不是任何绕过限制的手段而是一种常规的研究思路通过精心设计的提问观察模型在边界上的反应反推它的行为约束。比如你想知道某个产品是否被要求回答简洁不需要它把提示词念出来只要连续问几个开放式问题观察回答长度分布就够。想知道它是否有来源引用规范就问几个事实类问题看它怎么给依据。在整理上我习惯用行为反推表来记录每一行是一个观察点观察维度提问方式观察什么推断结论输出长度偏好提一个宽泛问题回答字数、分段数量是否有篇幅约束身份设定询问自我定位自称方式、能力描述角色与人设段落工具使用问需要实时信息的问题是否说明无法获取工具调用描述拒答边界提边缘性请求拒答话术、是否给替代方案安全段落写法格式规范要求列清单是否自动用表格或列表格式约束存在与否这张表的好处是把猜变成有记录的推。多个观察点交叉之后你能比较有把握地还原出提示词的骨架而不需要任何非常规手段。我实测下来五到八个观察点就足以判断一个产品的大致风格取向。注意这套方法只用于理解行为模式不用于获取任何私有配置。观察结论要标注来源类型和置信度别把推断当成事实写进仓库。3.3 三方交叉验证与可信度打分单来源的内容一律不进主目录这是我的铁律。验证方式是三方交叉官方公开来源、交互观察记录、第三方公开整理。三者能对上的部分可信度打 A两者能对上的打 B只有单一来源的打 C并且单独放在一个draft/目录里不进索引。为什么要这么严格因为这类资料最大的坑就是以讹传讹。一段被改了几个字的某产品系统提示词传了几手之后看起来像模像样实际上早就失真了。我见过不少号称是完整原文的版本前后风格不一中间还夹着明显的其他产品特有措辞基本可以判定是拼凑的。有了分级机制读者一眼就能知道该信几成。另外可信度不是一次定终身。后续如果有了新的官方来源印证可以把 C 升到 B把 B 升到 A变更也记录在元数据的提交历史里。这个过程本身就是仓库可信度积累的过程。4. 读这些提示词能学到什么收集只是手段从里面提炼出可复用的写法才是目的。我翻过不少这类资料之后总结出一套读法不要逐字读而是按结构块读。把每份提示词切成几个功能段落横向对比不同产品在同一段落上怎么处理效率会高很多。4.1 通用骨架拆解绝大多数线上系统提示词都可以拆成下面这几个块。你可以把它当作阅读框架角色块定义身份、定位、语气。这一块决定了模型像谁说话。能力块说明能做什么、不能做什么、知识截止、是否联网。约束块禁止行为清单通常是最用力写的部分。格式块输出结构要求Markdown、列表项数、字数上限。工具块可调用的工具说明、调用条件、失败处理。兜底块遇到不确定、被追问、被要求做超范围事情时怎么办。按这个框架去读你会发现很多之前觉得神秘的内容其实很有规律。比如大部分产品的角色块都写得很短两三句话而约束块往往占最大篇幅。这说明系统提示词的工程重心在防守而不是塑造——把不想发生的事情挡住比把想发生的风格描述清楚更重要。4.2 常见写法对照表我在整理过程中做过一份写法对照摘几个典型的维度给你看写法维度保守写法开放写法适用场景角色定义一句话身份不展开详细人设、语气、价值观面向 C 端的陪伴类产品拒答方式直接说明无法回答说明原因并给替代方向服务类产品输出长度硬性字数上限建议性描述成本敏感型产品工具调用调用前必须确认自主判断自主调用效率工具类产品不确定性处理明确承认不知道给出置信度与来源知识问答类产品这张表我平时用来做设计参考先确定自己产品的定位再从对应列里挑写法。它不能保证你一定写得好但至少能让你避开和不合适的产品抄了不合适的风格这种低级错误。4.3 把别人的写法变成自己的模板看到好写法就抄是新手最常见的问题。抄来的段落往往和自己的产品逻辑不匹配拼在一起像穿了不合身的衣服。我的做法是抄模式不抄句子看到一个好的拒答结构就把它抽象成先表明能力边界再给可行替代最后保持礼貌然后用自己产品的语言重新写一遍。举个具体例子。当用户询问我无法完成的事情时我应该说明原因并提供替代方案——这句话本身太笼统。我实际落地时会写成三段式第一句明确说明当前无法做什么第二句给出一个真的能用的替代路径第三句用一句话收尾不留悬念。这样写出来模型执行起来更稳因为每一步都有明确动作而不是抽象要求。我个人的经验是每读十份系统提示词能提炼出两三条真正能用在自己项目里的模式就已经很值了。指望全部照搬是不现实的因为每份提示词都是为特定产品、特定模型、特定场景量身定做的。5. 实操搭一个能用的本地检索与对比环境光有文件不行得能查、能比。这一节给两个能直接跑的脚本思路都是我实际用过、改动不大的版本。5.1 目录与索引脚本先写一个扫描脚本把所有元数据读进来生成按产品、按时间、按能力的三张索引表。核心逻辑很简单遍历meta/下的 JSON按字段分组输出成 Markdown 表格。import json from pathlib import Path ROOT Path(.) META_DIR ROOT / meta INDEX_DIR ROOT / index INDEX_DIR.mkdir(exist_okTrue) records [] for path in META_DIR.rglob(*.json): with path.open(encodingutf-8) as f: data json.load(f) data[_path] str(path) records.append(data) def render(rows, title, out): lines [f# {title}, , | ID | 产品 | 入口 | 采集日期 | 可信度 |, |---|---|---|---|---|] for r in rows: lines.append( f| {r[id]} | {r[product]} | {r[surface]} | f{r[collected_at]} | {r[confidence]} | ) out.write_text(\n.join(lines), encodingutf-8) render(sorted(records, keylambda x: x[collected_at]), 按时间排序, INDEX_DIR / by_timeline.md) render(sorted(records, keylambda x: x[product]), 按产品排序, INDEX_DIR / by_product.md)这个脚本跑一次几秒钟但省掉的是每次手动翻目录的时间。我建议把它挂到提交钩子里每次增删文件自动重建索引就不会出现索引和实际文件对不上的问题。5.2 全文检索与差异对比第二个是差异脚本。这是我觉得最有价值的一个工具因为它能把某产品改了约束这件事直接暴露出来。用 Python 标准库的difflib就够了不需要额外依赖。import difflib from pathlib import Path def diff(old_file, new_file): old Path(old_file).read_text(encodingutf-8).splitlines() new Path(new_file).read_text(encodingutf-8).splitlines() for line in difflib.unified_diff(old, new, lineterm, n1): if line.startswith((, -)) and not line.startswith((, ---)): print(line) if __name__ __main__: import sys diff(sys.argv[1], sys.argv[2])用起来就是一行命令python tools/diff_prompt.py prompts/product-a/web-2024-08.md prompts/product-a/web-2024-11.md输出里的加号和减号直接对应新增了什么约束和删掉了什么话术。我在做竞品跟踪时每周跑一次积累下来的变化记录比任何二手分析文章都准确。这里有个使用心得对比之前先做一次规范化处理把空格、全角半角、换行符统一否则你会被一堆无意义的格式差异淹没真正的语义变化反而看不出来。6. 常见问题与排查实录做这类项目问题基本都集中在资料质量和维护成本上。我把踩过的坑整理成一张速查表遇到问题可以先在这找。6.1 问题速查表现象可能原因处理方式同一产品出现多个互相矛盾版本来源混杂未做验证全部降级到 draft重新交叉验证索引链接打不开文件重命名未同步索引重建索引检查命名规范内容明显是拼凑的二手转载失真标 C 级并注明疑似拼凑仓库体积膨胀过快大量重复样板段抽出公共模板正文只存差异半年后看不懂某条记录元数据缺摘要字段补 summary并把摘要设为必填无法判断改动的影响缺少版本时间线用 changed_from 串链配 diff 脚本6.2 几个容易踩的坑第一个坑是追求完整原文。新手总觉得只有一字不差的全文才有价值结果为了凑完整度把推断内容当事实写进去。我的经验是宁可交一份标注清楚的 70% 版本也不要一份真假混杂的 100% 版本。后者对读者的误导比前者大得多。第二个坑是只收集不整理。文件堆了几百个但没有任何索引和摘要用的时候还是得一个个打开看。这种情况下仓库的实际使用率会非常低。我建议每新增一条记录强制自己写一句summary二十个字以内。这个动作只要十秒钟但它决定了半年后你还能不能用这个仓库。第三个坑是忽略时效性。这类内容变化很快一条记录如果不标采集日期一年后你根本不知道它对应哪个时期。所以collected_at字段是必填的而且我建议在按时间排序的索引里把超过一定时长未更新的记录标一个待复核标记提醒自己回头确认。第四个坑也是我认为最容易被忽略的把观察结论当成绝对事实。模型在不同会话、不同上下文下的表现本来就有波动你观察到的一次行为可能只是随机性。所以我一般在做行为反推时同一个观察点至少重复五次取稳定的模式而不是拿单次结果下结论。这一点看起来啰嗦但它是整个方法可信度的基础。第五个坑是把仓库当成终点。收集来的内容放在那里不会自动产生价值真正有价值的是你从里面提炼出的模式、写进自己项目的约束、避开的那些坑。我的习惯是每整理完一批就写一段自己的总结笔记记录这次学到了什么、准备怎么改自己的设计。这些笔记往往比原始资料更有用。7. 后续可以往下延伸的方向如果你已经把基础框架搭起来了可以往几个方向继续走。一个是做纵向趋势分析。把手里的记录按时间轴铺开看约束条款的整体演变方向。比如是不是越来越多的产品开始强调来源引用是不是拒答话术在变得更柔和。这类趋势判断对做产品规划的人很有参考价值。另一个是做跨产品同能力对比。挑一个具体能力点比如如何处理用户要求格式输出把所有产品的相关段落抽出来并排放。这种对比能让你很快看出行业内的主流做法和少数派的差异化选择对你做技术选型很直接。还有一个方向是把整理成果反向用于自己的提示词质量检查。我给自己定了一套检查清单每次写完系统提示词就拿这份清单过一遍角色块是不是太抽象了、约束块有没有互相矛盾、工具描述有没有说清调用条件、兜底话术会不会太生硬。这份清单里的大部分条目灵感都来自整理别人的提示词时看到的写法。这是一个挺正向的循环读别人的改自己的再把自己的经验补回去。最后分享一个小技巧。整理这类资料时别一开始就想着做全。选三个你最熟悉的产品把这三家的记录做到结构完整、来源清晰、版本可追溯就已经是一个能拿得出手的仓库了。等这套流程跑顺了再逐步扩展。我见过不少项目死在想一口气做完上而稳定迭代的那批往往是从很小的范围开始慢慢长起来的。
