Prompt 删了一句无关紧要的话，三天后发现输出内容变差了：提示词版本管理指南很重要
- 一条正在给用户干活的 prompt 被顺手删掉一句「废话」，上线后没有任何东西报警，三天后靠一张客服工单才暴露。
- 1018 条打过分的 prompt 里，最差的一项是「有没有交代过遇到烂输入该怎么办」，均分只有 31.5 分，而它恰好是删改时最先被当成废话删掉的那部分。
- 治法是四道关口，其中一道能在上线前把这类改动直接拦回去。不买工具的话，git 加一个打分脚本就够。
删掉几句看着没用的话，上线后没有任何报警
有人在改一条正在给用户干活的 prompt。他看里面有几句话没什么用，就删掉了，顺带还省了几个 token。上线前顺手做的那种清理，谁都做过，不会多想一秒。上线之后，没报错，没告警，监控一切正常。三天后一张客服工单来了：用户拿到的回复含混、跑题，有时候还错得很自信。
这是 Reddit 的 r/PromptEngineering 版上一篇开发者复盘帖，讲的是他被这件事逼出来的一套 prompt 版本管理流程。只要你有 prompt 正在给用户干活，接了 API 的应用也好、每天自动跑的流水线也好，这就是你迟早会踩、而且踩了不知道的那个坑。
三天里，一条已经变差的 prompt 在服务真实流量，悄悄发出去一批更差的答案，中间信号是零。
prompt 变差为什么不报警，眼睛也看不出来
同样是改坏了，代码和 prompt 的差别在于：坏了之后有没有人告诉你。
| 代码改坏了 | prompt 改坏了 | |
|---|---|---|
| 当场发生什么 | 抛异常、编译不过、一跑就崩 | 照样返回一段像样的文本 |
| 程序收到什么 | 一个失败 | 一个正常结果 |
| 谁会告诉你 | 测试、编译器、监控告警 | 没有人 |
| 你什么时候知道 | 当场 | 三天后，靠用户投诉 |
差别的根子在于：prompt 是自然语言，你把它改得再残缺，模型也会尽力返回一串文本。它不报错，也不给任何失败信号。所以它不会突然坏掉，只会一次比一次差一点，直到「差一点点」攒够了，变成「客户开始察觉了」。
那上线前扫几个输出看看行不行？肉眼能抓住的只有显性错误：返回一串报错、格式整个乱掉、答非所问到一眼可见。质量滑坡抓不住，原因有两条，输出看上去仍然是一个正经答案，只是更差的那个；而你自己是带着预期去看的，知道这条 prompt 该说什么，读到的每句都往那个方向对号入座。真正的滑坡要等大量真实用户花式提问才露得出来，而那时候露出来的形式就是工单。
1018 条 prompt 打分，应付意外输入这项最低
这不是一个人手滑。1018 条 prompt 打过分之后，同一个毛病到处都是。打分满分 100，拆成四项看，这四项本身就是一份「一条 prompt 可能烂在哪」的清单：
| 这一项 | 要求什么 | 典型翻车 |
|---|---|---|
| 清晰度 Clarity | 这个任务只有一种合理解读，模型不用猜 | 动词含糊：「帮我处理一下」「改进一下这个」 |
| 具体度 Specificity | 对输出的要求要能衡量，不能只给形容词，别让模型自己猜「什么算做完了」 | 「写一段简洁的摘要」，而不是「用大白话写一段三句话的摘要」 |
| 结构 Structure | 指令按逻辑顺序排：角色在前、背景第二、任务第三、格式最后 | 格式要求埋在任务后面、角色压根没写、约束条件散落各处 |
| 健壮度 Robustness | 对最可能出岔子的那几种情况，写死了该怎么办 | prompt 默认用户会给干净规整的输入，而真实用户什么都往里塞 |
四项里垫底的是最后一项，健壮度英文原词 Robustness。它问的是：这条 prompt 有没有交代过「遇到不正常的输入该怎么办」，用户没说清需求返回什么、输入是空的返回什么、格式完全不对返回什么。这几种情况要一个个点名写死动作，笼统一句「请妥善处理」不算。，也就是这条 prompt 有没有交代过「遇到不正常的输入该怎么办」。1018 条的均分只有 31.5 分。