周二下午，一个只有六行代码的系统提示词（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 中，新提示词在回答前输出了‘当然！我很乐意提供帮助……’；而旧版本没有——这是故意的吗？”，这讨论的是行为。
第二种评论的用处要大得多，但这需要评审界面能够展示行为差异。实用的模式包括：
- 对精选样本进行并排渲染输出差异。 完整的评估集可能包含数百个案例；PR 评论界面应包含约十个代表性输出的差异视图——旧版 vs. 新版——以便评审者阅读模型在两种情况下的实际表达。
- 将退化标注为红色，改进标注为绿色，模糊的变化标注为黄色。 这与测试通过/失败的辅助功能相同，只是应用于行为输出。它能引导评审者的注意力转向需要人工判断的案例。
- 让针对特定输出进行评论变得容易，而不只是针对提示词的差异。 如果评论线索挂载在提示词的行上，所有的对话都会塌缩到措辞上。如果它挂载在特定输入下的模型输出上，对话就能保持在行为层面。
采用这些模式的团队会发现一个显著的现象：以前只需 30 秒就能批准的提示词 PR 开始花费更长的时间——有时甚至长得多——而发布后的行为故障则大幅减少。延迟从“合并后、在生产环境中、当用户投诉时”转移到了“合并前、团队仍在参与其中时”。这是一种绝对的进步，尽管它减慢了单个 PR 的速度。
拆分评审角色：语气/风格 vs. 行为契约
提示词 PR 被草率批准的一个微妙原因是，团队没有区分两种完全不同的评审技能。一种是编辑性的：读起来是否顺口，语调是否与产品调性一致，指令是否足够清晰，以至于人类（更不用说模型）能够理解。另一种是行为性的：新提示词是否遵守了契约——在旧版本拒绝的安全案例上是否同样拒绝，输出格式是否符合下游代码的预期，是否处理了曾导致生产事故的四类问题。
这是不同的工作。编辑性评审可以由任何具有强大产品直觉和良好写作能力的人完成。而行为契约评审则需要熟悉评估套件、历史事故列表以及提示词必须处理的生产流量模式。假装一个审批者能同时做好这两件事，往往会导致 PR 虽然读起来很美，却悄悄破坏了不变式。
结构性的解决方案是要求两个独立的审批，并明确角色。语气/风格评审者对措辞、语调和清晰度发表评论。行为契约评审者阅读评估差异，查看退化的案例，检查安全子集上的拒绝行为是否得以保留，检查输出 Schema 是否仍能被下游解析。任何一位评审者都可以阻断（Block）；且双方都必须批准。这听起来很繁琐，直到你将其与另一种选择进行比较——另一种选择不是“更轻量的评审”，而是“由于无人负责发现行为退化，导致评审系统性地遗漏这些退化”。
在无法实行双人评审制度的小型团队中，同样的原则可以编码为单个人审批时必须执行的检查清单：一轮评审措辞，另一轮评审行为，并要求评审者针对每一项记录发现。角色的拆分比人数更重要。
评估覆盖率是隐藏的约束
即使是一个运行完美的成对 PR 流程，如果评估集本身没有覆盖提示词的实际职责，也可能会失败。一个提示词做了十件事；评估覆盖了七件；一个表面上旨在改进第 3 件事的修改，可能会悄悄破坏第 9 件事，因为没有任何测试覆盖过它。PR 以绿色状态发布，而退化则进入了生产环境。这并非流程失效，只是它没有看到它没去寻找的东西。
这就是为什么成熟的团队将评估覆盖率视为头等大事，并拥有自己的审计节奏。一些有帮助的实践：
- 将评估用例映射到提示词章节。 当提示词指令说“在总结技术内容时始终引用来源”时，应该有专门测试该指令的评估案例。如果没有案例对应某一行，那么这一行在任何意义上都没有经过评审——修改它就是在修改一段承重的注释。
- 挖掘生产环境追踪以扩大评估集。 用户实际发送的案例才是提示词必须处理的案例。定期对生产输入进行采样、脱敏并添加到黄金数据集（Golden Dataset）中，可以让评估随着实际使用而演进，而不是停留在团队第一天想象的状态。
- 将过去的事故编目为永久评估用例。 每一个逃逸到用户手中的行为退化都应该在套件中留下一个案例。这是提示词工程中等同于回归测试的做法。没有它，同类故障就可能再次发生。
- 显式而非隐式地跟踪覆盖率。 “我们有 200 个评估案例”并不能告诉你覆盖情况。“我们有评估案例覆盖了系统提示词中的 14 条指令中的每一条，以及 9 个已知的历史故障模式中的每一个”，这才能告诉你套件到底验证了什么。
对于任何提示词 PR，一个有用的诊断问题是：如果我把提示词改错了，哪个评估案例能发现它？如果答案是“没有具体的案例”，那么团队就是在凭信念批准。
当这种规范深入人心时，会发生什么变化
当 Prompt PR 经过配对的评估与 Prompt 审查、包含行为差异（behavioral-diff）评论、角色分离的审批以及经过审计的评估覆盖率时，会显现出几种二阶效应：
Prompt 本身重新变得可编辑。以前，团队将 4000 token 的系统 Prompt 视为具有承重作用的遗留代码——因风险太大而不敢触碰，因理解不足而无法重构。现在，由于有了评估安全网，团队获得了足够的信心开始清理工作。矛盾的指令得到调解。废弃条款（为了应对早已解决的故障而添加的）被停用。Prompt 体积缩小了。
行为故障减少了。并非降至零——评估覆盖率总是滞后于完整的输入空间——但“我们更改了 Prompt 却没注意到”这类故障基本消失了。剩下的故障则是团队从未设想过需要测试的全新行为，这些是值得研究的问题，而非令人尴尬的失误。
“Prompt 工程师”的角色不再是一个模糊的头衔，而变成了一项明确的技能。具体来说：他能够阅读评估增量（eval delta），识别哪些回归（regression）至关重要，重构 Prompt 以修复回归且不破坏其余部分，并更新评估套件以防止类似情况再次发生。这就是软件工程，而 Prompt 就是源码。
最深层的转变是文化上的。团队不再认为 Prompt 很简单，仅仅因为它的差异（diff）读起来像英语。他们深刻理解：diff 只是副作用；行为的变化才是真正的变化；而不以评估证据为基础的代码审查流程，只是披着工程仪式外衣的表演。一旦团队建立了这种信念，其他的实践就会自然而然地步入正轨——因为团队终于在审查正确的产出物了。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
