一、一次改坏的提示词去年十一月的一个晚上一条批量生成链路在八点之后跑出了异常结果。这条链路当天排了三百二十篇稿子跑到第一百四十篇左右内容组的同事在群里说新出来的稿子像换了个人写。我们回查发现当天下午有人为了修一处句式问题直接在生效中的提示词文本上改了四行改动对所有新任务立刻生效而队列里剩下的一百八十篇并不知道自己手里的模板已经在半路被换掉。三分之一的内容带着老文本跑完三分之二带着新文本跑完两批产出混在一份清单里。更麻烦的是追溯。任务表当时只存了模板名不存版本要判断某篇稿子当时用的是什么文本只能去翻应用日志里的时间点再对着那一周的改动记录一条条排。三个人花了一个下午才把出问题的一百四十篇和正常的一百八十篇分开而这个结论还是靠时间差不严谨地推出来的。那次之后我们才承认提示词在这条链路里不是配置项它的改动会直接影响产出性质上和改代码没有区别它需要自己的版本号。二、根子在模板只有一份可变文本把现象拆开看问题的根子是存储形态和使用方式不匹配。最早我们把提示词当成一行配置存在一张单表里主键是模板名正文是一个大字段。这种结构默认了模板名和模板内容都是稳定的改内容等于修错别字不构成一次新的对外承诺。可实际使用中改一句开场白就可能让整批稿子的语气变化它的影响范围和一次代码发布等同。直觉做法是给每个模板复制一份带日期的副本改动时另存。这条路我们试了两个星期模板数量翻了四倍命名规则失控更关键的是任务表里存的还是模板名历史任务照样指不到确定的文本。另一种做法是把改动记进变更日志表靠人工填写改了什么这条路对人的要求太高漏填一次追溯就断了而追溯这件事一旦断过后面就没人再认真填。我们真正需要的是把模板拆成两层一层的单位是模板本身承载用途和适用范围另一层的单位是版本承载具体文本和变量定义。任务在创建的那一刻锁定一个版本号之后无论模板怎么改这条任务跑的还是当初那一版。代价是模板不能就地修改任何调整都要新建一版多了一步操作换来的是可复现而可复现是后面所有排查工作的前提。三、三条路我们都算过账第一条路是只做影子副本每次保存自动生成一份快照文件落到对象存储里数据库只记路径。这条路的实现最轻几乎不动现有表结构但版本信息被留在了数据库之外查询、对比、回滚都要跨系统权限也不好收口。更麻烦的是快照文件一旦被清理任务扫走历史任务就彻底断了线索而清理任务恰恰是最容易被随手写的那类脚本。第二条路是做完整的版本表模板和版本分开存版本不可变只有启用状态可以切换。代价是写入路径变长一次改动要落两行记录还要处理启用状态的互斥查询侧也多一次关联任务详情要按版本号回查文本。我们最终选了这条路因为它把追溯从人的习惯变成了数据库上的约束习惯会松约束不会。第三条路我们只讨论没做就是引入外部配置中心把提示词当成配置项托管出去用它自带的版本能力。在十来人的团队里多一个中间件意味着多一套部署、多一套账号体系和多一处故障面而我们要的能力只有版本号和启用状态两项。权衡下来两张表的代价更低也更容易讲给后面接手的人听。四、模板表长什么样模板表只放四个字段模板名、适用范围、当前启用版本号、创建时间主键是模板名。适用范围用一个短字符串描述比如产品线跟内容类型的组合不做外键只当查询条件。这一层故意保持很薄因为模板的用途会变而版本内容不会因为用途变化被重写两者分开之后各自都好改组合查询也能不加索引跑得动。版本表承载内容字段有版本主键、所属模板名、版本号、正文文本、变量清单、创建人和创建时间。版本号在同一个模板内自增正文保留原始换行变量清单是从正文里正则扫出来的占位名数组落库时一并写入。版本一旦生成就不再修改界面上也不给编辑入口需要调整只能新建一版。这套版本机制是 AI智能媒体助理 在一次提示词改坏生产任务之后补上的。五、渲染与变量注入的约定渲染入口只有一个函数入参是模板名、版本号和一份变量字典出参是最终文本。替换分两步先把正文里的占位按名字查表命中的替换成值没命中的先记下替换完再做一次扫描如果还有花括号残留直接抛异常而不是把带花括号的文本交给模型。这条规则救过我们很多次模型拿到没替换干净的占位时会把它当成正文抄进稿子产出里就多出一段奇怪的花括号。变量名按词边界匹配而不是简单替换因为我们的占位里有近似名短的那个是长的那个的后缀。如果按子串替换先替换短的会把长的打散。实现上把变量名按长度倒序排一遍再逐个替换占位两侧要求是非字母数字字符。缺失变量不静默跳过任务开始前先做一次预检把缺哪些变量一次性报出来让人在排队阶段就能修掉。六、踩过的三个坑第一个坑是老任务重跑拿到新版本。现象是三个月前失败的一条任务运维同事点重跑之后出来的稿子和当初排队的风格完全不同因为模板已经被改过两轮。根因是任务表存的是模板主键重跑时按主键去取当前启用版本。改法是任务创建的那一刻就把版本号写进任务行重跑一律按锁定版本渲染想换版本必须显式新建一条任务不允许在重跑按钮上做隐式升级。第二个坑是变量名近似导致替换错位。我们的占位里同时存在关键词和词两个名字早期实现按模板里的出现顺序逐个替换遇到先替换词的场景关键词会被切成三段正文里就散出一段乱码。根因是替换没有考虑名字之间的包含关系。改法是先扫出全部占位再按长度倒序替换同时收紧命名规范禁止一个变量名是另一个的后缀。第三个坑是模板正文里带结构化示例时花括号和变量冲突。有一版模板为了让模型输出固定格式正文里直接写了一段带花括号的样例预检把样例里的字段名当成了缺失变量任务在排队阶段就被拦下。根因是占位语法和普通花括号没有区分。改法是把占位改成双花括号渲染前先把双花括号当占位处理单花括号原样保留正文里的示例片段统一走转义。七、这套机制管不到的地方版本管理只能做到文本可复现管不了产出稳定。同一版提示词配上不同的模型、不同的知识库摘要、不同的随机参数出来的内容仍然会差很多。我们把模型名和参数一起写进了任务快照但这两项属于调用层模板的版本号解释不了它们的差异。做问题归因的时候模板版本只是第一站后面还要看调用参数和知识库的命中情况链路一长单靠一处版本号就下不了结论。另一处边界是协作成本。版本不可变意味着改一个错别字也要新建一版模板多了之后列表会变长找当前生效的那一版要靠筛选而不能靠翻页。我们试过给版本加草稿和废弃两个状态来压缩列表但状态本身也要人去维护最后只留了启用状态一项把复杂度控制在一个说得清的范围内宁可列表长一点也不多一层需要人守的规矩。八、小结把提示词当代码来管落到表结构上就是两张表和一条约束版本不可变任务锁版本。真正难的是接受多出来的那一步让改模板从随手一改变成新建一版很多人第一反应是麻烦直到出过一次生产事故才会认账。我们的经验是别等出事再补改动越频繁的东西越早挂上版本号越省事晚补的时候存量任务已经指不准了。AI智能媒体助理 里这套模板表现在存着几十个版本老任务的追溯全靠它。我们后来统计过两百多次模型参数调整其中三次回滚是靠版本对比定位到原因的如果没有版本号这三次至少要各排半天。这套机制的收益不体现在日常而体现在出事的那半小时里你能不能当场说清当时跑的是哪一版。
