Prompt 修改不只是措辞变动：将 Prompt 视为软件的代码审查规范

周二下午，一个只有六行代码的系统提示词（system prompt）编辑出现在了一个 Pull Request (PR) 中。Diff 只是普通的英文。两位评审者扫了一眼新的措辞，觉得读起来更自然，于是点击了批准。PR 在不到一分钟内合并。到了周五，客服开始收到关于智能体的工单：它突然拒绝总结超过一定长度的文档，不再引用来源，并莫名其妙地在每句回复开头都加上 “Certainly!” —— 这种行为没人要求过，Diff 中也无法预见。

当一个花了十年时间学习如何评审代码的团队，在面对提示词这一产物时，竟然退化到了第一周的水平，结果就是这样。Diff 看起来 毫无害处，因为它读起来像英语，而人类正是用眼睛来审阅英语的。让代码评审发挥作用的规范 —— 运行测试、检查影响范围、对 “小改动” 保持适当的怀疑 —— 并没有悄然转化。措辞变好了，但行为变差了，直到用户发现之前，没人注意到。

解决办法不是 “更仔细地评审提示词”。像阅读更大的函数调用点那样费力地盯着英语看，并不能发现行为回归。解决办法是重新设计评审流程，让承重的产物不再是纯文本的 Diff，而是文本 Diff 所产生的测评增量 (eval delta)。一旦团队达成这一共识，几乎所有其他的评审弊病 —— 缺乏评审专长、过度自信的批准、相互矛盾的指令缓慢堆积 —— 都有了结构性的答案。

失败模式：针对行为变更的 30 秒批准

大多数交付 AI 功能的团队在他们的代码库中都有系统提示词，进行版本控制，并像对待其他文件一样在 Pull Request 中打开。这比起在供应商控制台中粘贴提示词的时代已经是一个进步。但版本控制并不等同于评审。版本控制给你一个 Diff，而评审赋予这个 Diff 意义。

弊病体现在批准时间上。一个典型的工程团队不会在 30 秒内批准一个 60 行的授权助手重构。他们会阅读函数，追踪调用者，运行测试，询问第三个分支中的边缘情况。同样的团队会在 30 秒内批准一个 60 行的系统提示词重写，因为 Diff “读起来没问题” —— 对于纯文本来说，“读起来没问题” 就像代码通过测试一样：是一个没有明显破坏的强烈信号。

但 “读起来没问题” 是 文本 的属性，而不是 产生文本的系统 的属性。提示词不是文档。提示词是一个部分程序，其运行时是一个模型，其行为对措辞极其敏感。从系统提示词中删除 “简洁 (concise)” 一词并非编辑性修改。它是对随机系统 (stochastic system) 的行为变更，而观察变化的唯一可靠方法是运行系统并进行测量。

因此，第一步是文化上的：停止称这些为 “措辞修改”。提示词编辑是行为编辑。PR 标题、提交信息、评审者的心理模型 —— 所有这些都必须从这一前提开始，否则其他规范都无法落地。

测评与提示词配对的 PR：测评增量是核心产物

最重要的评审模式是结构性的：如果没有附带测评增量 (eval delta)，提示词 PR 就不应该是可评审的。PR 模板应该强制要求它。没有它，CI 应该报错。评审者不应有绕过它的批准路径。这不属于官僚主义；这与大多数团队要求测试随代码一同提交的逻辑是一致的。

“测评增量 (eval delta)” 的具体含义是：PR 针对固定的测评集（包含代表性输入的黄金数据集，涵盖常见案例、边缘案例和已知的过去失败案例）运行新的提示词，并将与旧提示词结果的对比直接发布到 PR 中。评审者在看到措辞变化的同时，还能看到：忠实度 (faithfulness) 从 0.84 降至 0.81，7 个案例出现回归，12 个有所改善，以及一个之前通过的长文档总结案例现在失败了。随后，PR 评论中的对话将围绕回归展开，而不是围绕副词。

一些细节决定了这一规范能否坚持：

• 测评集必须与提示词一同版本化。 如果在评审提示词时黄金数据集发生漂移，对比就失去了意义。将测评集视为受追踪的产物 —— 采用与生产代码同样的评审严谨性，并通过专门的 PR 进行刻意更新 —— 的团队可以获得可靠的信号。
• 每个案例的 Diff 比总分更重要。 一个在默默破坏关键类别的同时将平均分提高 2 分的提示词，在总结中看起来像是在进步。成熟的评审模板会明确指出每个案例的回归，而不是将其埋没在一个绿色的对勾下。
• 裁判 (Judge) 也需要评审。 当测评使用 LLM-as-a-judge 评分时，裁判提示词本身也是一个提示词 —— 对其的编辑也应遵循同样的配对 PR 规范。否则，团队拥有的测量工具将无法被审计。
• 成本和延迟也是增量的一部分。 一个虽然提高了质量但使 Token 消耗翻倍的提示词更改并不是毫无疑义的进步；评审需要同时看到这两个轴。

当这一切到位时，评审对话的形式就变了。评审者不再说 “我觉得这读起来更好”，而是说 “测评显示文档总结出现了两个回归 —— 这是有意的还是副作用？” 争论点从品味转向了证据，这正是代码评审流程从 “我觉得行” 转向 “测试通过” 时所经历的变化。

行为差异评论：引用模型输出，而非形容词

即使 PR（拉取请求）中包含了评估分数，对话的实际质量仍取决于评审者关注的内容。如果评审者评论“我觉得用‘简短地’比‘简洁地’好”，这讨论的是措辞。如果评审者评论“在测试用例 #14 中，新提示词在回答前输出了‘当然！我很乐意提供帮助……’；而旧版本没有——这是故意的吗？”，这讨论的是行为。

第二种评论的用处要大得多，但这需要评审界面能够展示行为差异。实用的模式包括：

加载中…