TheBigPromptLibrary 的 CLAUDE.md：仓库结构、GPT 文档规范与自动化索引工具链-平芜编程栈

提示工程
AI 安全治理

【免费下载链接】TheBigPromptLibrary

A collection of prompts, system prompts and LLM instructions

项目地址：https://gitcode.com/gh_mirrors/th/TheBigPromptLibrary

本文以 CLAUDE.md 这份面向 Claude Code 的仓库指引文件为核心，系统讲解 TheBigPromptLibrary（一个汇集 LLM 系统提示词、Custom GPT 指令、越狱提示词与指令防护技术的集合仓库）的目录组织方式、GPT 文档的文件命名与格式规范，以及Tools/openai_gpts目录下用于索引、检索、模板生成和目录（TOC）重建的 Python 工具链的实现原理。读完后你将掌握：如何在该仓库中正确定位和阅读各类提示词文档、GPT markdown 文件的结构化字段规范、以及贡献新提示词时完整的操作流程（模板生成 → 目录重建）。

仓库定位：一个面向 LLM 提示词研究与教育的集合库

CLAUDE.md 开篇明确说明了仓库的性质：

This is a collection repository for LLM system prompts, custom GPT instructions, jailbreak prompts, and instruction protection techniques. The content is primarily markdown documentation for educational purposes around prompt engineering and LLM security research.

即这是一个以 Markdown 文档为主体的提示词集合仓库，服务于提示词工程学习与 LLM 安全研究。仓库根目录的 README 进一步说明了其教育用途，并声明内容仅用于学习与信息参考，包括研究提示注入（prompt injection）风险。该仓库的学术引用价值也体现在根 README 中被多篇 ArXiv 论文（如A Closer Look at System Prompt Robustness、PRSA: Prompt Stealing Attacks等）引用。

CLAUDE.md 中的 "Repository Structure" 一节给出了六大核心目录，与仓库实际结构一一对应：

目录	内容	组织方式
SystemPrompts/	各家 LLM 供应商的系统提示词（OpenAI、Anthropic、Google、Meta、xAI 等）	按供应商分子目录，文件名带日期戳
CustomInstructions/	Custom GPT 指令与配置，含大型索引 README	`ChatGPT/`子目录存放大量 GPT 文档
Jailbreak/	越狱（jailbreak）提示词	按 LLM 供应商分子目录
Security/	GPT 指令防护技术	见`Security/GPT-Protections/`
Articles/	关于 LLM 内部机制与提示词工程的技术文章	每篇文章一个子目录
Tools/openai_gpts/	管理 GPT 文档的 Python 工具	Python 脚本

从 SystemPrompts/README.md 的实际内容可以印证 CLAUDE.md 的描述：系统提示词按供应商分节（OpenAI、Anthropic 等），且条目普遍带日期，例如chatgpt4o、gpt45系列均标注了抓取日期（如06/29/2025）。而 CustomInstructions/README.md 则是一个超长的 GPT 总目录，当前标注为 "There are 1573 GPTs total"，每条 GPT 以- 标题 (id: GPTID)的形式链接到具体文档。

GPT 文档的命名与格式规范（由 gptparser.py 定义）

CLAUDE.md 的 "File Naming Conventions" 一节规定了两种命名模式：

SystemPrompts：YYYYMMDD-ProviderName.md或provider_feature_YYYYMMDD.md，如 20251027-gpt5.md、20260112-Claude-Cowork.md；
CustomInstructions 中的 GPT 文件：{gpt_id}.md，文件内含 GPT 元数据头（frontmatter-style headers）。

这一约定并非纯文档描述，而是由 gptparser.py 中的正则硬性执行：

GPT_FILE_ID_RE = re.compile(r'^([0-9a-z]{9})_(.*)\.md$', re.IGNORECASE) """GPT file name regex with ID and name capture.""" GPT_FILE_VERSION_RE = re.compile(r'\[([^]]*)\]\.md$', re.IGNORECASE) """GPT file name regex with version capture."""

即 GPT 文件名必须是9 位 GPT ID + 下划线 + 名称 +.md（ID 大小写不敏感），版本变体则通过文件名尾部的[版本]标注，如仓库中同时存在的03kpxFq48_AIJesusGPTSpiritual_Guidance_With_a_Visual_Touch.md与其...[v0].md版本。GptMarkdownFile.get()方法在读取version字段时，正是用GPT_FILE_VERSION_RE从文件名中提取版本号——这解释了为何版本信息不在文件内容中而体现在文件名里。

GPT markdown 文件的字段规范

gptparser.py 定义了 GPT 文件支持的字段表SUPPORTED_FIELDS，键必须小写，文件中的书写格式为GPT {display名}: {值}（FIELD_PREFIX = 'GPT'）：

字段键（小写）	显示名	排序权重
`url`	URL	10
`title`	Title	20
`description`	Description	30
`logo`	Logo	40
`verif_status`	Verification Status	50
`instructions`	Instructions	60
`actions`	Actions	70
`kb_files_list`	KB Files List	80
`extras`	Extras	90
`protected`	Protected	100

