What it actually takes to build frontier models | Tulsee Doshi (Head of Product for Gemini)

Google 前沿模型产品负责人 Tulsi 说，模型开发像斯内普的魔药课：材料放进去，总会冒出你没预料到的"魔法"，PM 的活是看懂它在哪里闪光。

真正难的不是把 AI 做出来，而是知道它在哪里会发光

Tulsee Doshi 负责 Google 的前沿模型产品，范围不只是 Gemini，还包括视频、图像、音乐、开放模型 Gemma 和音频能力。她此前在 Google 的 Responsible AI 团队做了六年产品。她在这期对话里讲的不是某个新模型的功能表，而是一个更棘手的问题：当模型本身在快速变化、能力又不完全可预测时，产品团队怎么判断该做什么、怎么评估、又该把人放在哪里。

这期回答了 6 个问题：

1. 模型已经有明确训练目标，为什么产品结果仍然会令人意外？
2. 产品经理怎样把“模型感觉不错”变成可执行的判断？
3. AI 产品该只做今天能稳定工作的功能，还是提前为下一代模型布局？
4. 评测为什么不能一上来就做成大而全的 benchmark？
5. AI 帮团队写得更快后，人还应该对文档负责什么？
6. 当所有人都能更快地造东西，产品经理真正稀缺的能力是什么？

被问到模型从研究、预训练到上线的过程时，Doshi 先否定了一个很自然的期待：给模型设了能力目标、盯着评测跑分，就能像传统软件那样预先知道交付物。研究团队当然会持续观察训练过程，看到指标上升也会在需要时介入；但这仍不等于产品团队已经知道用户最终会在哪个能力上惊喜。

她把这件事比作《哈利·波特》里的魔药课：配方要认真准备，可结果仍有意料之外的部分。"The model isn't predictable."（模型并不完全可预测。） 这不是把不确定性包装成神秘感，而是在说模型 PM 的任务有两段：先有意图地塑造输入，再去看输出端到底在哪些地方特别突出，然后把那个突出点变成用户能感到的体验。

这意味着，传统产品里“需求写清楚、交付按验收走”的惯性不够用了。模型在某项能力上进步，未必等于界面里最该强调的功能也随之确定。团队还要观察它的行为、表达方式、人格感，以及这些东西在真实任务中是否形成差异。模型研发更像一块不断显影的底片，产品工作不是等照片洗完，而是先辨认哪一处轮廓最值得放大。

被问到 PM 应该具备什么新能力时，Doshi 用了一个很容易被误解的词：vibes。她要的不是凭直觉拍板，而是每天真的去玩模型，对自己关心的任务有判断，知道什么结果算好，也愿意翻数据、写评测、亲手把问题拆开。"We are looking for PMs who understand the vibes of our models or other models."（我们在找能理解自己或其他模型“感觉”的 PM。）

这里的关键是把“感觉”落到长期、具体的使用场景里。有人会用 3D 动画试模型，有人拿它写作、综合信息或做金融分析。Doshi 的建议是，别为了测试而编一个陌生题目，而要找一个你已经很在意、现有模型又有一点希望但还不够好的任务。这样你才看得出不同模型在同一问题上究竟差在哪里，也能分辨偶然的漂亮答案和稳定的能力变化。

另一端是 eval。她不建议新人先造一套庞大基准，而是从五个 prompts 开始，再扩到能拉开模型差异的二十个左右。先由自己当评分者，先写清“好”长什么样，再逐步扩大样本和评分方式。它的意思很朴素：vibes 负责发现值得追的信号，eval 负责让团队能反复检查这个信号。只有前者，容易被一次惊艳答案带跑；只有后者，也可能测得很规整，却错过模型真正擅长的方向。

当主持人问到产品该领先模型多远时，Doshi 提出 60/20/20 的分配。传统做法是先做一个已经能工作、能发布的 MVP。她认为在模型快速迭代时，这样做还不够："you want to actually build features that aren't necessarily always working today"（你要去做一些今天未必总能工作的功能。）

她给的配比是：大约 60% 已经可用，让原型今天就有基本价值；20% 还不完美，但你已经看得见模型很快能补上的缺口；剩下 20% 是目前只有零星迹象、可一旦打通就会带来明显体验变化的方向。它不是预测模型三个月后必然怎样，而是给不确定的能力进展留一个有边界的位置。

