system_prompts_leaks：官方提示词归档的价值与风险

它记录的是一种正在消失的工程中间态

做 prompt 工程的人，迟早会撞上一堵墙：官方模型的 system prompt 大多不公开。

厂商把系统提示词看作产品的一部分，里面藏着产品逻辑、安全策略、输出偏好，甚至一些未公开的能力开关。

开发者只能从模型的输出反推它被设定了什么。

这个仓库做的事情，是把散落在各个渠道的 system prompt 原文收集、整理、归档，用 Python 做格式化，然后公开出来。

它覆盖的模型包括 Anthropic 的 Claude 系列、OpenAI 的 ChatGPT 和 Codex、Google 的 Gemini、xAI 的 Grok，还有 Cursor、Kimi 等。

仓库自述里写得很直接：Documented system prompts，定期更新。

这意味着它不是通过破解或逆向工程获取的，而是把已经出现在公开讨论、用户分享、或者产品界面里的系统提示词做了集中归档。

这个定位决定了它的价值边界：它提供的是"已知的"系统提示词，而不是"未知的"秘密。

对提示词工程，它解决了"参考系缺失"的问题

写 system prompt 最大的困难，不是不会写，而是没有高质量的参照物。

官方文档给的是 API 用法和参数说明，几乎不展示内部 system prompt 的完整结构。

开发者只能靠自己的经验和试错来摸索：安全声明放在哪里？输出格式怎么约束？工具调用的边界怎么描述？

这个仓库把多个主流模型的系统提示词放在一起，直接提供了横向对比的可能。

你可以看到 Claude 的 system prompt 如何组织角色设定，ChatGPT 的如何处理多轮对话中的记忆边界，Gemini 的如何声明自己的能力边界。

这些结构性的差异，比任何教程都更直观。

做过 agent 开发的人知道，一个 system prompt 里"不要做什么"的部分，往往比"要做什么"更重要。

这些负面约束的措辞方式，在官方提示词里通常写得非常精确。

直接参考这些原文，比自己凭空构造安全边界要可靠得多。

仓库用 Python 整理归档，说明它不只是把文本堆在一起。

格式化、去重、分类、版本跟踪，这些操作让原始文本变成了可以持续维护的结构化语料。

对需要批量分析提示词模式的研究者来说，这是一个比零散截图和转发可靠得多的数据源。

公开归档的代价：信息时效与真伪混杂

这个仓库最明显的局限，是它归档的 system prompt 并不一定是"当前生效"的版本。

模型厂商更新 system prompt 的频率很高，尤其是头部产品。

一次安全策略调整、一个功能开关的变更，都可能导致系统提示词发生实质性变化。

仓库自述里提到的具体版本号，比如 Claude Fable 5.1、Gemini 3.8 Flash，暗示它在尝试做版本区分。

但即便如此，开发者看到的仍然是一个时间切片，而不是实时同步的镜像。

拿一个过期的 system prompt 去调试自己的 agent，可能会得出错误的结论。

另一个更隐蔽的问题是来源的可靠性。

仓库本身无法验证每一条归档的 system prompt 是否真的是官方原文。

有些可能是用户自己整理后发布的版本，有些可能经过了二次编辑，有些甚至可能是故意伪造的。

在没有官方确认机制的情况下，这个仓库实际上是一个"高可信度但非权威"的语料集。

使用者需要自己判断：这条提示词的结构值得参考，但它未必就是模型此刻真正在用的那一份。

这个代价，是这个项目定位带来的必然结果——它选择了"收集公开信息"而不是"验证官方信息"。

同样的目标，别的方案怎么走

想获得官方 system prompt 的参考，其实还有几条不同的路径。

第一条是直接向厂商索要。部分企业级合作中，厂商会披露部分系统提示词逻辑，但这只对少数开发者开放，不具备普适性。

第二条是行为反推。通过大量测试模型的输出边界，推断它内部的安全策略和格式约束。

这种方式不需要任何泄露信息，但成本极高，而且只能得到模糊的行为模式，看不到精确的措辞结构。

第三条是社区散点收集。在各个论坛、社交媒体上，零散地出现用户分享的 system prompt 截图或文本。

但散点收集的问题是没有结构、难以检索、版本混乱，而且很快会被新的讨论淹没。

这个仓库做的事情，本质上是把第三条路径工业化——用 Python 脚本把散点信息变成结构化归档。

它没有厂商授权，也没有行为反推的严谨性，但在"快速获得可对比的参考系"这个目标上，它是最省力的方案。

代价就是前面说的：时效性靠社区维护，真伪靠使用者自己甄别。

边界与判断

这个仓库值得用，但只能当参考系，不能当事实源。

它的核心价值在于把多个模型的 system prompt 结构放在同一个平面上，让开发者可以横向对比"官方是怎么写的"。

对于正在搭建 agent 系统、需要快速建立提示词结构直觉的人来说，这是一个低成本的起点。

但如果你需要的是某个模型"此刻正在使用"的精确提示词，或者想用它来做严格的安全研究，这个仓库帮不了你。

信息滞后和来源混杂，是它无法靠自身机制解决的硬伤。

我的判断：在提示词工程的学习和结构参考场景下，它是有用且少见的公开资源；在需要精确性和权威性的场景下，它不适合作为唯一依据。

建议你把它当作一个"结构样本库"：学习它的组织方式、约束措辞、边界设定，但不要假设其中任何一条在你调用的模型上仍然生效。