01 触发事件

Google Gemini 产品负责人 Tulsee Doshi 在 Lenny's Newsletter 中解释，frontier model 的开发并非单纯把模型工程做得更复杂，而是同时处理研究、产品、基础设施和商业化问题；她还提出用 60-20-20 框架分配资源，用于平衡已经有效、接近有效与仍待验证的方向。

这看似是产品管理方法论，实际信号是：Google 正把 Gemini、Nano Banana、Genie、Veo、Lyria 等模型放进同一个 full-stack frontier AI 体系，而不是分别经营几个孤立模型。

02 这事的真正含义

问题不在于 Google 又讲了一套前沿模型研发流程，而在于它所选择的组织方式。

Doshi 将模型开发比作 Snape 的 potions class。这个比喻的重点不是“配方神秘”，而是每一步都要在目标、限制条件和偶然性之间做判断：数据是否足够，训练规模是否合适，eval 是否真正测到用户价值，以及产品形态能否把模型能力转成使用量。

这揭示了 frontier lab 的一个经常被忽略的事实：模型能力只是系统的一层。模型质量之外，data pipeline、训练资源、post-training、serving stack、developer tooling、distribution 和产品反馈回路，决定能力能否变成收入。

这也解释了为什么 Google 的优势不能只用 benchmark 衡量。它同时拥有 TPU、Gemini、Vertex AI、AI Studio、Android、Search 和 Workspace。对 frontier model 来说，这些资产提供了从训练到分发的完整回路；但回路越长，局部决策失误被放大的风险也越高。

60-20-20 的价值不在数字本身，而在它迫使团队明确区分三种不确定性：

  • 已经证明有效的工作；
  • 技术接近成熟、可以加码的工作；
  • 尚未验证、只能控制投入的方向。

很多 AI 创业公司其实没有这种纪律。团队把全部资源押在一个“快要成功”的能力上，却无法解释哪些结果来自真实产品信号，哪些只是 demo。这个差别会直接影响下一轮融资和下一轮 hiring。

我没在 Google 内部参与过这些资源分配，因此不应把 60-20-20 解读成 Gemini 项目的真实预算表。它更像是一套公开的管理框架，而不是具体 operating plan。

03 历史类比 / 结构对照

最接近的历史类比是 2007 年 iPhone，但需要修正一个常见说法。

iPhone 的真正突破不只是把计算设备装进手机，而是 Apple 重新控制了硬件、操作系统、应用商店和开发者 distribution。模型能力是“内核”，API、开发工具、SDK 与生态则是“App Store”。

2008 年金融危机也提供了一个反例：高增长叙事并不自动形成 moat。金融机构把信贷增长当成价值，直到 loss distribution 被重新定价。AI 同样如此：token 调用量可以快速增长，但如果客户无法留存、推理成本高于毛利、模型差异又被快速复制，增长本身不是壁垒。

2022 年 ChatGPT 则展示了 distribution 的爆发力。模型未必是当时绝对最强，但它进入了正确的用户入口，并建立了低成本试用与开发者反馈回路。Google 拥有比 ChatGPT 当年更完整的 distribution，却必须证明它能把这些资产转化成模型使用，而不是仅仅转化成曝光。

这里的核心结构是 aggregation：模型能力会持续商品化，而能把模型嵌入已有 workflow、积累 proprietary feedback、并降低切换成本的产品层，更可能保留价值。

但这也不自动导出“闭源模型必胜”。开源模型会持续压低同类能力的 API 价格，迫使 closed model 通过 reliability、tool use、multimodality、safety、latency 和 integration 收取溢价。若 full-stack 没形成这种溢价，distribution 也只是昂贵的获客渠道。

04 对 AI builder 意味着什么

第一，本周应重写产品路线图，明确哪些能力已经产生可重复的客户结果，哪些只是“接近成功”。不要用模型 benchmark 代替产品 eval；先定义任务失败成本、延迟预算和人工接管条件。

第二，API 产品需要建立自己的 eval layer。Tulsee 谈到如何写第一个 eval，重点应放在真实任务分布，而不是通用榜单。最小可行 eval 不必很复杂，但必须包含失败样本、版本记录和回归测试，否则每次换模型都会变成赌博。

第三，model routing 不应只按价格切换。应同时计算质量、latency、context length、tool-call reliability、data residency 与供应商故障风险。便宜模型承担简单任务，是 token 经济学的基本功；但如果错误率提高导致重试或人工复核，账面折扣可能只是成本转移。

第四，AI startup 应选择至少一个拥有强 distribution 的既有渠道。产品 moat 往往不来自模型本身，而来自 workflow 嵌入、权限体系、审计能力和团队协作数据。模型可以替换，迁移时积累的 friction 与 data gravity 更难搬走。

第五，对 opcx.ai 这类 model access 平台，关键不是支持模型数量，而是把 routing 变成可观测的产品能力。调用者需要知道每条请求为何落到某个模型、质量与延迟如何、cache hit 节省了多少、以及切换供应方的成本是否值得。这个控制面板才可能形成 switching cost。

我可能高估了“full-stack”的实际协同速度。拥有更多资产不等于拥有更强决策机制；如果内部审批、算力排队和 legacy 产品的包袱拖慢迭代，full-stack 反而会变成 full-stack bureaucracy。

05 反方观点 / 风险

我可能低估了模型技术本身的重要性。

Doshi 这套叙事强调产品与组织，容易产生一个误导：好像模型供给已经高度同质化，应用层只需做好包装。事实上，前沿模型在 reasoning、multimodality、context handling、agentic execution 和 safety 上仍有显著差异，而这些差异会直接决定产品能否成立。

更尖锐地说，Google 的 full-stack 也可能是防御性结构。它需要让 Gemini 在模型、cloud、device 和 application 各层保持统一，避免独立 AI 产品绕过其分发体系。反过来看，这也可能限制 Anthropic、OpenAI 或 AI-native startup 建立独立 distribution。Google 的资源壁垒越高，平台越可能主动把 API、工具链和默认 routing 锁进自己的生态。

第二个风险是 60-20-20 成为口号。若资源仍然围绕高可见度项目分配，或者“已经有效”的标准由内部叙事决定，这套框架只是重新包装年度规划。AI 公司的常见问题不是缺少方法论，而是无法承认方向错误。

第三个风险是 eval 被过度工程化。复杂 eval 平台可能比客户任务更精致，最终优化了指标而非结果。Tulsee 谈的是写出第一个 eval；从第一个有效 eval 扩展到可信评测体系，需要真实数据、持续维护和足够样本量，这比做一张 leaderboard 困难得多。

最后，不能把 Google 的组织能力直接外推到创业公司。Google 可以同时承担 TPU、data center、research lab、consumer distribution 和 enterprise sales；小型 AI builder 复制这种结构，通常只会复制复杂度。更好的策略反而可能是明确放弃某一层，与模型供应商、cloud 和现有 workflow 平台组成组合。

我依然认为这次公开信号值得写：frontier AI 的竞争单位已经从单个模型转向“模型—产品—基础设施—distribution”的完整系统。但真正需要观察的，不是 Google 下一款模型赢了多少 benchmark，而是这套 full-stack 是否让 Gemini 的单位经济、开发者采用和产品留存同时改善。