Gemini 产品负责人谈怎么做前沿模型：模型没法完全预测，产品经理要先读懂它，再去塑造它

给一个连研究员都无法完全预测的模型定目标，产品经理靠什么？Google 前沿模型产品负责人 Tulsee Doshi 的答案是手感、自己动手写的评测，以及从五个问题起步的小评测。

你有没有想过，一个产品经理要怎么给一个连研究员都没法完全预测的东西定目标？做普通产品的时候，需求写清楚，工程师照着做，做出来大体就是那个样子。模型不是这样。同样的数据，同样的训练方案，出来的东西总会有几处你没写进计划里的地方，有的让人惊喜，有的让人头疼。

最近我看到 Google 前沿模型的产品负责人 Tulsee Doshi 在 Lenny 的播客上聊了很多这方面的事，觉得她讲得很实在。她手下的模型很多：Gemini 不用多说，还有做图像和视频的 Nano Banana、Veo、Genie，做音乐的 Lyria，开源的 Gemma，以及对话、翻译、语音合成这一整条音频模型。在这之前，她在 Google 做了六年负责任 AI（Responsible AI）的产品负责人。管过这么多种模型，又长期盯着安全和公平，她看模型的角度跟只盯一个产品的人很不一样。

我从她的话里读出的答案是：模型没法被精确控制的时候，产品经理要靠对模型手感的判断，靠自己动手写的评测，还要靠给还没成熟的能力提前留出一块位置。下面一层一层讲。

模型定了目标也不一定照着来，产品经理要同时盯着进去的和出来的

常规的产品思路是先定目标：要什么能力，要达成什么结果，在哪几项评测上要做到多少。Tulsee 讲，不管是外部客户还是公司内部的同事，听到这些目标以后，往往默认模型就会照着交付。她做了这么久模型的产品，最意外也最有意思的地方恰恰是，目标要定，思路要清楚，但模型是不可预测的。

她用了一个比喻，说这像《哈利·波特》里斯内普的魔药课。配方上的原料你都可以放进去，你也该对结果有预期，可最后总会多出一点魔法，这点魔法是意外的，也是这个模型独有的。所以产品经理的工作有两头，一头是塑造放进模型里的东西，另一头是看它从另一边出来了什么：它在哪些地方特别亮，哪些表现是你没想到的，然后把这些特点做成对用户真正有用的东西。

这并不是说训练是一团乱。她提到研究员会一直盯着每一次训练，看各项指标怎么往上走，判断什么时候该出手干预，这一部分尽量做成科学。但除了指标，还有一层只能靠上手才知道的东西：某个能力提升以后，它最亮眼的场景在哪里，放进产品里是什么样子，跟它说话时它的行为和性格是什么感觉。这些在训练时会有意去设计，可每一轮评测和试用，总会发现一点新的东西。

我认为这里有一个很容易被忽略的区别。指标告诉你某项能力涨了多少，却不会告诉你这个提升在用户眼里是什么。同样是代码能力涨了几个点，有的版本是写得更对，有的是更愿意回头追问需求，有的是改动更少、更稳，用户感受到的是三种完全不同的东西。所以模型训完以后，还得有人把它重新认识一遍，这个人最合适的就是产品经理，因为只有产品经理同时知道用户要什么，也知道训练时想要什么。而认识模型的第一件事，就是看它怎么跟人打交道。

模型本身也有用户体验，这件事要放进训练里去做

说到怎么跟人打交道，Lenny 提了一个很多人都有的感受：现在的 AI 产品越来越复杂，Codex、Claude Code 都是一堆标签页和下拉菜单，找功能要靠运气，一些实验室像是先把能力扔出去，用户怎么用，以后再慢慢把体验做好。

Tulsee 的回答分了几层。头一层，她认为新的交互形态必须有人去试，Google 的实验室团队在做的 Flow 就是一个例子，专门做视频和音乐的编辑与生成，Veo 现在也在往 Omni 的方向做，NotebookLM 又是另一种完全不同的形态。第二层，形态要看用户是谁。AI 模式（AI Mode）面对的是搜索里的几十亿用户，必须每个人都能一眼上手；Anti-gravity 面对的是会用斜杠命令、会在终端和开发环境之间来回切的高级用户，就应该留足灵活度。

