Anthropic 技术产品经理：为什么最优秀的产品领导者正在为 2028 年布局

#649. Anthropic 技术产品经理：为什么最优秀的产品领导者正在为 2028 年布局

AI 时代的产品经理，不再靠写出漂亮的 PRD 证明价值，而要把用户反馈变成可复现的 eval，亲手使用模型，判断什么值得做，并带着团队把它交付出来。

来源：小宇宙节目页

先给结论

这期访谈讨论的核心问题是：当模型能力快速变化、构建本身越来越容易时，产品经理凭什么决定该构建什么。

节目给出的答案可以压缩成五点：

1. 从用户反馈出发。 把“模型不行”“有幻觉”继续追问到具体对话、具体失败路径和可复现案例。
2. 用 eval 定义质量。 对清晰、可重复的问题，eval 往往比一份描述性 PRD 更接近真正的产品需求。
3. 保持第一性原理和向前兼容。 不要因为过去一直写 PRD、做某种功能，就机械地继续做；要问更强的模型出现后，用户行为会怎样变化。
4. 管理者亲自使用模型并交付产品。 不亲手做，就很难判断什么算好，也无法理解团队面对的真实限制。
5. 把 AI 当作对练伙伴。 先保留自己的观点，再让模型挑战和打磨；可以把标准化、可验证的写作交给模型，但最终由人验证、签字。

节目背景

• 嘉宾：Dianne Penn，Anthropic AI 研究与 Labs 团队的产品负责人。
• 主持人：Lenny Rachitsky，Lenny's Podcast 主持人。
• 节目定位：小宇宙《跨国串门儿计划》对 Lenny's Podcast 一期访谈的中文 AI 翻译与配音版本。
• 节目时长：约 81 分钟。
• 核心问题：Anthropic 如何在模型能力尚未完全成熟时，提前孵化 Claude Code 等产品；AI 时代的产品经理如何工作。
• 嘉宾经历：Dianne 于 2023 年加入 Anthropic，此前在亚马逊参与 Alexa 的 AI 能力，也曾在摩根大通做高收益债券交易员。

1. Anthropic 如何从“没戏”走到找到定位

1.1 早期不是先有答案，而是寻找技术的价值

01:20–04:00。Dianne 回忆，自己 2023 年加入时，没人会把 Anthropic、Claude 和编程联系在一起。当时产品团队只有约五名工程师，API 业务甚至只有一名工程师，公司的状态更像一家创业公司。

早期团队同时在探索两件事：

• 技术本身能走到哪里；
• 这项技术如何给用户和社会带来价值。

Anthropic 从 Claude.ai 这样的聊天助手起步，再逐步演化出 tool use 等能力。重点不是一开始就知道最终产品，而是在探索中寻找自己的定位。

1.2 Golden Gate Claude：24 小时把研究变成体验

05:53。研究团队在可解释性研究中发现，模型内部存在能够表达特定主题的“特征”，其中一个主题是金门大桥。把这个特征调高后，Claude 会在几乎每个回答里绕回金门大桥。即使用户问意大利面食谱，它也会把酱汁颜色联想到金门大桥的橙色。

团队随后在约 24 小时内，把这个实验做成 Claude.ai 上的公开体验，工程、产品、设计和研究一起完成。节目中提到，这个体验可能只触达了约 2,000 人，但它的意义不在规模，而在于：

• 研究成果可以迅速变成用户体验；
• 自下而上的工程师和设计师也能推动产品；
• Anthropic 开始形成区别于竞争对手的表达方式。

Dianne 把它称为一个“隐藏的转折点”：团队开始意识到，自己可以用独特、创业公司的节奏，把研究带给公众。

1.3 Opus 3：一起“在战壕里”建立信任

09:46。Opus 3 是另一个关键节点。当时 Anthropic 还不到 200 人，研究、推理、预训练、微调等团队为共同目标协作了数月。Dianne 回忆，团队甚至在假期、各自父母家的房间里远程推进训练和测试。

这次经历建立了产品和研究之间的信任。大家共同回答“这个模型到底要被训练成什么样”，也共同承担结果。后续能更顺畅地推出生产模型，不只是流程成熟了，更因为团队曾经一起解决过高不确定性的问题。

1.4 编程能力：从用户行为中发现差异化机会

11:08。早期用户开始用模型写长篇代码，而不只是做代码补全。这个行为并不是团队最初训练 Opus 3 时的重点，却暴露出一个清晰机会：通过相对较小的训练调整，把编程做成早期差异化能力。

