本文由 辛梓煜@词元2号站（www.ciyuanerhao.com）撰写，转载请注明出处。

快速摘要

如果你只想要结论，看这一段就够了：网上有一个叫 system_prompts_leaks 的开源仓库，把 Claude、ChatGPT、Gemini、Grok、Copilot、Cursor、Perplexity 等主流 AI 产品的「系统提示词」（也就是 AI 出厂时自带的那份隐藏行为说明书）集中收录、按厂商分类、还带版本对比。它当前已经积累了 5 万多 Star、8000 多 Fork，用的是几乎无限制的 CC0 协议，连《华盛顿邮报》都专门报道过。对开发者、AI 产品经理、安全研究者来说，它最大的价值不是「抄一份提示词回来用」，而是让你能横向对照，看清楚不同产品是怎么给同一个大模型套上不同「人格」和「规矩」的。

系统提示词决定了 AI「是谁、能做什么、不能做什么、什么时候搜索、什么时候拒绝、怎么调用工具、怎么处理你的文件和隐私」。普通人只看到聊天框，真正决定体验的那层规则，藏在聊天框背后。这篇文章我会从「为什么不同 AI 答案差这么大」讲起，一路拆到这个档案库怎么用、系统提示词里到底写了什么、聊天机器人和编程 Agent 的提示词哲学差在哪，最后聊聊「提示词泄露」本身作为一个安全话题的另一面。想看完整拆解，往下翻。

⚠️ 阅读前请先看一眼： 本文提及的开源项目、命令和方法，仅供个人学习、研究与合法的产品设计参考之用。使用相关资料时，请务必遵守各 AI 产品的服务条款、用户协议以及所在地区的法律法规。请不要将这些内容用于绕过产品限制、攻击线上系统、复制他人商业机密或任何非法目的。研究的价值在于理解与建设，而不是破坏与规避——这条线，请每位读者自觉守好。

一、同一个问题，不同 AI 为什么答得不一样

你以为是「性格」，其实是「隐藏说明书」

先从一个你大概率也遇到过的场景说起。

我自己有个习惯：碰到拿不准的问题，会同时丢给好几个 AI，横着比一比。用得多了就发现一件怪事——同样一句话，不同产品给出来的东西，气质完全不同。不是答案对错的差别，而是那种说不清道不明的「调性」差别，就像同一个问题分别问了三个背景迥异的人。

有的很谨慎，动不动先给你贴一圈风险提示；有的像个产品经理，先帮你拆目标、列方案，再动手；有的像坐你旁边的程序员搭子，二话不说先去翻你的文件、跑几条命令、把代码改了再说。

一开始我也把这个归结为「模型性格不一样」。后来越研究越明白，这里面很大一块，根本不是模型天生如此，而是产品在模型外面套了一层看不见的指令。这层指令，业内叫系统提示词（System Prompt）。

什么是系统提示词，用大白话说一遍

系统提示词，说穿了就是产品方在你开口之前，先偷偷塞给模型的一段话。它不出现在聊天框里，你看不到，但模型每次回答都要先「读一遍」它。

打个比方会更好懂。同一个人（大模型）去三家公司上班，三家公司各发了一本《员工手册》（系统提示词）：

• A 公司手册写着「你是严谨的法务助理，任何有风险的话都要先声明」；
• B 公司手册写着「你是雷厉风行的项目负责人，先拆解目标再执行」；
• C 公司手册写着「你是资深工程师，可以直接读写文件、执行命令，但改动前要确认」。

同一个人，三本手册，干出来的活儿自然是三种风格。AI 产品之间那种「性格差异」，很大程度上就是这本手册写得不一样。

举个具体点的例子

抽象的比方讲完，来个更贴地的例子。假设我同时问三个不同取向的 AI：「帮我看看这段代码有没有问题。」

• 偏「严谨助理」型的会先问你：这段代码运行环境是什么？期望的输出是什么？确认清楚了再动手，生怕误判。
• 偏「执行者」型的会直接给你指出几处它认为可疑的地方，列成清单，末了补一句「要不要我帮你改」。
• 偏「工程师搭子」型的（尤其是编程 Agent）会更激进：它可能直接去读你项目里相关的其他文件，把上下文补齐，甚至试着跑一下，再回来告诉你结论。

