How asgeirtj/system_prompts_leaks Works

研究员对比分析AI模型指令集

一位AI研究员，为了深入理解不同AI模型在处理相似任务（例如，使用工具进行网络搜索）时的内在行为差异，利用本知识库进行对比分析。他通过浏览清晰的供应商分类，快速定位到目标模型的系统提示文件。通过直接阅读和比较这些通常不公开的指令文本，他能够洞察各个模型在安全策略、工具调用协议、输出风格控制等方面的设计哲学和实现细节，从而获得仅通过API调用无法得到的深度认知。

1. 根据供应商名称浏览并进入对应文件夹
2. 根据文件名中的模型、功能等信息定位目标提示词文件
3. 阅读提示词内容，理解其行为约束、工具规格和安全规则
4. 在不同供应商的提示词之间进行交叉对比，提炼设计模式和差异点

社区成员贡献新发现的提示词

一位社区成员在网络上发现了一个新的或更新过的AI系统提示。为了分享给更多人，他选择将这个发现贡献到本知识库。他通过一个简单的、开发者都非常熟悉的工作流——创建拉取请求（Pull Request），来提交他的新文件。仓库的维护者会收到通知并对内容进行人工审核。一旦审核通过，这个新的知识点就会被合并到主干，成为整个社区共享的财富。这个流程是驱动知识库持续增长和保持新鲜度的核心机制。

1. 将新提示词文件放置在正确的供应商文件夹下
2. 通过GitHub创建一个拉取请求（Pull Request）以提交贡献
3. 等待仓库维护者进行人工审查和合并操作

提示词收集与策展平台

该模块为整个提示词集合提供了基础架构和管理框架。其核心设计思路是，通过一个极其简单的、基于供应商的目录结构和纯手动的拉取请求（Pull Request）工作流，来最大化地降低社区贡献门槛。这种设计优先考虑了参与的便捷性而非流程的自动化，使得项目能够快速冷启动并依靠社区力量进行内容扩充。

• 基于供应商的分类法 — 【设计策略】采用一种基于AI供应商的实体文件夹分类法来组织所有提示词文件，为用户提供一个直观且无需学习的浏览体验。 【业务逻辑】 - Step 1: 将所有提示词按其来源供应商（如Anthropic, OpenAI, Google等）归类到对应的顶层文件夹中。 - Step 2: 用户只需根据自己感兴趣的公司名称进入相应文件夹，即可查看该公司的所有相关提示词。 - Step 3: 这种扁平化的结构使用户能轻松地在不同供应商之间切换，直接进行文件级的并排比较，而无需在复杂的多级目录中导航。 【权衡】好处是结构简单，符合用户心智模型；代价是当单个供应商的提示词数量激增时，文件夹内文件列表会变得冗长，查找效率降低。
• 社区贡献工作流（人工审核） — 【用户价值】为社区成员提供一个无障碍的渠道来贡献他们发现的新提示词，而无需申请特殊权限或经过复杂的自动化流程。 【设计策略】完全依赖GitHub内置的拉取请求（Pull Request）机制作为内容提交和审核的唯一通道。 【业务逻辑】 - Step 1: 贡献者在自己的分支（Fork）中创建或修改提示词文件。 - Step 2: 贡献者将修改提交一个拉取请求到主仓库。 - Step 3: 仓库维护者会收到通知，并手动审查提交的内容是否相关、格式是否基本正确以及是否是重复内容。 - Step 4: 审查通过后，维护者手动合并该请求，新内容即对所有用户可见。 【权衡】这种纯手动模式的好处是零开发成本，且流程对开发者社区极为熟悉。缺点是审核效率完全依赖维护者，缺乏自动化的命名规范、格式校验或内容去重，可能导致知识库质量随规模增长而下降。
• 文件命名与组织约定 — 【设计策略】通过在文件名中嵌入元信息，让用户在打开文件前就能对提示词的核心属性有一个基本判断。 【业务逻辑】 - 尽管没有强制规定，但社区在实践中形成了一套约定俗成的文件命名规则，主要包含以下几类信息： - **模型名称与版本**: 如 `gpt-5.1.md`, `claude-4.5` - **产品或功能名称**: 如 `chatgpt`, `claude-code`, `tool-deep-research` - **人格或风格**: 如 `-nerdy`, `-cynic`, `-professional` (常见于OpenAI) - **发布日期**: 如 `2026-02-04-GPT-4o...` - 这种命名方式充当了一种轻量级的标签系统，辅助用户快速筛选和定位目标文件。

Anthropic (Claude) 提示词集合

此模块专门收录Anthropic公司Claude系列模型的系统提示。其显著特点是结构化和文档化的程度非常高，不仅提供了提示词本身，还通过详尽的说明文档（readme.md）解释了其设计哲学和组件构成，是理解复杂、多组件提示词系统的绝佳范例。

• 结构化的提示词架构（XML与Markdown） — 【设计策略】采用高度结构化的格式（如XML标签和详细的Markdown章节）来定义模型的行为、工具调用和约束条件，以确保指令的明确性和可解析性。 【业务逻辑】 - Anthropic的提示词经常使用类似XML的标签（如`<tools>`, `<style>`）来封装特定功能的指令，将不同职责的指令块清晰分离。 - 对于复杂的提示，会提供一个`readme.md`文件作为官方文档，详细解释每个指令组件（如引文说明、工具使用、用户偏好等）的作用和用法。 【权衡】好处是指令的确定性高，便于机器解析和维护。坏处是编写和阅读成本相对较高，不如纯自然语言灵活。

OpenAI (GPT) 提示词集合

此模块收录了OpenAI的GPT系列模型的系统提示。其特点是多样性和情境化，通过大量的变体来适应不同的产品形态和用户交互风格，展现了如何通过提示词微调来塑造AI的人格和能力边界。

