好提示词别只存在收藏夹里：vibe 项目的提示词模板库实战

用 AI 写东西、写代码、做客服的人，很快会发现一个问题：好用的提示词散在聊天记录里、收藏夹里、同事的口头传授里。下次要用，又得重新翻、重新试、重新改。这篇讲的是怎么给 vibe 项目建一个提示词模板库：让好用的提示词变成团队可以复用、可以改进、可以放心用的资产，而不是个人的运气。

先说明：文中出现的产品名“青禾客服”、人物林小雨、陈默均为虚构示例，用来讲流程，不代表真实产品或真实人物。方法本身是通用的。

先分清：模板库不是收藏夹

收藏夹解决的是“我存下来了”，模板库解决的是“别人也能用好”。这两者的差别，决定了整个库的设计。收藏夹里的一条提示词，往往只有作者自己看得懂：它默认了很多上下文，缺了关键的输入说明，换一个人、换一个任务就不灵了。模板库里的一条模板，必须做到三件事：说清它用来干什么、说清它需要什么输入、说清它产出什么样子的东西。

所以入库的第一道门槛不是“这条提示词效果好”，而是“这条提示词能不能被别人复现”。复现不了的效果，再好也只是个人经验，不是团队资产。入库之前，先让另一个人拿着模板、在没有作者讲解的情况下跑一次：如果他能跑出可用的结果，这条模板才有入库的资格；如果跑不出来，先补说明、补示例，而不是先入库。

还有一个常见的误会：模板越多越好。实际上模板库的价值在“找得到、用得对”，不在数量。一百条没人敢用的模板，不如二十条人人都知道怎么用的模板。建库的初期，宁可少而精：先收十条团队真正反复在用的提示词，把它们打磨成标准模板，再慢慢扩。数量是后面自然长出来的，不是建库第一天就要凑出来的。

一条好模板的五个部分

一条能复用的模板，通常由五个部分组成，缺了哪一部分，用起来都会打折。第一是用途：这条模板解决什么问题，适合什么场景，不适合什么场景。用途要写得具体，比如“给新用户写欢迎邮件”，而不是“写邮件”。场景写得越具体，别人选错模板的概率越低。

第二是输入：模板需要哪些信息，哪些是必填的，哪些是可选的，格式是什么。输入说明要像表单一样清楚：用户姓名、产品名、语气要求，分别从哪里来，有没有默认值。很多模板用不好的原因，不是模型不行，而是输入给得不全：缺了产品名，模型只能编一个；缺了语气要求，模型只能猜一个。

第三是指令本身：要模型做什么、按什么步骤做、有什么约束。约束比要求更重要：不要出现什么、不要超过多少字、不要编造没有给出的事实。约束写得越明确，输出的波动越小。对客服、对外文案这类场景，一定要加一条“不知道就说不知道，不要编造”的约束，这条约束的价值，出了问题才看得出来。

第四是输出格式：输出是一段话、一个列表、一张表格，还是结构化的数据。格式定下来，下游才能接得住：如果输出要进系统，就定成结构化格式；如果输出是给人读的，就定成段落加小标题的格式。格式不定，每次输出的样子都不一样，后面的人还得再加工一遍。

第五是示例：一到两个“输入—输出”的完整例子。示例是模板里最有用的部分，因为它把前面四部分的抽象要求变成了具体样子。新人看示例就知道该怎么填输入、该期待什么样的输出。没有示例的模板，新人只能靠猜；有示例的模板，新人第一次就能用对大半。

分类：按任务分，不要按模型分

模板库的分类方式，决定了它好不好找。最容易犯的错误是按模型分类：“GPT 的模板放一堆，Claude 的模板放一堆”。模型会换、会升级，按模型分的库很快就乱了。更耐用的分法是按任务分：写作、客服回复、代码辅助、数据整理、头脑风暴，任务是稳定的，模型是流动的。

在任务之下，再按场景分一层就够了。比如客服回复下面，可以分“道歉与补偿”“进度查询”“功能咨询”；写作下面，可以分“欢迎邮件”“更新公告”“帮助文档”。两层分类通常就够了，再多，维护成本会超过查找收益。每一层的名字要用团队自己的话，不要用模型厂商的术语：团队成员是按“我要干什么”来找模板的，不是按模型的功能名来找的。

分类之外，还需要两个辅助的找法：搜索和标签。搜索要能搜用途和输入字段，不要只搜标题；标签用来标一些跨分类的属性，比如“对外发布需审核”“含客户数据慎用”“仅内部使用”。标签的作用是提醒风险，不是再做一套分类。标签超过十个，就说明分类本身没做好，先修分类，再加标签。

