你发布 Agent 的那天，系统提示词（System Prompt）仅包含三条规则和一个语气指令。评估测试集（Eval suite）为每条规则覆盖了十个案例，CI 徽章是绿色的，团队理所当然地感到自豪。十八个月后，同样的提示词变成了四十条规则、六个工具描述、四个 Few-shot 示例、两个安全前导语，以及一个在每次事故后都会增加一项的拒绝分类法。相比之下，评估测试集可能只增加了二十个案例——每个事故增加一个，且都是在压力下编写的，从未针对通过日常提示词 PR 悄无声息引入的几十条规则进行补测。
当 PR 发布时，团队仍然会说“评估通过了”。他们实际的意思是“我们十八个月前编写的评估，在针对那些评估已无法完全描述的提示词时依然通过了。”置信区间的分母在默默扩大，而分子几乎固定不变。下一次触及三十七条未测试规则之一的提示词修改，将被一个对其毫无判断力的测试集评定为安全。
这与没有测试的代码模式相同，只是提示词的增长与评估的增长之间的不对称性让情况变得更糟。一条提示词规则只有一行——输入、提交 PR、从读得懂英语的队友那里获得点赞、发布。而一个评估案例是一个结构化的产物——编写输入、编写预期行为、编写评分器（grader）、将其集成到 CI 中、标记其覆盖范围。前者只需要三十秒，后者需要一个下午。这两个层面正以不同的梯度演进，唯一能让它们保持同步的，只有团队对上次审计测试集时存在哪些规则的记忆。
提示词是没有编译器的代码平面
对系统提示词的常规解读是将其视为指令——模型所依赖的自然语言引导。这种构架虽然正确但并无用处。一个更有用的构架是：系统提示词是一组可寻址、可单独测试的规则，只是恰好以纯文本形式编码。每条规则都是一份契约：在条件 X 下，模型应产生行为 Y。规则是用英语编写的这一事实并不意味着它们不是规范；它只意味着编译器就是模型本身，而编译发生在推理阶段，且作用于你可能采样也可能未采样的流量上。
当你以这种方式看待提示词时，你开始提出的问题就是你会对一个服务提出的问题。这个提示词编码了多少条规则？其中哪些有测试？哪些有生效 的测试——即产生有意义的通过/失败，而不是退化为“模型没崩溃”？哪些规则相互冲突？哪些规则已经失效——由一个触发场景不再出现在生产流量中的评估所维护？
这些问题中没有一个可以通过阅读提示词来回答。只有通过将提示词视为工具的输入才能回答。不构建这些工具的团队是在凭信念行事，相信“我们知道里面有什么”——而一旦最初的作者轮换出团队，这种信念就是剩下的唯一东西了。
规则是如何在没有测试的情况下进入的
提示词增长与评估增长之间的双轨漂移有几条特征性的进入路径。识别它们是阻止它们的大部分工作。
第一种是事故补丁 。生产环境产生了错误的输出，事后分析确定根本原因是提示词未能预见到某种场景，修复方案是在系统提示词中增加一个新句子，并且针对该特定场景的回归测试在同一天被添加到测试集中。新规则有了覆盖。到目前为止一切都很好——除非在下一个 Sprint 中，同一位作者为了解决新规则边缘情况与旧行为的重叠，在相邻规则中添加了一个澄清条款。这个澄清条款在没有自带测试的情况下发布了，因为没有事故来推动它。随事故而来的规则经过了测试；而与之并存的规则却没有。
第二种是安全插件 。一项新法规、一类新的误用、或来自安全审查的新发布阻碍因素产生了一个前导语。前导语被视为政策而非逻辑——它由政策团队审查、批准并合并。政策文本很少伴随评估案例，因为负责政策的团队并不负责评估测试集。规则作为文本进入提示词，别无他处。
第三种是 Few-shot 渐长 。有人注意到模型在给定示例时能很好地处理特定的歧义，于是他们添加了一个示例。然后有人添加了第二个示例来覆盖相邻的案例。然后是第三个。六个月后，提示词有了四个 Few-shot 示例，它们共同暗示了一条团队从未明确写下的行为规则。规则存在，规则塑造输出，规则未经过测试——而且与其他两条路径不同，规则甚至没有被写成 规则。它是示例的一种涌现属性。
第四种是工具描述重写 。工具目录发生了变化；描述被更新以反映新的参数或新的返回结构；提示词的工具部分增长了二十行。编写更改的是工具团队而非提示词团队，而提示词团队没有注意到新的描述隐含了一种使用模式，该模式与系统提示词中三页前的某条规则相冲突。
在这些路径中的每一条中，规则通过低摩擦进入，而评估则因为高摩擦未能进入。结构性的修复方案是反转这种摩擦。
覆盖率是一个比率，而分母才是难点
如果你接受 Prompt 是一组规则，而评估套件（eval suite）是一组测试，那么显而易见的指标就是 带有测试的规则数除以 Prompt 中的规则总数 。分子很简单——统计你的评估用例（eval cases），按它们针对的规则进行分组。而分母则是让团队头疼的部分。
要计算分母，你必须从运行中的系统 Prompt 中提取出可寻址的规则。这种提取并非没有成本。简单地按句子拆分会造成过度计数，因为有些句子只是同一条规则的延续。按段落拆分则会计数不足，因为一个段落通常包含多个约束条件。真正靠谱的方法是采用一个解析步骤，通过它识别出具有规则特征的单元：祈使句、条件句、约束、禁止项、格式要求、语气指令、工具使用指令。这个解析器本身也是一段代码，需要保证其正确性，但它不一定要完美——它必须保持一致。如果同一个解析器针对每个版本的 Prompt 运行，那么即使单次快照的数据不够精确，“带有测试的规则 / Prompt 中的规则”这一趋势仍然是有意义的。
一旦你能计算出分母，Prompt PR 和评估 PR 之间的不对称性就会变得显而易见。一个增加了三条规则但零测试的 Prompt PR，现在会在覆盖率上显示为负增量。审阅者看到这个增量，要么编写测试，要么明确决定接受覆盖率的下降——这变成了一个记录在案的产物，而不是一种无声的债务。
让两个层面协同演进的模式 有几种模式可以缩小 Prompt 增长与评估增长之间的差距，它们是叠加关系而非替代关系。表现出色的团队通常会结合使用其中的大部分模式。
合并前覆盖率检查 。这是一个 CI 步骤，它将提议的 Prompt 的解析规则集与 main 分支进行对比，如果新规则集的配对评估用例比旧规则集少，则 PR 失败。这是影响力最大的改变，因为它在修改 Prompt 的瞬间施加了摩擦力，此时作者仍有编写测试的上下文背景。
覆盖率报告与评分报告并列 。大多数团队在每个 PR 上都会发布一个评估通过率数字。很少有团队发布覆盖率数字——即哪些规则至少有一个通过的评估。将它们并排放置，可以让任何阅读 PR 的人都能看到这种不对称性，而不仅仅是评估团队。“评估通过率 98%，覆盖率 41%” 比单纯的“评估通过率 98%”要难忽略得多。
陈旧评估的弃用节奏 。那些不再触发的评估规则——因为模型现在能轻易处理该情况，或者因为底层场景不再出现在生产流量中——都是累赘。它们虚增了分子，却没能提供任何保护。每季度进行一次审计，删掉那些触发场景在 N 个月内未在生产中出现的评估，可以保持套件的真实性。这也会迫使团队讨论该规则是否仍然具有支撑作用。
将 Few-shot 示例视为命名规则 。Few-shot 示例是规则在没有被写成规则的情况下潜入的路径。将每个示例提升为它旨在演示的命名规则——并针对该命名规则编写测试，而不是针对字面示例编写测试——可以将隐式规范转换为显式规范。规则现在是可寻址的。当有人重新组织示例的措辞时，测试不再会失效。
每个 Prompt PR 配备第二作者 。许多团队已经要求在代码上有两名审阅者。很少有团队要求对 Prompt 修改进行两名审阅，因为 Prompt 修改看起来很轻量。要求其中一名审阅者来自评估团队——或者仅仅要求其中一人将相关的评估用例附加到 PR 上——闭合了社交反馈环。作者无法独自合并，而第二位审阅者的工作是询问：“如果这部分发生退化，什么测试能捕捉到它？”
技术失败背后的组织失败 在技术偏移的背后是组织的偏移，如果不解决组织问题，技术修复就无法持久。评估团队衡量的是“我们测试的 Prompt 是否仍然通过”，而产品团队发布的是“我们要发布的 Prompt”。这两个层面有独立的评审周期、独立的所有者和独立的失败模式。两个团队中没有人因为注意到它们的背离而获得报酬。
坚守底线的团队通常会做两件事之一。要么他们将评估团队和 Prompt 编写团队合并为一个具有共同轮值（on-call）责任的职能部门，这样未经测试规则的成本就会被编写规则的团队内部化。或者他们将覆盖率作为直接考核 Prompt 编写团队的指标——此时不对称性发生反转，编写评估的摩擦力变得低于解释覆盖率为何下降的摩擦力。
如果没有这些结构性变革，技术干预就会变成逐渐被侵蚀的仪式。合并前检查会在截止日期压力下被绕过。覆盖率报告变成了一个大家都默许忽略的黄牌警告。弃用节奏不再进行，因为负责该工作的团队进行了轮换。偏移仍在继续，只是表现得更体面一些。
当你不衡量覆盖率时，你交付的是什么 一个没有单条规则覆盖率的 Prompt 和一个没有集成测试的服务，在本质上是语法形式不同的同一种产物。两者在流量触及未经测试的分支之前看起来都运行良好。在下一次事故复盘中，它们都会被以类似“我们没意识到还存在这种情况”的理由进行辩护。两者都可以变得可控，但前提是必须将这些产物视为代码：可寻址、可解析、受版本控制，并根据覆盖率梯度进行持续衡量。
如果一个团队任由 Prompt 增长而不扩充测试集，那么他们交付的置信区间，其分母正在悄然扩大。Eval 通过率看起来和一年前一样，但它所代表的意义已远不及当初。下一次回归将不会是模型故障，而是一次衡量失效 —— 针对三个月前悄悄添加且无人维护的规则，由于缺乏相应的 eval 评估，最终由用户发现了问题。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
