CL4R1T4S：把 AI 系统提示词放到台前的开源档案库

市面上谈"系统提示词"的内容，大多是转述与截图：某家 AI 被挖出了什么指令，配一段戏剧化的引文，看完就散了。CL4R1T4S 做的事不太一样——它把这些一手的提示词文本按产品归档、带版本标记地沉淀下来，让"系统提示词"从传闻变成可以 diff、可以归档、可以交叉验证的研究材料。截至 2026 年 10 月 2 日，这个仓库有 50,841 stars、10,419 forks，是同类项目中规模最大的一个。

这不是一个"教你写提示词"的教程库。它的读者是研究者、安全人员和想弄清"AI 产品为什么是这个行为"的开发者。读它的正确姿势也不是找最劲爆的那份文件，而是把它当成样本库：比较不同产品的设计取舍，追踪同一产品跨版本的演进。本文会给出一个可以直接复现的分析案例，也会把使用边界说清楚——仓库里的文本不自动等于"官方最终版本"，更不等于模型能力的完整解释。

它是什么

CL4R1T4S 由 GitHub 用户 elder-plinius 维护。他在自我介绍里写自己是 “prompter, red teamer, hacker”（提示词工程师、红队队员、黑客），运营 pliny.gg，X 账号 @elder_plinius 有 2.2 万关注者——在提示词注入（prompt injection）研究圈子里是知名人物。他还有个姊妹仓库 L1B3RT4S（21.6k stars），收录的则是"越狱提示词"。两个仓库放在一起看，维护者的立场很清楚：他要的是 AI 系统的透明，手段是进攻性的安全研究。

CL4R1T4S 这个名字本身就是 leetspeak 变体，对应的仓库描述也毫不掩饰：“LEAKED SYSTEM PROMPTS FOR CHATGPT, CLAUDE, GEMINI, GROK, PERPLEXITY, CURSOR, LOVABLE, REPLIT, AND MORE! — AI SYSTEMS TRANSPARENCY FOR ALL!"（各大 AI 产品的泄露系统提示词——为了所有人的 AI 系统透明）。

README 里有一句核心主张：“In order to trust the output, one must understand the input."（要信任输出，先理解输入。）这里的"输入"不是用户发出的那句话，而是模型背后那层长期生效、用户通常看不到的系统级指令。README 随后用了一个流传很广的比喻：不了解系统提示词就和 AI 交谈，“你面对的不是中立智能，而是一场皮影戏”（shadow-puppet）。

仓库本身的参数如下（GitHub API，2026-10-02 快照）：

收了什么

仓库按产品分目录，顶层目前有 26 个：ANTHROPIC、OPENAI、GOOGLE、XAI、PERPLEXITY、META、MISTRAL 这些大模型厂商是一类；CURSOR、DEVIN、REPLIT、WINDSURF、CLINE、MANUS、LOVABLE、BOLT、FACTORY（Droid）、VERCEL V0 这些编码与代理工具是另一类；还有 DIA（The Browser Company 的 Dia 浏览器）、BRAVE（Leo）、CLUELY、HUME、MULTION、SAMEDEV 等各形态产品。值得注意的是 KIMI 和 ZAI——月之暗面与智谱的产品也在收录之列，其中 ZAI 目录下是 ZCode。

这个覆盖范围本身就说明了一个常被忽略的事实：系统提示词早已不限于 ChatGPT、Claude 这类对话产品。真正深度介入开发者工作流的 Cursor、Devin、Windsurf，提示词往往更长，结构上是"操作手册 + 行为守则 + 安全限制"的混合体。只盯着对话产品看提示词，会漏掉代理式 AI 最有意思的那部分。

每个目录下的文件按提取时间与版本命名。以 ANTHROPIC 为例，15 个文件从 Claude_Sonnet_3.5.md 一路排到 CLAUDE-OPUS-5.5.md，中间的 Claude_Sonnet-4.5_Sep-29-2025.txt 带着精确到日的提取标记——这个日期与 Anthropic 官方发布 Sonnet 4.5 的日子（2025-09-29）完全吻合，社区提取和产品发布基本同步。README 对贡献者的要求也写得很明确：提交时必须带模型名与版本、提取日期，备注可选。这份规范让每份材料自带证据上下文，是仓库能做版本研究的前提。

