Prompt 管理实战：分层、版本与回归上线（附清单）

客服 Agent 的提示词散在三个地方，代码里的一个常量、某人的飞书文档、还有一份配置文件。上个月改了一处上线，两天后同事在另一个入口发现还是旧版。想回滚更麻烦，谁都说不清上周的版本长什么样。这篇把提示词的管理规范整理成清单。

一次性任务写成 prompt 模板，这次要做什么、看哪些范围、怎么算完成，调用时把变量填进去。长期约束固化到规则文件，格式要求、安全边界、禁止项放这里。多步骤的固定流程单独放一份文档，用到才加载，不占常驻上下文。

三层混在一起是第一个大坑。一个五千字的提示词里塞着任务、规则、流程和示例，改一个数字要通读全文，模型也跟着变差。拆开之后，改任务只碰模板，改规则只碰规则文件，各自的影响面清楚。

规则文件里写请写高质量代码没有意义，模型没法稳定执行抽象要求。写法正确的是项目独有的约束，金额禁止用浮点数，统一整数或定点数；数据库查询必须参数化，不允许字符串拼接。这种规则模型能逐条对照执行。

有个判断标准，同一件事提醒到第三次，就该写进规则文件。写之前先问是不是可执行、是不是项目特有，两个都满足才进规则文件。

规则别贪多。堆到上百条的规则文件，模型对中段的遵循度会下降，和记忆篇里长上下文注意力稀释是同一个现象。定期做减法，过时规则删掉，我们一个季度从一百二十条砍到六十八条，坏例率反而降了。

提示词存哪决定了后面所有流程。我们的规范是全部进代码仓库，模板和规则都走代码评审，改动在 diff 里看得清清楚楚。版本按语义化编号，每条变更记录写清改了什么、为什么改。

变量注入留出位置，运行时填充，禁止在代码里手工拼字符串版本。回滚就是切版本号，一条命令的事，回滚演练每个季度做一次，确保真出事的时候手不抖。

改提示词和改代码一样要跑测试。我们维护了一份固定样本集，两类的题都放，正例看会不会回归，负例看有没有修好。改动必须跑全量，报告里附前后对比。

上线走灰度，按会话百分比放量。观察窗口内看三个指标，坏例率、拒答率、格式校验不通过率，任何一项恶化超阈值自动回滚。灰度拦下来的坏版本，上季度有四个，全量上线的话每个都是一次事故。

口径说明。数字来自自己项目的客服 Agent，样本集四百道题，改造内容是三层拆分、代码化版本和灰度。业务场景不同差别很大，套用前先建自己的样本集。

坑一，同一规则存在多处。三个入口各存一份，改一漏二。统一到一份规则文件后，各入口引用同一份，问题消失。

坑二，规则堆太长。一百二十条时模型开始挑着遵守，砍到六十八条并补齐示例后，遵循度回升。规则长度和遵守率要拿样本集量出来，凭感觉做减法不可靠。

坑三，回归集过拟合。样本集反复用来调提示词，后来发现新问题的表现比样本集差一截。加了留出集，调优只看一半，另一半只在验收时跑。

结合系列。结构化输出篇的格式约束在这里属于规则层，写一次全局生效。工具设计篇的错误提示也是提示词的一种，口径一致。记忆篇的注意力稀释解释了规则为什么要定期做减法。人工审核队列篇的抽检样本，可以顺手回流进回归集。

来源。任务、规则与流程的三分法和文件载体实践参考公开笔记（tz_zs 的 AI 编程使用笔记，讲 Rule、Skill 与 Prompt 的分工），回归与灰度的数字按自己项目口径整理。

觉得有用点个关注。