项目内提示词模板库: 从散记到可复用的工程化沉淀

AI 工作流页放了 10 个拿来即用的 prompt 模板,但那是”个人级”的——你在自己电脑里存一份就能用。这篇讲的是团队级:怎么把散在各人本地的 prompt 沉淀成项目级模板库,让新人 clone 仓库就拿到同一套质量基线。

一、为什么要有模板库

不是”prompt 写得好”的问题,是”重复”和”不一致”的问题。团队里每个人都在重复造差不多的 prompt,结果:

同一个重构需求,A 让 AI 出方案、B 让 AI 直接改,产出质量和风险完全不同
新人不知道怎么提需求,AI 产出质量低,回头怪 AI 不行
调试时临时想 prompt,漏掉”先定位不改代码”这种关键约束,AI 直接动手把代码改乱

模板库解决的是这三件事:把验证过有效的 prompt 固化下来,让团队复用同一套质量基线。

二、模板库长什么样

不是把 prompt 堆一个 markdown,是按”场景”组织。每个模板四要素:场景、意图、模板文本、校验项。

目录结构:

prompts/
  refactor.md       # 重构
  test.md           # 测试生成
  review.md         # Code Review
  debug.md           # 调试
  perf.md           # 性能定位
  ...

每个文件格式:

场景: 重构
意图: 让 AI 给职责单一的重构提案,但不直接改

模板:
把这个函数重构成职责单一的子函数,保持行为不变。要求:
- 每个子函数 < 30 行
- 命名表达意图
- 列出重构后可能引入的风险

校验项(产出必须满足才算合格):
- [ ] 给了风险清单
- [ ] 没有改对外接口
- [ ] 子函数命名不是 data/obj

关键在校验项——prompt 不是写完就完,得标”产出长什么样才算对”,否则没法判断 AI 这次的输出能不能用。

三、怎么接入项目

两条路:

放进仓库根目录的 prompts/:版本管理跟着代码走,review prompt 改动和 review 代码一样。新人 clone 仓库就有。
配 AGENTS.md / .cursorrules 引用:让 AI 工具自动读到(见约束文件实战)。Cursor 可以在 .cursor/rules 里链到 prompts 目录。

落地动作:

README 加一节”AI 协作约定”,指明改函数先套 refactor.md、调试先套 debug.md
PR 模板加 checkbox:“本 PR 用到的 AI 产出,已套用 prompts/ 对应模板并 review”
不是强制流程,是降低新人踩坑成本的默认路径

四、模板的三条核心原则

缺一不可:

1. 意图 > 步骤。说”我要什么”不说”你怎么做”。AI 自己会拆步骤,你越描述步骤越把它框死在你想的那条路里,反而拿不到更优解。

2. 要求列不确定。每个模板末尾让 AI”标注你不确定的地方”。这是把 AI 从”答案”降级成”带风险标注的草稿”的关键——不确定的地方你来确认,确定的它直接给。

3. 可校验。模板附校验项,AI 产出对照清单打勾。打不了勾就退回重生成,不要手工补——手工补就把”草稿”当”答案”用了。

五、维护:怎么不让模板库烂掉

模板库的死亡方式是”写了不改”。三种腐烂和对策:

场景过时:项目从 RN 换 Flutter,refactor 模板还写”组件 memo”。对策:每次大版本升级,过一遍 prompts 目录。
模板失效:模型升级后某些约束不需要了(旧模型要提醒”用 const”,新模型默认就给)。对策:模板里标注”针对 [模型版本]“,升级时按标注清理。
没人用:模板堆了 30 个但团队不知道有。对策:控制在 8-10 个核心场景,多了就砍;周会点一次”这周用哪个模板避了什么坑”。

砍比加重要。模板库不是越多越好,是”每次用都有效”才值。

六、一个反例

见过一个团队的 prompt 库:50 个模板,每个 200 字,全是”请你扮演资深工程师,仔细分析…”这种角色扮演开场。半年后没人用,因为套模板比现想还慢。

好的模板库反过来——每个模板短到能扫一眼记住,套用前不用读说明。模板的价值在”复用质量基线”,不在”覆盖所有场景”。

小结

模板库不是炫技,是工程沉淀。和组件库、设计 token 一个逻辑:散在各人手里是负债,沉淀进仓库是资产。区别只在于——prompt 模板比组件更容易烂,所以砍的频率比加的频率更高才是健康的。