system_prompts_leaks，一个公开归档 AI 系统提示词的 GitHub 仓库
如果你平时研究 AI 产品、Agent 设计，或者正在写自己的 system prompt，最近可以看一个开源资料仓库，system_prompts_leaks。它的仓库地址是，https://github.com/asgeirtj/system_prompts_leaks
这个项目由 asgeirtj 维护，开源协议是 CC0 1.0。也就是说，仓库采用公有领域 dedication 的方式发布。它不是一个可执行应用，也不是一个可以直接运行的 AI 工具，而是一个社区维护的资料归档仓库。
简单说，它做的事情只有一件，把主流大语言模型聊天机器人、AI 编程助手、Agent 产品中被公开提取出来的系统提示词，按厂商和产品整理成 Markdown 文件，放在 GitHub 上供研究者阅读。说实话，如果只是听别人讲 system prompt，很多概念会有点虚；直接看这些公开文本，反而更容易知道真实产品到底在约束什么。
这里的系统提示词，指的是用户正式开始对话之前，由服务端注入给模型的隐藏指令。它通常不会直接展示给普通用户，但会影响模型的角色设定、回答格式、工具调用方式、拒答边界、内容安全策略，以及多轮任务中的行为约束。
对很多人来说，system prompt 是一个有点抽象的词。看完这个仓库，你会更直观地看到，一个成熟 AI 产品背后，并不只是一个模型名称，还包括大量围绕模型行为设计的规则、工具说明和安全约束。
这个仓库收集了什么
截至 2026 年 6 月，system_prompts_leaks 的 README 中已经按厂商和产品整理了多个目录。其中包括 Anthropic 相关的 Claude 系列，例如 Claude Sonnet、Opus、Fable，以及 Claude Code、Claude Design 等产品提示词。也包括 OpenAI 相关内容，例如 ChatGPT 不同变体、Codex、GPT-4o、o1、o3 以及后续版本相关提示词。Google 目录中可以看到 Gemini Flash、Gemini Pro、Gemini CLI、NotebookLM 等相关内容。
xAI 目录中有 Grok 与 Grok 3+ 等产品线的提示词整理。Microsoft 与 GitHub 相关内容里，可以看到 Copilot、GitHub Copilot、VS Code Agent、macOS Agent 等不同形态的系统提示词。另外还有一个更广的 Misc 或其他产品区，收录 Cursor、Perplexity、Devin、Replit、Windsurf、Notion AI、Meta Llama、Mistral 等产品或模型相关资料。
这些文件通常以 md 形式存放。部分文件会标注模型版本、提取日期、来源说明或校验说明。仓库本身也接受社区通过 Pull Request 持续更新。有一说一，这个项目的重点不在「某个文件是否永远最新」，而在它把许多分散样本放到了同一个可比较的目录里。
什么是系统提示词
普通用户在聊天框里输入的内容，通常叫 user prompt。开发者在 API 中传入的上层指令，常被称为 system prompt 或 system message。大型 AI 产品上线以后，还会在服务端加入更多隐藏规则，用来控制模型如何回答、什么时候调用工具、什么时候拒绝、怎么处理敏感问题、怎么维持产品人格。
比如，一个 AI 编程助手不只是回答代码问题。它还可能被要求先阅读项目结构，避免覆盖用户改动，按特定格式给出计划，调用终端前先解释意图，遇到测试失败时先定位原因，再继续修复。
讲真，这些要求如果不写在系统层，模型很容易只把自己当成「会回答问题的人」，而不是一个要负责完成任务的工作流参与者。
再比如，一个通用聊天机器人不只是「友好回答」。它可能还有一整套关于医疗、法律、金融、儿童安全、版权内容、政治内容、隐私数据的处理规则。模型是否拒答、如何拒答、拒答后能不能给安全替代方案，都可能写在系统层指令里。
所以，系统提示词并不是简单的一句「你是一个有帮助的助手」。在真实产品中，它往往是一个复杂的行为配置层。
仓库是怎么组织的
从结构上看，system_prompts_leaks 更像一个资料馆，而不是一个软件项目。它没有常见应用项目里的安装步骤、运行依赖、构建脚本或部署说明。用户进入仓库后，主要操作就是打开目录、阅读 Markdown 文件、比较不同产品的提示词结构。
常见查看方式有两种。第一种是在线浏览。直接打开 GitHub 仓库，进入对应厂商目录，再打开具体模型或产品的 md 文件阅读。
第二种是本地克隆。可以先执行 git clone 后跟仓库地址，把项目拉到本地；再进入 system_prompts_leaks 目录；说到最后查看 Anthropic、OpenAI、Google 等厂商目录。
本地克隆以后，可以用编辑器全文搜索关键词，比如 tools、safety、refuse、format、policy、workspace、agent。这样更容易看出不同厂商在同类问题上的指令写法。不是我说，如果要做横向比较，本地搜索比一页一页点开 GitHub 更省时间。
如果只是浏览资料，在线 GitHub 页面已经足够。如果要做系统性对比，本地克隆会更方便。
对 Prompt Engineering 有什么参考价值
对 Prompt Engineering 学习者来说，这个仓库最大的价值，是可以直接看到成熟 AI 产品如何组织 system prompt。
很多人写提示词时，会停留在「你是一个资深专家」「请一步一步思考」「输出要清晰」这类泛化表达。但在真实产品里，提示词通常会更具体，它会定义角色边界、任务步骤、禁止事项、工具调用条件、输出格式，以及遇到异常时的处理方式。
你想啊，一个产品每天面对成千上万种输入，靠一句泛泛的角色设定，很难稳定覆盖所有边界。
例如，AI 编程助手的提示词往往会强调工程边界，不要改无关代码，不要覆盖用户改动，优先读取上下文，验证后再声称完成。聊天机器人类产品则更常见内容安全、语气、人设、对话边界等规则。
对照这些材料，可以学习三类写法。第一，如何把角色写清楚。不是只写「你是专家」，而是写明这个角色在什么场景下行动、有哪些权责、应该避免什么行为。
第二，如何把流程写清楚。成熟提示词往往不是一句要求，而是一套步骤和状态机。模型应该先做什么，什么时候停下来问用户，什么时候继续执行，什么时候返回证据，都有明确约束。
第三，如何把工具写清楚。Agent 类产品会详细描述工具的用途、限制、调用前提和返回结果解释方式。这个部分对自定义 Agent 开发尤其有参考意义。
对 AI 安全研究有什么参考价值
对 AI 安全研究者来说，这个仓库可以用来观察不同厂商如何设计安全护栏。系统提示词里经常能看到拒答规则、敏感内容分级、危险请求识别、隐私信息处理、版权内容限制、未成年人保护，以及高风险场景下的回答边界。
这些内容不一定代表厂商完整安全体系。真实线上系统通常还包括模型训练、分类器、后处理、服务端策略、权限系统和人工审核等多层机制。但系统提示词仍然是一个可观察窗口。
通过横向比较，可以看到不同厂商的侧重点。我发现，越是复杂的 AI 产品，越会把「能做什么」和「不能做什么」同时写清楚。
有的提示词更强调「什么不能做」，有的更强调「拒绝后提供什么替代帮助」。有的把安全规则写成大段政策，有的把它拆成任务流程、工具权限和输出约束。有的对医疗、法律、金融等高风险领域单独列出规则，有的把它们归入更通用的风险框架。
这些差异对研究提示注入、防越狱、防泄露、防工具滥用都有帮助。
对开发者有什么参考价值
如果你正在做自己的 Agent，system_prompts_leaks 也可以作为系统提示词设计参考。开发者可以重点看三块。第一，看角色设定。比如一个编程助手如何定义自己和用户的关系，什么时候应该自主执行，什么时候应该先解释，什么时候应该停止。
第二，看输出格式。很多成熟产品会对列表、代码块、引用、警告、最终回答做格式约束。这些约束能让模型输出更稳定，也方便前端或后端继续处理。
第三，看工具描述。Agent 最容易出问题的地方，不是模型不会说话，而是工具调用边界不清楚。系统提示词里如何描述文件读写、终端命令、浏览器、搜索、代码编辑、任务计划，是值得开发者专门对照学习的部分。
不过，这里也要说清楚，参考不等于照搬。不同产品的提示词服务于不同模型、不同工具系统、不同安全策略。直接整体复制到自己的商业产品里，既可能不适配，也可能涉及厂商专有内容和用户协议风险。讲道理，真正值得学的是结构和边界，不是把别人家的长提示词原样搬过来。
更合理的方式，是学习结构，不复制原文；学习约束方法，不搬运整套规则。
使用时需要注意什么
这个仓库的内容主要通过提示注入、模型输出诱导、公开服务交互等方式提取。仓库本身不提供提取工具，也不等于鼓励用户去绕过服务规则。
由于 AI 产品更新很快，仓库中的提示词可能滞后于线上版本。即使文件标注了日期，也只能说明当时被提取或提交的版本，不一定代表今天产品正在使用的最新版本。
部分提示词可能经过脱敏、整理或社区校验。不同贡献者提交的内容，也可能存在格式差异和完整性差异。研究时最好把它当作公开资料样本，而不是厂商官方文档。
另外，一些 AI 服务商的用户协议中，可能明确禁止试图提取、逆向工程或公开系统提示词。阅读公开仓库是一回事，主动对线上产品做提取尝试是另一回事。涉及账号、服务条款和商业环境时，最好先确认边界。
如果只是学习 Prompt Engineering、比较不同 Agent 设计、做安全分析，这个仓库可以作为资料入口。如果要用于产品实践，建议只抽象出结构化方法，再结合自己的业务、工具和合规要求重新设计。好家伙，这一点看起来像老生常谈，但对商业产品来说确实是底线。
说到最后放一个客观结论
system_prompts_leaks 的定位很明确，它是一个公开归档资料库，不是 AI 工具，也不是模型评测榜单。它适合三类人看。Prompt Engineering 学习者，可以用它理解成熟产品如何写系统层约束。AI 安全研究者，可以用它观察不同厂商的安全边界和拒答策略。
开发者，可以用它参考 Agent 角色设定、输出规范和工具调用说明。
如果你想快速理解「系统提示词到底长什么样」，这个仓库比很多抽象教程更直观。因为它展示的不是概念，而是一批真实产品曾经使用或被提取出的提示词文本。你说是不是，很多时候理解一个东西，最直接的方法就是看它在真实产品里的样子。
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～ 谢谢你看我的文章，我们，下次再见。
作者：剑飞，本文共4300字
资料来源，GitHub 仓库 https://github.com/asgeirtj/system_prompts_leaks