她还补了第三层，这一层我觉得最有意思：模型自己也有用户体验。它有多透明，跟你沟通得好不好，它会回头问你什么问题，这些全都是体验。所以她一直在想，怎么把对体验的讨论带进模型训练本身。

做法是这样的。Google 内部有一个专门做模型行为的团队，她的产品团队跟他们一起，先看客户和用户的反馈，再问一个具体的问题：对 Gemini 来说，什么叫好？答案先写成一份规格说明（spec），再翻成评分标准（rubric），再变成可以拿来训练的数据，最后进到奖励模型（reward modeling）里，模型就是按这条线被教出来的。

这条线我认为值得每个做 AI 产品的人看一遍。传统产品经理写完需求文档，后面的事交给工程师；在模型这里，产品经理能出手的位置，正好是把“好”这个字拆开讲清楚。你说不清什么是好，评分标准就写不出来，数据就没法选，奖励模型也就没有方向。换句话说，模型的性格和说话方式不是研究员随手调出来的，是有人先把想要的样子一条一条写下来，才一路传导到模型里。这也解释了为什么她后面反复讲评测，评测就是把“好”写成可以检查的东西。

Google 同时做这么多模型，是为了服务不同的人，也没打算退出前沿

在讲评测之前，先说一下 Google 为什么要同时养这么多种模型，因为这直接决定了产品经理要管多宽。

Lenny 问到一个很多人在讨论的看法：Google 是不是已经落后于最前面的两家实验室。Tulsee 的回答是，Google 的打法是全链条，从硬件到模型，再到服务几十亿用户的终端产品，据她所知有十四个产品的用户已经超过十亿。在这条线上，目标不只是做最前面的体验，还要在成本和质量之间做出一整条曲线上的模型，让不同阶段的人都有合适的选择：来搜索信息的人，要造下一个产品的工程师，保护关键基础设施的网络安全人员，用的是不同的模型。

但她也说得很直接，Google 想赢的就是前沿这场比赛。她不认为应该说 Google 没有参与前沿，Gemini 4 就是继续往前沿推进的一步，也是她希望这段对话播出时大家已经在用的东西。

前沿模型要放出去，安全是绕不开的。她提到一个让她觉得踏实的做法，是给模型加监控，直接盯着模型的思考过程，看它的行为有没有偏离被指示的方向，一旦发现就介入，这样既能更放心地发布，也能知道模型哪里容易出问题，反过来把模型做得更好。她还讲了另一面，AI 也可以用来加固系统。Gemini 4 在跟网络安全防御方合作，包括已经并入 Google 的 Wiz，去找系统里的漏洞并修补；她举的例子是，Wiz 有一个项目，帮一家医院系统发现了漏洞，并且补上了。

我自己的感受是，这种广度对 Google 是优势，也是负担。优势在于，同一套研究能力能同时服务搜索、工程师和安全人员；负担在于，产品多了，用户就找不到，Lenny 提到不少人根本不知道 AI Studio 的存在，说的就是这个。对产品经理来说，这意味着你要同时管成本曲线上不同位置的模型，每一个都要知道它的用户是谁、好是什么意思，而每个“好”的定义都不一样。这个问题最后还是要落回到怎么评测上。

评测可以很小，先写五个问题，再慢慢培养对模型的手感

说到评测，她一上来就承认，这件事 Google 内部也还在摸索，团队里有些产品经理做得好一些，有些弱一些，所以他们在整体上提升大家的能力。她现在招产品经理，越来越看重几样：对模型的手感，也就是真的每天在用这些模型，有自己的观点，有自己判断一个模型好不好的用例；愿意下场，能自己看数据、写评测；还有就是灵活，因为这个领域每两周就变一次，两个月前写的路线图，两个月后就要重写。

对于完全没写过评测的人，她的建议很朴素：从五个问题开始。大家总觉得评测就是搭一个很大的基准测试，其实一个二十个问题的小评测，只要能拉开两个模型的差距，已经很有用，而且不用一开始就把所有环节想清楚。

