你的 Prompt 发布得像个牛仔：为什么代码审查的严谨性没能延伸到 AI 交付物

浏览任何成熟工程团队的 PR 队列，你都会看到同样的现象：一个四行的 Bug 修复会引来三轮关于命名、错误处理和测试覆盖率缺失的评论；而对系统提示词（System Prompt）的四十行修改却能凭借一句 “LGTM, ship it” 轻松过关。作者对此不以为意，因为差异对比（diff）看起来就像文档；审查者也无所谓，因为他们对于那段英文块中什么是“好”没有心理模型。结果是，一个具有功能发布级别影响范围的提示词更改，却仅以修复拼写错误的门槛通过了审查。

这是每个在生产环境中使用 LLM 构建产品的团队所面临的隐秘质量危机。代码库拥有数十年积累的纪律——Linter、类型检查、代码所有者（Code Owners）、测试关卡、发布窗口。而真正引导模型的产物——系统提示词、评估准则（Eval Rubric）、工具描述、少样本示例（Few-shot Exemplars）——虽然存放在同一个仓库中，却通过为英文散文设计的审查流程进行发布。因此，提示词回归、评估准则漂移和工具模式（Schema）损坏，却能以团队永远不会接受的代码质量标准通过。

解决办法不是“更仔细地审查提示词”。这种指令的效果等同于告诉初级工程师“写更好的代码”。团队需要的是一套针对每种 AI 产物失败模式量身定制的审查规范，包括审查者路由、关卡和工具化，使行为的变化而非文本的变化变得可见。

你的审查者不知道如何阅读的三种产物

每种 AI 产物都有其独特的失败模式，这些模式无法映射到审查者用于代码的启发式方法中。一个接受过 Python PR 培训的审查者能发现循环中的“差一错误（Off-by-one）”，却会漏掉以下每一个问题。

系统提示词。 提示词的修改是对模型指令栈的一次隐秘优先级调整。将一行内容从提示词底部移到顶部，你并没有“澄清”任何事情——你改变了当两个约束冲突时模型会听从哪一个。在已经写有“始终提供推理”的提示词中增加一行“保持简洁”，你就制造了一个内部矛盾，模型将根据每个请求随机解决这个矛盾。审查者看到的是增加了一个英文句子；生产环境的流量看到的则是性格转换。从业者已经开始将这些称为“提示词请求（Prompt Requests）”——即审查者签署同意上下文、意图、约束和假设，而非仅仅是措辞的同行评审。

评估准则（Eval Rubric）。 评估准则的修改是代码库中最危险的产物，因为它改变了你衡量事物的尺子。如果对“按 1-5 分衡量帮助程度”进行评分的判别提示词（Judge Prompt）增加了一个新的锚点示例（Anchor Example），那么仪表盘中所有的历史分数现在都变得不可比了。更糟糕的是，LLM-as-a-judge 校准会悄然漂移——三月份有效的准则到七月份可能就会悄悄地不再与人工审查者达成一致，而且除非有人专门观察，否则这种一致性指标是不可见的。如果你在不针对预留的人工标注集重新运行判别器的情况下修改锚点示例，你就已经在没人察觉的情况下重新锚定了整个校准体系。

工具描述。 工具描述不是 API 文档；它们是模型用来决定 是否 以及 如何 调用函数的提示词。模型实际上是将描述、参数名称和参数文档字符串作为标记化文本（Tokenized Text）来读取的。将参数名从 start_date 改为 sd1，模型的参数生成分布就会发生静态类型检查器无法捕捉的偏移。将描述从“当用户询问价格时使用”缩减为“仅当用户明确提到以美元计费时使用”，你可能就压制了该工具一半的调用量。函数签名没有改变，但行为改变了。

具有强大代码直觉的审查者一个也发现不了这些问题。他们只会注意到参数名现在符合蛇形命名法（snake_case），然后予以批准。

为什么“更仔细一点”对尝试过它的每个团队都失效了