以一个真实文件 3rtbLUIUO_Succubus.md 为例，其结构完全符合上述规范：

GPT URL: https://chat.openai.com/g/g-3rtbLUIUO-succubus GPT Title: Succubus GPT Description: Look into my eyes. v1.0 - By mindgoblinstudios.com GPT Instructions: ```markdown Succubus is designed to role-play as a seducer, ...

解析过程见 `GptMarkdownFile.parse()`（[gptparser.py](https://link.gitcode.com/i/7f0dbe9b16246d44e47ce5e20e18ce0e#L85-L113)）：逐行匹配 `GPT {字段名}:` 前缀行，命中后该行前缀之后的内容及后续所有行都归入当前字段，直到出现下一个字段标记行为止。写入时（`__str__` 方法）则按 `SUPPORTED_FIELDS` 的 `order` 权重排序输出，并对字段值中首次出现的 ` ```markdown ` 标记前补空行以保证代码块渲染正确——这套"按序序列化"正是 `oneoff.py` 批量重排 GPT 文件的实现基础。 GPT 的 ID 则从文件内的 `GPT URL` 字段解析。`parse_gpturl()`（[gptparser.py](https://link.gitcode.com/i/7f0dbe9b16246d44e47ce5e20e18ce0e#L127-L135)）同时兼容 `https://chat.openai.com/g/g-` 与 `https://chatgpt.com/g/g-` 两种历史前缀（见 `GPT_BASE_URLS` 常量），取出 `g-` 之后、第一个 `-` 之前的 9 位字符作为 ID。这也是 [idxtool.py --find-gpt](https://link.gitcode.com/i/26da307512db26bb46bf1ab989e3521a) 能直接吃完整 URL 的原因。 ## Tools/openai_gpts：GPT 文档管理工具链 CLAUDE.md 的 "Tools" 一节列出了四条核心命令，全部围绕 [idxtool.py](https://link.gitcode.com/i/4f1c810c9d812b0163042e9222b1f238) 和 [gen_gpt_templ.py](https://link.gitcode.com/i/df53515429e6cede15a6eab5c61d7a9e)： ```bash # 重建 CustomInstructions/README.md 的目录（table of contents） python Tools/openai_gpts/idxtool.py --toc # 按 ID 或 URL 查找 GPT 文件 python Tools/openai_gpts/idxtool.py --find-gpt <GPT_ID_OR_URL> # 为新 GPT 条目生成 markdown 模板 python Tools/openai_gpts/idxtool.py --template <CHATGPT_URL> # 独立工具：生成模板并附带元数据 dump python Tools/openai_gpts/gen_gpt_templ.py <URL_OR_ID> --dump

该目录共四个脚本（见 Tools/openai_gpts/README.md）：

idxtool.py—— GPT 索引与检索工具（主入口，argparse 支持--toc、--find-gpt、--template、--parse-gptfile、--rename五个参数）；
gen_gpt_templ.py—— 从 ChatGPT 网站下载并解析 GPT 元数据、生成 markdown 模板的独立工具；
gptparser.py—— 被 idxtool 依赖的 GPT 文件解析/序列化模块；
oneoff.py—— 批处理脚本，如reformat_gpt_files(src, dst)将目录内所有 GPT 文件按标准字段顺序重排后输出（oneoff.py）。

依赖方面，requirements.txt 仅声明了GitPython（供--rename使用git mv），而gen_gpt_templ.py还直接使用了requests库（源码中的import requests），运行模板下载功能时需自行确保环境可用。

idxtool 的四个功能与实现细节

1.--toc：重建目录。rebuild_toc()（idxtool.py）的工作方式是"截断 + 追加"：

读取 CustomInstructions/README.md（路径由TOC_FILENAME基于gptparser.get_prompts_path()推导，指向CustomInstructions/下的 README），逐行写入输出，直到遇到标记行## ChatGPT GPT instructions（常量TOC_GPT_MARKER_LINE，见 idxtool.py）；
标记行之前的内容（Games、Gemini Gems、Gab.ai 等手工维护部分）原样保留，其后的 GPT 列表全部由程序重新生成；若 README 被改动导致标记行丢失，脚本会报错提示 "Please revert the TOC file and try again"；
随后通过enum_gpts()（gptparser.py）遍历CustomInstructions/ChatGPT/下所有.md文件并解析，统计有效数量写入 "There are {N} GPTs total:" 行；
每个 GPT 按标题+版本 (id: GPTID)排序后输出为- 标题版本 (id: GPTID)，其中文件名经过urllib.parse.quote转义，正确处理含空格、括号、中文（如5億年ボタン…）的文件名。

2.--find-gpt：按 ID/URL 检索。find_gptfile()（idxtool.py）支持三种输入形态：

单个 GPT ID（如3rtbLUIUO）；
完整 ChatGPT URL（先经parse_gpturl提取 ID）；
以@前缀传入的文件（如@gptids.txt），文件内每行一个 ID 或 URL，#开头的行视为注释。

检索本身不解析文件内容，而是依赖enum_gpt_files()对GPT_FILE_ID_RE文件名正则的匹配——这再次说明规范的文件名是仓库检索能力的前提。

3.--template：生成新 GPT 文档模板。make_template()（idxtool.py）内部调用gen_gpt_templ的process_gpt_input与generate_template，从 ChatGPT 网站抓取真实元数据，在当前目录写出{gpt_id}.md；若文件已存在则报错拒绝覆盖。Tools README 明确区分了两者的定位：idxtool --template是 GPT 管理工作流中的快速模板生成；直接运行gen_gpt_templ.py则多了--debug（保存 HTML 与 dump 调试文件）、--dump（保存解析出的全部元数据到 .txt）、@response_file批量处理等能力。

4.--rename：批量规范化文件名。rename_gpts()（idxtool.py）遍历所有 GPT 文件，将缺少{id}_前缀的文件通过git mv（失败时回退os.rename）重命名为带 ID 前缀的形式，保证enum_gpt_files()的正则匹配始终有效。

gen_gpt_templ.py 的元数据抓取原理

gen_gpt_templ.py的技术核心在于从 ChatGPT 页面 HTML 中还原 GPT 元数据，流程为"下载 → 正则提取 → 结构化解析 → 模板渲染"：

下载：download_page()（gen_gpt_templ.py）用requests.Session附加一整套浏览器样式的请求头（User-Agent、Sec-Fetch-* 等）发起 GET，且刻意不带Accept-Encoding以获得未压缩响应；
提取：extract_enqueue_args()（gen_gpt_templ.py）用正则匹配 React Router 的window.__reactRouterContext.streamController.enqueue('...')调用，取出其中的字符串字面量，并用json.loads安全地解码转义序列（源码注释特别说明这是为了避免 emoji 等 Unicode 被二次编码）；
解析：CustomGPTParser取其中最长的字符串作为 Gizmo 数据并json.loads，随后用位置启发式提取字段——例如get_title()查找'description'键的前一项作为标题，get_author_display_name()按'user_id' → 'user-{id}' → '{display_name}'的三连项模式提取作者名；
输入规范化：process_gpt_input()（gen_gpt_templ.py）统一处理四种输入——完整 URL（含/c/会话后缀，会自动截断出基础 URL）、g-前缀 ID、9 位裸 ID，最终拼出https://chatgpt.com/g/g-{id}形式；
渲染：按内置TEMPLATE字符串输出标准 GPT markdown（GPT URL / GPT logo / GPT Title / GPT Description / GPT instructions骨架），其中的GPT instructions代码块留空，等待人工填入提示词正文。

需要说明的适用前提：由于页面结构来自 ChatGPT 前端渲染产物，上述streamController.enqueue正则与字段位置假设依赖 OpenAI 前端实现，页面改版后解析可能失效——--debug保存的 HTML 与 dump 文件正是为此类排障准备的。

贡献新提示词的标准工作流

CLAUDE.md 的 "Contributing New Prompts" 一节给出了三步流程，结合源码可以还原为完整操作链：

遵循命名规范。系统提示词按YYYYMMDD-ProviderName.md或provider_feature_YYYYMMDD.md放入对应供应商目录（见 SystemPrompts/README.md 中的既有条目）；GPT 文档则放在 CustomInstructions/ChatGPT/ 下，文件名符合{9位ID}_名称.md正则。
用--template生成初始文件：
```
python Tools/openai_gpts/idxtool.py --template https://chatgpt.com/g/g-XXXXXXXXX-xxx
```
脚本会下载该 GPT 的 URL、标题、描述、Logo 与作者信息，写出{gpt_id}.md，开发者只需补全GPT instructions代码块中的提示词正文，并按需改名为{id}_名称.md。
运行--toc更新总目录：
```
python Tools/openai_gpts/idxtool.py --toc
```
CustomInstructions/README.md 中## ChatGPT GPT instructions标记行以下的条目列表会被自动重建，手工维护的目录上半部分（Games、Gemini Gems、Gab.ai 等）不受影响。

这一"模板化 + 索引自动化"的设计，使得仓库中 1500+ 个 GPT 文档能够保持统一的结构与可检索性：文件名正则支撑--find-gpt，GPT URL字段支撑 ID 解析与 TOC 排序，SUPPORTED_FIELDS的固定顺序支撑oneoff.py的批量重排。

小结

CLAUDE.md 虽然篇幅不长，但它把 TheBigPromptLibrary 的"数据规范"（目录划分、日期戳命名、GPT 文件格式）与"工程手段"（idxtool 索引/目录工具链）压缩成了一份可执行的 Agent 指引。对读者而言，这份文档的价值在于它同时扮演三种角色：提示词研究与贡献者查阅仓库布局的地图、Tools/openai_gpts工具链的速查手册，以及 GPT markdown 规范（{id}_名称.md命名 +GPT 字段:结构）的事实性定义——后两者均可在 gptparser.py、idxtool.py 与 gen_gpt_templ.py 的源码中获得逐行印证。