这三种反应，粒度、主动性、谨慎程度全都不一样。而决定它们「性格」的那份说明书里，往往就明明白白写着：遇到模糊需求先追问还是先假设、能不能主动读文件、改动前要不要用户确认。你以为是模型脾气不同，其实是产品在替它做选择。

为什么普通用户几乎意识不到这层

系统提示词最「狡猾」的地方，是它对用户完全隐形。你打开聊天框，看到的是一片空白，仿佛在跟一个「原生」的模型对话。但事实上，在你敲下第一个字之前，产品早已把那份长长的说明书塞进去了。

对开发者来说，看聊天框是没用的，真正该看的是聊天框背后的行为规则。问题在于——各家的说明书通常都是不公开的，被当作核心资产捂得严严实实。正因如此，才会有人费劲去把它们「问」出来、整理成公开档案。这就引出了今天的主角。

二、把 AI「隐藏说明书」摊开的这个开源项目

项目到底是什么

system_prompts_leaks 是一个专门收集、整理、对比主流 AI 聊天机器人和编程助手系统提示词的开源仓库。项目地址是 asgeirtj/system_prompts_leaks，作者是来自冰岛的开发者 Ásgeir Thor Johnson。

它做的事情特别朴素：把散落在各处、被人从各家产品里「问」出来或提取出来的系统提示词，按厂商和产品归类，放进一个统一的仓库里，还持续更新。仓库自己的定位写得很直白——目标就是把市面上所有 AI 聊天机器人的系统提示词指令记录下来，Claude、ChatGPT、Gemini 一个都不落。

覆盖范围相当广，粗粗数一下就包括：

它火到什么程度

判断一个开源项目值不值得看，Star 数只是最粗的一个信号，但这个项目的数字确实够抢眼：目前已经攒到 5 万多 Star、8000 多 Fork，而且还在往上走，采用的是 CC0-1.0 协议——这个协议基本等于作者主动放弃著作权，谁都能自由取用。

更值得一提的是，它已经不只是技术圈自嗨。《华盛顿邮报》在 2026 年 5 月专门报道过它，用的框架是「看看 AI 背后那些隐藏的规则」。当一个 GitHub 仓库被主流大报拿去当「AI 透明度」的案例来写，说明这件事的意义已经溢出了开发者社区——普通用户也开始意识到，AI 产品背后并不是一句轻飘飘的「你是一个助手」那么简单。

辛梓煜@词元2号站在这里插一句我的观察：这个项目能破圈，靠的不是「泄露」两个字的猎奇感，而是它第一次让「AI 到底被怎么调教的」这件事变得可查、可对比。

再补一个细节。作者是个人开发者，不是什么大机构，仓库能滚到这个体量，靠的是持续更新加上社区大量的 Pull Request（贡献者提交的合并请求）。你去翻它的提交记录会发现，新模型一发布，往往没几天对应的提示词文件就更新进来了。这种「众包 + 高频维护」的模式，是它能一直保持新鲜、不沦为一次性快照的关键。

它不是市面上唯一一个，但确实是维护得最勤的

其实同类项目不止这一个，社区里还有像 jujumilk3/leaked-system-prompts 这样的仓库也在做类似的事。相比之下，system_prompts_leaks 的特点是更新更频繁、覆盖产品更多、目录结构更清晰，还把 OpenAI、Anthropic、Google、xAI、Cursor、Copilot 等一大堆产品放进同一个视图里，方便你横着比。

我个人的用法是两个都留着，交叉验证。毕竟这类靠提取和社区提交攒起来的档案，多一个来源对照，可信度就多一分。这也顺带引出后面会专门讲的一点——别把任何单一仓库当成绝对真相。

它背后其实有一场「透明 vs 保密」的争论

这个项目能被大报盯上，是因为它戳中了一个正在发酵的公共议题：当 AI 越来越多地介入新闻、作业、招聘这些日常场景时，它背后那套决定「什么该拒绝、什么该谨慎」的规则，到底该不该对公众透明？

