提示词别硬编码在业务代码里
最开始我把提示词写成模板字符串，直接塞在 service 里：
const prompt = `你是一个专业的客服助手，请根据以下资料回答用户问题...`;三个月后这段代码变成了 200 行，改一个字要发一次版，运营想调语气得找我。这明显不对。
把提示词当配置，不当代码
现在所有提示词放在一张表里，字段是：key、版本、内容、备注、启用状态。业务代码只认 key，比如 support.reply.v3。
好处很直接：
- 运营可以自己在后台改措辞，改完点"试运行"，看十个样例的输出
- 出问题能一键回滚到上一版
- 谁改的、什么时候改的、为什么改，都有记录
版本号怎么定
不是每次改都升大版本。我们的规则是：
- 改错别字、调语气 → 同一个版本，记一条变更说明
- 改输出结构、加字段 → 升版本，旧版本保留，允许业务方慢慢迁
- 换模型 → 一定升版本，因为同样的提示词在不同模型上表现可能完全不同
提示词里该写什么
踩过的坑是"什么都往里塞"。系统提示词一度有 1800 token，里面写着公司简介、产品线、竞品对比、话术禁忌。结果模型经常抓错重点。
现在的结构是分层的：
- 角色和边界（必须）：你是谁、能做什么、不能做什么，控制在 100 字以内
- 任务说明（必须）：这次要完成什么，输入是什么，输出格式是什么
- 业务规则（按需）：真正跟本次任务相关的规则，不超过 5 条
- 示例（可选）：一两个就够，多了反而限制发挥
公司简介这类"背景知识"不要放系统提示词，走检索。需要的时候才带进来，不需要就是纯浪费。
一个容易忽略的点
提示词改了，评估集要跟着更新。我们有一次把输出格式从"段落"改成"要点列表"，提示词改完直接上线，结果下游解析代码全挂了——因为没人想到要去跑一遍回归。
现在改提示词会自动触发一次评估，通过率低于阈值就不让发布。流程重一点，但比线上出事强。