从零搭建提示词库的工程实践：yao-open-prompts目录生成、质量检查与版本发布拆解

从零搭建提示词库的工程实践：yao-open-prompts目录生成、质量检查与版本发布拆解

【免费下载链接】yao-open-promptsPractical bilingual AI prompt library for prompt engineering, work, learning, content, marketing, and everyday use.项目地址: https://gitcode.com/gh_mirrors/ya/yao-open-prompts

yao-open-prompts 是一个面向真实工作、学习、内容、营销和生活场景的中文 AI 提示词库，目前已整理出118 个结构化提示词文件。很多新手收集提示词的方式是"存一堆文档进收藏夹"，结果越存越乱、无法复用。这篇工程实践拆解 yao-open-prompts 是怎么把提示词库当工程项目来管理的：用目录分类 + frontmatter 元数据 + 脚本自动检查，实现提示词库的目录生成、质量检查与版本发布全流程闭环。

提示词库目录结构

一、提示词库的目录结构：分类即架构

提示词库规模一旦超过 50 个，"靠记性找文件"就会失效。yao-open-prompts 采用按场景编号的九大分类目录，这是整个工程的地基：

仓库整体结构同样服务于"可维护"这一目标：

prompts/ # 按场景分类的提示词正文 prompts-en/ # 英文同步版提示词（与 prompts/ 同路径镜像） references/ # 推荐资源、第三方内容和外部项目索引 templates/ # 新增提示词模板 maintenance/ # 维护、评审、发布检查清单 scripts/ # 目录生成和仓库质量检查脚本 docs/ # 提示词类型与代表提示词网页 CATALOG.md # 全量提示词索引（脚本生成） CHANGELOG.md # 更新记录

分类标准写在 maintenance/taxonomy.md，新增提示词前先查这张表，保证"同类内容进同一个抽屉"。

二、统一 frontmatter：每个提示词都自带"身份证"

提示词库质量的第一道防线是统一元数据。每个提示词文件都用 templates/prompt-file-template.md 作为起点，文件头部包含 8 个必填字段：

title: 提示词标题 category: 一级分类 subcategory: 子类 source_section: 原合集章节号 author: 作者或来源 version: 提示词版本 created: 创建日期 status: active | draft | third-party-review tags: 标签列表

正文只保留三部分：标题、简介、Prompt。教程链接、效果截图、长案例一律放到references/，不与可复制的提示词正文混在一起。

💡 这套设计的关键在于：frontmatter 是机器可读的。有了它，脚本才能统计分类数量、生成目录、校验合规性——这正是"提示词库工程化"和"收藏夹式管理"的分水岭。

三、目录生成：一条命令重建全量索引

118 个提示词手动维护一份索引表格基本不可能。scripts/generate_catalog.py 的做法是：

1. 递归扫描prompts/下所有 Markdown 文件（跳过 README）；
2. 解析每个文件的 frontmatter；
3. 按九大分类统计数量，输出分类统计表格；
4. 生成全量索引表：分类 | 子类 | 标题 | 状态 | 主标签。

运行方式非常简单：

python3 scripts/generate_catalog.py

输出直接写入 CATALOG.md，开头会显示"当前共拆分出118个提示词文件"。同样的思路也用于网页端——scripts/generate_webpage.py 会扫描提示词并生成 docs/index.html 导航页，还内置了每个分类的专属配色和代表提示词入口；英文侧的 scripts/generate_english_readmes.py 则为prompts-en/各分类自动重建 README。

核心思想：索引文件永远不手改，只由脚本生成。这样增删提示词后，目录不会与实际文件脱节。

四、质量检查：把"人肉 Review"变成脚本规则

新增提示词最怕两种问题：格式不统一、中英镜像缺文件。scripts/check_repo.py 把评审标准写成了自动化规则：

