为什么凭感觉调提示词一定会失败
大多数人改提示词的过程是这样的：跑一次，觉得不太好，加一句话，再跑一次，好像变好了，于是保存。问题在于，你觉得变好的那次，可能只是恰好碰上了一个简单输入；而那个被你删掉的表述，可能在处理边界情况时非常关键。
更麻烦的是，提示词的改动效果不具有可加性。加了约束 A 变好，加了约束 B 也变好，两个一起加可能反而变差，因为它们互相干扰。没有测试，你永远发现不了这件事。
第一步：给提示词建版本档案
先把提示词从聊天框里搬出来，放进一个受控文件。建议目录结构：
prompts/
customer_reply/
v1.0.md
v1.1.md
v1.2.md
CHANGELOG.md
testcases.json
每个版本文件顶部写元信息：版本号、修改日期、修改人、改动原因、预期影响。CHANGELOG 里记一句人话：这一版改了什么，为什么改。
版本号规则：小修调最后一位（措辞优化），结构改动调中间一位，目标或输出格式变更调第一位。
第二步：构建测试用例集
这是整套方法里最花时间也最值得的部分。测试集需要覆盖四类输入：
- 典型场景：日常最常见的 5 到 8 个输入，占实际流量的大头
- 边界情况：极短输入、超长输入、空输入、只有标点符号
- 对抗输入：试图让模型越狱、输出敏感内容、或诱导它编造事实的请求
- 历史事故：过去真实出过问题的输入，必须收录，这是回归测试的核心
测试集不是一次建成的。每发现一次线上问题，就往里加一条。三个月后这份测试集会成为你最值钱的资产——它记录了所有你踩过的坑。
规模建议：起步 15 到 20 条就够用了，不要追求上百条导致自己懒得跑。
第三步：定义可判定的评分标准
请帮我看看哪个更好 这种主观判断无法积累。要把评价拆成可打分的维度，例如客服回复场景：
- 事实准确性：是否出现知识库外的编造（0 或 1，出现即为 0）
- 格式合规：是否按要求输出了指定字段（0 或 1）
- 语气一致：是否符合设定的品牌调性（1 到 3 分）
- 信息完整：是否覆盖了用户问题的全部要点（1 到 3 分）
- 长度控制：是否在规定字数区间内（0 或 1）
前两项是一票否决项，这类错误必须归零。后面的主观项允许有分歧，但要把评分理由写下来，慢慢对齐团队标准。
第四步：跑 A/B 对照实验
对比两个版本时，必须遵守三条规则：
- 同输入、同模型、同参数：温度值、随机种子能固定就固定，只让提示词这一个变量变化
- 每条用例跑多次：单次结果有随机性，重要用例至少跑 3 次取多数结果
- 盲评：如果有人参与打分，不要让他知道哪个是新版本，否则会有期待偏差
记录方式很简单，一张表格：行是用例，列是版本 A 得分、版本 B 得分、差异、备注。跑完算总分，同时单独看有没有某条用例大幅退步——总分提升但个别用例崩掉的版本不能直接上线。
第五步：建立回归测试清单
每次发布新版本前，跑一遍历史事故用例。这个清单来自第二步的第四类输入，是硬门槛。任何一条不过，版本就不能上。
同时养成一个习惯：当新版本在某条用例上表现更好时，把该用例加入回归清单，锁定这个改进。否则下次改动很可能又把它改回去了。
第六步：控制变量，一次只改一处
这是最容易被违反也最致命的原则。一次改三处，效果好了你不知道是哪处的功劳，效果差了你也不知道该回滚哪处。
如果确实有一批想法要验证，正确做法是为每个想法单独建一个分支版本，分别跑测试，最后只合并通过的那几个，并对合并后的版本再跑一次完整测试。
常见问题与误区
- 问：测试集多大才够？覆盖住你的主要场景和历史事故就够了。15 条认真维护的用例，价值远高于 100 条建完就没人碰的用例。
- 误区：分数高的版本一定更好。要看得票分布。总分领先但方差很大的版本，说明稳定性差，线上表现会飘。
- 问：模型升级后提示词要重测吗？必须重测。模型版本变化可能导致原有提示词失效，尤其是那些依赖特定表述习惯的写法。
- 误区：提示词越长越精确。过长的提示词会稀释重点，且消耗成本。每次加约束前先问一句：这条约束是为了解决哪个已发生的问题？答不上来就别加。
- 问：团队协作时怎么避免互相覆盖？提示词文件纳入版本控制系统，改动走评审流程，禁止直接在线上编辑框里改。
效率数据与实测结论
以一个电商客服回复提示词为例：凭感觉迭代阶段，两周内改了 11 版，输出质量波动明显，期间出现 3 次线上事故。改为测试集驱动后，同样两周内迭代 6 版，每一次都有明确的分数变化依据，事故降为 0，人工返工率从约 35% 降至 12%。
前期投入约 4 小时建测试集，之后每次迭代的测试成本约 20 分钟。跑过五六次之后就已回本——因为返工和事故的时间远比测试贵。