当你在重复性工作中使用AI时，可能会发现自己一遍遍编写同类提示词：礼貌但坚定的拒绝邮件、文档审核、结构化决策支持或图像简报。每次重写结构也会改变指令，使结果更难比较。
一种实用做法是建立提示词库：一套规模不大、经过筛选且可以检索、测试和修订的模板。下面将介绍如何构建、应记录什么、如何组织，以及怎样选择合适的存储方式。
共享提示词库不是一堆文本片段。每个可复用提示词都需要有使用场景、负责人、版本、示例、限制和审核日期。否则，提示词库只会变成换了个好听标题的过时建议。
为什么需要提示词库，而不是“更聪明的提示词”
阅读高级提示技巧时，人很容易不断收集更巧妙的方法。对于重复性工作流，更值得测试的假设是稳定模板能否减少本可避免的变化。请在有代表性的案例上与当前做法比较，不要假定复用本身就会改善结果。
提示词库有三项具体好处：
减少重复设置。 任务结构和占位符已经准备好，但每次使用仍需正确输入和审核。
变更可测试。 新版模板可以先在相同案例和验收标准上运行，再取代旧版。
团队可以共享起点。 人们可以使用同一个获准版本，而不是从聊天历史重新拼装。
对团队而言还有第四项好处：**质量变得可以审核。**某个人聊天记录里的提示词，团队无法审核、管理版本或改进；提示词库里的提示词则可以。
提示词库中应该有什么
一个实用的提示词库包含三层。我们分别来构建每一层。
第1层：高频模板
先收录那些反复出现、且结果重要到值得测试的提示词。每个条目都应是带占位符的完整模板，并记录其评估方式。
候选类型包括：
结构化邮件起草器。
用我的口吻起草一封邮件。背景：{{situation}}。受众：{{recipient and their preferences}}。目标：{{what I want to happen}}。限制：不超过{{N}}字，以明确的下一步结束，不要使用“希望你一切都好”。生成三个版本：简短版、中等长度版、较长版。分别标注。
三轮文档审查器。
分三轮审查我接下来要分享的文档：
**第1轮——初步印象。**这是什么文档？三个要点是什么？整体结构如何？ **第2轮——风险和危险信号。**哪些条款或章节可能损害我的利益？逐一引用，并用通俗语言解释风险。 **第3轮——决策和行动。**我需要决定、询问或做什么？如文中注明截止日期，请一并列出。
用[unclear]标记不确定之处。供你了解背景，我的情况是：{{your role and stake}}。
决策陪练。
我正在决定{{the decision}}。先不要发表看法，只提出澄清选项、限制条件、成功标准和我最可能后悔之事所需的问题。等待我回答。然后列出支持每个选项的最有力论据、我可能遗漏的选项、最重要的考量维度，以及我最薄弱的假设。接着，针对我倾向的选择提出反方意见。最后，给出有限定条件的建议，并说明什么证据会改变它；不要把模型自报的置信度当作已经校准的证据。
结构化分析器。
按以下结构分析{{the thing}}：
它是什么（一段话） 三个最重要的特征（每项都提供依据） 它擅长什么（哪些情况下我会使用它） 它不擅长什么（哪些情况下我不会使用它） 使用时的常见错误 普通读者容易忽略的两项真正有洞察力的观察
请具体说明，不要使用泛泛而谈的套话。
匹配文风的改写器。
改写这份草稿，使其符合以下示例所定义的我的文风： {{example 1}} {{example 2}} {{example 3}}
只做精准修改——保留结构，仅修改不符合该文风的内容。逐项引用每处改动，并用一句简短的话解释原因。
只构建由你自己的重复工作证明有必要的条目。工程师、营销人员和律师所需的具体组合会不同。共同模式是：经过测试的模板、清晰的占位符和明确的审核边界。
第2层：针对不同领域的框架
某些工作需要专门的框架，不能直接套用上述通用模板。例如：
客户访谈总结。
根据这份客户访谈记录，提取：
- 客户描述痛点时的原话（附时间戳的逐字引语）
- 他们提到想要的功能或改进，并按意愿强度排序
- 他们目前使用的产品，以及喜欢和讨厌它的哪些方面
- 他们暗示但没有直接说出的任何未满足需求
- 他们如何描述自己和自己的工作——使用原话
尽可能引用客户原话。用[my read]标记所有推断内容。请具体说明。
技术规格生成。
根据这份功能说明，按照我们团队的格式生成技术规格：
- 问题陈述（用用户自己的话描述其痛点）
- 建议的解决方案（高层说明）
- 详细流程（正常路径 + 2至3个边界情况）
- 范围之外（明确说明不属于目标的内容）
- 待解决问题（实施前必须作出决定的事项）
- 风险（工程、产品、业务）
- 成功指标（如何判断方案奏效）
语气：直接，不含模糊措辞。我的原话表达准确的地方请直接引用。凡是需要你自行补充细节之处，都用[confirm]标记。
代码审查助手。
按以下顺序审查下方代码：
- 缺陷——会导致错误行为的代码。引用并解释。
- 安全问题——任何会扩大攻击面的内容。引用并解释。
- 性能问题——任何在规模扩大后可能变慢的内容，并给出大致数量级。
- 可维护性——任何会让下一位阅读代码的人困惑的内容。
- 代码风格小问题——仅指出严谨的审查者会在意的问题，略过吹毛求疵之处。
不要重写代码。引用行号。最后给出最重要的一项修复。
这些模板分别针对一种工作进行了调校。工作流中每一种会重复出现的任务类型，都应有一个第2层模板。
第3层：要附加的参考资料
有些提示词不仅需要指令，还需要辅助文件。提示词库应包含：
- **品牌文风示例。**一组具有代表性的短文，用来体现目标文风。
- **风格指南。**公司的编辑规范、团队的代码风格、设计令牌。
- **领域术语表。**内部术语、代号和缩写，以免模型误解。
- **模板。**你希望模型填写的实际模板结构。
- **反例。**需要避免的内容——用泛泛、偏离品牌或结构混乱的示例，向模型展示不应生成什么。
将这些资料与提示词放在一起，任何使用模板的人都能同时取用正确的参考材料。
提示词库应该存在哪里
应根据所需控制和工作流选择存储方式，而不是依据通用排名。请比较以下维度：
**访问与权限。**谁可以读取、运行、编辑、批准和停用条目？
**检索与采集阻力。**人们能否在工作发生的地方找到获准版本，并在不丢失上下文的情况下保存候选条目？
**版本管理与审核。**能否比较变更、保留历史、要求审批并回滚？
**评估与使用证据。**能否关联测试用例和结果，并区分真实使用与仅仅存在的条目？
**可审计性。**能否确定负责人、活动版本、配置、批准状态和使用边界？
**成本与可移植性。**订阅、实施、迁移和供应商锁定的成本是多少？
多种存储模式可以满足这些要求的不同组合：
轻量级个人存储
Raycast snippets、Espanso或TextExpander等文本扩展工具。 个人检索可能很快，但权限、评估记录和变更审核可能需要另一套系统。
Apple Notes、Notion、Obsidian或Confluence等文档与知识工具。 可以把提示词、指南和示例放在一起。请核对权限、版本历史、批准和导出选项是否符合需求。
托管与团队存储
由结构化文本文件组成的git仓库。 这种方式可以提供差异比较、同行审核、负责人规则和回滚。它最适合熟悉仓库工作流的预期用户，或由另一套界面负责检索的情形。
提示词管理和可观察性工具。 PromptHub、Langfuse或Helicone等产品可以把提示词版本与部署、评估和使用数据关联。应根据需求核实当前功能、数据路径、权限和定价；例如，Langfuse的提示词管理文档介绍了版本化提示词和部署标签。
受管理工作空间中的已保存助手。 Custom GPTs和Claude Projects可以通过对话界面打包指令与参考材料。ChatGPT Team已于2025年更名为ChatGPT Business；Business和Enterprise工作空间可以在工作空间控制规则允许的范围内共享GPT。Claude Team和Enterprise项目可按Claude Projects文档所述，共享给指定成员或整个组织，并设置项目级权限。在添加内部资料前，请核对当前共享、保留、数据使用和导出政策。
可以组合多种模式，但应指定一个权威版本，以免便利副本在无人察觉时偏离已审核条目。
版本管理很重要
不进行版本管理的提示词库会不断积累矛盾和失效模板。对提示词进行版本管理，才能让使用者识别活动条目、审核变更，并在需要时回滚。
最低要求包括：
- **标识、负责人和契约：**条目名称、版本、负责人、获批使用场景、需要时的批准人、模板、必填输入、预期输出和人工审核规则。
- **最后测试的配置：**提供商、可用时的准确模型或快照、相关系统或开发者指令、工具、检索来源，以及推理或生成设置。
- **评估证据与限制：**最后测试日期、有代表性的案例、验收标准、结果、重大失败、未获批用途、敏感数据边界、已知故障模式，以及需要合格人员审核的条件。
- **后备方案与变更历史：**输入缺失、检查失败或获批配置不可用时，使用者应如何处理；改了什么、为何修改、由谁批准，以及重新运行了哪些测试。
一个实用做法是：对提示词作出实质性修改时，将旧版本存入归档，让新版本取而代之。你随时可以回看，了解当初为何作出修改。
对于团队提示词库，实质性变更应经过工作流风险所要求的审核。同行审核可以发现错误，但在需要评估或合格审批的情形下，不能取代这些环节。
除提示词本身外还要记录什么
只有提示词模板而没有背景信息是不够的。一个实用的提示词库条目应包含：
- 提示词本身，含
{{placeholders}}。 - 预期使用场景——用一句话说明何时应使用它。
- 完整示例——除非来自获批且有记录的案例，否则应明确标注为合成示例。
- 已知限制——这个模板在哪些方面表现不佳，需要注意什么。
- 经过测试的配置——模型、相关设置与工具、测试日期和比较基线。
- 作者和最后修改时间——由谁构建、何时修改，以及上次修改的原因。
- 审核规则——输出在投入使用前需要何种人工审核。
- 故障模式——这个模板通常会以何种方式出错。
这些内容会增加维护工作。是否值得，应与当前工作流进行比较：投入时间、故障率、审核工作量，以及拥有可审计版本的价值。
本文链接的配套模板提供了一份起始结构。在把条目视为生产可用之前，还要按照上文补充最后测试的模型与配置、评估证据、限制和后备字段。
坚持维护
提示词库需要明确的维护触发条件：
变更触发审核。 提示词、模型、系统指令、工具、检索来源、输出契约或政策发生变化时，重新运行相关评估。不要把与当前配置存在实质差异的“已测试”标签沿用下来。
风险触发审核。 条目被用于后果更重的场景、获得敏感数据或操作权限，或造成重大影响的失败时，应进行审核。在领域需要时增加合格审核和经过验证的控制。
使用情况触发审核。 检查反复失败、经常被覆盖、采用率低或成本异常的条目。使用率低可能意味着难以发现、模板不佳或任务根本不需要共享提示词；仅凭使用数据无法判断是哪一种原因。
连同证据一起采集。 把有希望的提示词保存为候选条目，经过测试后再标记为已批准。只有在政策允许时才保留输入和输出，并对敏感材料进行脱敏。
有意识地合并重复条目。 如果多个条目面向同一任务，请在相同案例上比较后再选择规范版本。服务于有记录的不同上下文或政策时，应保留独立变体。
完整示例：构建一个提示词库条目
为了让以上内容更加具体，下面是一条合成示例。它只展示模式，不能证明模板对真实客户、收件人或组织有效。
**名称：**三版本邮件起草器
**使用场景：**在受众、语气或长度尚未确定，且我希望获得多个选项时，用于起草任何邮件。
**版本：**v0.3（说明性候选版本）
**候选配置：**组织批准的聊天模型和工作空间。只有当评估显示相关收益时，才将常规配置与任何更高推理候选方案比较。
**最后测试：**尚未测试。批准前，应运行有代表性的合成邮件或获准邮件，覆盖明确请求、敏感边界、上下文缺失和长对话线程。
模板：
用我的口吻起草一封邮件。
背景：{{the situation, including any prior thread}}
受众：{{who the recipient is — name, role, our relationship, their communication preferences if known}}
目标：{{what I want to happen as a result of this email}}
限制：
- 不超过{{N}}字
- 以明确的下一步结束
- 不要使用“希望你一切都好”“我想联系你”或“如有任何问题，请告诉我”
- {{any other specific constraints}}
生成三个版本，并标注：
1. **简短直接**（{{N1}}字）
2. **亲切常规**（{{N2}}字）
3. **更长、更详细**（{{N3}}字）
在每个版本下方附上一句简短说明：“适合在……时发送”
待验证的候选限制：
- 长对话线程可能包含无关、矛盾或敏感的历史信息；只提供任务所需且获准的最少上下文，并检查是否遗漏必要承诺。
- 三个版本可能没有实质差异；如果测试发现重复，应定义差异标准或减少版本数量。
- “适合在……时发送”说明可能产生泛泛建议；如果未通过评估，就删除它。
示例变更日志：
- v3：添加禁止使用的开场语；批准前重新运行语气和指令遵循案例。
- v2：添加“适合在……时发送”说明；核实说明具体且安全。
- v1：初始候选版本。
条目通过评估和批准流程后，用户可以取用经过审核的版本，填入占位符，并生成供人工审核的候选草稿。
团队视角
团队提示词库还要考虑以下事项：
**共享词汇。**确保模板面向整个团队，而不只是针对你个人。将“我的文风”替换为“[品牌名称]的文风”，并明确记录这种文风的定义。
入职培训。 向新用户说明如何找到权威版本、理解使用边界、提供获准输入并报告失败。优先介绍与其工作相关的条目，而不是固定数量。
负责人。 每个获准模板都需要一名负责人，负责审核触发条件、证据和废止决定。
审批流程。 批准强度应与失败后果匹配。面向客户、监管、法律、金融、医疗或安全相关的工作流，可能需要权威来源、合格审核、经过验证的控制和保留证据，变更才能上线。
一个能产生复利的小习惯
按照已定义的触发条件审核提示词库。把有希望的提示词记录为候选条目，附上允许使用的证据，并在晋级前与当前版本比较。成功与失败都要记录，避免只根据令人印象深刻的案例来选择。
目标是让活动条目具备负责人、当前配置、有代表性的评估和明确后备方案。对不再值得维护成本的条目予以废止。
宁可使用小而经过测试的提示词库，也不要未经审核的合集
当重复任务足以证明维护工作合理时，提示词库才有价值。从你已经反复输入的模板开始，再衡量复用是否改善一致性、审核工作量、任务成功率或成本。
记录每个候选条目的占位符、使用场景、经过测试的配置、证据、已知限制、审核触发条件和后备方案。只保留在这些检查下仍然有用的条目。
