# 深度｜对话 Anthropic 产品负责人：不懂评测的 AI 产品负责人，只是在假装做产品

- 原文链接：https://mp.weixin.qq.com/s/1aT2ueDwoH8SoekxTZ_V2A
- 来源：微信公众号「Z Finance」；作者：ZF 编辑部
- 原始访谈：Lenny's Podcast，《Why AI is going vertical (again) | Dianne Penn (Anthropic)》
- 嘉宾：Dianne Penn，Anthropic AI Research 与 Labs 产品负责人
- 发布时间：2026-08-22 20:04 CST；获取时间：2026-08-25

## 正文

文章整理了 Dianne Penn 对 Anthropic 产品、研究和组织协作方式的解释。其中心观点是：前沿模型能力不会自动变成用户价值，产品团队必须用合适的体验让用户感知能力；反过来，产品机会也要通过评测发现。对 AI 产品经理而言，评测不只是质量检查，而是把用户痛点转换成研究团队可执行目标的产品规格。

### 1. 前沿模型需要前沿产品承载

Penn 2023 年加入 Anthropic 时，产品团队很小，API 业务由一名工程师负责。她将 Golden Gate Claude、Opus 3.0、Claude Code 和后续模型视为公司寻找产品身份的关键节点：模型与产品互相放大。Claude Code 让用户能够感受更强模型端到端完成任务的能力；缺少相应产品表面，模型能力便难以被理解和使用。

模型能力的显现不是线性的。训练损失可能平滑下降，但某些能力会在特定阈值突然变得可靠。团队不能只靠主观试玩判断能力边界，需要持续评测来发现“模型已经能做什么”、哪些产品机会可以提前启动，以及安全风险是否已出现。

### 2. 评测就是新的 PRD

传统 PM 收到“Claude 不擅长遵循指令”的反馈，可能写一份模糊需求；Penn 的做法是继续追问到具体输入、期望和失败输出。她举的早期案例中，大约 80% 的“未遵循指令”问题实际是 JSON schema 输出不正确。

团队随后收集 30 至 40 个失败案例，每个案例包含 prompt、模型 response 与预期 golden answer，形成可反复运行的 eval 集。一个有效 eval 必须稳定复现痛点，并覆盖会失败的正向情境和不该失败的对照情境。它进入评测库后，可在每个模型版本运行，直接告诉研究团队该改善什么，并验证改善是否真的发生。

因此，AI PM 的工作链条变为：理解用户痛点 -> 阅读交互轨迹与 token 级失败 -> 归因并标准化 -> 构建 eval -> 反馈研究训练 -> 回归验证。评测不取代产品判断，却把“用户说不好用”转成可行动、可衡量的共同接口。

### 3. PRD 的角色改变而非消失

当问题和成功标准已经很清晰，eval 可以直接定义目标；但在机会模糊、需要协调产品、工程、法务和安全团队时，PRD 仍然是统一目标、体验与事实来源的工具。例如 computer use 早期并没有一组固定痛点，产品愿景需要先定义可服务的用户群体和体验边界，随后才逐步获得可评测的任务。

### 4. AI PM 的能力要求

Penn 认为产品领导者必须亲自使用模型、读经同意提供的用户反馈、与客户交谈并实际交付一两个工作流。没有亲手构建和 token 级理解，就难以判断好的 AI 体验、模型进展和用户痛点。

她还建议以“Claude 8.0 到来后用户会怎么变”为问题检验产品是否向前兼容。人类持续重要的能力是判断、领域经验、独立观点、好奇心和坚持：当 AI 让构建变得更容易，组织仍需决定值得构建什么、如何评估结果、什么风险可接受。

### 5. 安全、个性与组织协作

文章反对把安全和对齐简单理解为削弱能力。一个有用的 AI 不应只顺从，还应在必要时提出异议、补充视角并帮助用户获得更好的结论。与其只问内容是否像人写的，更重要的是谁验证、谁最终签字。

高速迭代也不只是个人英雄主义。Penn 将 Anthropic 的速度归因于低自我、强使命感和研究、产品、工程之间的信任：成员可在他人缺席时作出合理判断，发布期间主动补位，团队能在模型进展与新反馈出现时调整计划。

## 来源限制

本文为 Z Finance 对播客访谈的中文整理。Anthropic 的组织人数、收入、模型版本、项目名称、能力描述、案例比例和所有引语均未独立核验；应作为“评测驱动产品开发”的访谈经验，而非通用基准或官方产品承诺。

标签： #主题/AI产品管理 #主题/评测驱动开发 #主题/AI评测 #主题/Anthropic #主题/产品工作流 #场景/公众号长文 #节点/评测即PRD #节点/反馈归因 #节点/回归验证