我最早注意到 prompts.chat，不是在什么技术新闻里，而是一个朋友甩过来的链接：一个页面，一堆按场景分好的提示词，点一下就能复制。当时我第一反应是，这不就是把提示词整理成清单吗？直到我自己开始维护一个类似的提示词项目，才发现“整理成清单”这四个字背后的工作量，远比想象中大得多。
prompts.chat 最大的价值，不是某个提示词写得有多惊艳，而是它把提示词从“聊天框里的随手输入”变成了“可复用、可分类、可协作的内容资产”。更进一步，它从一份个人清单长成一个可自建的开源社区，意味着提示词工程这件事，终于有了内容库和协作机制。如果你也在收集提示词、想做一个提示词站点、或者考虑用开源方式组织自己的提示词库，这篇内容应该能帮你想清楚很多问题。
1. 提示词清单为什么值得单独做一个站
1.1 prompts.chat 最初解决的是“复制粘贴”的痛点
很多人第一次接触提示词清单，是在各种社区帖子、公众号文章或者收藏夹里。看到一个好用的提示词，复制下来，丢进自己的备忘录，等下次要用的时候再翻。这个过程听起来没问题，实际用起来却一塌糊涂：收藏夹里越堆越多，但真到要用的时候，你根本想不起来自己存过什么。
prompts.chat 这类站点解决的问题，本质上就是把“收藏散装提示词”变成“浏览结构化清单”。它给每个提示词一个固定入口，按用途分类，附带可预期的输出效果。你不需要记住某条提示词存到哪儿了，只需要知道自己要干什么，然后去对应分类下翻。
这个逻辑和代码仓库很像。你单独写一段脚本放在桌面，和把它提交到一个带 README、带目录结构的仓库里，完全不是一回事。列表本身不稀缺，稀缺的是围绕列表形成的组织方式。
1.2 清单的复用价值，比单条提示词更高
单条提示词的效果是有限的。你单独写一条“你是一个资深产品经理，请帮我分析需求”，模型给的结果很泛。但如果你的清单里有一套完整的产品分析框架提示词，再配合后续的角色约束、输出格式、检查清单，结果会明显更稳定。
这就是清单的复用价值：它不依赖你每次临时发挥，而是把“优秀输入”沉淀成可重复调用的模板。对个人来说，这是一套私人工作流；对团队来说，这是一套团队知识库；如果把它开源出来，它就是一个社区共同维护的提示词资产库。
prompts.chat 从“清单”变成“社区”，路径也是这么走出来的：先是有人发现“把提示词整理到一起”很爽，然后发现“大家一起来整理”更爽，最后发现“整理出来的东西还能反哺更多场景”。
2. 提示词工程的底层套路：清单背后不是文字，是结构
2.1 提示词的本质，是一份给模型的输入协议
很多人把提示词理解成“对模型说的话”，这个理解不算错，但太浅了。真正好用的提示词，本质上是一份输入协议：它约定了角色、目标、上下文、约束条件、输出格式、质量标准。
你可以把提示词想象成给外包同事写的需求单。需求单上只写一句“帮我做个方案”，对方交回来的东西必然五花八门。但如果需求单写清楚“你是方案负责人、服务对象是谁、要解决什么问题、输出几个模块、每个模块多少字、什么风格、什么时间交”，对方做出来的东西才可能接近你要的。
提示词工程里那些“角色设定”“Few-shot 示例”“输出格式控制”“否定约束”，本质上都是在拉齐这份协议的完整度。prompts.chat 这类清单的价值，就是把经过验证的协议保存下来，让别人直接复用，不需要每次重新试。
2.2 一条高质量提示词的常见结构拆解
我整理了手头一批常用提示词，发现它们基本都包含这几块：
| 组成块 | 作用 | 示例 |
|---|---|---|
| 角色定义 | 限制模型从什么视角回答 | “你是一位有10年经验的运营专家” |
| 任务描述 | 说明用户要什么 | “分析这个活动的转化漏斗” |
| 上下文信息 | 提供前置材料 | 用方括号包裹具体数据 |
| 约束条件 | 规定不能做什么 | “不要写空话，不要超过300字” |
| 输出格式 | 规定回答结构 | “用表格输出，包含结论和建议” |
| 验收标准 | 让模型自检 | “输出前检查是否覆盖了用户痛点” |
这六块不需要每条提示词都有，但至少要占三块以上。你去看那些被广泛传播的提示词，几乎都是这一类完整结构，而不是一句话。
2.3 为什么“鹈鹕骑自行车”这类提示词也能进清单
最近网上很火的“鹈鹕骑自行车”提示词，表面看是个娱乐梗：给它一段文字，生成一张鹈鹕骑自行车的图片。很多人觉得这不就是玩笑吗？但仔细拆开那些效果好的版本，其实包含了主体、动作、环境、视角、风格、光线、画面细节等一系列描述。
“一只鹈鹕在骑自行车”和“黄昏阳光下的鹈鹕，单脚踩在自行车踏板上，羽毛随风扬起，背后是欧洲小镇街道，低机位仰拍，摄影风格，85mm镜头，浅景深”完全是两件事。
这类提示词能火，恰恰说明提示词清单的适用场景比想象中宽：不只是写文案、写代码、做分析，也包括视觉生成那些看起来“不正经”的需求。真正有参考价值的提示词，往往是那些“把模糊想法翻译成模型能理解的结构化描述”的例子。
3. 自建一个提示词社区，我的最小技术栈组合
3.1 先想清楚：自建到底是想解决什么问题
prompts.chat 的可自建属性，意味着你不只是用一个网站，而是可以把整套清单机制跑在自己手里。但在动手之前，我建议先想明白一件事：你自建，是为了隐私、定制、数据归属，还是纯粹想折腾一套自己的东西？
很多人一上来就想搞数据库、搞后端、搞用户系统，结果项目没跑三个月就荒废了。我自己踩过这个坑。提示词这个场景，核心不是技术，是内容组织方式。内容少的时候，你需要的只是一个能看到分类、能搜索、能复制内容的界面。
所以我的建议是：先小后大。第一个版本甚至不需要“社区”，一个静态站就够。
3.2 技术选型对照：从静态页到真正的社区
自建方案可以分成几个台阶，你可以按需选择：
| 方案 | 技术组成 | 适合阶段 | 说明 |
|---|---|---|---|
| 纯静态清单 | Markdown + GitHub Pages / Cloudflare Pages | 个人用 | 维护成本最低，分类清晰 |
| 静态站生成器 | Astro / VitePress / Docusaurus | 内容变多之后 | 支持搜索、侧边栏、标签过滤 |
| 带提交的协作仓库 | Gitea / GitHub + Issue + PR | 开始有人贡献 | 通过提交流程管理新增提示词 |
| 完整社区系统 | 前端 + 数据库 + 用户系统 | 团队或组织用 | 投入大，需要有持续维护动力 |
我个人的推荐组合是：内容用 Markdown 管理，仓库用 Gitea 或 GitHub 托管，展示层用静态站生成器，贡献流程用 Issue 和 Pull Request。
如果你是个人自建，用 Gitea 会比 GitHub 更轻，尤其是你想把仓库放在自己的服务器上时。Gitea 部署非常轻量，一个 Docker 容器就能跑起来。GitHub Desktop 也能正常管理自建的 Gitea 仓库，只需要在克隆地址里填你自己的服务器地址，日常提交、推送、拉取的操作体验和 GitHub 基本没差别。
3.3 内容模型：给每条提示词加“元信息”
自建提示词社区最容易忽略的，不是技术框架，而是内容模型。你需要在每个提示词文件里，给出一套结构化的字段，方便后续生成索引、搜索过滤和标签聚合。
拿我自己项目里的一个模板举例：
--- id: prd-analysis title: PRD 需求分析助手 categories: - 产品 - 需求分析 tags: - PRD - 用户故事 - 优先级 author: jiang created: 2025-01-12 updated: 2025-03-01 license: CC BY 4.0 --- 你是一位拥有十年经验的 B 端产品经理，请基于以下需求描述，产出一份结构化 PRD。 ## 上下文 [把需求背景粘贴在这里] ## 输出要求 1. 按背景、目标用户、核心问题、功能清单、优先级、验收标准输出。 2. 功能清单用表格呈现，优先级用 P0/P1/P2 标记。 3. 不要使用抽象词汇，每条功能描述必须给出可验证的行为结果。这套 Front Matter 看着简单，但它决定了你能不能做到“按分类浏览、按标签搜索、按作者筛选”。我见过很多提示词项目内容不错，却因为没在开头定义字段，后期只能靠人肉找，非常痛苦。
4. 让“清单”长成“社区”：协作机制比代码更关键
4.1 提示词贡献的提交流程要设计得“无痛苦”
开源社区能不能起来，很大程度上取决于贡献者提交一条提示词的摩擦有多大。如果别人要花半小时搞清楚提交格式，那就不会有人来。
我实际实践中比较顺的流程是三步：
- 别人复制模板文件，填好提示词内容。
- 提交 Pull Request，并在说明里写清楚适用场景和验证方式。
- 维护者做合并前检查，重点是看隐私信息和提示词质量，然后合并。
这里有件很关键的事：模板不等于表单，填起来必须足够傻瓜。你要把字段说明写在模板注释里，并在仓库的CONTRIBUTING.md里放一个完整的示例。
4.2 许可证和版权边界，早定比晚定好
既然叫开源社区，许可证就不能随便。提示词算不算软件作品，在版权上其实有点灰色地带，但你至少要在仓库里明确授权方式，避免别人复制走了又反过来投诉。
常见选项有这几种：
| 许可证 | 适合场景 | 注意 |
|---|---|---|
| CC0 | 希望提示词完全进入公共领域 | 放弃署名权，社区控制力弱 |
| CC BY 4.0 | 允许分享、修改，但要求署名 | 比较适合提示词库 |
| MIT | 类似代码开源逻辑 | 适合附带代码的提示词项目 |
| Apache 2.0 | 想加入专利授权条款 | 提示词项目用得不多 |
我的偏好是 CC BY 4.0：允许别人拿去改造、商用，但保留了署名要求。这样既能扩散，又不会导致项目的源头完全被人无视。
4.3 分类和标签体系要靠“日常维护”
很多开源项目死不是死在没人贡献，而是死在分类体系崩了。一开始只有几十条，目录随便放没什么问题。等有两三百条，大家开始为了“这个应该放生产力还是写作”而分歧。
这个阶段，你需要一套维护策略：分类控制在 6~8 个一级大类，标签不限，但提交时必须从预定义标签里选。如果你想加新标签，要先提 Issue 讨论，而不是自己在 PR 里直接加。
我自己的经验是，分类不求全面，求稳定。一个分类下如果只有两三条提示词，就先挂到“其他”或相近分类里，等数量够了再拆。
5. 运行过程中会踩的坑，我都替你踩了一遍
5.1 提示词质量污染比想象中严重
提示词社区最大的风险，是“能跑”和“好用”之间没有被区分。随便写一条“你是一个专家，请回答我的问题”，它能跑，但没有沉淀价值。如果人人都往里加这种内容，这个清单很快就废了。
我会在提交流程里增加“验收描述”字段，要求贡献者说明：这条提示词适用场景是什么，输出有什么特点，和现有同类提示词有什么区别。就算无法做严格的数据评测，“这个理由能说清楚”本身就是一道过滤网。
5.2 搜索体验做不好，社区再热闹也没用
清单超过两百条之后，分类浏览就不够用了。你必须有全文搜索和标签过滤。静态站点上可以做简单的前端搜索，把标题、描述、标签全部索引进来，体验会比很多人想象中好。
我建议直接不要做“登录才能搜索”的设计。提示词社区的核心使用场景是快速复制，任何阻碍复制的交互都是在榨干用户耐心。复制按钮要显眼，代码块和普通文本要分开，移动端样式要保证能用。
5.3 更新维护节奏决定项目生死
开源提示词项目有个隐性成本：大模型迭代太快，提示词失效也很快。三五个月前好用的提示词，换了个模型版本，可能效果就明显下滑。如果你建了社区却半年不更新，等你回来看的时候，内容可能已经全部过时。
我的建议是：设一个明确的最小维护频率。哪怕一个月只更新一次，也要让用户知道项目还活着。同时，在每条提示词里注明“最后验证日期”，比在站点公告栏里写“长期维护”更有说服力。
5.4 冷启动阶段，别指望“开源”自动带来贡献者
开源社区是一个有网络效应的东西，但网络效应启动之前，内容质量只能靠你自己顶。头五十条提示词，大概率只有你一个人在写，这很正常。很多人就是在这时候放弃的。
我的处理方式是：把积累过程公开化。每次更新都写一条 commit 说明，告诉关注者“这周加了什么，删了什么，为什么调整”。即使只有几个 star，透明维护记录也会让后来者觉得这个项目是认真在跑的。
6. 如果让我重做一次，我会这样把项目落地
6.1 先定内容模型，再碰任何前端框架
血泪教训顺序：先写清楚一条“提示词文件”长什么样，再决定用什么技术展示它。内容模型稳定了，前端不过是把它渲染出来；内容模型乱了，前端写得再漂亮也是空中楼阁。
具体来说，我应该先用两周时间，把自己在用的所有提示词按统一模板整理好，再开始搭静态站。这样既验证了模板是不是够用，也顺便攒出了第一批高质量内容。
6.2 一切流程都围绕“让复制和贡献变简单”
一个提示词网站，核心动作无非两个：用户复制提示词、贡献者添加提示词。其他都不重要。我不会再做复杂账号体系，不会做点赞积分，不会做花里胡哨的页面动效。按钮就一个，点击就是复制；添加就是提 PR。
如果你的目标是社区化，那么对贡献者的正向反馈也得跟上。合并之后第一时间在更新日志里列出贡献者名字，和项目首页标注贡献者列表，这些看起来很小的事，对早期社区凝聚力的影响很大。
6.3 最后留一个扩展位：给提示词做版本对比
我最近在考虑给提示词加“验证记录”字段：同一条提示词在不同模型下的表现差异。比如同一套提示词，在 A 模型下表格结构更稳，在 B 模型下语言更自然。如果这个信息能随着开源社区沉淀下来，那就不是“提示词清单”，而是一份带可观测数据的提示词工程资源库了。
这会比单纯堆几百条提示词更有长期价值。因为大模型会变，提示词技巧会变，但“什么输入在什么模型上产生什么输出”的实证数据，永远有参考意义。
如果你也想搭一个提示词站点，我的建议是从一份自己的清单开始，先跑通“复制、分类、检索”这三件事，再考虑开源、协作和社区。prompts.chat 给我的最大启发，不是它有多少内容，而是它一开始也没想着要做得多大——它只是认真把提示词整理好了，然后顺着用户需求，一步一步长成了可以自建、可以参与的东西。
