AI 让产品更容易做出来，产品经理该靠什么创造价值？

代码更容易写了，原型更容易做了，团队却可能更难回答一个问题：接下来究竟应该做什么？

Lenny Rachitsky 在访谈里观察到，AI 降低了制作门槛，也让团队造出了更多没人需要的东西。识别值得解决的问题、判断什么算做好、让大家朝同一个方向工作，这些能力重新受到重视。

Google 前沿模型产品负责人 Tulsee Doshi 认同这个判断，也坦承自己的产品经理身份会带来偏向。她强调，当实现越来越容易，选择什么、做到什么程度，以及怎样让团队形成共识，会占据更大的价值。

这是一位产品负责人的工作观察，不能直接推导出岗位或薪资的变化。但她给出的实践方法很具体：亲自试模型，把质量标准写成评测，用原型和数据给需求增加分量，同时为模型下一步的能力留出空间。

模型本身也有用户体验

传统产品规划容易让人期待，列出目标，再让工程团队逐项实现。模型开发的过程多了一层不确定性。

Doshi 用斯内普的魔药课作比喻。团队会认真选择训练材料、设定能力目标，也会监控训练过程和指标变化；最终形成的能力组合，仍可能出现计划之外的长处。

因此，模型产品经理需要同时做两件事：参与决定模型应该朝哪里走，训练完成后亲自探索它究竟擅长什么。某项能力的分数变高了，还需要进一步确认，它能支撑怎样的产品体验。

她谈到的体验，也包含模型的行为：是否解释清楚自己的动作，什么时候追问，怎样表达不确定性，回应的方式是否适合任务。用户每天接触到的这些细节，同样属于产品设计。

在她描述的工作流程里，用户反馈会进入模型行为规范，再被转化为评测标准、训练数据和奖励建模的依据。产品判断需要一路进入模型的训练与评估，才能稳定地影响用户体验。

Google 想把前沿能力变成不同人的日常工具

谈到 Google 的竞争策略，Doshi 的表态很明确：公司希望参与并赢得前沿模型的竞争。她以 Gemini 4 Argon 为例介绍这个方向。模型是否领先，仍需要结合具体任务判断，不能只凭厂商的表态下结论。

她同时强调 Google 从硬件、模型到应用的完整布局。搜索用户、软件工程师和网络防御人员，对能力、成本和使用方式的要求各不相同，产品组合需要覆盖这些差别。

界面也要随用户变化。搜索里的 AI 面向广泛人群，需要容易理解；Antigravity 面向熟悉终端和开发环境的人，可以提供更复杂的操作。Flow、NotebookLM 则体现了围绕不同任务探索产品形式的思路。

这种探索仍有未完成的部分。Lenny 追问，为什么其他 AI 助手已经在调用 Gmail、日历和文档，而 Google 自己还没有交出足够令人满意的个人助手。Doshi 承认还有工作要做，只表达了期待，没有给出发布时间。

她对安全的乐观也有条件：持续监控模型行为，发现偏离后干预，并利用模型加强现有系统的防御。她提到 Wiz 的 Scan for Good 项目；Wiz 的公开报告也记录了与医院合作发现并修复风险的案例。这些是具体的防御工作，不能据此认为模型风险已经解决。

从 5 条提示词开始，把“好”写清楚

Doshi 招聘研究型产品经理时，很看重候选人有没有亲自用模型、有没有自己的测试任务，以及能否根据数据形成意见。

访谈把这种熟悉程度称为模型的“手感”。它来自反复使用：选择自己熟悉、确实关心的任务，让不同模型处理同一个问题，观察它们各自在哪一步做好了，又在哪一步失去可靠性。

任务太简单，模型之间看不出区别；完全超出能力，也很难发现进步。她建议寻找那些已经显露潜力、距离理想结果还有差距的任务。写作、视觉创作、复杂分析都可以，关键是评测者能够判断结果。

正式评测也可以从很小的规模开始。先写 5 条提示词，亲自评价输出，再逐渐形成约 20 条能区分模型表现的测试。

在多步骤、多轮交互任务里，连“什么算好”都可能尚未想清楚。少量实例能迫使产品经理说明标准：结果好在哪里，失败发生在哪一步，为什么这个差别会影响用户。之后才有基础扩大规模。

这里的数量是起步建议。几条成功案例不能证明系统在所有场景都可靠，但能帮助团队把模糊的偏好变成可以讨论、可以重复检查的标准。

评测要覆盖真实的人，也要覆盖完整的产品

Doshi 举了肤色评测的例子。她在负责 AI 责任与公平性工作的时期发现，团队使用的 Fitzpatrick 分类只有 6 类，原本服务于医疗用途，用来代表全球用户的肤色存在局限。

她的团队与哈佛学者 Ellis Monk 合作，引入包含 10 种肤色的 Monk Skin Tone Scale，重新审视产品和模型的评估方式，并将其用于改善 Pixel 相机、图像生成等体验。Google 的研究介绍也说明了这套量表的设计背景。

这个案例提醒产品团队，评测标准本身决定了哪些问题会被看见。样本没有覆盖的人群，即使遇到持续的失败，也可能不会明显影响汇总分数。这是从案例得到的产品启示；换一套分类，也需要继续检查实际效果。

另一类容易遗漏的问题发生在模型之外。

评测使用的裁判是否可信？测试环境是否带上了线上实际使用的过滤与防护？模型的部署和输出方式，会不会改变结果？Doshi 认为，这些都属于评测的一部分。