同情性的理论认为，提示词发布得草率是因为审查者懒惰。而真正的原因是结构性的。

代码审查之所以有效，是因为审查者带来了两样东西：一个关于代码应该做什么的模型，以及一套失败模式的词汇表（竞态条件、差一错误、资源泄漏、SQL 注入）。对于 AI 产物，这两者都缺失了。审查者没有关于模型在长尾输入上如何表现的模型——这本该是评估套件（Eval Suite）提供的——而且他们也没有针对提示词修改、准则修改或工具描述修改的特定失败模式词汇表。

告诉审查者“更仔细一点”会产生三种结果之一：他们会因为不知道该找什么而直接盖章通过；他们会纠结于表面问题（大写、逗号位置），因为表面问题是他们词汇表中唯一存在的内容；或者他们会把球踢回给作者，问一句“你测试过了吗？”——在没有评估套件（这才是真正缺失的部分）的情况下，作者无法做出有意义的回答。

需要落地的纪律不是“更加小心”，而是一个能够补偿缺失的模型和缺失的词汇表的系统。

指明失效模式的评审者入职文档

团队在加强 AI 产物评审之前，应该交付的第一份产物是一份单页的评审员指南，其中列出了每种产物类型的失效模式。这不是风格指南，而是一个失效模式目录。值得包含的例子有：

• 针对提示词（Prompt）编辑：指令优先级偏移（之前的隐式顺序是什么？新顺序是否产生了矛盾？）、示例污染（新的 few-shot 示例是否意外地教导了评估集未涵盖的模式？）、人格漂移（“你是一个得力的助手”是否悄然变成了“你是一个咄咄逼人的谈判者”？）。
• 针对评分标准（Rubric）编辑：锚点重新校准（“5/5”的含义改变了吗？）、准则扩张（一个评分标准是否增长到要对四个正交维度进行评分？）、裁判提示词漂移（是否在未针对人工标签重新运行校准的情况下更新了裁判提示词？）。
• 针对工具描述编辑：调用率偏移（模型调用此工具的频率会增加还是减少？）、参数生成偏移（参数重命名是否改变了模型填充的值？）、工具选择歧义（新描述是否与现有工具的描述重叠？）。

这份文档是评审员缺失的词汇表。没有它，每次对 AI 产物的评审都得从零开始。有了它，评审员至少能问出正确的问题。

将 AI 产物路由给具备“评估熟练度”而非“代码熟练度”的评审员

下一个规范是机械性的：建立一条 CODEOWNERS 规则，将涉及 prompts/、evals/、tools/ 或 system-messages/ 的每个 PR 路由给一小组具备评估熟练度（Eval Fluency）的评审员。这与团队在 migrations/ 和 infra/ 目录上使用的模式相同——具有高爆炸半径（high-blast-radius）且拥有专门失效模式的目录，应由专门的评审员负责。

该评审小组的构成至关重要。评估熟练度并不等同于资历。一个从未写过裁判提示词的高级后端工程师，在处理评分标准变更时，其评审效果可能不如一个花过六个月调整评估的中级工程师。由于该目录风险很高，因此该小组应由真正理解这些产物的人员组成，而不是由代码仓库中提交次数最多的人组成。在实践中，这通常意味着要包括负责评估流水线的人，无论他们在组织架构中的位置如何。

这条规则也让 AI 产物变更的成本变得可见。当每个提示词 PR 都路由给相同的三个评审员时，这三个人将成为团队在提示词设计方面的专家中心——同时也是瓶颈。这就是反馈。如果瓶颈令人痛苦，团队就需要扩大评审员池，这意味着要为更多工程师投资培养评估熟练度。这正是应该施加的正确压力。

强制作者声明评估影响的评审模板

如果作者没有通过工作让行为变化变得可见，评审员的工作就是不可能完成的。解决方法是一个 PR 模板，要求作者填写：

