改完 prompt 就忘？给它加一份更新日志

改动 prompt，跑两个输入，觉得「好多了」，收工。一周之后没人记得改过什么、为什么改，某个早就修掉的老毛病又悄悄回来了。

Reddit 的 r/PromptEngineering 上有位用户 ClickOk5811 提了个轻量做法：给 prompt 建更新日志，再配一套固定的测试输入。思路和写代码差不多，每次改动记下来，可回溯，也可复测。

他给的示例条目是构造的，不来自真实项目：

PROMPT: support-ticket-summarizer
VERSION: 7  (was 6)

CHANGE
  Added: "If the ticket has no clear request, write 'No request found'
  instead of guessing."
  Removed: "Be concise." (replaced by "max 2 sentences")

WHY
  v6 invented a request for tickets that were just complaints.

TEST SET (frozen, 20 tickets)
  Includes: 4 complaints with no request, 3 very long threads,
  2 non-English tickets, 1 empty ticket.

RESULT (each ticket run 3 times)
  Complaints: 12/12 now say "No request found" (v6: 5/12)
  Long threads: unchanged
  Non-English: 1 of 6 runs answered in English instead of the ticket's language
  -> new issue, logged for v8

KEEP / REVERT:  keep

每个部分存在的理由：

一个版本只改一处，或者明确打包成一组。一次动四个地方，你分不清是哪一个起了作用、哪一个帮了倒忙。

WHY 这一栏。把理由写下来，后来的人才不会觉得这行字多余，顺手删掉。

固定测试集，里面必须有难看的案例。空输入、超长输入、其他语言、根本没有正确答案的输入。只用简单样例拼出来的测试集，结论永远是「变好了」。

如果输出不确定，每个输入多跑几次，报次数，别报感觉。

发现的退化要记下来，哪怕最后保留了这次改动。上面那条非英语的结果就是一个取舍，值得写进档案。

局限他也没藏着：

20 条输入是冒烟测试，算不上统计证明，在 20 条上好看的改动未必能推广。输出如果由人或另一个模型打分，这个判断本身也有噪声，需要抽查。结果依赖模型和参数设置，这些要一并记下，换了模型版本得重跑，同一个 prompt 在新版本上的行为可能完全不同。还有，这是额外开销。一次性的 prompt 不值当，跑在生产线上的，大概率值。

他最后问了句：你们怎么追踪 prompt 改动，repo、表格、提示词管理工具，还是什么都没有？测试集里都放些什么？

这类习惯门槛低到不像个方法，但去问一圈会发现，大多数团队确实什么都没有。