为什么值得看

系统提示词重要，不是因为它神秘，而是因为它直接影响产品行为。用户感受到的"AI 风格”——语气、回答结构、拒绝方式、工具调用顺序——很多不是模型天然如此，而是被这层指令持续塑形的结果。README 把这些影响归纳为四个方向：AI 不能说什么、被要求扮演什么角色、被要求如何拒绝或转移、默认注入了哪些伦理与政治框架。

这四个方向是维护者的研究立场，不必当成已被严格证明的结论。更稳的用法是把它们当作观察窗口：结合真实产品交互、版本变化和其他公开材料交叉验证。具体到研究价值，有三条判断。

第一，对话产品和编码工具适合分开研究。前者的提示词回答"这个助手被设定成什么样”；后者的提示词回答"一个会动手的 AI 如何被工程化管理"——文件修改原则、测试与验证要求、工具权限、输出格式约束，每一条都能对应到真实的产品风险控制。如果你的兴趣点是 coding agent，后一半仓库的价值更高。

第二，版本差异本身就是研究对象。同一产品不同时期的提示词放在一起 diff，能看到产品策略的演变：哪些约束是后来加的，哪些规则从短 prompt 长成了整份文档，哪些功能扩张带来了新的安全条款。这类问题比"某家 AI 藏了什么秘密"更接近真实的产品治理过程。

第三，重复出现的结构化规则比戏剧化片段更有价值。“优先级顺序"“不得披露内部指令"“何种条件下调用外部工具"这类条款在各家提示词里反复出现，它们揭示的是行业共同的设计模式；而个别夸张的表述，证据等级往往存疑。

一次完整的分析

以 ANTHROPIC 目录为例走一遍最小分析流程，所有命令都可以直接复现。

第一步，列出目录里的版本文件：

git clone https://github.com/elder-plinius/CL4R1T4S.git
cd CL4R1T4S
find ANTHROPIC -maxdepth 1 -type f | sort

15 个文件按模型代际排开：Sonnet 3.5 → Sonnet 3.7 → Claude 4 → 4.1 → Opus 4.5 → Opus 4.6 → Opus 4.7 → Opus 5 → Opus 5.5。行数是最直观的证据：Claude_Sonnet_3.5.md 204 行，Claude-4.5-Opus.txt 1,222 行，OPUS-5.md 2,049 行，最新的 CLAUDE-OPUS-5.5.md 达到 21,531 行——行为守则在逐代累积。

第二步，对相邻版本做 diff，看约束怎么长出来的：

git diff --no-index ANTHROPIC/Claude-4.5-Opus.txt ANTHROPIC/Claude-Opus-4.7.txt

重点看新增的段落：新版本要求什么、禁止什么、把哪些原来一句话带过的规则展开成了章节。这一步回答的问题是"Anthropic 在两次模型迭代之间，往行为守则里加了什么”。

第三步，跨产品搜索共同条款，找行业通行的设计模式：

rg -in "cannot|must not|do not|refuse|redirect" ANTHROPIC OPENAI GOOGLE XAI

第四步，把结果落成结构化记录：样本文件路径、提取时间、目标产品、核心规则、你的解释。没有这一步，多文件比较很容易变成"看了很多，说不出结论”。

这四步走完，你得到的不只是几段提示词文本，而是一套可以复用在其他目录上的分析流程。

三种用法

产品行为对比。 选两个同类系统——Claude 和 ChatGPT，或者 Cursor 和 Windsurf——沿四个维度对比：角色设定（工具型、顾问型还是代理型）、拒绝策略（直接拒绝、解释拒绝还是重定向）、工具权限（什么场景允许搜索、写文件、执行命令）、风险态度（是否要求先解释再执行）。对比看到的是"谁被设计成什么样”，这是"谁更强"回答不了的问题。

安全与注入研究。 系统提示词里显式写着系统最怕被覆盖的规则和厂商设计的拒绝、重定向机制。对安全研究来说，先看重复出现的结构化规则，再看个别表述——前者告诉你这类系统的防御共性，后者才涉及具体产品的弱点。