• 评估集的哪个切片（Slice）涵盖了这次变更？ 如果答案是“无”，那么在请求评审之前，该 PR 应该增加评估覆盖。没有对应评估切片的提示词变更，就是没有测试覆盖的提示词变更——这正是团队应用于代码的标准。
• 评估增量（Delta）是什么样的？ 不是“评估已通过”——而是受影响切片上的实际指标变动，最好附带运行链接。一项能将整体准确度提高 1% 但导致某个切片从 95% 暴跌到 70% 的变更，是隐藏在总量中的退化（Regression）。
• 你进行了哪些人工抽检？ 对于裁判提示词本身的变更，这是不可协商的。自动化评分无法验证对自动化评分器本身的更改。
• 回滚计划是什么？ 提示词是部署的配置，而不是编译的代码。回滚应该是单次提交的撤销加上热加载，而不是长达数小时的部署。

评审员的工作变成了验证而非占卜。他们不再被要求预测行为变化——而是被要求确认作者测量到的行为变化是否符合作者的预期行为变化。

在 PR 内部运行评估切片

最后一块拼图是工具化：一个 CI 作业，在每个涉及 AI 产物的 PR 上运行相关的评估切片，并将结果作为评审评论发布。这与代码覆盖率门槛的模式相同，但被测试的产物是行为，而不是代码行。

到 2026 年，这些机制已经非常成熟。Promptfoo、Braintrust 等框架可以接入 GitHub Actions，针对更改后的提示词运行黄金集（Golden-set）评估，将结果与生产基准进行比较，并在 PR 中发布每个案例的差异（Diff）。评审员不仅能看到文本差异，还能看到分数增量、每个案例的退化以及实际发生变化的模型输出。这就是缺失的模型——不是由评审员的直觉提供的，而是由评估流水线提供的。

关键的实现细节：

• 切片选择。 在每个 PR 上运行完整的评估套件既缓慢又昂贵。CI 作业应根据变更内容选择切片——提示词编辑触发提示词切片，工具描述编辑触发该工具的工具调用评估，评分标准编辑触发针对留出的人工标签的校准检查。
• 具有回归容忍度的质量门槛。 当指标低于定义的阈值时阻止合并，但允许小幅波动。1000 个案例的评估中 0.5% 的下降可能是噪声；但在安全切片上 5% 的下降则是发布阻断因素。
• 输出差异，而不只是分数差异。 最有用的信息是“这里有五个案例，新提示词生成的输出与旧提示词不同”。这就是评审员眼中的“确凿证据”。
• 针对评分标准编辑的校准检查。 一个评分标准 PR 应该自动针对人工标注的校准集重新运行裁判，并发布一致性差异。如果一致性下降，合并将被阻止，团队必须在发布前重新校准。

成本与价值

这种规范的成本是实实在在的。编写和维护评审者入职文档需要时间。CODEOWNERS 规则将工作集中在少数人身上。PR 模板为那些工程师以前五分钟就能上线的变更增加了摩擦。CI 评估运行为每一个 prompt PR 增加了延迟和计算成本。

而 不 这样做的隐形成本更高，且更难察觉。提示词回归表现为客户满意度的缓慢下降，而不是测试失败。Rubric 漂移表现为仪表盘显示一切正常，而用户却在流失。工具描述的更改可能导致在上线六周后，智能体（Agent）对特定工具的使用率下降 15%，而没有人能记得原因。

在大多数团队中，AI 产物是代码的“低纪律性近亲”，因为它们看起来像文档，行为却像已部署的配置。能赢得持久战的团队是那些认识到这种不对称性，并专门为这些目前代码库中最具影响力的变更构建评审流程的团队。拼写错误修复在 diff 中应该看起来就像个拼写错误。而提示词的更改应该看起来像一次功能发布 —— 因为它本质上就是。

下次当一个四十行的系统提示词修改出现在你的评审队列中，且没有评估数据、只有一个 "LGTM" 时，请像对待一个四十行未经测试的函数一样予以回绝。你的模型正在发布一种行为变更。你的团队至少应该像对待行为变更一样去评审它。