这是一种典型的产品发现路径：

用户先做出了团队没有预设的事情，产品团队再判断这是不是值得投入的高价值方向。

1.5 Opus 4.5 与 Claude Code：模型和产品互相成就

12:28。节目反复强调，前沿模型需要前沿产品体验才能释放价值。Opus 4.5 的能力与 Claude Code 的产品载体共同形成了转折点：

• 没有足够强的模型，Claude Code 很难端到端运行复杂任务；
• 没有 Claude Code 这样的产品，模型能力也很难被普通用户感知和使用。

模型不是孤立的能力，产品也不是模型的简单包装。两者共同定义用户能够获得的价值。

2. 指数级进步：产品要向前兼容

2.1 计划不能替代适应能力

14:24。在指数级增长的技术环境里，很难预测下一次模型发布后具体会出现什么能力。因此，产品团队不能把原计划当成不可改变的承诺，而要建立接收新信息、快速调整决策的能力。

节目中提到的适应机制包括：

• 能力评估与安全测试；
• 红队测试；
• 面向新能力的原型；
• 根据真实用户反馈调整产品方向。

这不是放弃路线图。路线图需要为新事实留出调整空间，不能凌驾于已经发生的变化之上。

2.2 缩放定律与涌现能力

16:47。嘉宾区分了两种变化：

• 随着算力和数据增加，下一个 token 的预测损失可能平滑下降；
• 某些具体能力却会突然出现，从“算不出 1+1”跳到“可靠地算出 1+1”。

这种涌现能力意味着，团队可能已经拥有一个新能力，却还没有意识到它存在。评估测试的作用不只是给模型打分，也是主动发现能力、产品机会和安全风险。

2.3 “每年花 10 万美元买 token”：token 是投入，实验才是产出

18:31。节目引用 Gary Tan 的观点：如果现在愿意每年花 10 万美元在 token 上，实际上是在提前体验 2028 年的人会如何工作。

重点不在消费本身，而在于用这些 token 进行大量实验，提前形成对未来工作方式的直觉。Dianne 的补充很重要：

• token 消耗只是输入；
• 真正的输出是实验、洞察和产品原型；
• 不亲自使用模型，很难凭空想出好的产品策略。

对产品团队来说，模型预算不应该只被记录为成本。它也可以是探索新工作流、验证新需求的实验预算，前提是每次实验都留下可复用的观察和判断。

2.4 “Claude 8 假设法”：用未来检验今天的决策

30:19。Dianne 经常问团队：

假设 Claude 8 出来了，用户的行为会发生什么变化？这对你今天做产品意味着什么？

这个问题不是让团队预测模型版本，而是用来检查当前方案是否向前兼容：

• 今天做的功能，在模型更强后还成立吗？
• 它解决的是长期问题，还是只是在弥补暂时的能力缺口？
• 模型能力增强后，用户会不会绕开今天设计的流程？
• 当前产品是在帮助用户发现新能力，还是把用户锁在旧范式里？

3. Labs：用小团队押注非连续增长

3.1 Labs 的任务不是完成路线图

21:26。Labs 负责寻找核心路线图之外的“非连续性大赌注”，并继续追问它有没有 10 倍、100 倍甚至 1,000 倍的增长空间。节目中举到的相关产品或方向包括 Claude Code、Claude Code Skills、Claude Design MCP 等。

它与常规产品线的区别是：

• 常规产品更关注连续迭代和确定性交付；
• Labs 更关注是否存在改变产品边界的跳跃式机会。

3.2 大方向坚定，原型路径开放

23:14。Labs 的工作方法可以概括为：

对大的方向保持判断，对具体原型保持开放。

这允许团队：

• 让工程师自下而上推动想法；
• 用小团队从零开始做实验；
• 接受某些原型暂时跑不通；
• 等一两代模型更新后重新评估；
• 把“没有发布”也视为一种学习结果。

3.3 为什么需要小团队和低 ego

大团队追逐模糊而宏大的想法时，容易因为协调成本变慢。Labs 因此倾向于寻找真正喜欢从 0 到 1、愿意像创始人一样深挖的人，同时也必须接受赌注被拒绝或项目被关闭。

这类组织需要的不是“每个想法都成功”，而是快速暴露假设，尽早获得关于未来能力的认知。

4. AI 时代的 PM：Evals 是新的 PRD，但 PRD 没死

4.1 第一性原理：不要把过去做过的活动当成目标