• 模型与人格变体系统 — 【设计策略】通过为同一基础模型配备多个不同的系统提示，来生成具有不同人格、风格或能力侧重的AI变体。 【业务逻辑】 - 系统通过文件名的后缀来区分不同的人格变体，例如为 `gpt-5.1` 模型提供 `gpt-5.1-friendly.md` (友好型) 和 `gpt-5.1-professional.md` (专业型) 两种不同的系统提示。 - 这些提示词在核心能力指令之外，会包含大量关于语气、措辞和交互模式的描述，从而塑造出独特的AI“人格”。
• API 与 UI 提示词分离 — 【设计策略】为通过API调用的模型和直接面向用户的产品（如ChatGPT网站）提供不同的系统提示，以分别优化开发者体验和终端用户体验。 【业务逻辑】 - 在 `OpenAI/` 目录下，存在一个专门的 `API/` 子目录。 - `API/` 目录下的提示词通常更侧重于输出格式的确定性、指令的简洁性以及与工具的稳定集成。 - 主目录下的提示词（UI版本）则可能包含更多引导对话、维持人设和处理模糊输入的指令。

Google (Gemini) 提示词集合

收录Google的Gemini系列模型的系统提示。该集合最核心的设计特点是“面向交互表面（Surface-Specific）”，即为同一个模型在不同产品和应用场景下的使用，设计了不同的系统提示，体现了情境自适应的AI设计思想。

• 面向交互表面的情境化提示 — 【设计策略】认为AI的行为不仅取决于其基础模型，更取决于它在哪个产品界面（Surface）上与用户交互。因此，为不同界面定制专门的系统提示，以优化特定场景下的用户体验。 【业务逻辑】 - 系统为不同“交互表面”提供专属的提示词文件，例如： - **命令行 (CLI)**: `Gemini-cli system prompt.md`，可能更注重指令的精确执行和文本的简洁性。 - **Web应用**: `gemini-2.5-pro-webapp.md`，可能包含更多引导用户探索和进行多轮对话的指令。 - **笔记本环境**: `NotebookLM-chat.md`，可能优化了与代码和长文本分析相关的能力。 - **办公套件**: `gemini-workspace.md`，可能包含了调用日历、邮件等协同工具的特定指令。

其他供应商提示词集合

收录来自xAI (Grok), Perplexity, Proton等其他AI公司的系统提示。这些提示词展现了更多样化的应用场景，特别是在特定渠道（如浏览器、语音助手）和特定治理策略（如安全指令）上的设计思路。

• 面向特定渠道的提示设计 — 【设计策略】为不同用户交互渠道（如浏览器插件、语音助手）定制系统提示，以充分利用渠道特性并弥补其限制。 【业务逻辑】 - 系统包含为特定渠道设计的提示词，例如： - **浏览器助手**: `Perplexity/comet-browser-assistant.md`，其指令可能侧重于页面内容理解、信息摘要和网页导航。 - **语音助手**: `Perplexity/voice-assistant.md`，其指令可能更注重对话的简洁性、即时性和对口语化输入的容错性。

基于Git的零成本、可扩展知识策展架构

Problem: 如何构建和维护一个公开的、版本化的、支持社区协作的大型文档知识库，同时实现零服务器成本和免运维？传统的“数据库+Web应用”方案开发和维护成本高昂。

Solution: Step 1: 使用一个公开的Git仓库（托管于GitHub）作为整个系统的“数据库”与“后端”，利用Git的分布式特性实现数据备份和版本控制。 Step 2: 将简单的文件夹目录结构作为核心的“索引”机制，以供应商为分类依据，实现直观的数据组织。 Step 3: 采用Markdown作为标准内容格式，确保内容既人类可读，也具备一定的结构化，便于未来进行机器解析。 Step 4: 完全复用GitHub内置的拉取请求（Pull Request）功能作为内容贡献、审核和讨论的完整工作流，自带身份验证、版本追溯和评论系统。 核心价值：此方案将后端基础设施、版本控制、用户权限、协作流程等完全“外包”给GitHub，实现了近乎零成本的部署和运维，同时其工作流对目标用户（开发者、研究员）天然友好。

Technologies: Git, GitHub, Markdown

Boundaries & Risks: 该架构不适合复杂的结构化数据查询（如SQL）。内容搜索完全依赖GitHub平台的文本搜索能力。内容审核是手动过程，在贡献量激增时会成为效率瓶瓶颈。无法实现实时内容更新，所有变更都是异步的。

纯人工驱动的内容治理模式

Problem: 在一个社区驱动的内容项目中，如何在项目初期快速启动，并在不投入工程资源开发自动化工具（如持续集成、校验脚本）的前提下，对内容质量进行基本把控？

Solution: Step 1: 将内容质量的保证完全寄托于仓库维护者的手动审核环节。 Step 2: 对贡献者不设立严格的自动化门禁（如格式检查、命名规范检查），仅通过简单的`readme.md`文件进行引导，信任社区成员能通过观察和模仿来遵循约定。 Step 3: 维护者在审核拉取请求时，凭借个人经验和判断力，对内容的合规性、质量和重复性进行把关。 核心价值：这种“人工优先”的模式，使得项目可以零基础设施投入、即刻启动。它将所有复杂性都推给了人的判断，从而极大地简化了系统本身。

Technologies: GitHub Pull Requests, Manual Review

Boundaries & Risks: 这是项目在当前阶段的一个核心特征，也是一个巨大的技术负债。系统的质量和响应速度高度依赖于核心维护者的可用性和责任心。随着内容规模的扩大，非常容易出现命名不一致、格式混乱、内容重复等问题，导致知识库的价值被稀释。这也是项目报告中指出的最主要的技术风险。