Prompts.chat：开源提示词平台、自托管方案与 MCP 集成完全指南

难度：⭐⭐⭐ 到 ⭐⭐⭐⭐ | 类型：工具全景指南 | 预计阅读时间：30 分钟 适合读者：AI 使用者、提示词工程实践者、开发者、技术内容策展人、想自建提示词库的团队 一句话定义：Prompts.chat 不只是“提示词列表”，而是一个面向人类用户与 AI Agent 同时开放的提示词平台、提示词资产库与可自托管基础设施。 事实边界：本文仅基于官方站点、GitHub 仓库主页、公开 API 文档、SELF-HOSTING 指南、CLAUDE.md 等可验证公开信息撰写。由于未逐行审阅全部源码，本文的“源码分析”以目录级、关键文件级和架构级解读为主，不对未公开验证的内部细节做推断。

Prompts.chat 的价值，不在于“收集了很多提示词”这么简单，而在于它把提示词从一次性文本，变成了可以浏览、搜索、复用、分享、版本化、私有化部署、再进一步通过 API 和 MCP 嵌入 Agent 工作流的提示词资产层。

如果你只是想快速判断它值不值得用，可以先记住 4 个结论：

1. 对普通用户来说，它是一个高质量的提示词发现与复用平台。
2. 对团队来说，它是可以白标化、自托管的提示词知识库。
3. 对开发者来说，它是一个同时提供 Web、REST、MCP、插件接入能力的提示词基础设施。
4. 对 AI Agent 生态来说，它最重要的意义是把“提示词检索与调用”做成了机器也能直接消费的接口层。

学习目标

读完本文，你应该能回答以下问题：

1. Prompts.chat 究竟是提示词网站，还是提示词平台？
2. 它和“把提示词写在 Markdown 文档里”相比，核心优势在哪里？
3. 它的 Web、API、MCP、自托管和 Claude Code 集成分别适合什么场景？
4. 如果你准备二次开发或团队内部部署，应该先看哪些入口文件和配置项？
5. 从新手到专家，应该如何逐步把它用成个人工具、团队资产和 Agent 基础设施？

一、Prompts.chat 到底是什么

1.1 先给出严格定义

从公开资料看，Prompts.chat 可以被更准确地定义为：

一个开源、社区驱动、支持自托管、支持程序化访问的提示词平台。

这个定义里有 5 个关键词：

1.2 它与早期 “Awesome ChatGPT Prompts” 有什么关系

Prompts.chat 的仓库主页明确写着：它前身是 Awesome ChatGPT Prompts。这意味着它不是从零起步的新产品，而是从最早一批“提示词集合”演化而来。

这条演化路径很关键，因为它解释了为什么 Prompts.chat 同时具备两种气质：

• 一方面，它保留了“社区提示词集合”的开放性和可传播性；
• 另一方面，它又逐步发展出“平台产品”的搜索、提交、私有化、API、MCP、自托管等能力。

换句话说，它已经不只是“把提示词放在 GitHub 上”，而是在把提示词做成一套可管理、可分发、可集成的内容系统。

1.3 可验证的公开事实

以下内容来自官方主页、官方仓库主页和公开文档：

1.4 为什么这个项目值得认真研究

很多提示词库的问题在于：适合看，不适合用；适合复制，不适合管理；适合人类浏览，不适合机器调用。

Prompts.chat 的特别之处在于，它在公开资料中同时解决了这三件事：

1. 给人看：有站点、分类、标签、搜索、儿童教育内容、交互式书籍。
2. 给团队管：有私有提示词、认证、白标化、自托管、主题与品牌配置。
3. 给工具调：有 MCP、API Key、HTTP 请求方式、REST 搜索接口、技能接口。

这就是它从“提示词集合”升级成“提示词基础设施”的关键。

二、Prompts.chat 解决了什么问题

2.1 提示词管理的真实痛点

如果团队没有专门的平台，提示词通常会散落在：

• 聊天记录里；
• 飞书、Notion、Google Docs 文档里；
• Markdown 仓库里；
• 个人剪贴板和命令历史里；
• 各种内部群聊中。

这会带来几个典型问题：

2.2 Prompts.chat 的解法

Prompts.chat 的公开能力，基本对应上面 5 个痛点：

因此，Prompts.chat 解决的不是“缺少一个提示词网页”，而是“缺少一套可复用、可运营、可集成的提示词系统”。

三、功能全景：它到底能做什么

3.1 面向最终用户的能力