一种观点认为，这类规则关系到每个人接收到的信息，理应像其它影响公共生活的规则一样接受审视，把它整理成公开档案是一种「知情权」的体现。另一种观点则担心，把产品的内部规则和防护边界一股脑摊开，可能被人拿去钻空子，反而削弱安全。

这两种声音都有道理，我个人不站队，但我觉得有一点是共识：AI 应用的安全，不该建立在「用户永远看不到规则」这个假设上。 一个健康的产品，即便规则被看到了，也依然稳固。这个话题我在最后一章还会从技术角度再展开。

它和「提示词模板库」根本不是一回事

很多人第一眼会把它跟那种「Prompt 模板大全」搞混。两者其实完全不同，方向甚至是相反的。一个是教你怎么写好一句 Prompt 去指挥 AI，另一个是让你去研究 AI 产品本身是被什么指令塑造出来的。我做了张表把差别摊开：

一句话总结：模板库让你更会「用」AI，这个档案库让你更懂 AI 产品是怎么「被造出来」的。它真正有价值的地方，是让人能系统性地去研究——不同产品到底如何定义自己。

三、一条系统提示词里到底写了什么

光说「系统提示词很重要」还是虚。我们把一条典型的系统提示词剖开，看看里面通常有哪几块。理解了这个骨架，你再去这个仓库里翻任何一份文件，都能迅速定位到关键信息，不至于对着满屏文字发懵。

先给你打个预防针：不同产品的提示词写法千差万别，有的用大量结构化标签把每一块框得清清楚楚，有的则写得像一封长长的说明信。但万变不离其宗，它们要交代的东西，基本逃不出下面这几大类。你把这几类记在心里，就等于有了一张通用的「阅读地图」。

我把常见的模块画成一张「解剖图」：

graph TD
    A[一条系统提示词] --> B[角色与身份<br/>你是谁]
    A --> C[能力与工具边界<br/>你能调用什么]
    A --> D[搜索与引用规则<br/>何时查、怎么标来源]
    A --> E[安全与拒答边界<br/>什么不能做]
    A --> F[输出风格与格式<br/>话怎么说、格式怎么排]
    A --> G[隐私与数据处理<br/>用户信息怎么对待]

下面一块块说清楚，术语第一次出现我都会用一句白话解释。

角色与身份

开篇一般会先定义「你是谁」。比如声明产品名称、由哪家公司开发、当前是什么版本、知识截止到什么时候。别小看这几句，它直接决定了 AI 会不会自称某个名字、会不会承认自己是 AI、遇到「你是谁做的」这类问题怎么回答。

能力与工具边界

这一段告诉模型：你手上有哪些工具可以用。所谓「工具（Tool）」，就是模型自己不会做、但产品给它接上的外部能力，比如联网搜索、执行代码、读写文件、看图、调用第三方服务等等。

提示词会规定每个工具「什么时候该用、什么时候不该用」。举个通用化的例子（下面是我虚构的伪代码，用来示意逻辑，不是任何真实产品的原文）：

# 工具调用逻辑（示意）
IF 用户问的是「当前正在发生 / 可能已变化」的事实:
    调用 联网搜索
ELIF 用户问的是「稳定不变的常识」:
    直接回答，不搜索
IF 任务需要生成文件或跑代码:
    先读取相关说明，再调用 代码执行工具

编程类产品这一段往往写得极其细，因为一步走错，可能就是把用户的文件改坏。

搜索与引用规则

对于带联网能力的产品，提示词里会有一整套「什么时候该查、查完怎么标注来源」的规矩。比如：涉及当下事实、最新版本、现任某职位的人，就必须先搜再答；而对于历史常识、基础概念，则不必浪费一次搜索。

引用规范也在这里。像 Perplexity 这类主打「带出处回答」的产品，提示词会强制要求每一条来自网络的结论都挂上引用标记。这就是为什么你用某些产品时，答案后面总跟着一串小角标。

安全与拒答边界

这是最敏感、通常也写得最长的一块。它规定了模型在哪些话题上必须谨慎或直接拒绝，比如涉及未成年人安全、危险物品制作、恶意代码等。它还会写明「遇到用户情绪危机时怎么应对」这类关怀性条款。