更朴素的一步是，你自己当第一个评分的人。拿一个问题，看模型的回答，自己判断好不好。尤其是那种很长、很多轮、要走很多步的任务，光是说清楚自己心里的“好”是什么，就已经很难了。她认为，先有一批你自己认可的好例子，你就知道想要的是什么，等想清楚了，再去想怎么扩大规模。

至于手感，她认为没有标准答案，最好是拿你自己真的感兴趣的东西去试，因为你最容易在那里看到模型的魔法。她观察到，不同的人试的东西差别很大，网上很多人用三维动画这类视觉效果来看模型好不好，有人拿它写作文、写创意文章、整理信息，也有人直接丢给它很难的财务分析。她的建议是找一个模型已经有点样子、但还不完美的任务，这样不同模型处理同一件事的差别才会露出来，这本身就是很好的信息。

我认为手感和评测不是两个阵营。手感提出假设，说这个模型好像更会写长文章了；评测验证假设，拿二十个问题去看是不是真的。只有手感，容易被一两个漂亮的例子带偏；只有评测，又容易评出一堆没人关心的分数。她两样都要，这是对的，而且这两样都要从你自己真正在乎的任务开始。

评测不只看模型，裁判和上线环境也会改变结果

评测做起来以后，还有一层是很多人没想到的：你不能只盯着模型。她讲了几件事。负责评分的裁判模型本身也要靠谱，裁判打分不准，你对模型的判断就是错的。模型在你自己的环境里表现好，不代表放进真实产品里还好，因为真实产品里有各种保护措施和过滤器，会影响结果。模型怎么部署、怎么提供服务，同样会影响用户最后拿到什么。

她讲得最多的是音频，因为音频最复杂。除了内容，还有声音是不是自然、语气怎么样、抑扬顿挫对不对，这些恰好是服务方式最容易改变的东西，哪怕模型本身很好，部署一变，声音就可能不对了。所以她的结论是，要在一套干净的环境里，从头到尾评测用户会实际体验到的东西。

她还讲了一个她做负责任 AI 时的例子，来说明旧的评测可能已经不对了。那时他们评估产品里肤色的表现，用的是业内常用的 Fitzpatrick 量表，只有六种肤色。问题有两个：六种肤色装不下世界上真实的多样性；而且这个量表原本是为医疗用途设计的，所以整体偏浅，哪怕只看六档，也不是代表全球人口该有的六档。

后来他们跟哈佛的 Monk 教授合作。Monk 教授从人类学和社会学的角度，用多年的用户调研，建立了一套十档的肤色量表。团队把这套量表拉进评测，重做了很多对产品和模型的评估，又用它去改进 Pixel 相机和图像生成里肤色的表现，让它们在这件事上更有意识。

这个故事我觉得最有价值的地方在于，评测规定了什么算好，规定错了，模型越努力往那个方向优化，就越偏。六档量表当年被当成标准用，没人觉得它有问题，直到有人去问它当初是为什么设计的、为谁设计的。这提醒做评测的人，除了问“模型分数涨了没有”，还要时不时回头问一句“这套评分标准本身还对不对”。

60-20-20：六成现在能用，两成差不多能用，两成是已经看到一点光的

评测和手感都有了，下一个问题是产品要往前做多远。Lenny 听过的建议里最常见的一条是，按模型三个月以后的样子去做。Tulsee 有一条自己的办法，叫 60-20-20。

她说比例不必太当真，但道理是一样的。传统的创业智慧是先做一个能用的最小产品；她认为现在应该这样做：六成的东西今天就能用，原型至少是能跑的；两成不完美，但已经能用，而且你能看到模型在很近的将来会在这里变好；还有两成是你希望模型最终到的地方，现在只有一点光，如果能把它做成，就会是非常好的产品体验。这样做出来的东西，今天能用，等模型变强以后，产品也跟着长大。

她为什么不用“三个月后”这个说法？因为即便是做模型的人，也很难准确说出三个月后模型会到哪里。所以她更愿意让产品团队用自己的参照物：我的产品现在在哪，我在哪些地方看到了光，怎么把中间这段补上。这是一个更具体的问法，能回答同一个问题。

