一、项目背景

这个项目的起因很朴素：我们当时支撑多条业务线接大模型能力，智能客服、智能核单、辅助采购各自为政地写提示词。时间一长，问题全暴露了——同一类任务（比如"从订单备注里抽取收货信息"）在三个系统里有三套写法，效果还各不相同；某条业务线改了一处话术，结果上游另一个调用方没跟着回归，线上直接冒出一批 bad case；更糟的是，没人说得清线上跑的到底是哪个版本的提示词。

说白了，提示词在大家心里还是"一段写在代码注释里、随手改的字符串"，既没有版本、也没有评审、更没有评测。当大模型能力从 POC 走向生产，提示词本身就变成了需要被工程化治理的资产。我们决定把散落在各处的提示词收拢到统一的模板库，并配上一套版本管理与评测机制。

二、落地场景

我们采用的 AI 私有化部署底座之上，又叠了一层提示词治理能力，落地了三块场景。

第一是统一提示词模板库：所有业务线的提示词以"模板"为最小单元入库，模板由系统提示（system）、任务指令（instruction）、占位变量组成，调用方通过变量注入参数，不再把整段提示词硬编码在业务代码里。

第二是 Few-shot 样例沉淀：针对泛化不稳定或易出错的场景，把历史高质量问答对沉淀为 Few-shot 样例库，按任务类型与置信度打标，模板可引用样例集合。

第三是版本管理与 A/B 评测：每个模板独立版本号，变更走评审；新版本先在影子流量或评测集上跑，指标达标才放量，避免"改一处、崩全链路"。

三、关键技术挑战与解决思路

挑战一：提示词版本与变更管理

提示词最大的工程陷阱是"无版本即无回滚"。我们当时给每个模板建了版本表，关键字段包括版本号、内容哈希、生效状态、创建人与评审记录。业务调用只认"模板名 + 生效版本"，底层切换不影响调用方：

CREATE TABLE prompt_template (
  tmpl_id      VARCHAR(32),
  version      INT,
  content_hash CHAR(40),
  status       SMALLINT DEFAULT 0,  -- 0草稿 1评审中 2生效 3下线
  reviewer     VARCHAR(32),
  created_at   TIMESTAMP,
  PRIMARY KEY (tmpl_id, version)
);

上线采用"灰度标签"机制：新版本先对 5% 流量生效，评测通过后再切 100%，出问题用内容哈希一键回滚到上一生效版本，平均回滚耗时控制在分钟级。

挑战二：Few-shot 样例去噪与沉淀

Few-shot 不是"样例越多越好"，脏样例会直接把模型带偏。我们这个项目里对样例做两道过滤：一是自动去重与格式校验，剔除字段缺失、超长或答案明显错误的样本；二是用当前主模型对候选样例做"自一致性打分"，保留高置信度样例。样例库按任务类型建索引，模板引用时按相似度取 top-k：

样例选取规则：
1. 仅取 status=approved 且 confidence >= 0.85 的样例
2. 按 embedding 余弦相似度取 top_k=4（k 可配）
3. 同一来源批次样例占比不超过 50%，避免偏置

实测下来，经过去噪的 4 样例模板，比直接堆 12 条未筛选样例的回答稳定率更高，也省了 token。

挑战三：模板复用与权限隔离

业务线多了以后，既要鼓励复用、又要防止"张三改了模板影响李四"。我们在模板库上做了两层隔离：逻辑上按业务域（business domain）分组，模板可被跨域引用但不可跨域修改；权限上用 RBAC，模板的编辑、发布、引用分属不同角色。引用关系单独建表，谁引用了谁的模板一目了然：

CREATE TABLE tmpl_reference (
  caller_tmpl  VARCHAR(32),
  callee_tmpl  VARCHAR(32),
  ref_type     VARCHAR(16),  -- include / fewshot
  created_by   VARCHAR(32)
);

任何模板下线前，系统先扫描引用表，存在活跃引用则禁止直接下线，强制调用方先解耦，从机制上杜绝"静默破坏"。

案例片段（已脱敏）： 智能核单模板 v3 的一次变更评审记录（已脱敏）：变更内容将"拒收理由"输出格式由自由文本改为 JSON 枚举。影子流量评测集 500 条样本上，回答稳定率由 v2 的 91.3% 提升至 95.8%，bad case 由 43 条降至 21 条。该版本先对 5% 线上流量灰度 24 小时，回归 bad case 0 新增，随后全量；v2 保留为可回滚版本，content_hash 为 a1f3...e9。

案例片段（已脱敏）： Few-shot 样例库去噪前后的对照（已脱敏）：某"地址抽取"任务模板，未去噪时引用 12 条样例（含 3 条字段缺失样本），线上抽取准确率约 88.4%，且偶发把"楼层"误并到"门牌号"。经去噪保留 4 条高置信样例（confidence 均 ≥0.9）后，准确率升至 94.1%，错误合并类 bad case 归零；单次调用 token 由约 1,260 降至约 640，成本下降约 49%。

四、效果数据

下表为提示词治理落地前后脱敏示意对比（数据为示意值，非审计口径）：

五、可复用经验总结

第一，提示词也要版本化。把提示词当成代码资产，建版本号、内容哈希、评审与回滚机制，是它从"随手改的字符串"走向生产的分水岭。没有版本，就没有安全感。

第二，样例比话术更值钱。Few-shot 样例库是真正的护城河，但前提是去噪——脏样例比没样例更危险。保留高置信、去偏置的少量样例，往往比堆一大堆效果更好也更省成本。

第三，复用与隔离要同时做。鼓励跨业务域引用模板降本，但用 RBAC 和引用关系表守住"改自己不影响别人"的边界，下线前强制解耦，避免静默破坏。

结语

大模型时代，提示词就是业务逻辑的一种新形态表达。把它纳入工程治理——版本化、样例去噪、权限隔离——看似增加了流程，实则是让 AI 能力能在多条业务线上稳定、可回滚、可复用地长期运行的前提。治理到位，模型才真正"可用"。