不同产品在这一块的松紧、写法差异极大，恰恰是横向对比时最有洞察的部分——你能看出一家公司把哪些红线看得最重。有的产品会花大段篇幅反复强调某一类风险，有的则处理得相对简洁，这些侧重背后往往藏着公司的价值取向和它踩过的坑。看这一块，就像在读一家公司的「风险清单」，很能说明问题。

输出风格与格式

「话该怎么说」也写在提示词里。比如：默认要不要用大量的加粗和列表、什么时候用连贯段落、要不要显得亲切、能不能用表情符号、回答要简洁还是详尽。你感觉某个 AI「爱列点」、另一个「像在跟你聊天」，多半是这一段调出来的。

隐私与数据处理

最后通常会有关于用户数据的说明：能不能记住历史对话、如何对待上传的文件、什么信息不该主动泄露给用户。对做企业内部助手的人来说，这块是重点参考对象。

一个容易被忽略的隐藏模块：出厂知识与时间

还有一块新手常常忽略，但特别影响体验，那就是「知识截止时间」和「当前日期」的处理。很多产品会在提示词里明确告诉模型：你的训练数据截止到某个时间点，今天是某年某月某日，凡是可能已经变化的事实（谁现在担任什么职位、某个东西的最新版本、某项政策现在是否还有效），都要先联网核实，别凭记忆硬答。

这一段直接决定了一个 AI「敢不敢承认自己不知道」，以及「会不会主动去查」。你会发现，处理这块处理得好的产品，回答时事类问题时明显更靠谱，因为它不会拿几个月前的老黄历当现状糊弄你。

把这七块拼起来，你就理解了一件事：一个通用大模型，是怎么被一份文档「配置」成一个具体产品的。 仓库里每一份文件，本质上都是这样一套配置的快照。你现在再回过头去翻任何一份，脑子里都能对着这张骨架图快速归位——哦，这一段是在定角色，那一段是在划安全红线。带着结构去读，效率会高得多。

顺便说说：为什么这些提示词动不动就上千行

很多人第一次点开一份完整的系统提示词会被吓到——怎么这么长？尤其是编程类产品，一份提示词加上工具说明，规模可以相当惊人，有的甚至达到几千行、两万多 token 的量级。

这里补一个新手常常不知道的概念：token，你可以粗略理解成模型处理文本的「计量单位」，一段中文大概每个字算一到两个 token 不等。系统提示词占用的 token，是每一轮对话都要重新算进去的「固定开销」——它就像每次对话都要先交的一笔「税」。

这也解释了两件事。第一，为什么各家都在想办法把提示词组织得更高效，因为它直接吃掉宝贵的上下文空间。第二，如果你自己做产品，一定要把「系统提示词占多少 token」这件事明确预算进去，别写着写着就把上下文撑爆了。从这些泄露出来的长文件里，恰恰能看到一线产品是怎么在「把规则写全」和「别太占地方」之间做权衡的——这本身就是一门手艺。

四、聊天机器人 vs 编程 Agent：两种提示词哲学

在这个仓库里翻久了，我最大的一个收获，是看出了两类产品在提示词设计上截然不同的取向。这一点比任何单条 Prompt 都更有启发。

聊天产品：把功夫下在「人设 + 政策」

面向普通用户的聊天产品（像各家的对话版本），系统提示词的重心在人格塑造和行为政策上。大段篇幅在定义语气、边界、拒答策略、情绪关怀、格式偏好。因为它要面对海量、五花八门的真实用户，得靠这套规则把「一个模型」稳定成「一个可信赖的助手」。

编程 Agent：把功夫下在「工具语法 + 防幻觉」

而编程类 Agent（像 Claude Code、Codex、Cursor、Copilot 这些），提示词的重心整个偏移了。它们花大力气在**工具怎么调、文件怎么读写、命令怎么执行、什么时候要用户确认、怎么防止模型「一本正经地瞎编」**上。

原因也好理解：coding agent 的每一个动作都可能真实地改动你的项目，容错空间极小。它不需要太多「人设」，但需要一套极其严密的「操作协议」。