我认为这个办法的好处在于，它把赌一个未来，变成了分成几份去投入。过去团队常讲的是组合式的产品投入：几个有野心的大项目，加一批风险低、能稳稳推动指标的小项目。60-20-20 是同一个思路换到模型时代，只不过风险的来源变了，不是用户要不要，而是模型来不来得及。六成保证今天有东西可交，两成留给近期，两成看远处，哪一部分落空了，都不至于全盘皆输。

另一个她很在意的点是产品要能跟着模型变。她见过一些客户围绕当时模型的能力搭了一整套很僵的系统，结果模型已经强了很多，系统却改不动了。Lenny 提到一个说法，叫模型会把你的框架当早饭吃掉，你围着模型搭的那些优化，会随着模型变聪明而失去用处，他还说到有人建议隔一阵就把自己搭的技能全部删掉，看看没有它们会怎样。Tulsee 的回应是，要不停重新测，因为你可能在拿旧结构去硬套新模型，反而限制了它。

这里的 harness（框架），她的解释很简单：就是模型外面的那层包装，包括系统提示词、能用的工具、技能，以及它能拿到的上下文，合起来给模型一个可以工作的环境。这个环境搭得越贴合旧模型，换了新模型以后就越容易成为绊脚石，所以每次模型更新，都值得把老办法拆出来再测一遍。

什么都能做出来的时候，决定做什么的人更值钱了

把模型的事讲到这里，再看产品经理这个职业本身。Lenny 提到最近网上有一个有意思的变化：前一阵很多人说有了 AI 就不需要产品经理，什么都能直接做，后来大家发现，做出来的东西很多没人想用，于是又开始重新认识这个角色。Tulsee 说她喜欢“产品经理的复兴”这个说法，当然她自己是产品经理，难免有点偏。

她的看法是，什么都能很容易做出来的时候，做出一个好东西本身就成了稀缺的价值，品味变得很重要。一个好的产品经理，能从一堆噪音里分辨出信号，找到真正能打开好体验的那个洞察。另一件事在 Google 这样产品很多的地方感受尤其深：当大家都能飞快地做东西，速度本身会带来混乱，这时候能把人聚到一起、推动共识、把混乱理出秩序的人，就变得很重要。

她还聊了网上常见的一类说法，“原型是新的产品需求文档”，“评测是新的产品需求文档”，“数据是新的产品需求文档”。她认为这些说法真正说明的是，产品经理不能再只写一份需求，然后默认数据科学家、工程师、研究员或设计师会替你把里面的东西补上，你要多往前走一步，让你交出来的东西有分量，不管这分量是以原型、评测还是数据的形式出现。

这一点和前面几节正好接起来。写评测、写评分标准、拆“好”是什么，其实都是在给需求文档加分量。我的体会是，AI 把执行变便宜以后，写一份漂亮的需求变得没有价值了，真正难的是把一个判断压到足够具体，具体到可以拿来检查、拿来训练、拿来比较。能做到这件事的人，不管他的职位叫什么，都会越来越被需要。

另外，AI 写的文档越来越多，也带来新的麻烦，现在很多人是要花时间读别人用 AI 写的东西。Tulsee 团队的做法是先分清哪些文档适合让 AI 来写。比如产品上线两周后，想知道谁在用、怎么用、反馈怎么样，这种文档 AI 做得又快又好，它会从各个看板和指标里取数，还能整理优势和不足，也能从社交平台上抓取评论。原则是数据交给模型，洞察要留给人。团队还在投入做技能，让模型能稳定拿到正确的数据，把这类文档的结构做规整，省下来的时间用在需要创造力的思考和写作上。

团队怎么跟上：共享技能，留出时间，一件事要做第二遍就问问 AI

数据交给模型、洞察留给人，这条线要落实，团队的使用习惯得先跟上。Lenny 问她是怎么带团队提升的，她的回答让我意外，她说其实更多是团队在帮她。团队里有些人已经很深地用上了内部工具，经常试各种模型，他们做出来的技能别人也能用。所以现在在做的事情是，把某个人做出来、确实在日常工作里有用的技能分享出来，慢慢攒成一个整个产品团队都能用的库。