• frontmatter 完整性：8 个必填字段缺一不可，缺失直接报 Error；
• 状态合法性：status只允许active/draft/third-party-review三种取值；
• 标题查重：同一标题出现多次会给出 Warning，提示合并或改名；
• 格式残留检查：检测飞书导出残留的<span style=样式标签；
• 中英镜像校验：每个prompts/中文文件必须有同路径英文对应文件，反向亦然；英文文件的source_section必须指向中文源文件路径，正文中还出现中文字符会被警告。

python3 scripts/check_repo.py # 输出示例：Checked 236 prompt files. # 有错误时以退出码 1 结束，可接入 CI 做门禁

脚本末尾打印OK或Errors: ...并以非零退出码结束，这意味着它可以无缝挂进 CI——质量检查从"靠自觉"升级为"不通过就不能合并"。

五、评审标准：五条可执行的判断准则

脚本只能检查格式，内容质量仍需要人。仓库把评审经验固化成两张检查清单：

单条提示词评审（maintenance/prompt-review-checklist.md）：

• 目标用户和使用场景明确
• 输入变量清楚，可直接替换
• 输出格式可验证
• 没有导出样式、推广说明或无关截图引用
• 第三方内容已标注来源和授权状态
• 高风险领域（医疗/法律/金融等）已加免责声明或人工复核要求
• 已更新version和 CHANGELOG.md

版本迭代规则（见 CONTRIBUTING.md）：

评审时还有一条"四可"准则：目标清楚、可执行、可迁移、可维护，外加风险可控。通用提示词里不要把一次性项目细节写死，这是新手最容易踩的坑。

六、版本发布：日期版本 + 发布检查清单

发布环节同样清单化，完整流程在 maintenance/release-checklist.md 中：

1. 确认仓库名、简介、许可证（提示词内容采用 CC BY 4.0）；
2. 处理待审内容：确认third-party-review文件是否发布，或移入references/；
3. 跑三个脚本：check_repo.py→generate_catalog.py→generate_webpage.py；
4. 人工验收：检查 CATALOG.md 链接、docs/index.html 页面渲染；
5. 记录变更：更新 CHANGELOG.md；
6. 打 tag：使用日期版本格式vYYYY.MM.N，如v2026.05.1。

日期版本对内容型仓库很友好——提示词库不像软件有严格语义化需求，"哪天发布的哪一批"比"哪个功能版本"更直观。发布后还需回到平台检查 README 和目录链接的渲染效果。

七、日常工作流：新增一条提示词的标准动作

把前面所有环节串起来，日常维护就是一条固定的流水线：

# 1. 复制模板到对应分类目录（templates/prompt-file-template.md） # 2. 填写 frontmatter + 简介 + Prompt 正文 # 3. 质量检查 python3 scripts/check_repo.py # 4. 重建目录 python3 scripts/generate_catalog.py # 5. 重建网页 python3 scripts/generate_webpage.py # 6. 更新 CHANGELOG.md，按 vYYYY.MM.N 节奏发布

想动手实践的话，clone 仓库即可完整体验：

git clone https://gitcode.com/gh_mirrors/ya/yao-open-prompts

总结：提示词库工程化的四层配方

yao-open-prompts 给新手的最重要启示，是提示词库不需要"聪明"，只需要可重复：

• 📁分类即架构：编号目录 + 明确分类标准，新增文件有处可放；
• 🏷️元数据先行：统一 frontmatter 让提示词可被机器统计、校验、索引；
• 🔁脚本生成索引：目录、网页、英文 README 全部自动生成，永远与文件同步；
• ✅检查与发布清单化：质量检查脚本 + 评审清单 + 日期版本 tag，让每次发布可预期。

按这套配方，即使是个人收藏的几十个提示词，也能长成结构清晰、可持续迭代的"提示词工程项目"。

【免费下载链接】yao-open-promptsPractical bilingual AI prompt library for prompt engineering, work, learning, content, marketing, and everyday use.项目地址: https://gitcode.com/gh_mirrors/ya/yao-open-prompts