在 Notion 搭一个 300 条提示词的营销提示词库（让团队别再反复问你要同一套 prompt）

我的 Notion 提示词库到 300 条那天，我在找一份我很确定六个月前写过的 blog 大纲模板。一位同事在 Slack 上甩给我一份同一个 prompt 的两倍好版本——她一直在自己的 Google Doc 里藏着。那一刻我意识到：提示词库不是个人笔记，得当成团队共享工具来做。

大多数人听到「提示词库」第一反应是：一个 50 条复制粘贴的 Google Doc，三个月就过时了。这种库不值得搭。真正能复利的版本是一个结构化的 Notion 数据库（一种结构化表格，每条 prompt 是一行，每个属性是一列，可以筛选和排序），配分类、版本历史和明确的负责人。我自己的库跑着 300+ 条，覆盖内容、SEO、付费、邮件、增长——团队天天用，因为它回答的是周二上午 10 点我们所有人真正在问的那个问题：「上次用的那条 prompt 是啥？」

下面是我在 18 个月里、为多个真实客户和内部团队跑出来的端到端搭建流程。

第 1 步：先把数据库结构（schema）定好

大多数提示词库会死，是因为 schema（列定义）在写了一百行之后才被补出来。先加一列「tags」，再补一列「model」，再来一列「last used」，到第 200 行时横向得滚屏才能看完。先定 schema，再写第一条 prompt。

下面这套属性（property，即 Notion 数据库的列）在三支不同团队、累计 1,200+ 条数据上跑下来仍然稳：

属性	类型	用途
Name	Title	简短、动作导向的命名（如「Blog outline — listicle, 1500w」）
Category	Select	8–10 个分类之一（见第 2 步）
Use case	Multi-select	这条 prompt 具体做什么（「ad copy」「subject lines」「content brief」）
Model	Multi-select	适用于哪些 LLM（Large Language Models，大语言模型——ChatGPT、Claude 等，「Claude Sonnet」「GPT-4o」「any」）
Variables	Multi-select	这条 prompt 期望的占位符（例如 {{product}}、{{audience}}，见第 3 步）
Status	Select	Draft / Active / Retired
Owner	Person	谁负责保持它可用
Last used	Date	手动更新——每次跑过就更新一次
Version	Number	重大调整时自增
Example output	Files & media	截图或粘贴一份输出，让别人知道「好」长什么样
Notes	Text	这条 prompt 为什么存在、替代过什么、要注意什么

两条不要做的事。别加「Rating」或「Effectiveness score」属性——你永远填不完整；一条低分但填补小众场景的 prompt，比没有强。别把完整 prompt 文本塞进一个 Text 属性；用 page 正文（Notion 数据库里每一行都是一个 page，prompt 主体写在那个 page 的正文区，不在属性列里）。

第 2 步：建 8–10 个分类，而不是 30 个

如果让团队自由打 tag，三个月后你会得到 87 个分类，谁都找不到东西。先把分类列死，别再扩。

试过几版之后，下面这套分类我坚持用了：

• Content — 博客、brief、大纲、二次创作
• SEO — 关键词聚类、brief、页面审计、内链
• Paid Media — 广告文案、RSA（Responsive Search Ad，谷歌自适应搜索广告）素材、人群 prompt、创意 brief
• Email — 标题、序列、再激活、事务邮件改写
• Social — LinkedIn、X、短视频脚本、二次分发
• Growth — 落地页文案、引流磁石、新手引导
• Analytics — 看仪表盘、解释异常、类 SQL 的数据提问
• Research — 竞品分析、市场规模估算、用户访谈提炼
• Operations — 内部沟通、会议纪要、复盘、决策文档
• Image prompts — Midjourney / DALL-E / Nano Banana 的提示词（建议单独成库或子库）

九条对大多数团队刚刚好——少到能一眼扫完，多到分类之间不会挤破头。真的需要 12+ 的话，说明你该拆成多个库，而不是把一个库撑爆。

每个分类内部，用 Use case 多选再细分。我库里的「Content」分类下有 60+ 条 prompt，拆成「blog outline」「intro hook」「meta description」「TL;DR」「case study writeup」等等。两层筛选就够用。

第 3 步：把 prompt 写成模板，而不是聊天记录

提示词库里的每一条 prompt 都应该能被没参与你写它的人复用。这意味着两件事：会变的部分用变量，不变的部分用上下文。

变量用 {{双花括号}} 语法。我库里的 prompt 变量在 0–6 个之间。举例：

• Write a {{format}} blog outline on {{topic}} targeting {{audience}} with a {{tone}} tone.
• Generate {{n}} Google Search ad headlines (max 30 chars) and {{n}} descriptions (max 90 chars) for {{product}} targeting {{audience}}. Each headline should highlight {{proof_point}}.
• Audit this landing page copy for {{audience}} looking to {{job_to_be_done}}. Flag: weak hooks, vague claims, missing objection handling, CTAs (Calls to Action，行动号召) without specificity.