从官方站点和文档可确认，Prompts.chat 至少包含以下用户侧能力：

3.2 面向内容贡献者的能力

Prompts.chat 不是只读目录，它还支持“内容生产和优化”：

这说明 Prompts.chat 的思路不是“把最终答案贴上去”，而是把提示词当作持续演进的内容对象来管理。

3.3 面向学习者的能力

Prompts.chat 在“教学”上也做得比较完整：

这意味着它不仅提供“答案”，还试图提供“方法论”。

3.4 面向开发者与 Agent 的能力

这是 Prompts.chat 最容易被低估的一层。

公开 API 文档显示，它不只暴露了普通提示词接口，还把提示词访问能力做成了 MCP 和工具接口：

这让 Prompts.chat 从“提示词站点”升级为 “Prompt + Skill” 的内容服务层。

四、从新手到专家：最合理的使用路径

如果你第一次接触这个项目，最好的学习方式不是一头扎进自托管，而是按能力层次逐步推进。

4.1 新手阶段：先把它当成高质量提示词入口

这个阶段只做 4 件事：

1. 浏览站点，感受分类与标签是如何组织提示词的。
2. 搜索和复制几个常用提示词。
3. 留意提示词中是否包含变量位。
4. 对比“普通一句话提示”与“结构化提示词”的差异。

你的目标不是“学会全部功能”，而是建立一个判断：

什么样的提示词值得沉淀成资产，而不是临时打一遍就忘。

4.2 进阶阶段：把提示词从文本变成可管理对象

这一阶段，重点从“使用”变成“管理”：

• 给提示词补标题、描述、标签、分类；
• 区分公开提示词与私有提示词；
• 用统一命名和主题组织提示词资产；
• 尝试保存和复用个人常用提示词。

这一步最重要的认知变化是：

优秀提示词不是聊天时的一次灵感，而是可以维护、搜索、版本化、分享的内容资源。

4.3 高手阶段：接入 MCP、API 和工作流

当你开始把提示词用于自动化工作流时，Prompts.chat 的价值会明显上升。

典型做法包括：

• 在 AI IDE 中接入 MCP，让 Agent 直接搜索提示词；
• 通过 REST API 查询某类提示词；
• 通过 get_prompt 动态获取模板并填充变量；
• 用 improve_prompt 让系统协助把原始想法改写成更成熟的提示词。

4.4 专家阶段：自托管、白标化、团队治理

如果你要把它变成团队平台，就进入专家阶段：

• 自托管独立实例；
• 配置品牌、主题、认证方式；
• 启用私有提示词和变更请求；
• 设计团队标签体系和分类体系；
• 把 MCP 接口接给内部 Agent、编辑器、自动化流程。

此时，Prompts.chat 已经不再只是“网站”，而是在团队内部承担提示词知识库 + 提示词发布平台 + 提示词 API 层的角色。

五、使用说明：普通用户、开发者、团队管理员分别怎么用

5.1 普通用户怎么用

对于普通用户，最直接的用法是：

1. 打开官方站点浏览提示词；
2. 用关键字搜索相关主题；
3. 按分类、标签或类型过滤；
4. 复制提示词内容到 ChatGPT、Claude 等工具中；
5. 如果提示词中包含变量，则按场景替换变量值。

根据官方自托管文档中的产品说明，浏览公共提示词通常不需要账号；而创建、保存和管理个人提示词时，则需要登录。

如果你注册并登录，还可以进一步：

• 保存自己的提示词；
• 保留私人提示词；
• 参与社区内容贡献与互动。

5.2 开发者怎么用

5.2.1 命令行入口

官方仓库主页给出的 CLI 入口是：

npx prompts.chat

如果你的诉求是快速试用，而不是长期部署，这是最轻量的入口。

5.2.2 Claude Code 插件

仓库主页公开了 Claude Code 插件安装方式：

/plugin marketplace add f/prompts.chat
/plugin install prompts.chat@prompts.chat

它的意义不是“把网站搬进 Claude”，而是让 Claude Code 在工作环境内直接调用 Prompts.chat 的提示词能力。

5.2.3 MCP 集成

这是当前最值得开发者关注的部分。

远程模式：

{
  "mcpServers": {
    "prompts.chat": {
      "url": "https://prompts.chat/api/mcp"
    }
  }
}

本地模式：

{
  "mcpServers": {
    "prompts.chat": {
      "command": "npx",
      "args": ["-y", "@fkadev/prompts.chat-mcp"]
    }
  }
}

