打开本季度发布的任何 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)”的驳斥。这两个论点关注的是不同的事物。
Hamel 谈论的是评估集的覆盖范围 (coverage)——即你评分时针对的失败模式清单。在这一点上，错误分析胜出，因为 LLM 那些奇奇怪怪的长尾失败行为是无法在办公桌前凭空列举的。你需要通过阅读数千条 Trace 并对坏案例进行聚类来发现它们。为想象中的失败模式编写投机性的评估器是浪费工作；你发布的版本中出现的失败绝不会是你预想的那些。
而“评估即规格”论点关注的是功能的预期行为 (intended behavior)——即为了确定你所理解的请求在“表现良好”时是什么样子而编写的案例。在这里，你不需要 Trace，因为这些案例不是为了捕捉 Bug，而是为了决定功能要做什么。食谱生成功能的规格说明包括“食材列在指令之前”，这是因为团队决定了这一点，而不是因为他们观察到了食材缺失的 Trace。评估集冻结了一项产品决策。
两者都需要，且它们积累的速度不同。预期行为评估主要在发布前编写，并随着功能范围的扩大而缓慢增长。错误分析评估则由生产环境的 Trace 驱动，持续增长且没有上限。如果团队混淆了两者，要么会交付一个伪装成回归测试集的僵化产品规格，要么会交付一个对功能定位毫无见解的开放式 Bug 目录。
诊断：将评估用例视为 PRD 来阅读
了解团队是否编写了技术规范的最快方法，就是打印出评估用例（eval cases），并像阅读唯一的 PRD 一样去阅读它们。如果一名新工程师仅凭这些用例就能还原出该功能的忠实版本——或者足够接近，以至于差距仅在于审美而非行为——那么你就拥有了一份规范。如果他们做不到，那么这项评估就是在做别的事情：回归覆盖、Demo 策划、情感量化（vibes-quantified）或榜单刷分。
这种病态显而易见。评估包含 200 个用例，它们都在断言回复是“非空”、“有效的 JSON”且“少于 500 个 token”。它们都没有体现产品经理（PM）所关心的决策。模型通过了测试套件并发布，结果第一个用户投诉的就是评估从未评分的行为。团队针对该行为添加了一个用例，再次发布，循环往复。每一次迭代都是被动的，因为测试套件从未起到主动引导作用——它只是测量工具，而非规范说明。
另一种病态：评估包含 50 个用例，全部由一名聪明的工程师亲手策划，蕴含着强烈的个人观点。PM 从未见过这些用例。当 PM 要求更改行为时，工程师说“让我更新一下评估”，然后评估便悄无声息地改变了。产品正在测试文件中被设计，而设计者并非其职责所在。这不是关于职责边界的道德问题，而是协作问题。影响用户的决策应该由负责用户成果的人，在这些人能读懂的产物中做出。
合规、格式、语气——披着同一件风衣的三个 PRD
一旦你接受了评估即规范的观点，你就会发现它承担了不止一份工作，当你试图演进它们时，不同用例之间会产生拉锯。一个客户支持功能的评估套件通常混杂了：
- 行为正确性：助手是否识别了正确的意图、检索了正确的数据、采取了正确的行动。
- 语气与调性：回复是否符合品牌的语调，既不太正式也不太随意，并在适当的地方表现出共情。
- 政策与合规：回复是否避免了违禁声明、包含了必要的免责声明，以及在必要时予以拒绝。
这些部分拥有不同的负责人——工程、产品/营销、法律——以及不同的发布节奏。当它们被混杂在一个评估套件中时，任何一部分的改动都会导致其他部分的行为回归。加强政策用例后，语气用例可能会在一些无害的输出上失败，因为模型为了遵守红线而牺牲了语调。
一个成熟的评估套件会像成熟的 PRD 一样沿这些轴线拆分。行为正确性套件由工程和产品负责，每次改动都会运行，并作为发布门禁。语气套件由产品负责，在品牌或界面发生变化时进行评审。政策套件由合规和法律部门负责，被视为监管产物，并通过记录在案的流程进行更新。每个套件都是针对不同关注点的独立规范。把它们混在一起就像是写了一个没人读的“上帝类”PRD。
组织测试
最后一个问题并非技术性的。将评估套件递给团队负责人并询问：你会在这份文件上签字，将其作为该功能的产品规范吗？如果答案是肯定的，那么团队已经完成了工作——该套件是可审计的，决策是可追溯的，产品是由那些可以编译成可衡量契约的产物定义的。
如果团队负责人退缩了，那么差距所在就是工作的重点。用例可能太稀疏、太狭隘，或者过于倾向于模型今天能做的事情，而不是团队希望它明天能做的事情。这种退缩本身就是一种信息。它说明 PRD 仍然只是一个新闻稿，产品仍然是由最后一个修改提示词（prompt）的人临时决定的。解决办法不是写一份更好的 PRD，而是不断添加用例，直到这个套件在独立阅读时就能定义该功能——然后弃用 PRD 中的那些形容词，因为它们不再发挥作用。
做对这一点的团队不再将评估视为质量工程问题，而是将其视为持久的产品产物。PRD 变成了发布公告，评估则是契约。新员工通过阅读用例来了解功能的作用。评审人员阅读用例的差异（diff），就像以前阅读文档中的修订标注一样。模型的非确定性不再是规范模糊的借口，反而成为了必须存在精准规范的原因。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