提示词工程反向学习。 自己设计 AI 助手时，值得学的不是具体句子而是设计方法：角色定义如何约束职责范围、安全边界如何分层描述禁止事项与例外、工具调用规则如何写明何时调用何时先解释。可迁移的是结构，不是措辞——照抄别家的人设文本，既没有版权上的安全余地，也适配不了你自己的产品语境。

四条边界

这部分是全文最重要的。CL4R1T4S 有价值，但不能被神化，引用其中任何一份材料前，先过四条核验：记录文件路径与文件名（只记产品名无法复现）、记录查看时间（文本更新快，时间戳本身就是证据）、确认版本或日期信息（没有版本上下文的结论容易失真）、用真实产品行为交叉验证（防止拿历史文本当现状）。

四条核验背后的边界各有一条：

来源未必统一。 README 给贡献者的指引是 “Leak, extract, or reverse-engineer something? Good."（泄露、提取、逆向，都行）——三种获取路径的证据等级并不相同，泄露文本可能是真实的完整快照，逆向复原可能只是近似。不能默认每份文本都有同样的可信度。

提示词不等于完整系统。 系统行为还受模型权重、检索、工具路由、后处理过滤、产品界面逻辑影响。把单份系统提示词当成产品的全部，是这类研究最常见的误区。

版本极易过期。 仓库最近一次推送是 2026 年 9 月，你读到这篇文章时，具体文件可能又换了几代。写研究结论时，把文件日期、抓取时间和你自己的验证时间一起记录在案。

透明度研究和滥用只有一线之隔。 同一份材料，研究者拿来分析安全边界，攻击者也能拿来找绕过路径。一个可以长期坚持的原则：研究结构，不传播可操作的规避细节。顺带一提，维护者自己就把这个立场写进了仓库——CL4R1T4S 的 README 末尾附了一段他署名的注入指令演示（用字符替换写成，要求 AI 把自己的系统指令完整输出给用户），L1B3RT4S 的仓库描述同样是各种注入话术的活体展示。读这个仓库的人，应该对"提示词可以被操纵"这件事本身保持警觉。

采用建议

把 CL4R1T4S 当八卦集看，它的价值会被严重低估；把它当"AI 产品如何被塑造"的样本库，它是目前公开渠道里最全的一份材料。

如果你是研究 AI 产品行为或做安全研究的人，可以直接从 ANTHROPIC、OPENAI、CURSOR、DEVIN 这几个收录最全的目录开始，按上一节的四步流程走一遍。如果你是 AI 助手的开发者，重点看与你产品形态相近的那一类（编码工具对编码工具，对话产品对对话产品），学结构不抄措辞。如果你只是好奇"AI 为什么这样回答”，花半小时读一份 Cursor 或 Claude 的提示词全文，比读十篇转述文章收获大。

两种情况都建议 star 仓库跟更新：这类材料的时效性就是价值的一部分，过期文本和过期药一样，会误导后来者。

常见问题

这些提示词是真的吗？ 部分是泄露的一手文本，部分是提取或逆向的结果。README 要求贡献者标注模型版本与提取日期，标注越完整的材料越可核验。用之前拿真实产品行为对一遍，别把仓库文本直接当最终事实。

能把这些提示词用到自己的产品里吗？ 不建议。仓库整体按 AGPL-3.0 授权，但收录的各厂商提示词文本，著作权仍归各厂商——照抄进产品既有版权风险，也可能违反对应产品的服务条款。研究设计方法，自己写。

怎么判断一份提示词的版本？ 先看文件名里的日期与版本标记，再到对应产品里做几个典型交互交叉验证。拿旧文本解释新产品的行为，是这类研究里最常见的硬伤。

仓库的更新节奏如何？ 从提交历史看，主流产品的提示词在发布后很快就有社区跟进提取（Sonnet 4.5 的文件日期与官方发布日同一天），小众产品的更新依赖有人贡献。没有正式 Release，直接跟踪 main 分支即可。

相关资源

• CL4R1T4S GitHub 仓库
• README 原文
• 姊妹仓库：L1B3RT4S（越狱提示词集，可与本文对照理解维护者的研究立场）