35:00。Anthropic 招聘和评估 PM 时看重的第一项能力是第一性原理思考。它不是“我擅长把事情想得很深”这么抽象，而是：

• 不直接套用消费者产品或 B2B SaaS 的旧模式；
• 回到当前时刻、当前用户和当前技术；
• 重新判断用户价值到底是什么；
• 决定为实现这个目标，今天真正需要做什么。

活动不是目标，用户价值才是目标。

4.2 为什么说 Evals 是新的产品需求文档

36:28。对于研究产品经理，驱动用户价值的关键工作常常不是先写一份漂亮的需求文档，而是找到正确的用户反馈，并把它变成 eval。

一个有效的 eval 至少要完成这些事情：

1. 指向一个具体的用户痛点或机会；
2. 复现问题；
3. 用一组有代表性的案例描述什么算失败；
4. 在新模型版本上重复运行；
5. 让研究员知道下一步应该改进什么；
6. 验证改进是否真的发生。

4.3 从“Claude 有幻觉”到可操作的问题

约 24:37–35:00。用户说“Claude 有幻觉”，对研究员几乎不可操作。PM 要继续追问并查看经过授权的用户反馈：

• 当时 Claude 是否应该调用工具？
• 是工具使用失败，还是搜索与知识整合失败？
• 工具调用正确但读错了事实吗？
• 是对齐问题，还是模型已有知识不足？
• 这是偶发案例，还是持续出现的模式？

只有把问题拆到具体失败路径，才能判断它是否足够重要，并设计对应 eval。

4.4 一个实际案例：从 JSON 失败建立评估集

约 36:28–41:00。节目中给了一个早期案例：用户说 Claude“不太会遵循指令”，进一步深挖后发现，约 80% 的反馈实际指向同一个问题：模型无法稳定输出正确 JSON。

团队随后：

1. 追问用户具体输入和输出；
2. 收集约 30–40 个失败案例；
3. 把提示词、模型回复和预期结果组成评估集；
4. 将评估加入评估库；
5. 每个新版本都重新运行；
6. 观察通过率是否改善。

Dianne 表示，这个评估后来长期保持约 100% 或 99.9% 的通过率，因此它不再是早期那个痛点。

这个案例的价值不在于数字本身，而在于展示了 PM 如何把模糊反馈转换成研究团队可直接使用的对象：

反馈 → 复现 → 标准化 → 回归评估 → 验证改进

4.5 Evals 不是传统的精确匹配测试

模型输出具有不确定性，不能要求每次都生成完全相同的字符串。好的 eval 往往需要描述更宽泛的质量标准，同时保留足够具体的失败边界。

因此，AI 产品的评估既需要数据，也需要判断力：

• 不能只看一个总分；
• 要看失败轨迹；
• 要判断案例是否有代表性；
• 加入“不应该失败”的正例，避免为了修复一类问题破坏另一类能力。

4.6 PRD 没死：它负责愿景和跨团队对齐

36:28–43:00。Dianne 明确说，Anthropic 仍然写 PRD，每次发布模型也会有相应文档。Evals 更像是在问题足够清晰时，对产品需求的一种可执行表达，但不能替代所有 PRD。

PRD 仍然适合：

• 让产品、工程、法务、安全等团队对目标达成一致；
• 描述尚未完全清晰的产品愿景；
• 探索 Computer Use 这类尚未成熟、用户痛点还不稳定的方向；
• 说明如何先为一小群用户提供完整体验。

更准确的分工是：PRD 负责愿景、范围和跨团队对齐；eval 负责质量、回归和具体改进。

5. 亲自动手，才有判断力

5.1 管理者也要交付真实产品

44:19。无论职级高低，产品经理和管理者都必须亲自使用模型、深入 token 消耗、参与真实交付。

即便是经验丰富的 PM，入职后也要从这些事情开始：

• 理解用户；
• 阅读经过授权的用户反馈；
• 与客户交流；
• 亲手跟模型和工作流打交道；
• 判断什么算好，什么值得投入。

Dianne 自己也会在模型可用时，留时间实际跑一两个工作流，以保持对模型能力和迭代速度的认知。

5.2 构建变容易后，选择变成核心难题

访谈结尾，Lenny 总结了一个重要变化：现在构建本身变得容易，难的是：

• 应该构建什么？
• 构建出来的东西是否正确？
• 是否足够好？
• 是否值得投入？

