开发提速之后，判断更重要：Tulsee Doshi 谈 AI 产品经理的责任

一、嘉宾背景

Tulsee Doshi 是 Google 前沿模型产品负责人，负责包括 Gemini 在内的模型产品。在 Lenny Rachitsky 主持的《Lenny's Podcast》中，她讨论了产品经理如何参与模型研发，以及应用团队如何将不断变化的模型能力转化为产品。她提供的是研发与产品交界处的管理视角，其中对公司战略和团队实践的描述，也保留着参与者自身的判断。

她的职责范围包括 Gemini、图像与视频生成和编辑、Nano Banana、音乐模型 Lyria、开放模型系列 Gemma，以及对话、音频理解、语音合成和翻译等音频能力。这意味着她面对的质量问题远不止文字回答是否正确，还涉及视觉表现、声音和交互行为如何组成完整体验。

Doshi 说，她曾在负责任 AI 领域工作六年，其中包括模型和产品中的肤色呈现。这段经历为她讨论评估标准提供了具体依据：采用什么标准，会影响团队能够发现什么问题。她还回顾了在 Stanford 与 Michael Bernstein 研究 flash teams 的经历。这项研究关注如何按互补优势组织众包工作者；她将其与主持人引入的 agent swarms 框架作了区分，同时认为其中一些组织原则如今可能用于 subagents。

二、本期主要内容

模型产品开发的一项难题，是目标可以明确，结果却不能完全预知。Doshi 认为，团队仍须有意识地设定能力目标、希望带来的用户结果，以及相应的评估目标。但这些安排无法消除最终能力和行为的不确定性。产品经理还要仔细观察模型实际生成的内容，发现意料之外的强项，再判断它们能支撑怎样的产品体验。设定方向与发现能力，是这项工作的两个部分。

她将 Google 的战略描述为贯穿硬件、模型和终端产品的布局：既追求前沿能力，也提供成本与质量的不同组合，以满足不同用户的需求。不过，战略判断与已经核实的发布信息需要分开看。她预计节目发布时 Gemini 4 Argon 已经可用，并认为它处于前沿水平；这些是她在访谈中的预期与评价。谈到 Google 拥有十四个十亿用户产品时，她也明确表示，这个数字需要核对。

安全工作同样贯穿训练与部署。Doshi 描述，团队会监控模型的思维链，观察其是否偏离预定行动，并在发现问题后介入和改进。她的乐观建立在持续审视风险、主动设置防护之上，并不意味着风险已经消失。她还援引 Wiz 的 Scan for Good 项目，称其帮助一家医院系统识别并修补了漏洞，以此说明 AI 在防御中的用途。访谈没有提供该案例的独立验证或量化结果，因此能够确认的是她对这一案例的介绍。

模型能力如何进入产品，则取决于用户和交互形式。Doshi 以 Flow 和 NotebookLM 说明团队对不同产品形态的探索，并对比搜索 AI Mode 与 Antigravity：前者面向更广泛的人群，需要容易理解和使用；后者面向熟悉终端、IDE 和斜杠命令的用户，可以采用更复杂的交互。产品形态是否合适，需要落到具体用户能否有效使用上。

能力投资也由这些使用需求反向推动。Doshi 描述了与 Search、Gemini app、YouTube、Labs 等内部客户，以及外部客户之间的反馈循环，用来判断哪些能力值得继续投入。模型出现令人意外的强项，可以带来产品机会；机会是否值得追，仍须结合用户在哪里受阻、什么变化能够改善体验来判断。这也使产品经理的工作从观察模型表现，延伸到评估标准、能力投入和日常交付。

三、核心观点：推理、例子与边界

开发变得容易之后，选择值得解决的问题、定义什么才算好结果，反而更重要。这是主持人 Lenny Rachitsky 提出的判断。Doshi 表示认同，并强调产品品味、洞察和凝聚共识的价值。实现速度提高，并不会替团队决定方向；目标不清时，速度还可能带来更多混乱。两人由此讨论产品经理的价值，但访谈没有提供产品经理需求回升的市场数据。

在 Doshi 看来，模型是否透明、怎样与用户沟通、何时追问，都是用户体验的一部分。产品经理需要与研究团队合作，把理想行为和用户反馈转化为规范、评估标准、数据和奖励建模。产品品味因此不能只停留在对输出好坏的感受上，还要形成团队能够讨论和检验的行为标准。主动到什么程度、何时需要追问、何时可以执行，都属于这类设计问题；这些是沿着她的方法需要回答的问题，并非节目披露的具体训练规范。

这种工作方式也影响她对研究型 PM 的要求。她看重每天使用模型、主动测试其能力边界、形成独立判断、亲手检查数据和构建评估，以及随情况变化调整计划的能力。她建议从自己真正关心的任务入手，选择模型已经显露潜力、表现却仍不完善的领域，例如视觉动画、创意写作、信息综合和复杂财务分析。对任务的熟悉有助于识别细微差异，但个人判断仍需要结构化评估来检验。Doshi 也承认，团队成员的评估能力并不均衡。

她给初学者的建议是从五条提示开始，逐步积累到约二十条有区分度的提示。先亲自评分，说清楚什么算好，再考虑扩大规模。提示的作用是检验特定能力、拉开不同表现之间的差距，而不是凑足数量。对于长流程、多步骤、多轮交互的任务，质量标准尤其难定义：单次回答出色，并不等于整个任务完成得好。小型提示集可以帮助团队起步、发现标准中的含糊之处，但五条或二十条提示本身并不能证明统计可靠性，也不能自动代表所有用户。