举个能感受到差别的细节。聊天产品的提示词里，你会看到大量类似「回答要简洁、别过度堆列表、语气要自然」这种关于「怎么说话」的规定；而编程 Agent 的提示词里，同样的篇幅位置放的往往是「改文件前先读一遍原文」「破坏性操作要先征得确认」「找不到就说找不到，别编一个不存在的函数名」这类关于「怎么干活」的硬约束。一个在管「嘴」，一个在管「手」，侧重完全不同。

一张图看懂差异

我把这两类的侧重画在一起：

graph LR
    subgraph 聊天产品
    A1[人格 / 语气] 
    A2[拒答与安全政策]
    A3[输出格式偏好]
    A4[情绪关怀]
    end
    subgraph 编程 Agent
    B1[工具调用语法]
    B2[文件读写规范]
    B3[用户确认机制]
    B4[防幻觉约束]
    end

这个观察有个非常实用的推论：如果你要自己设计 AI 产品，千万别把聊天产品那套「人设 + 关怀」的提示词，原封不动搬到一个数据库 Agent 上，反过来也一样。产品形态不同，提示词的骨架就该不同。这一点，是我在这个仓库里对着几十份文件反复对比后才真正体会到的。

再往深里说一层，这两种哲学其实反映了两种不同的「风险观」。聊天产品面对的最大风险，是说错话——语气冒犯、给出有害信息、在敏感话题上失当，所以它把重兵压在「政策」上。编程 Agent 面对的最大风险，是做错事——改坏文件、执行了不该执行的命令、编造出根本不存在的接口，所以它把重兵压在「操作规范」上。想清楚了「我这个产品最怕出什么事」，你自然就知道提示词该往哪个方向使劲。这比死记硬背任何模板都管用。

五、动手：把档案库变成你的研究工作台

这个项目不是传统软件，不需要编译、不需要运行，它更像一个能在本地检索的文档库。很多人第一次接触会犯嘀咕：这玩意儿没有界面、没有安装包，我该怎么「用」它？答案是——把它当成一座图书馆，用命令行当你的检索工具。

下面这套流程是我自己在用的，六步走完，你就能把「围观热闹」变成「结构化研究」。别被命令行吓到，用到的都是最基础的几条命令，我会逐条解释清楚，哪怕你平时不写代码也能照着操作。

第一步：把档案库拉到本地

git clone https://github.com/asgeirtj/system_prompts_leaks.git
cd system_prompts_leaks

这一步是把整个档案库下载到本地，方便离线搜索、对比和做标注。在线看当然也行，但真要做横向研究，拉到本地用命令行检索会快得多。这里的 git clone 是把远程仓库完整复制一份到你电脑上的命令，cd 则是进入这个目录。如果你还没装 Git，先去装一个即可，这是做技术研究的基础工具，值得花十分钟配好。

拉下来之后，这一整个文件夹就是你的「资料库」了，之后所有的检索、对比都在本地进行，不依赖网络，也不用担心哪天网页打不开。

第二步：先建立一张全局地图

ls

你会看到大致按厂商拆开的目录：

Anthropic
OpenAI
Google
xAI
Microsoft
Cursor
Perplexity
Meta
Mistral
Notion
Qwen
Misc
README.md
LICENSE

研究系统提示词，第一步不是急着读某一份，而是先看清楚整片森林。不同厂商、不同产品已经替你分好了目录，后面检索会顺畅很多。ls 这个命令就是「列出当前目录下有什么」，一眼扫过去，你就对这个仓库的版图有了大概的印象。

我的建议是，第一次进来别急着钻进某个具体文件，先花几分钟把目录逛一圈，心里对「哪家有哪些产品、大致分成几类」有个谱。有了这张全局地图，你后面无论是想定位某个产品，还是想横向对比某个主题，都能更快找到落脚点，不至于一头扎进去就迷路。

第三步：定位你关心的产品

find . -iname '*claude*'
find . -iname '*cursor*'
find . -iname '*copilot*'

find 配合 -iname（忽略大小写匹配文件名）能帮你快速把某个产品的所有相关文件揪出来。想研究 Claude Code、Cursor、Copilot、ChatGPT、Gemini，换个关键词就行。

这一步的意义在于，同一个产品往往不止一份文件——可能有网页版、有 API 版、有不同版本、有带工具和不带工具的变体。用 find 先把它们一网打尽，你才不会漏掉某个关键版本。找齐了再决定先读哪一份，研究才算做扎实。