命名也值得定一条规矩：名字里要带任务和场景，比如“客服-道歉与补偿-标准版”，不要起“小雨的好用模板”这种只有作者懂的名字。名字是模板的门面，门面不清楚，库里再多好东西也没人翻。

变量和版本：模板是活的，要能改

模板里的可变部分，要用变量标出来，而不是写死在正文里。比如“欢迎{{用户姓名}}使用{{产品名}}”，变量一眼就能看出来，填错的概率也低。变量还要有说明：这个变量从哪里来、格式是什么、有没有默认值。变量说明缺了，填的人只能猜，猜错了输出就跟着错。

模板一定会改：产品改名了、政策变了、发现某个约束没写导致输出翻车了。改模板要像改代码一样留版本：改了什么、为什么改、谁改的、什么时候改的。版本号不需要复杂，“v1、v2、v3”加上一行改动说明就够了。关键是，旧版本不要直接删掉：正在用的流程可能还依赖旧版本，删了就断了。旧版本标成“已废弃、请用新版”，并写明迁移方法，比直接删除安全得多。

改动模板之前，先想好影响范围：这条模板被哪些流程在用，改动会不会让它们的输出变样。影响大的改动，先在小范围试跑：拿三到五个真实的历史输入跑新版，对比旧版输出，确认没有翻车再全量替换。试跑的成本很低，翻车的成本很高，这个顺序不要反。

还有一条：模板里不要藏机密。不要把真实的 API 密钥、内部链接、客户真实数据写进模板示例。示例里的数据一律用虚构的：虚构的产品名、虚构的人名、虚构的订单号。模板库会被分享、被导出、被新同事看到，写进去的机密很难彻底收回。入库检查里加一条“示例数据是否全是虚构的”，能省掉很多事后的麻烦。

质量门：入库之前跑三组测试

模板入库之前，应该过一道质量门，门槛不用高，但必须有。建议跑三组测试：正常输入、边界输入、刁钻输入。正常输入是模板最常见的用法，输出应该直接可用；边界输入是输入缺了一项可选信息，或者输入特别长、特别短，输出应该仍然合理、不要崩；刁钻输入是故意给一个容易让模型编造的信息，比如不存在的产品功能，输出应该按约束说不知道、或者明确标注不确定，而不是编一个像真的答案。

三组测试跑完，把结果附在模板后面：输入是什么、输出是什么、有没有人工改过。附测试结果有两个好处：后来的人能判断这条模板的可信度，模板改版的时候也有对比的基线。没有测试记录的模板，可信度只能靠口碑；有测试记录的模板，可信度可以验证。

测试的负责人不一定是作者本人。让另一个人来跑测试，效果更好：作者对自己的模板有盲区，别人按字面意思跑一遍，更容易发现说明不清的地方。测试发现的问题，先补说明、再改模板，顺序不要反：很多时候问题不在指令本身，而在输入说明没写清楚。

质量门还要包括一道合规检查：这条模板会不会让模型输出敏感内容、会不会涉及用户隐私、对外发布之前需不需要审核。对外文案、客服回复这类模板，默认标成“对外发布需审核”，不要等到出问题再补流程。审核不是不信任模板，而是给模板的使用加一道保险。

用起来之后：度量、废弃、推广

模板库建起来之后，要定期看三个数：哪些模板最常用、哪些模板从来没人用、哪些模板经常被改。最常用的模板值得继续打磨：补更好的示例、把常见输入做成默认值；从来没人用的模板要问一句：是分类藏得太深，还是任务本身就不存在，问清楚再决定是改名、合并，还是废弃；经常被改的模板说明它处在高频变化的场景里，要留意它的版本管理是不是跟上了。

废弃是模板库健康的一部分，不要怕废弃。任务没了、产品下线了、模型换代让某个模板没意义了，都应该及时废弃。废弃的动作要完整：标成已废弃、写明替代模板、通知正在用它的人、给一个过渡期。直接删除是最差的废弃方式：正在用的流程会突然断掉，而且没人知道该换成什么。

推广靠的不是发通知，而是让好模板出现在工作流里。新人入职的第一周任务里，放三条最常用的模板；团队周会里，花五分钟讲一条本周用得好的模板和它的输出；客服、写作这些高频场景的入口处，直接挂上对应的模板链接。模板出现在干活的地方，才会被用；只躺在库里，再好的模板也没人想起来。

最后提醒一句：模板库的终极目标不是让所有人都用同一套提示词，而是让好的做法可以被复制。复制之后，每个人仍然可以根据自己的任务微调，微调出更好的版本，再反哺回库里。库是活的，流动起来才有价值；建好就不管的库，三个月后就是一堆过期的文字。

一份可以直接抄的入库检查表