为什么优先推荐远程模式？因为远程模式直接连接官方 MCP Endpoint，省去了本地服务进程维护成本。只有当你需要本地控制、环境变量隔离或定制运行方式时，本地模式才更有优势。

如果你希望让某个客户端只看特定作者、分类或标签，公开 API 文档还支持把过滤条件直接写进 MCP URL 查询参数，例如：

{
  "mcpServers": {
    "prompts-chat": {
      "url": "https://prompts.chat/api/mcp?categories=coding&tags=js"
    }
  }
}

5.2.4 认证与 API Key

公开 API 文档说明：

• 大多数查询功能可以匿名使用；
• 保存提示词、访问私有提示词等功能需要 API Key；
• API Key 以 pchat_ 开头；
• 在远程 HTTP 模式下，通常通过 PROMPTS_API_KEY 请求头传递。

示意配置如下：

{
  "mcpServers": {
    "prompts-chat": {
      "url": "https://prompts.chat/api/mcp",
      "headers": {
        "PROMPTS_API_KEY": "pchat_your_api_key_here"
      }
    }
  }
}

5.2.5 REST 接口

如果你不需要 MCP，而只想做传统程序集成，也可以使用 REST 搜索接口：

curl "https://prompts.chat/api/prompts?q=code+review&perPage=10"

这适合：

• 内部工具只需要“搜索提示词”；
• 暂时不想引入 MCP 客户端；
• 想用普通 HTTP 请求快速验证能力。

5.3 团队管理员怎么用

如果你要给团队搭一个“内部提示词库”，最实用的路径是自托管。

官方 SELF-HOSTING 指南给出的前置条件是：

• Node.js 18+
• PostgreSQL
• npm 或 yarn

快速开始：

npx prompts.chat new my-prompt-library
cd my-prompt-library

手动安装：

git clone https://github.com/f/prompts.chat.git
cd prompts.chat
npm install
npm run setup

根据 SELF-HOSTING 指南，安装向导会引导你配置以下内容：

• 品牌名称、Logo 与描述；
• 主题圆角、样式与主色；
• 认证方式；
• 可用语言；
• 私有提示词、分类、标签、AI 搜索、MCP 等功能开关。

之后还需要：

cp .env.example .env
npm run db:migrate
npm run dev

如果面向生产环境，还需要构建和启动：

npm run build
npm run start

六、工作原理：Prompts.chat 为什么不只是一个“提示词网页”

6.1 它的核心对象不是页面，而是“提示词实体”

从 API 和平台能力来看，Prompts.chat 的设计中心不是页面，而是 “Prompt Object”。

一个提示词对象至少会围绕这些维度被管理：

• 标题；
• 内容；
• 描述；
• 分类；
• 标签；
• 类型；
• 作者；
• 可见性；
• 版本与变更关系。

这意味着系统处理的不是“文章段落”，而是可检索、可过滤、可调用、可分享、可持续更新的内容实体。

6.2 Web、REST、MCP 共用的是同一套内容资产

这是它的第二个关键点。

从公开文档看，同一个平台能力会被多个入口复用：

也就是说，Prompts.chat 并不是“给网站做了一个 API”，而更像是“围绕统一内容资产，提供了多个消费端”。

6.3 MCP 为什么是它的战略重点

很多提示词库的终点是“让人复制提示词”。Prompts.chat 进一步往前走了一步：让 Agent 直接检索和获取提示词。

这意味着提示词不再只是阅读材料，而是变成了：

• AI 编程工具的外部知识源；
• Agent 的任务模板库；
• 自动化流程中的可调用内容资产；
• 技能系统与工作流编排的上游输入。

因此，MCP 集成不是一个“附加功能”，而是它平台化程度的重要标志。

6.4 变量替换机制解决了“同一提示词反复手改”的问题

API 文档明确提到：

• prompts/get 支持带变量的提示词；
• 变量形如 ${name} 或 ${topic:default value}；
• 支持 elicitation 的 MCP 客户端会向用户补采这些变量值。

这件事看似小，实际上很重要。因为它把“复制一段固定文本”升级成了“调用一个可参数化模板”。

这正是提示词从静态内容走向可编排资产的一步。

6.5 improve_prompt 的原理是什么

官方文档对 improve_prompt 给出的说明很明确：它会先查找相似提示词作为参考，再生成改进版提示词，同时尽量保留原始意图。

这意味着它背后的思路大致是：

