上周改了系统提示里的一句话，三条业务线悄无声息地坏了，两天后才有人反馈。写点教训。 问题不在于那句话改错了，而在于我们把提示当文案在管，不是当代码在管。它没有版本，没有评审，改动没有 diff，出了事没人说得清是哪一次改的。而它对行为的影响，实际上比一半的代码都大。 现在的做法是：提示进仓库，跟代码一起走 PR；每条业务线固定一组回归用例，大概三十条，改提示必须先跑一遍，逐条对比输出的差异；差异不是自动判分，是人看的，因为大部分变化没有对错，只是风格漂移，得有人决定这个漂移能不能接受。 三十条用例听着少，但它拦下的两次都是那种上线之后极难查的问题。
Treating the prompt as a versioned artifact is the single highest-leverage change most teams have not made. The part I would add is pinning the model version alongside it. The same prompt against a silently updated model is a different system, and if only one of the two is under version control you will eventually spend a week bisecting a change you never made.
if it changes behaviour it goes through review. a prompt is config and config has always been the thing that breaks prod
人工比对三十条这个量刚好，再多就没人认真看了，变成走过场。我们还额外存了每次评审时的判断理由，下次出现类似的漂移可以直接翻旧账，不用重新吵一遍。
模型版本这条确实是漏了，我们只锁了提示，模型一直是跟着服务方走的。回去就把版本号一起写进用例的元数据里，不然对比的基准本身就是浮动的。
yep totally get the human in the loop for reviewing prompt diffs its crucial cause subtle shifts can be intended or accidental and the context matters a lot where automated checks fail is where this really shines imo
