企业官网建设流程全解析

• 人工智能
• AI 技能
• 提示工程
• 媒体生成

ai-image-prompts-skill 是面向 OpenClaw、Claude Code、Cursor 等 AI 助手的 AI 图像提示词库 Skill，内置 10,000+ 条社区精选的图像生成提示词，兼容 Nano Banana Pro、Midjourney、Flux、Stable Diffusion 等主流模型。本文揭秘它背后的数据管线：一条基于 GitHub Actions 的定时任务，每天两次从社区 CMS 拉取最新提示词，自动清洗、分类并同步到 GitHub 仓库，让每个用户拿到的永远是"新鲜出炉"的提示词模板。

一、先认识这套提示词库：它不是普通的"提示词合集"

大多数提示词项目是一份写死的 Markdown 清单，而 ai-image-prompts-skill 的核心资产是一个持续自动更新的 references/ 目录——每个使用场景对应一个 JSON 数据文件，条目内包含提示词正文、标题、描述和示例图片链接，AI 助手可直接检索、引用。

以下是当前库的数据快照（来自 references/manifest.json）：

📦 当前库共有15,771条提示词。注意各分类数之和会超过总数——同一条提示词可以同时归属多个场景，这是"多对多"分类设计。另外最大的单文件social-media-post.json超过 20 MB，手工维护几乎不可能，这正是自动化管线的价值所在。

二、数据管线全景：一张图看懂

整条管线可以概括为：CMS 是唯一数据源 → GitHub Actions 是传送带 → references/*.json 是成品 → setup.js 是用户侧的"最后一公里"。

三、每天两次定时同步：GitHub Actions 是如何配置的

管线的"心脏"是工作流文件 .github/workflows/generate-references.yml，核心配置只有三处：

1. 双 cron 触发器——每天 UTC 00:00 与 12:00 各执行一次，正好覆盖 24 小时：

on: schedule: - cron: '0 0 * * *' # UTC 午夜 - cron: '0 12 * * *' # UTC 正午 workflow_dispatch: # 同时保留手动触发入口

2. 凭据走 Secrets 注入——CMS 地址与 API Key 通过CMS_HOST、CMS_API_KEY两个仓库机密传入 scripts/generate-references.ts，绝不硬编码在代码里。

3. "有变化才提交"防污染设计——生成完成后先执行git diff --exit-code检查，只有数据确实发生变化时，才以chore: update references <UTC时间>为提交信息推回仓库。社区没有新内容时，仓库不会产生任何空提交，提交历史干净可读。

其余步骤是标准的 Node 20 + pnpm 环境搭建：检出代码 → 安装依赖（--frozen-lockfile锁定版本）→ 执行pnpm run generate启动生成脚本。

四、生成脚本深潜：拉取、清洗与落盘

scripts/generate-references.ts 是整个管线的重头戏，逻辑可以拆成五步：

1. 环境校验：缺少CMS_HOST或CMS_API_KEY立即报错退出，避免"静默失败"污染数据；
2. 拉取分类：调用 CMS 的/api/prompt-categories接口，只取use-cases父分类下的场景子分类——分类完全由 CMS 侧动态维护；
3. 分页拉取全量提示词：调用/api/prompts接口，每页 100 条循环翻页直到取完（见 分页循环实现），仅保留model = nano-banana-pro的条目，并按排序权重 + 发布时间倒序排列；
4. 清洗与过滤：没有示例图片的提示词直接丢弃（"能看图选提示词"是这个 Skill 的核心体验）；存在英文翻译字段时优先采用；
5. 落盘三连：先清空references/下所有旧 JSON → 按分类逐个写入新文件（未归类的统一进others.json）→ 最后生成清单文件。

生成的 references/manifest.json 长这样（节选）：

{ "updatedAt": "2026-10-12T03:06:41.884Z", "totalPrompts": 15771, "categories": [ { "slug": "profile-avatar", "title": "Profile / Avatar", "file": "profile-avatar.json", "count": 2133 } ] }

五、manifest.json：让分类彻底"动态化"

manifest 文件是整条管线的单一事实来源（Single Source of Truth），它同时服务两端：

• AI 助手端：SKILL.md 明确规定"不要依赖硬编码的分类表"，助手每次搜索前先读 manifest，根据title语义匹配用户意图，再决定检索哪个 JSON 文件；
• 同步脚本端：客户端下载逻辑不写死任何文件名，而是遍历 manifest 里的categories[]逐个下载。

更有意思的是 SKILL.md 中<!-- REFERENCES_START -->与<!-- REFERENCES_END -->标记之间的分类表格，也是每次生成时自动重写的——新增、改名、删除分类，全程零代码改动，数据流自己"长"出文档。

六、客户端最后一公里：24 小时新鲜度机制

服务端管"新鲜生产"，客户端管"及时送达"。scripts/setup.js 是一个零依赖的 Node 脚本，内置三种模式：

几个值得细品的设计：

• 🕐安装即就绪：package.json 中配置了postinstall钩子，用户安装 Skill 时提示词库自动下载，无需任何凭据——所有数据都是公开的仓库文件；
• 📝时间戳防半失败：只有全部文件下载成功，才会写入.last-updated时间戳文件。一旦部分失败，下次--check仍会触发重试，天然形成断点恢复；
• 🔁24 小时阈值：与"每天两次"的服务端节奏刚好衔接——用户最多落后一次更新，且--check在数据新鲜时是瞬时 no-op，不影响 AI 助手响应速度（SKILL.md 要求每次搜索前先执行它）。

七、手动管理提示词库：3 个常用命令

如果你想在本地亲自"跑一遍"这条管线，记住这三条就够了：

node scripts/setup.js --check # 检查本地库是否过期（新鲜则无输出） pnpm run sync # 强制拉取全部最新 references pnpm run generate # 重新生成 references（需 CMS 凭据，一般由 CI 执行）

八、值得借鉴的 5 个设计亮点

1. Manifest 驱动的动态分类：数据契约先于代码，CMS 加分类 = 全链路自动适配；
2. 有变化才提交：CI 里git diff --exit-code挡掉空提交，历史保持干净；
3. 24 小时新鲜度阈值：在"数据新鲜度"和"网络开销"之间取了个恰到好处的平衡；
4. 全成功才打时间戳：用一个小文件实现"天然重试"，无需复杂状态管理；
5. 大文件只搜不读：SKILL.md 明确禁止整文件加载，要求用grep类方式精确检索——15,000+ 条提示词对 token 消耗的影响被压到最低。

小结：ai-image-prompts-skill 用一份 YAML 定时任务 + 一个生成脚本 + 一个同步脚本，就把"社区创作 → CMS 沉淀 → 每日两次发布 → 用户终端自动更新"这条完整数据管线跑通了。对想做开源数据项目的同学来说，这套"manifest + 定时同步 + 新鲜度检查"的组合拳，几乎可以直接照搬。

• 人工智能
• AI 技能
• 提示工程
• 媒体生成