这正是产品经理的传统优势：深入用户细节，理解真实目标，把模糊洞察提炼成可执行的方向，并坚持把它做出来。

6. AI 应该是思考伙伴，而不是替代思考

6.1 用 Claude 做管理教练

50:59。Dianne 分享了一个具体工作流：她根据《关键对话》的内容建立一个 skill，在准备与同事进行困难对话时，让 Claude 帮她思考：

• 当前情境需要多深的沟通；
• 应该如何表达才更容易建立信任；
• 对方可能会如何反应；
• 怎样更直接、准确地传达重点。

她把 Claude 视为个性化教练和思考搭档，而不是自动替自己做决定。

6.2 先有观点，再让 AI 挑战观点

53:07。面对“脑腐”或过度依赖 AI 的担忧，Dianne 的做法是区分任务：

• 对需要保留个人判断、语气和观点的工作，先自己形成看法，再和 Claude 一起打磨；
• 对月度业务复盘这类标准化、信息提炼型工作，可以把写作交给 Claude，自己重点审核事实和结论。

关键不在于是否使用 AI，而在于分清哪些思考必须由自己完成，哪些表达可以交给模型完成。

6.3 好的 AI 不应该只会附和

55:54。访谈把对齐和安全与产品体验联系在一起：清晰的宪法和对齐原则，不一定会让模型变得无趣，反而可能让它更有个性，更知道什么时候应该提出质疑。

一个好的思考伙伴不会只是附和你，而应该让你离开时带着更好的想法。

AI 的主动性不只是替用户完成更多任务，也包括在正确的节点提出问题、指出假设和补充不同角度。

6.4 写作的重点从“像不像人”转向“谁来验证”

节目讨论了 AI 写作的局限：当前生成文本仍容易暴露 AI 痕迹，语气、个性和自然度仍需改进。但在很多业务写作中，真正关键的可能不是谁写的，而是：

• 信息是否正确；
• 输出是否达到任务目标；
• 谁负责验证；
• 谁愿意对结果签字。

可验证性比作者身份更重要。

7. 人类仍然稀缺的能力：判断、专业知识与团队协作

7.1 判断力来自长期经验

01:02:11。当 AI 可以生成大量产品和方案时，稀缺问题会从“能不能做”转向“应该做哪个”。Dianne 认为，人类仍然重要的部分包括：

• 经过时间积累的判断力；
• 对细微差别的感知；
• 坚持和主动性；
• 决定什么值得做的品味。

这些不只是通用能力，更接近行为和品格。

7.2 领域专业知识仍然重要

软件工程已经较早进入 AI 的快速增长阶段，但生物学、生命科学等领域仍处于起点。AI 带来的社会价值，不应只集中在写代码，也包括把能力带到尚未被充分改变的专业领域。

7.3 给孩子保留“内心的声音”

01:03:55。谈到孩子，Dianne 提到她希望培养的不是某个固定技能，而是：

• 好奇心；
• 对学习的渴望；
• 坚持；
• 相信并表达自己的观点；
• 敢于不同意。

她还提到一种有趣的做法：让孩子先接触能力较早期的模型或本地开源模型，不要一开始就获得所有答案，以保留探索和努力的过程。

这和成人使用 AI 的原则相通：先建立自己的观点，再让 AI 帮你扩展，不要把思考的起点也交出去。

7.4 集体心流：对抗 AI 工作的孤独感

01:06:01。Anthropic 的高强度工作依靠的不是某个英雄个人，而是团队之间的互相照应：

• 发布前一晚，即使不是直接负责人，也会帮忙审文章、改内容、想 demo；
• 让成员能够安心休假，不至于回来后面对堆积如山的工作；
• 让同事理解彼此的第一性原理和关键假设，从而能替你顶上或挑战你的决定。

他们把这种互相帮助、心意相通的状态称为“集体心流”。在越来越多的人与 Agent 工作的时代，真实的人际协作反而更重要。

7.5 低 ego 是组织能力，不是性格装饰

招人时，团队会区分两类动机：

• 更在乎个人 ego 和扩张部门；
• 更在乎团队影响力和组织使命。

低 ego、愿意共享上下文、能在关键时刻帮助别人，是高压高速度组织保持可持续性的基础。

8. 快问快答与职业经验

8.1 推荐读物

• 《如何养育一个成年人》（How to Raise an Adult）：把养育目标从照顾孩子转为培养未来能够独立生活的成年人。
• 《Incorruptible》（Eric Ries）：讨论如何打造伟大公司，以及如何用更好的指标维护组织文化。只衡量收入，组织就会朝收入最大化走；要守住价值观，就需要把文化也变成可讨论、可衡量的东西。

