提示词散落，是团队的隐性负债
提示词一多，就会出现典型症状 ✗：同一个功能有三份"差不多"的模板 ✔、
没人知道哪份在生效 ✔、改了一处忘了另一处 ✔、新同事复制了一份过期的 ✔。
把提示词做成"可复用资产" ✔：目录化、命名规范、带元数据 ✔。
一、目录结构（按"用途"而不是按"人"）
prompts/
answer/ 回答类
v3.txt 模板正文
v3.meta.json 版本、作者、目标评测集、变更说明
extract/ 抽取类
summarize/ 摘要类
classify/ 分类类
shared/ 共享片段（语气、安全约束、格式约定）
CHANGELOG.md 人写的变更历史
要点：shared/ 很重要 ✗→✔ —— 把"安全约束、输出格式、术语表"等共用片段抽出来 ✔，
避免每个模板各写一份 ✔（那样改一处就要改十处 ✔）。
二、命名规范（让人一眼看懂）
<用途>.<语言>.<版本>.txt 例如 answer.zh.v3.txt
反例 ✗：prompt_final_v2_new.txt ✔、张三的提示词.txt ✔ ——
没有用途、没有版本、没有归属 ✔。
三、元数据里必须有五项
① 用途（做什么、不做什么 ✔）
② 目标模型与参数（温度、上限 ✔）
③ 目标评测集（用哪批样本验收 ✔）
④ 变更说明（动机、证据、回滚方式 ✔ —— 见变更说明那篇 ✔）
⑤ 负责人（谁维护 ✔）
第 ③ 项最常被省 ✗ —— 没有它，改动就只能靠感觉验收 ✔。
四、三点纪律
- 模板里不写分支 ✗（"如果 X 就 Y" 放代码 ✔，模板保持可读 ✔）；
- 变量用占位符（
{{var}}✔ 而不是拼字符串 ✔）； - 提示词改动走四道关 ✔（见提示词流水线那篇 ✔）。
五、复用怎么发生
- 共享片段引用（在模板里用 include 语法 ✔ —— 由组装器展开 ✔）；
- 按场景组合（
shared/安全约束+extract+shared/输出格式✔ —— 见可组装上下文那篇 ✔）； - 禁用复制粘贴 ✗（复制出去的那份不会被更新 ✔）。
一条判据
新同事第一天 ✔，能否只读目录与元数据就找到"某个功能正在用哪份提示词、为什么这么写" ✔？
不能，说明提示词还是散落的文本，不是资产 ✗。