1. 输入一个比较原始的提示想法；
2. 用相似提示词做“灵感检索”；
3. 基于检索结果和模型生成能力输出更结构化的版本；
4. 最终返回 improved prompt 和 inspirations 信息。

注意，这里我们只能依据公开文档说明它的输入输出逻辑，而不能假设它的内部模型编排细节。

七、架构分析：从公开资料能确认什么

7.1 技术栈总览

仓库中的 CLAUDE.md 给出了非常明确的项目概览：

7.2 公开的目录结构说明了什么

CLAUDE.md 中披露了这样一组核心目录：

src/
├── app/              # Next.js App Router pages
│   ├── (auth)/       # Login, register
│   ├── api/          # API routes
│   ├── prompts/      # Prompt CRUD pages
│   └── admin/        # Admin dashboard
├── components/       # React components
│   ├── ui/           # shadcn/ui base components
│   └── prompts/      # Prompt-related components
└── lib/
    ├── ai/           # OpenAI integration
    ├── auth/         # NextAuth setup
    └── plugins/      # Auth and storage plugins

从这个结构可以做出有依据的高层判断：

1. 这是一个标准的全栈 Next.js 应用，而不是纯静态站点。
2. app/api 表明它内置了 API 路由层。
3. app/prompts 说明“提示词 CRUD”是产品核心，不只是展示页。
4. admin 目录意味着平台存在后台治理或管理维度。
5. lib/plugins 说明它在认证或存储等方向上考虑了插件化扩展。

7.3 关键文件的职责边界

公开资料列出的关键文件如下：

对二次开发者来说，这 5 个入口的优先级非常高，因为它们分别对应：

• 平台配置；
• 数据结构；
• 认证与权限；
• 数据访问；
• 国际化扩展。

7.4 可以怎样理解它的分层

在不臆测未公开细节的前提下，可以把 Prompts.chat 理解为 4 层：

这种结构的好处是：

• Web 产品可用；
• 自托管容易定制；
• 程序接口可独立消费；
• 多语言和品牌能力可以配置化复用。

八、源码分析：如果你准备二开，先看哪里

8.1 第一个入口：prompts.config.ts

SELF-HOSTING 指南给出的配置示例非常有代表性，它显示出这个项目的二开思路不是“让你改一堆源码”，而是先通过配置做大部分定制。

配置项可确认包括：

• branding
• theme
• auth
• features
• homepage
• i18n

这说明项目具有明显的配置驱动特征。对于内部部署团队来说，这种设计非常友好，因为常见的品牌和功能改造可以先通过配置完成。

8.2 第二个入口：prisma/schema.prisma

虽然本文没有直接逐行审阅 schema 文件，但只要项目以 Prisma 为核心 ORM，这个文件就是数据模型的权威来源。

如果你准备扩展：

• 自定义提示词字段；
• 增加组织、团队或项目维度；
• 扩展投票、收藏、版本、审阅能力；
• 接入更多审计字段；

那你最先要读的就是这个 schema。

8.3 第三个入口：src/lib/auth/index.ts

自托管文档已经明确说明支持多种认证方式，例如：

• GitHub
• Google
• Apple
• Azure AD
• Email/Password

因此，认证模块不是附属功能，而是平台化能力的重要一环。任何涉及私有提示词、团队权限、组织身份映射的二开，几乎都离不开这里。

8.4 第四个入口：src/lib/db.ts

CLAUDE.md 将它定义为 Prisma client singleton，这个细节非常重要。它通常意味着项目在处理数据库客户端实例生命周期时，采取了较为标准的集中访问方式。

对开发者来说，这个文件通常意味着两件事：

1. 它是数据访问统一入口之一；
2. 你在写新的服务逻辑时，最好沿着现有数据访问模式扩展，而不是随处重新创建数据库连接。

