Anthropic 产品负责人：评测就是新的 PRD

核心结论（一句话）

AI 产品的需求不能停在“用户说不好用”：产品经理应把真实失败交互归因为可复现、可衡量、可回归的 eval，让它成为用户、产品和研究训练之间的共同规格；PRD 则继续承担机会探索和多团队对齐。

文章给出了一条非常具体的工作流。用户说“模型不遵循指令”时，不把这句话直接翻译成需求，而是追问具体任务、prompt、模型输出、期望输出和出现频率。Penn 的例子发现，早期大量“指令遵循”问题实为 JSON 格式不正确。

接着将 30 至 40 个失败交互固化为 eval：输入、模型输出、golden answer 或判分标准，以及必要的正负对照。这个评测集只有能稳定重现痛点时才有用。它被加入版本回归后，研究团队可据此训练或调优，产品团队也能验证新模型是否真的改善了用户体验。

这使产品文档从“描述想要什么”前移为“证明模型在真实任务上该怎样表现”。重点不是套用某个指标，而是让用户反馈到研究行动的距离足够短、可追溯、可验证。

两者不是替代关系。若问题明确，例如模型能否按 schema 输出，eval 可以是最直接的需求语言。若技术仍在探索、用户群和体验尚未确定，PRD 更适合提出产品假设、限定首批用户和协调产品、工程、安全、法务等决策。

合适的顺序是：先用 PRD 收敛模糊机会和边界，再用实际交互长出 eval；已被验证的用户任务，则用 eval 驱动后续模型与体验迭代。

把“AI 分诊不准”改成 Case。 每次人工改写 AI 结论时，保存原始输入、AI 输出、人工判定、理由和预期动作，累积成设备与反馈分诊的 eval 集。
每个 Skill 建立最小回归集。 先收集 20 至 40 个高频失败或高风险 case，版本更新前后都运行，避免“看起来更聪明”但关键任务退化。
将 PRD 与 eval 分层。 模糊的新能力先写目标用户、风险和成功标准；流程稳定后再把关键行为压成可重复验证的任务。
负责人保留一线样本。 PM、技术负责人和运营负责人每周各抽读一批真实输出，不将能力判断完全外包给仪表盘或团队汇报。

[[01-ai-agents/Agent评测漫谈-由浅入深讲解Agent评测]]：解释 Trace、Rubric、Case、回归和评测基础设施；本文补充 PM 如何从用户反馈供给这些 Case。
[[02-ai-coding/用Agent评测思路管理AI-Coding-31万行代码重构实践]]：说明评测思想在 AI Coding 质量治理中的工程应用。

[[02-ai-coding/Capihom-OpenAI-Codex-Andrew-Ambrosino-产品工作新形态]]：同为 Lenny’s Podcast 产品负责人访谈；Andrew 讨论构建成本下降后的品味与媒介选择，Penn 讨论如何将模型表现转化为可验证产品目标。
[[06-ai-tech/经纬创投-李飞飞-当答案变得廉价]]：共同强调 AI 不能替人设定问题与判断标准；本文给出产品团队把标准写进 eval 的具体机制。