这套方法还倒逼团队把架构留得更松。Doshi 提醒，很多客户围绕旧模型的限制做了很死的系统，模型变强后反而被自己的结构困住。所谓 harness，按她的解释，就是围绕模型搭出的运行环境：系统指令、工具、技能、上下文和数据。它们原本是为了帮助模型做事，但也可能把新模型硬塞回旧框架。更实际的动作不是一次性重做，而是定期拿掉一些旧限制重测，确认它们还在解决问题，还是已经成了阻碍。

Doshi 在负责 Responsible AI 时参与过肤色表示的评估改造。团队发现，过去常用的 Fitzpatrick 六级肤色量表既只有六档，本来也是为医疗目的设计，偏向浅肤色，并不适合拿来代表全球人群。后来他们和 Harvard 的 Professor Monk 合作，把他基于长期访谈和研究形成的十级量表带进评测，进而影响 Pixel 相机和图像生成的改进方向。

这个例子提醒人们，评测的第一步不是收集更多题，而是问：你用来观察产品的尺子，对当前问题还合不合适。"The quality of the judge also matters."（评审者本身的质量也同样重要。） 如果判断好坏的模型、量表或人工规则有偏差，模型分数再漂亮也未必接近用户体验。

而且最终用户接触的从来不是裸模型。上线时加的过滤器、缓解措施、服务方式，都会改变实际输出。她拿音频举例：内容是否正确是一层，声音是否自然、音色和抑扬是否合适又是另一层。也就是说，团队应该评测端到端体验，而不是只在干净的离线环境里证明底座模型不错。产品出了问题时，先别急着问“模型行不行”，先查从评分标准到交付链路，究竟是哪一层把体验扭曲了。

被问到 AI slop 时，Doshi 没有主张少用生成工具。她给的是一条分工线：上线两周后，要汇总谁在用、怎么用、反馈如何，AI 很适合去仪表盘、社交讨论和各类反馈里抓取信息，快速列出强项和问题。但如果一份文档的价值在于解释“这意味着什么”，这部分不能外包给自动生成。

她的原话很直白："what you should be providing is the insight. What the model should be providing is the data."（你应该提供洞见，模型应该提供数据。） 这不是说人永远不该让模型写句子，而是要求责任别被句子掩盖。一个团队若只让 AI 把材料拼成长文，读者得到的只是更多待筛选的信息；若让模型先整理证据、人再明确判断和取舍，文档才真正减少了工作量。

这也解释了 PM 角色为什么没有因为原型更容易做而变轻。过去 PM 写要求，工程、设计、数据或研究同事再把它做实。现在原型、数据分析和评测都更靠近 PM，要求不再只是“把需求写下来”，而是要带着可检验的分量去提出它。AI 让资料更容易到手，却没有替任何人决定哪些资料构成了一个值得投入的判断。

当构建成本下降，组织的风险也换了形态。以前是想法很好但做不出来，现在更常见的是每个人都能很快做出一点东西，最后留下许多没人真正需要的产物。Doshi 对 PM 价值的概括不是“多写需求”，而是从噪音里找信号、定义什么算好，并把人拉到同一个方向。

"speed can basically introduce chaos"（速度本身就可能带来混乱。） 她强调，路线图两个月后就可能要重写，PM 得持续看外部环境、市场变化和手头方向，而不是把计划当固定答案。对大组织而言，这还包括让不同产品和研究团队形成共识，把快速建造带来的分叉收拢成能推进的结构。

她也没有把这讲成永远加速的鸡血。团队确实工作很重，她坦承还在想怎么创造可持续的环境。她认为倦怠不只来自工时，还来自反复的混乱和无意义的杂活。工具若用得好，应该拿走这些摩擦，让人把时间放回思考、创造和自己在乎的工作上。管理者真正要处理的，不是要求所有人以同一种方式拥抱 AI，而是弄清不同人为何投入，并为他们移开各自最消耗的那一段。

这期访谈的主线不是“模型会越来越强”，而是模型越强，团队越不能把判断外包给它。第 1 条说模型结果仍会给人惊喜，所以必须去发现真正的亮点；第 2 条把这种发现接到小型 eval 上，避免只凭一次试用下结论；第 3 条要求产品同时服务今天和正在靠近的能力，但不把未来当保证；第 4 条再把目光拉回测量本身，连尺子和上线环境都要经得起检查。

后两条把这套逻辑放进组织。AI 可以替团队汇集数据、完成重复动作，甚至帮助做原型，但洞见、优先级和共识仍得由人承担。对正在做 AI 产品的人，最有用的起点或许不是再找一个万能工作流，而是挑一件你已经做过两次的具体任务：先问它能否交给模型，再保留一套小而真实的标准，持续看它究竟替你省掉了什么、又把什么新的判断责任交回给你。