8.5 第五个入口：messages/*.json

自托管文档提到语言选择，CLAUDE.md 又明确指出了 messages/*.json 的存在。这说明国际化不是后加能力，而是项目一开始就考虑的重要维度。

如果你准备做：

• 中文化优化；
• 企业内部术语替换；
• 多语言提示词门户；

那这些消息文件就是非常关键的切入点。

九、开发扩展：Prompts.chat 最值得做的二开方向

9.1 白标化私有提示词平台

这是最直接的一类扩展。

官方配置示例显示，你可以定制：

• 名称；
• Logo；
• 深色 Logo；
• 描述；
• 主题圆角；
• 主题样式；
• 主色；
• 首页是否展示 Prompts.chat 成就和赞助信息。

这意味着它非常适合被改造成：

• 企业内部提示词门户；
• 某个业务团队的行业提示词库；
• 面向客户的品牌化提示词网站；
• 培训用提示词学习平台。

9.2 功能开关化扩展

文档示例中的 features 说明，至少以下能力可被显式控制：

• 私有提示词；
• 变更请求；
• 分类；
• 标签；
• AI 搜索。

这类设计的价值在于：你可以按组织成熟度逐步开启，而不是一次把所有功能都暴露出来。

9.3 把提示词平台扩展为 Skill 平台

公开 API 文档里，最值得关注的一点是：它不只支持 save_prompt，还支持 save_skill 和 get_skill。

这意味着 Prompts.chat 的对象模型已经不只停留在“单段提示词”，还开始覆盖“多文件技能包”这类更复杂的内容资产。

对 AI 开发者来说，这很有想象空间，因为它允许你：

• 存储完整的 Agent Skill；
• 给 Skill 附带参考文档和脚本；
• 把 Skill 当作可分发内容而不是散装文本。

9.4 内部 Agent 的提示词供给层

如果你的团队在做 Agent，Prompts.chat 可以扮演一个非常明确的角色：

把它当作 Agent 的上游提示词仓库，而不是最终交互界面。

典型模式包括：

• Agent 先调用 search_prompts 找模板；
• 再用 get_prompt 拉取完整内容；
• 由客户端补齐变量；
• 最终将生成后的提示词注入具体模型调用链。

这种模式比把提示词硬编码进代码更易维护，也更适合运营型优化。

十、使用场景：哪些人最应该关注 Prompts.chat

十一、优点、边界与注意事项

11.1 明显优点

11.2 必须知道的边界

11.3 常见误区

误区一：Prompts.chat 只是一个提示词网页。

不对。它至少已经同时具备内容平台、自托管产品、API 服务、MCP 服务和 Skill 内容接口等属性。

误区二：提示词平台只适合新手。

不对。新手受益于现成模板，高手受益于参数化模板、版本化、团队治理和 Agent 集成。

误区三：自托管只是“把官网复制一份”。

不对。白标、自定义认证、功能开关、私有提示词等能力，使它更接近一个可运营的内部产品。

十二、常见问题

12.1 它支持哪些 AI 模型

官方仓库主页明确提到，它适用于 ChatGPT、Claude、Gemini、Llama、Mistral 等现代 AI 助手。更准确地说，它提供的是模型无关的提示词资产，而不是只绑定某一家模型厂商。

12.2 它适合个人还是团队

两者都适合。

• 个人用户适合把它当作提示词发现与复用平台；
• 团队适合把它当作可自托管的提示词知识库与工作流入口。

12.3 它可以商用吗

公开授权为 CC0 1.0 Universal，整体方向上对商业复用非常友好。但如果你的使用场景涉及额外的第三方内容、企业合规或内部安全要求，仍然需要结合自身制度审查。

12.4 MCP 和普通 API 有什么区别

简单理解：

• REST API 更适合传统程序调用；
• MCP 更适合 AI IDE、Agent、助手类客户端直接接入。

如果你的目标是“让 AI 工具自己去搜提示词”，MCP 通常更自然。

12.5 它的“源码分析”为什么没有深入到具体函数

因为本文严格遵守“只写可验证事实”的原则。公开资料已经足够支撑架构级、目录级和关键文件级分析，但若没有逐文件源码审阅，就不应该编造更细的内部实现细节。

十三、结论：Prompts.chat 的真正价值是什么

如果只把 Prompts.chat 看成“提示词大全”，你会低估它。

它更准确的价值在于：

1. 把提示词做成资产：可搜索、可过滤、可分享、可版本化。
2. 把提示词做成平台：有人类界面，也有认证、私有化、配置与治理。
3. 把提示词做成接口：可被 REST、CLI、Claude Code、MCP、Skill 工作流直接消费。
4. 把提示词做成基础设施：适合个人复用，也适合团队沉淀，更适合 Agent 生态集成。

从“新手复制提示词”到“专家构建内部 Prompt Hub”，Prompts.chat 覆盖的是一条完整路径。

这也是它最值得重视的地方：它不是单点工具，而是一层正在成形的 Prompt Infrastructure。

相关链接

• GitHub 仓库：f/prompts.chat
• 官方网站：prompts.chat
• API 文档：prompts.chat/docs/api
• 自托管指南：SELF-HOSTING.md
• 儿童入口：prompts.chat/kids
• 互动书籍：prompts.chat/book