上下文用「Role / Task / Constraints」（角色 / 任务 / 约束——一种标准的 prompt 结构：让 AI 扮演谁、要产出什么、必须避开什么）开头写 1–3 行。以 blog 大纲 prompt 为例：

Role: 你是一位有 10 年 B2B SaaS（Business-to-Business Software as a Service，面向企业的软件服务）经验的高级内容策略师。 Task: 产出一份结构化的 blog 大纲，让一个写手能在 90 分钟内填完。 Constraints:

• 二级标题（H2）尽量用问句形式（匹配搜索意图）。
• 必须包含至少一个反常识角度——不允许写「10 个小技巧」型清单。
• 结尾必须有一段「这条内容哪里说得不对」，预先回应最强反对意见。
• 目标字数：{{word_count}}。

变量写进第 1 步的 Variables 属性，主体放在 page 正文里。团队里谁都能复制、改变量、发布。

第 4 步：用「page history」做版本控制，别用「分支」

Notion 自带页面历史（每次修改自动按时间戳存档，免费版可回溯 30 天，付费版更久）。但别把自动存档当有意打版本号的替代品。

我跑通的纪律有三条：

1. 重大修改要打版本号。 改完一条 prompt——加了一个约束、调细了 role、修了一个已知翻车点——就把 Version 属性自增，标题前缀加 v3 — 。Name 属性是「Blog outline — listicle, 1500w」，页面标题变成「v3 — Blog outline — listicle, 1500w」。同事打开就知道这是第三版，不是第一版。
2. 在 page 正文顶部留一行「Change log」。 不用写完整 changelog，每个版本一行：v2 (2025-08): 加了「不允许 10 招清单」约束，源自 Sarah 那篇 B2B SaaS 文章翻车。未来的你（或者六个月后的同事）能看清这条 prompt 长成这样的原因。
3. Retire，别 Delete。 一条 prompt 被替代时，把 Status 改成 Retired，在正文里加一条链接指向替代它的新 prompt。删了就丢了组织记忆。我库里有 47 条 retired prompt，大概每个季度会有一条被重新激活——老用例总有一天会回来。

免费版 30 天的历史已经够用，前提是你改 prompt 的当天就 bump Version。别把所有记忆甩给 Notion。

第 5 步：按两层权限分享

团队不能编辑的提示词库会变成坟场。团队能误删的提示词库会变成恐怖片。两层权限能解。

• Teamspace（Notion 里的共享工作区，相当于一个团队都能访问的文件夹）放整个数据库，市场团队默认 Can edit，其他人 Can view。免费版要手动加每个成员；Plus 及以上可以用 group 权限统一管。
• 库内部用 Status 把关信任。 Draft 可见但有标记；Active 是工作集；Retired 是单独视图，默认在 Board 视图里隐藏。这样库首页永远不是 47 条半成品——首页显示的是当下敢用的 200 多条。

团队再大点，加一个 Reviewer 字段。任何新 prompt 升级到 Active 之前要过两个人的 review。30 条的时候这是过度设计；300 条的时候这是库还能不能信的唯一保障。

第 6 步：每月 30 分钟的维护循环

300 条这种规模，不碰就会烂。最小可行的维护清单：

• 每月第一个周一： 扫一遍 Draft，把好的提上来，把死的 retire 掉。预算 20 分钟。
• 跑一次「翻车 prompt 接力」： 每个季度让团队把过去 90 天里翻过车的 prompt 丢到 Notion 一个 inbox 里。诊断、修一修、bump 版本、或 retire。预算 30 分钟。
• 更新 Last used： 本月真跑过的 prompt 都 bump 一下。不用太较真——但一条 6 个月没人用、又不算小众用例的，就是 Retired 候选。

就这些。每月总开销 45 分钟。换来的复利是：一个新人入职第 7 天就能产出跟资深市场人同等质量的东西，因为 prompt 在那、且都是「打过仗的」。

一个 300 条的库真正买到了什么

几件我没预期到的事：

• 跨团队复用。 SEO 团队的关键词聚类 prompt 被内容团队接手（只换了变量）。两个团队、一条 prompt、零次重复发现。
• AI 工具评测更轻松。 OpenAI 发了新模型，我从库里拿同 12 条 prompt 跑一遍对比输出。同任务、同输入，只换 Model 属性再跑。是穷人版的 benchmark（基准测试，一种结构化的模型效果对比），但比凭感觉强。
• 新人上手更快。 新市场人第一天就能跑已经经过几百次战役的 prompt。第一周不再需要「看我做三遍」——变成「打开库、找到 prompt、跑起来」。

最大的转变其实是「团队共享」这个角度。我意识到 217 条自己存的 ChatGPT 对话对除我之外的任何人都毫无用处那天，就是我开始搭这个库的那天。到 300 条，它不再是「我的笔记」，是团队基础设施。

你现在 prompt 体系里最大的缺口是分类不齐，还是协作模式跑不通？这个答案会告诉你先动手哪一步。