8.2 最近喜欢的内容和产品

• 电视剧：亚马逊 Prime 的《辐射》（Fallout）。
• 产品：Claude Tag。Dianne 认为它在 Anthropic 内部展现了很强的产品潜力，也在探索如何把它带到更开放的社区。

8.3 一句人生格言

她从祖父那里听到的一句话：

不管你走了多远，前面总还有更高的台阶。

这句话对应她对 AI 时代的态度：面对不断出现的新能力，前面总还有另一座山，需要持续学习和攀登。

8.4 从交易员经历带来的经验

在摩根大通交易台上，Dianne 曾是唯一的女性，也是背景与周围人差异很大的成员。她带走的经验是：

• 最好的想法和对想法的坚定信念，比资历和身份更重要；
• 在团队面前展现真实和脆弱，可以建立信任；
• 不论级别和任职时间，只要有人提出好想法，就应该帮助它落地；
• 真正执行需要跟进许多琐碎、具体的工作。

8.5 用户反馈是最直接的帮助

Dianne 说，用户在产品中点赞、点踩，或通过销售渠道反馈模型问题，最终都有机会进入研究和产品改进循环。对用户而言，最直接的贡献方式是：

1. 真正使用产品；
2. 具体描述它在哪个场景、哪一步失败；
3. 提供可复现的输入和输出；
4. 说明你原本想完成什么。

给产品经理的可执行清单

A. 把模糊反馈变成 eval

当用户说“模型不好用”时，按这个顺序追问：

1. 用户当时想完成什么？
2. 原始输入是什么？
3. 模型具体输出了什么？
4. 失败发生在工具调用、搜索整合、事实判断、格式遵循，还是对齐行为？
5. 能否得到用户授权并复现？
6. 能否收集一组既包含失败、又包含不应失败的正例？
7. 新模型版本是否能自动回归这组案例？

B. 用不同工具解决不同问题

C. 建立面向未来的工作节奏

• 每周亲自深度跑 1–2 个真实工作流；
• 新模型出现时，先探索能力，不要直接沿用旧假设；
• 给每个重要方向都问一次“Claude 8 问题”；
• 把 token 消耗视为实验预算，而不是单纯成本；
• 把个人实验分享给同事，寻找共同探索者；
• 不要追逐所有新玩具，选一两个能真正改善生活或工作的方向做深。

D. 对 AI 产出负责，而不是只负责调用

使用 AI 后，产品经理的责任没有消失，只是从亲自写完转向：

• 定义任务目标；
• 设计评估标准；
• 验证事实和关键推断；
• 判断是否达到可交付质量；
• 对最终结果签字。

节目页 Show Notes 时间轴

我的收获

这期节目最值得记住的不是某个模型版本，而是一套产品工作方式：

先理解用户的真实目标，再把失败拆成可操作的 eval；亲自使用模型获得判断力；用 PRD 组织模糊愿景，用 eval 驱动具体改进；最后保留人的判断、专业知识和责任。

在 AI 把“做出来”变便宜之后，产品经理的稀缺性不会消失，反而会更集中在“为什么做、做什么、怎样判断做对了”。

关键原话

“Evals 就是新的产品需求文档。”（36:28）

“你得像抠像素一样去抠 token。”（37:43）

“假设 Claude 8 出来了，用户的行为会有什么变化？这对你今天做产品的方式意味着什么？”（30:19）

“没有 Claude Code 这样的产品，Opus 4.5 就不会有那个高光时刻；而没有 Opus 4.5，Claude Code 也不会那么快被大家用起来。”（12:28）

“思考伙伴不会只是附和你，它应该给你加分。”（55:54）

“现在构建本身很容易，难的部分变成了：我们应该构建什么，我们构建出来的东西是否正确、够好、值得投入。”（约 01:12:00）

来源

• 小宇宙：跨国串门儿计划 ep649 Anthropic 技术产品经理：为什么最优秀的产品领导者正在为 2028 年布局
• 原访谈：Lenny's Podcast — How Anthropic builds products like Claude Code before the AI models are ready | Dianne Penn

本文中的时间点沿用节目页和转写记录，播客原话按原意做了断句与标点整理。节目中的个人判断、公司案例、模型版本和数字，以节目原文与 Anthropic 官方页面的最新信息为准。

发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：AI-PM Wiki Team
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用