另一类是已经很会看数据的产品经理，擅长盯着很长的轨迹和过程看出问题，团队就办工作坊，让大家一起把这份信心练出来。她说自己做的事主要是建立信心，让每个人更相信手上的工具，也更有把握把它用好。

但最实在的一点，是时间和空间。她坦率地说，他们还没做到，但正在往这个方向走：人一直在冲刺的时候，很难停下来把工具摸熟，可一旦摸熟了，之后的效率会快十倍。所以 11 月他们要办一个两天的工作坊，把所有产品经理从日常工作里抽出来，专门给时间去做东西、去玩工具。她还在用一条经验法则，同一件事如果要做第二遍，是不是真的得自己做？有些事情当然要自己来，比如策略写两遍也还是要自己写；但有很多事情重复度很高，可以让模型帮忙。

Lenny 在这里补了一个他自己养成的习惯：在冲动和行动之间，插入一句“这件事 AI 能替我做吗”。Tulsee 同意，并且说你只需要一个真正做得很好的例子，就能改变心态。她自己也是这样，以前很难跳出“做我会做的事”这种惯性，直到有一次用了模型，发现确实很有帮助，之后就会越来越多地想“这个也丢给模型试试”，对它能做什么的信心也跟着长起来。

我觉得这个过程说明了一件事：学会用 AI，主要不是学一门技术，而是改一个习惯，而习惯要靠一个个具体的小成功来建立。所以她的做法是对的，不是发一份培训资料，而是让大家共享自己做成的小东西，一个人做成一个，别人看到以后才会想“那我也试试”。

累的原因不只是工作时间长，还有混乱和不想做的活

做模型的团队工作量很大，这一点她也不回避，团队里每个人现在都投入了全部的时间，怎么让这个环境可持续，她自己也还在想。不过她对倦怠有个人的看法：倦怠不只来自工作多，主要来自两个地方，一个是混乱和反复，一件事今天定了明天又变；另一个是不喜欢的工作，觉得是在做杂活、在浪费时间。做自己热爱的事当然也会累，但同时会带来更多快乐。

所以她期待这些工具能把杂活和让人烦的部分拿掉，让人有更多时间思考和创造。Lenny 也补了他做的一份调查：工作时间长不等于倦怠，很多人工作得比任何时候都辛苦，也比任何时候都开心，因为能自己做原型，能直接跟客户聊，不用再等工程师。她还提到，团队里每个人来上班的原因都不一样，作为负责人，她要弄清楚每个人的动力，帮他们在自己的位置上做成事。

我认为这里最值得记的是“混乱”这个词。AI 让东西做得更快，也让方向改得更快，如果团队没有清晰的重点，快就会变成混乱，混乱才是最消耗人的。前面讲的 60-20-20 和先拆清楚“好”是什么，在这里也成了减少混乱的办法：目标越清楚，团队越不用反复推翻重来。

我自己的一点思考

回头看这一路，Tulsee 讲的其实是同一件事的三个时间点。模型训练之前，要把“好”写成规格、评分标准和数据；模型出来以后，要靠手感和评测去认识它，看它在哪里亮、在哪里不稳；产品往前做的时候，要给还没成熟的能力提前留位置，同时别把自己锁死在旧模型的样子里。这三件事听起来分得很开，其实都是在回答同一个问题：什么叫好，以及怎么知道它到了没有。

这也是我认为前沿模型这件事对产品经理最有意思的地方。过去产品经理的能力，一半在判断用户要什么，另一半在协调别人把东西做出来；现在协调执行这一半越来越多由工具完成，留下来的是把判断压到足够具体的能力，具体到能写成五个问题、能变成一条评分标准、能在模型更新时再测一遍。

她的建议也不难做。想知道自己有没有这个能力，今天就可以试：挑一件你真正在乎的任务，写五个问题，自己给模型的回答打分，把“好”讲清楚。想让模型做好一件事，先得自己说得清什么叫好。