还在写PRD？AI时代的产品经理，核心交付物变了

核心内容速览

• 核心观点：AI 产品的行为无法像传统功能那样写进 PRD 穷举——能定义「什么叫好」的评测集，事实上承担了 PRD 的角色。
• 评测驱动的飞轮：eval 写清期望 → 发现差距 → 改进 → 回归验证 → eval 扩充，产品能力在这个循环里长出来，而不是在文档里。
• PM 的新交付物：黄金评测集 + 评分 Rubric，正在和原型、PRD 并列成为 AI PM 的核心产出。

适合谁 · 怎么用

适合作为入门第 2 篇（读完 a07 后）。如果你需要说服团队「为什么值得在 eval 上投入」，这篇提供了最好的论据。

闯关自测

先合上原文在心里作答，再点开对照。全对 = 本篇真正通关。

以下为原文全文

上方为本站原创导读，下方为原文完整收录，便于对照阅读。

传统产品开发是一条直线：问题 → 需求文档 → 设计 → 工程 → 上线。但 AI 产品不是这么玩的——同一个 prompt 每次跑出来的结果都不一样。「模型应该有帮助且简洁」写在 PRD 里，太模糊没法执行，太含糊没法验证，太静态跟不上模型变化。PRD 是为确定性世界设计的，AI 产品的世界是非确定性的。

答案是 eval——结构化、可重复、自动化的产品质量评测。它不只是工程工具，应该成为产品经理的核心交付物。

新循环：Eval 一份抵三份文档

Eval 同时扮演三个角色：产品规格（定义目标）、验收标准（衡量通过/失败）、产品路线图（指向下一步该改进什么）。团队的工作方式变成 hillclimbing：PM 设定 eval 的标准线，工程团队在 prompt、检索策略、工具选择、模型选型上反复迭代，直到产品达标。

OpenAI 的 Kevin Weil：在 AI 时代，写 eval 是 PM 能做的最重要的事。传统 PM 的核心能力是「把需求写清楚」，AI PM 的核心能力是「把好坏定义清楚」。你不再是写文档给工程师看的人，你是给 AI 出考卷的人。

食谱生成器的例子：PRD 写「要有帮助且准确」毫无用处。拆成三个可衡量的信号才有用：① 食谱格式对不对（AI 评审员按评分标准打分）；② 视频里提到的食材是否都包含（确定性字符串匹配）；③ 步骤是否简短易扫（AI 评审员，用好/差示例校准）。注意：三个信号里一个是确定性的、两个是非确定性的——混搭才是正解。

Eval 飞轮

• Observe（观察）：记录每一次输入、输出、trace 和失败。你没法改进你看不到的东西；
• Analyze（分析）：找模式——什么在坏、在哪坏、为什么坏；
• Evaluate（评测）：把发现的失败模式变成新的 eval case。用户投诉是免费的 eval case；
• Improve（改进）：针对更新后的 eval suite 做 hillclimbing，上线，然后重复。

这个循环会自我加速：更多线上数据 → 更好的 eval → 更好的 AI → 更好的产品 → 更多用户 → 更多线上数据。失败到改进的路径被大幅压缩：线上错误案例不需要 PM 翻译成需求文档，它直接变成 eval case。

Eval 成熟度四阶段

• Stage 0：Vibes（直觉）——靠手动抽查、直觉和用户投诉，完全盲飞。现在大部分团队还在这个阶段；
• Stage 1：Test Sets（测试集）——有带通过/失败标准的测试集，大版本发布前跑，但仍是被动的；
• Stage 2：CI/CD（自动化）——Eval 集成进流水线，坏的发布被自动拦住；
• Stage 3：Flywheel（飞轮）——线上数据持续回流 eval suite，系统每周都在变好。这是大多数团队应该瞄准的目标。

三种评委

• 算法评委：确定性检查（字符串匹配、格式验证）。快、便宜、完全可靠；
• AI 评委：模糊的质量评估（语气、有用性）。可瞬间扩展，但需用人类判断校准；
• 人类对齐的 AI 评委：深度主观评估。人类审核提供 ground truth，AI judge 学着逼近。

关键不是选哪一种，而是知道什么时候用哪一种：能用算法解决的就别用 AI，需要 AI 的就别偷懒不校准。

常见坑

• 试图衡量「通用智能」：通用 benchmark 不会告诉你食谱格式对不对。给你的产品写它自己的考试；
• Eval 设计拉太多人：人越多妥协越多。Eval 应由最了解用户的一两个人写，不是十人评审委员会；
• 只在上线时跑 eval：模型在变、数据在漂移，不持续跑的 eval 只是一次性 sanity check；
• Goodhart 定律：优化 eval 分数而不是真实结果，就会 game 它。必须持续把 eval 分数跟真实业务指标（任务完成率、留存、满意度）绑在一起；
• 盲信第三方 eval：别人的 eval 就是别人的 vibes，你的产品只有你自己最清楚什么叫「好」。

PM 的新节奏（每周）

周一：看线上 trace，标记 20 个不达标的响应
周二：从中提炼 5 个新的 eval case，加进 eval suite
周三：跑完整的 eval suite，对比上周模型和本周候选
周四：看差异。数据说了算——发布还是不发布
周五：飞轮又转快了一圈

给工程团队的指令也变了：不再是 30 页 PRD，而是一句话——「这是 eval。把这个数字提上去。」eval 是代码，代码不含糊，沟通内容从「这个需求是什么意思」变成「这个 eval 应该怎么优化」。

对我们意味着什么

1. AI 产品的质量不是「做出来再说」，而是「先定义好」。大多数质量问题不是技术问题，是「没人定义好什么叫好」的问题；
2. Eval 是复利引擎。PRD 是一次性消耗品，eval 是资产，积累 eval 就是积累壁垒；
3. PM 的角色正从「写文档的人」变成「定义质量的人」。一个有 500 条 case 的 eval suite，记录了半年里所有边界情况、用户投诉和产品决策——新人跑一遍就能理解「这个产品关心什么」。

起步建议：从一个功能开始，定义三个可衡量的信号，写你的第一个 eval——甚至可以从 spreadsheet 开始：列出 20 个输入 case，手动标记期望输出，跑一遍看通过率。这就是 Stage 1。PRD 会过期，Eval 会进化。