肤色评估的经历进一步说明，问题有时出在测量工具本身。据 Doshi 介绍，Fitzpatrick 六种肤色量表原本用于医疗相关目的，不能充分代表全球肤色。她的团队将 Monk 教授的十种肤色量表纳入评估，并用于 Pixel 相机和图像生成工作。这里需要审视的不只是分类数量，还包括量表最初的用途是否适合当前产品。访谈没有报告量化收益，不能据此推算更换量表带来了多大改善。

评估还必须覆盖模型交付给用户的整个过程。Doshi 提醒团队检查评分者是否可靠，以及生产环境中的防护、过滤和服务环节如何影响结果。音频尤其能说明这一点：除了内容，自然度、声音特质和语调也决定体验。基础模型的分数需要与最终使用效果相互验证；如果生产环境中的体验变差，也需要逐环节排查，才能判断问题是否来自模型能力。

面对未来能力，Doshi 提出可调整的 60/20/20 框架：60% 建立在今天已经可用的能力上，20% 面向已经能用、但仍有缺口且可能较快改善的能力，另 20% 留给刚显露潜力、可能带来更好体验的能力。这个比例用于安排当下交付与未来探索，并非固定规律，也不保证模型会按预期进步。她明确表示，即使自己参与模型开发，也无法准确说出三个月后的模型具备什么能力。判断是否值得投入，需要指出产品中已经出现了哪些进展、还存在哪些缺口。

模型外围的 harness 也需要随能力变化而重新检验。Doshi 所说的 harness，包括指令、工具、skills、上下文和模型可访问的数据。为旧模型搭建的僵硬结构，可能限制新模型的表现。Rachitsky 转述 Boris Cherny 的建议：偶尔移除 skills，观察结果如何变化。Doshi 认同持续重测，而不是把新模型强行放进原有结构。需要验证的是每层结构是否仍有贡献；移除之后能否维持任务质量，仍要交给实际任务检验。

四、学习与应用

实践可以从一个反复出现、自己有能力判断质量的任务开始。按照 Doshi 的建议，先写五条有区分度的提示，亲自检查结果并评分，再逐步扩展到约二十条。关键是明确哪些表现影响任务完成，以及怎样才算做好。视觉动画、创意写作、信息综合和复杂财务分析，都是她提到的探索方向：模型已经显示出潜力，却仍有值得追查的缺口。起步时依靠熟悉领域的判断，随后仍须检查标准是否覆盖目标用户和完整流程，包括长任务、多步骤与多轮交互。肤色量表的经历提醒团队审视标准的适用范围；音频评估则提醒团队把自然度、声音特质、语调和实际服务效果纳入判断。

规划路线图时，可以按当前可用、接近可用和刚显露潜力的能力整理投入。60/20/20 的价值，在于要求团队同时交代当下能交付什么、未来机会依赖什么。每一类都需要具体依据：现有原型怎样产生价值，哪个缺口阻碍体验，已经观察到什么进展。对于尚未具备的能力，需要写清等待条件和投入边界。Doshi 无法准确预测三个月后的能力，这也限制了路线图能够承诺的程度。模型更新之后，外围的 harness 同样需要重测；比较保留或移除某条指令、某项 skill 后的结果，才能判断结构是否仍然有用。

团队学习还需要留出时间。Doshi 描述了共享有用的技术 skills、建立仓库，以及让 PM 教同事检查数据和长 traces 的做法。围绕真实工作流展示输入、过程、失败和修正，可以帮助同事判断哪些做法值得复用。但她也承认，受到保护的学习时间尚未完全建立。她提到计划在十一月举办两天工作坊，访谈并未确认活动已经发生；她所说的工具熟练后能够带来十倍提速，也没有测量结果支持。判断学习投入是否值得，仍需观察具体任务节省了多少工作，又增加了哪些检查负担。

对于日常自动化，Doshi 把第二次遇到同一任务视为考虑模型辅助的提醒，同时保留战略写作等例外。Rachitsky 的建议更靠前：开始工作之前，先问 AI 是否能帮忙。这两种做法都可以推动尝试，但重复出现并不意味着必须交给模型。输入来源清楚、产物结构稳定、结果能够检查的整理工作，可以作为起点；涉及方向选择时，仍须保留人的判断。

她以上线两周后的复盘报告说明这种分工：模型汇集使用情况、仪表盘数据、用户反馈，以及 Twitter、Reddit 上的信息，由人提供洞察。PM 需要解释这些材料意味着什么，判断哪些信号可信，再作出取舍。材料汇总得完整，并不等于结论已经成立，仍须检查来源是否足以支持判断。交付物也应附上能够检验的原型、评估或数据。Doshi 对 PM 的要求，是让需求本身带有实质支撑，而不是写完文档后，再由其他职能补足其中的内容。

工具带来的速度变化，还需要与工作的可持续性分别观察。Doshi 承认团队工时很长，这个问题仍未解决。她将反复变动、返工和不愿做的工作视为倦怠来源，希望 AI 减少摩擦，同时强调每个人的动力不同。沿着这些问题检查工作方式，需要分别关注工时、返工、消耗精力的事务，以及成员真正重视的工作。访谈没有证明 AI 已经减少工时或缓解倦怠；产出增加本身，也不足以说明工作体验已经改善。自动化是否兑现价值，仍须结合任务质量、检查负担和人的实际感受判断。

来源

• 原始节目：Why PMs are suddenly valuable again | Tulsee Doshi (Head of Product, Gemini)