第四步：用关键词做横向对比

这一步才是精华，也是我个人花时间最多的一步。前面几步都在「找文件」，到这里才真正开始「做研究」。核心思路是转换视角：别再纵向地一份一份从头读，而是横向地锁定一个主题，去看所有产品在这个主题上分别是怎么规定的。

# 看各家怎么写「引用来源」
grep -R "citation" OpenAI Anthropic Google | head

# 看各家怎么定义「工具调用」
grep -R "tool" Anthropic Cursor Microsoft | head

# 看各家怎么处理「隐私」
grep -R "privacy" . | head

grep -R 是递归搜索关键词，| head 只看前几行结果先探个路。你可以围绕引用、工具、隐私、安全、拒答、搜索策略这些主题，一个个横向切。这么切上几轮，各家的取向差异会非常直观地浮出来。

我举个我自己做过的横向对比，帮你体会这套方法的威力。我当时的问题是：「联网搜索」这件事，各家产品是怎么规定的？ 于是我围绕搜索相关的关键词，把几家的提示词扫了一遍，最后归纳出这么一张对照表（下面是我整理后的观察，不是任何产品的原文照抄）：

你看，光是「搜索」这一个主题，横着扫一遍就能得出这么多结构性的结论。这些东西你逐份通读全文是很难提炼出来的，但用关键词横切，一下就清晰了。这就是把档案库当「工作台」而不是「资料堆」的区别。

第五步：看版本 Diff

同一个产品的新旧两版，差异往往比全文更有信息量：

diff -u Anthropic/old-version.md Anthropic/new-version.md

diff -u 会用统一格式把两份文件的不同处标出来，加了什么、删了什么、改了什么，一目了然。通常以 + 开头的行是新增的，以 - 开头的是删掉的，扫一眼就知道这次更新动了哪些地方。相比从头啃几万字，看变化更能读出产品策略的调整方向。

如果你懒得敲命令，仓库本身也很贴心，直接在显眼位置挂了做好的版本对比链接，点开就能看到新老两版的差异高亮。不想动手的话，用它现成的也行。这一点它做得比很多同类项目都体贴，我下一章会专门展开讲为什么「看差异」这么重要。

第六步：沉淀成你自己的方法论

看热闹很容易，但收藏一堆 Prompt 没什么用。真正值钱的，是把观察抽象成一份可复用的清单。我一般会给自己开个研究笔记，长这样：

研究主题：AI 编程助手如何约束工具调用
样本：Claude Code / Cursor / Copilot / Codex
关注点：文件读写、终端执行、用户确认、安全边界、防幻觉
产出：一份「Agent 系统提示词设计要点清单」

把「我看到了什么」变成「我总结出了什么结构」，这个仓库对你的价值才算真正兑现。

我自己的经验是，这份笔记会越滚越厚，慢慢就变成了一套你个人的「AI 产品设计参照系」。下次你要设计一个新功能，或者要评估一个新产品好不好，脑子里就有一把现成的尺子可以量。这种沉淀下来的判断力，是刷再多短视频、收藏再多 Prompt 都换不来的。说到底，方法论才是能跟你走很久的东西，素材看过就忘了。

六、Diff 才是宝藏：看懂一次更新改了什么

我想单独把「版本对比」拎出来讲，因为它是这个项目里我个人最看重的部分。

系统提示词不是刻在石头上的东西。模型能力升级、产品策略调整、安全规则收紧，最后都会落到这份文档的字里行间。所以读一次更新改了什么，往往比通读全文更有洞察。

道理其实跟看新闻一样：一份长长的规章，你从头读到尾，很难判断哪些是重点；但如果有人告诉你「这次改动只动了这三处」，那这三处几乎必然是当下最要紧、最能反映意图的地方。变化，本身就是一种极强的信号过滤器。

仓库里就专门挂了一条从 Claude Opus 4.8 到 Claude Fable 5 的 Diff 链接，用来直观展示新版的 claude.ai 系统提示词到底变了什么。它还维护着一张「Recently Updated」（最近更新）表，把各产品最新一次改动的日期和链接列得清清楚楚：