你的评估套件就是你拒绝编写的产品需求文档

打开本季度发布的任何 AI 功能的 PRD。注意那些形容词。助手应该是有帮助的 (helpful)。回复应该是自然的 (natural)。智能体应该理解 (understand) 用户的意图。摘要应该是准确 (accurate) 且简洁 (concise) 的。每一个这样的词都是团队放弃决策的地方。他们并没有决定这个功能要做什么。他们只是决定了在会议中如何向彼此描述这个功能，然后——在没人点破的情况下——悄悄地将实际的产品定义移交给了编写评估集的人。

这不是文档问题。评估集就是规格说明书。PRD 是一份在产品诞生前撰写的官方新闻稿。文档中模糊的形容词在评估集中变成了明确的行为断言，否则它们就毫无意义——模型会自行挑选一种解释并发布，而团队在三个月后才会发现，“简洁”对审核者、用户以及在上一个 Sprint 调整 Prompt 的人来说，含义完全不同。一个评估集薄弱的 AI 功能，其产品定义也同样薄弱。模型并没有失败。团队从未决定过成功意味着什么。

形容词是被推迟的决策

读一份传统的 PRD，假设你必须根据页面上的文字来实现它。“有帮助的”是一个包含十几个维度的向量：助手是优先处理用户的任务还是字面上的请求？在模糊不清时是先询问还是先猜测？它是否会建议用户没问过但相关的任务？对于表述不清的问题，它是回答用户想问的问题还是字面输入的问题？产品经理 (PM) 和工程师都可以对“有帮助”点头示意，但私下里对这 12 个问题的答案却互不兼容。当编写评估集时，必须做出选择——每一个测试用例都是在各个轴向上未曾言明的抉择。

“简洁”也是如此。对于只想要一个数字的用户来说，200 字的回答并不简洁。对于想要推理过程的用户来说，12 个字的回答也不简洁。简洁是请求内容、用户专业程度、阅读渠道以及出错后果的函数。PRD 假装这是一个决策；而评估集则强迫做出 12 个决策，并将其写下来，在代码审查中进行辩护，最后通过真实案例的测试通过或失败来予以批准。

大多数团队采用的交付顺序把这些决策放在了错误的位置。工程团队在 Prompt 基本构建完成之后，根据已经积累的 Trace 采样数据来编写评估集。评估集对 Prompt 现有的行为进行编码，将其称为规格说明并将其冻结。忙于下一次发布的 PM 从不阅读这些案例。他们也没被邀请参与。因此，团队在优化一份从未经过产品人员批准的行为契约，而测试用例则是由评估集建立时恰好值班的人编写的。

以 PM 的口吻，先写评估集

反转工作流比听起来要难，因为大多数 PM 从未写过评估案例，而大多数工程师从未写过产品规格。这种规范并不是“由工程师写评估来代替 PM 写 PRD”，而是评估案例就是 PRD，编写案例是一项产品决策活动，而非测试活动。

从一个足以驱动评估的功能简报开始——用户、交互界面、成功的结果。然后与 PM 坐在一起编写案例。案例分为三种类型，每种都锁定了 PRD 规避的不同决策：

• 消歧案例 (Disambiguation cases) 将每个形容词转化为“是”或“否”。“助手是简洁的”变成了十对请求/回复，团队一致认为这些回复长度适中，另外十对则太长，分界点在数据中清晰可见，而非在散文中宣称。
• 拒绝案例 (Refusal cases) 通过示例决定哪些内容超出范围。PRD 经常说“助手专注于 X”，却不列举它必须拒绝的非 X 内容。拒绝案例是团队承认他们刻意不构建哪些相邻任务的地方。
• 边界案例 (Edge cases) 强迫做出 PRD 磨平的权衡。对于一个部分在范围内、部分被拒绝的请求，助手该怎么做？对于用户语气粗鲁的问题呢？对于真实但没用的事实呢？每个案例是一个决策；收集它们就是规格说明。

预构建的评估框架使这一过程正式化。对于每个场景，你需指定预期意图、所需的提取数据、允许的工具行为、Grounding 规则、回复预期以及明确的失败条件。框架的约束力在于模糊的需求无处藏身——每一行都是一个可测试的主张。

Hamel 的反论及其真实含义

在从业者社区中，对这种框架确实存在反对意见。引用最多的是 Hamel Husain 的观点：在实现功能之前编写评估器听起来很诱人，但带来的问题比解决的更多，因为 LLM 具有不可预测的失败面，你无法预见什么会出错，更好的路径是对实际输出进行错误分析，然后针对观察到的问题建立评估器。

这是正确的，但这并不是对“评估即规格 (eval-as-spec)”的驳斥。这两个论点关注的是不同的事物。

加载中…