语音尤其明显。内容正确，并不代表听起来自然。语气、音色、重音和表达的流畅程度，都可能在实际服务过程中发生变化。最终要检查的是用户收到的完整体验，模型分数只是其中的一项证据。

用 60／20／20 给产品留出成长空间

模型在持续变化，产品规划需要兼顾现在能交付的价值，以及下一步可能打开的空间。Doshi 给出的思路是 60／20／20：

• 60%：已经能工作，保证当前原型和产品有成立的基础。
• 20%：还不完美，但已有可用表现，并能看见近期进一步改善的可能。
• 20%：仍在探索，只出现了能力的苗头；一旦突破，可能形成很好的体验。

她先说明，这几个比例可以调整。它们描述的是产品探索的组合，不能被当成允许上线大量失效功能的标准，也不等于固定的团队工时分配。

Lenny 提到另一条常见建议：提前按 3 个月后的模型能力开发。Doshi 的回应是，即使自己就在模型团队，也很难准确预测那个时间点能做到什么。

相比押注一个日期，更具体的判断来自产品本身：现在什么能跑通，什么已经接近，什么只有局部成功的迹象。团队可以根据这些证据安排投入，并在新模型出现后重新检验。

这套方法保留了探索空间，也要求今天的产品先有真实价值。模型进步属于机会，产品团队仍然需要承担验证与取舍的工作。

模型升级后，重新检查包在外面的系统

很多团队围绕旧模型的弱点，积累了一层又一层提示词、工具、步骤和补救规则。模型变强后，这些设计可能需要重新评估。

Doshi 将 harness 解释为模型的运行环境，包含系统指令、工具、Skills、上下文和可访问的信息。它决定模型能拿到什么、能做什么，以及怎样行动。

她提醒，一套过于僵硬的结构，可能把新模型继续限制在旧模型的能力范围内。团队需要持续重测，辨认哪些规则仍有帮助，哪些已经让任务变得更复杂。删改也应以实际测试为依据。

组织任务的方式同样值得检查。Doshi 曾参与 Stanford 的 Flash Teams 研究。这项发表于 2014 年的工作，研究如何临时组织有不同专长的人，通过任务与交接协作完成复杂工作。

她今天看到，其中一些组织原则可以启发智能体协作。原研究的对象是人，不能直接当成当代多智能体系统的有效性或安全性证据；它提供的是一个组织工作的思路。

给团队留出练习时间，也减少无意义的忙碌

新工具不会因为进入采购清单，就自动变成团队能力。

Doshi 观察到，一些产品经理会主动构建日常工作用的 Skills，再分享给同事。另一些人更擅长阅读数据、检查模型执行过程，就可以带着其他人练习。这些经验可以逐步积累成共享的工具与工作方法。

困难在于时间。一直赶进度的人，很难停下来熟悉工具。录制访谈时，她的团队正在筹备十一月的一场 2 天工作坊，希望让产品经理暂时离开日常事务，集中动手尝试。访谈描述的是当时的计划，并未证明活动已完成或取得某种效率提升。

她还提到，一个任务需要重复做时，可以先判断哪些步骤适合交给模型。Lenny 将这个习惯描述为，在接到任务和开始动手之间，插入一次对 AI 能力的考虑。一次确实有帮助的尝试，往往能增加继续探索的信心。

这种变化也需要对工作负荷保持诚实。Doshi 承认团队仍在长时间工作，可持续性问题还在摸索。她认为，反复折腾、混乱和缺乏意义的杂活，会加重疲惫；AI 有机会减少这些部分，让人腾出时间思考和创造。

这仍是一种管理判断与期待。喜欢一份工作的人也会疲惫，提高效率之后，团队仍然需要决定把省下的时间用在哪里。

让 AI 整理资料，让产品经理带来判断

访谈后半段谈到一个熟悉的困扰：写文档变容易了，阅读同事发来的大量 AI 文档却成了新的负担。

Doshi 给出的分工很具体。假设产品上线 2 周，团队想知道谁在使用、怎样使用、反馈如何，AI 很适合从仪表盘、指标和用户讨论中整理资料，帮助人获得更新。

接下来，产品经理需要说明这些资料意味着什么：哪些反馈值得采取行动，哪项问题应优先解决，为什么选择这个方向。这部分判断需要由人承担。

原型、数据分析和评测，都能给判断增加可检验的依据。过去，产品经理可能写下需求，等待工程师、设计师或研究人员补足细节；现在，AI 让他们能够往前多走一步，拿出能运行的原型、一组实际结果，或者一套具体的质量标准。

产品经理的工作因此变得更具体：把重要的问题选出来，把好的结果定义清楚，再拿出足够的证据推动团队行动。 当制作本身越来越容易，这些工作仍然需要有人认真完成。

原始资料：Why PMs are suddenly valuable again | Tulsee Doshi (Head of Product, Gemini)，Lenny’s Podcast，2026-11-08 发布，YouTube 时长 58:33。主持人：Lenny Rachitsky；嘉宾：Tulsee Doshi，节目介绍其为 Google 前沿 AI 模型产品负责人。

本文依据节目方在视频简介中公开提供的完整英文文字稿整理，保留原稿时间标记，并结合上述一手资料核对专有名词与相关案例。文字稿的制作方式未注明，不能视为逐字无误的记录。本文为主题整理，省略广告及末尾私人生活快问快答；观点、内部实践与未来计划均保留归属及限制。节目说明与资料链接。