• 用途写清了吗：解决什么问题，适合什么场景，不适合什么场景？
• 输入说全了吗：必填、可选、格式、默认值，分别是什么？
• 约束写够了吗：不要出现什么、不要编造、有没有字数和格式限制？
• 输出格式定了吗：下游是人读还是系统接，格式匹配吗？
• 示例有没有：至少一个完整的输入—输出例子，数据全是虚构的吗？
• 三组测试跑了吗：正常、边界、刁钻输入的结果附上了吗？
• 分类和名字对吗：按任务分类，名字里有任务和场景吗？
• 合规标了吗：对外发布需不需要审核，含不含敏感数据？
• 版本留了吗：这是第几版，改了什么，旧版怎么处理？

从个人收藏迁移到团队库：三步走，不要一次性搬家

很多团队的模板库不是从零建的，而是从几个人的个人收藏里拼出来的。一次性把所有收藏倒进库里，是最糟糕的迁移方式：库里会立刻多出几十条没说明、没示例、没测试的条目，找起来比原来更难。更稳妥的做法是三步走，每一步都小。

第一步是盘点：让每个人列出自己最常用的五条提示词，不要多。五条这个上限很重要，它逼着每个人先挑真正反复用的，而不是把收藏夹整个倒出来。盘点完，团队会发现大量重复：三个人收藏的其实是同一类任务的不同版本，合并成一条标准模板，比留着三条相似条目有用得多。

第二步是打磨：按前面说的五个部分，把盘点出来的模板逐条补齐用途、输入、约束、格式、示例，再跑三组测试。打磨的顺序按使用频率来：最常用的先打磨，低频的往后放。打磨一批、入库一批，不要等全部打磨完再一次性发布；先入库的模板先产生价值，也能让团队早点习惯用库而不是翻收藏夹。

第三步是立规矩：新模板怎么入库、谁负责审核、多久复查一次。规矩立在迁移完成之后，比立在迁移之前更有说服力，因为团队已经用过几条标准模板，知道好模板长什么样。规矩也不用复杂：一页文档，写清入库检查表、审核人、复查周期，就够了。规矩的目的是让库保持流动，而不是让入库变成审批马拉松。

工具选型：先问三个问题，再选工具

模板库存在哪里，是文档、代码仓库、还是专门的工具，这个问题经常被过度讨论。其实选型之前先问三个问题，答案会自己指向合适的工具。第一个问题：模板的使用者是谁？如果主要是非技术人员，文档和在线协作文档更友好；如果主要是开发者，代码仓库更顺手，因为模板可以和代码一起做版本管理。

第二个问题：模板需不需要进系统？如果模板的输出要直接进客服系统、进发布流程，那么模板库最好能和系统对接，或者至少输出格式是结构化的；如果模板只是给人参考、人工复制粘贴，文档就够了。把“给人看”和“给系统用”混在一个库里，两边都会别扭，分开存放反而更清楚。

第三个问题：团队有多大？十人以下的团队，一份结构清晰的共享文档加上一张索引表，完全够用；上到几十人、模板上百条的时候，才值得考虑专门的工具和搜索。工具是跟着规模走的，提前上重型工具，只会让维护成本先行一步。很多模板库死掉，不是因为工具不好，而是因为工具比团队的需求重太多，没人愿意维护。

无论选什么工具，有两条是通用的：模板要能被搜索到，模板的版本变化要能被追踪。搜索不到的库等于没有库，版本追踪不了的库，改错了都没法回退。选型时先确认这两条，再谈其他功能。

一个虚构的翻车复盘：模板没错，用错了地方

讲一个虚构的复盘，帮助理解模板库的风险点。虚构的“青禾客服”团队有一条用得很好的道歉模板，语气诚恳、补偿方案清楚，客服团队用了几个月都没出问题。后来市场团队觉得这条模板写得好，拿去改了改，用在了一次公开活动的致歉公告里，结果翻车了：模板里的补偿方案是针对个别用户的，不适合公开承诺；模板里的语气是对一个人说话的，放在公开公告里显得轻率。

复盘的结论不是模板不好，而是模板的适用场景没写清。道歉模板的用途一栏里，只写了“道歉”，没写“适用于一对一客服对话，不适用于公开公告”。市场团队按字面理解拿去用，错不在他们，在模板的场景说明上。修复的办法也不复杂：在用途里补上适用和不适用场景，并且在模板标题里加上场景，比如“客服-一对一道歉-标准版”，让拿错的人一眼就能发现不对。

这个复盘说明了一个道理：模板库最大的风险，往往不是模板本身写得差，而是模板被用在了它没设计过的场景里。用途和场景说明，是模板最便宜的保险。每次模板出问题，先问一句：是不是用错了场景，再问指令本身有没有问题。很多时候，补一句场景说明，比改十行指令更有效。