深度拆解Google AI逆风翻盘：打赢 ChatGPT 的，从来不是技术，而是组织与算力的残酷物语

guozi

Gemini的逆袭不仅是一场技术突围，更揭示了AI时代产品竞争的全新逻辑。从Google内部的组织阵痛到自研TPU的算力突围，这场千日反击战重新定义了产品经理的思考维度——真正的竞争力往往藏在组织协同、战场选择和成本基建这些看不见的底层。



最近下班后去夜跑，耳机里一直循环播放着各种商业科技播客，脑子里却反反复复在推演 Google 靠 Gemini 绝地反击的这 1000 天。

这段时间，我一直在摸索如何深挖 AI 产品经理的行业深度。每天下班后，我都一头扎进暗黑模式的 IDE 里，尝试用 Windsurf搞”Vibe Coding”重构个人作品集网站，甚至还在业余时间自己写了一个小游戏，我给他起名叫《解救》的暗黑风忍者动作游戏，从核心逻辑框架到过场 CG 的提示词，全靠 AI 自动化工作流来生成。


➡️—游戏进入的画面之一配图
越是深度卷在这些 AI 工具链里，就越是能体会到大模型战场那种令人窒息的压迫感。

以前看产品，我习惯性地从 UX（用户体验）视角切入，总觉得一款伟大的产品，靠的是天才的”灵光一闪”和极致的交互视觉体验。但亲历了这几年 AI 浪潮对底层商业逻辑的疯狂洗礼后，我越来越清醒地认识到：在绝对的商业竞争与底层范式转移面前，产品表面的光鲜，全靠底层的组织调度、成本算计和战略定力。

2022 年底 ChatGPT 横空出世时，Google 经历的那场”Code Red（红色警戒）”，险些让这家科技巨头跌下神坛，市值一夜蒸发千亿。但他们硬是靠着极其痛苦的自我重组，拿出了惊艳市场的 Gemini 系列。

在这场翻身仗里，我反复咀嚼出了几个让我特别有感触的点。说不上是什么方法论，更像是这段时间一边跑步一边瞎想，慢慢攒下来的一些碎片。
01. 组织架构的”大企业病”，是所有糟糕产品的万恶之源
当初 ChatGPT 横空出世，Google 慌乱中推出了一个漏洞百出的 Bard 来应对。宣传片里连韦伯望远镜的常识都能搞错，直接导致市场恐慌性抛售。

外行看热闹，觉得 Google 技术不行了。但只要经历过大厂跨部门协作的人都懂，这根本不是技术断代，而是严重的内部组织损耗和山头林立造成的必然结果。

其实早在 2022 年初，DeepMind 就做出了类似的产品 Sparrow（麻雀），但哈萨比斯带着浓厚的学术完美主义包袱压着不发。结果呢？被 OpenAI 抢先定义了市场。

彼时的 Google 内部，两股 AI 势力割裂得令人发指： 一边是由 Google 第 30 号员工、技术图腾 Jeff Dean 领导的 Google Brain（硅谷派，偏工程与产品）； 另一边是由天才棋手哈萨比斯领导的 DeepMind（伦敦派，偏学术与前沿探索）。

这两拨人连使用的底层兵器都不一样。Google Brain 坚持用自家的 TensorFlow，而 DeepMind 死守 JAX，甚至还有人想偷偷用竞争对手的 PyTorch。

如果我们用 UX 和工程协同的视角来看，这就好比平时做跨部门项目，体验团队严格遵循了一套极具延展性的 Design System，而前端研发却非要自己去弄另一套组件库，不仅沟通成本极高，连代码都无法复用。更荒唐的是，当初仓促应战的 Bard，居然不属于这两个顶尖 AI 团队，而是隶属于搜索部门。

一个产品横跨三个部门，两个顶尖团队在做重复的轮子。这种内耗放在任何一家公司都够喝一壶的，何况是在打仗。

皮查伊最终的破局手段堪称铁腕。他动用两位创始人的权威，强行将 Brain 和 DeepMind 合并，把整个 AI 帝国的指挥棒交给了哈萨比斯。为了统一战线，哈萨比斯做了一个极其冒险的产品决策：抛弃 TensorFlow，将底层框架全部改为 JAX。这种伤筋动骨的底层重构，导致 Google 承受了一整年被对手碾压的阵痛。

我后来反复想这件事，觉得它其实揭示了一个挺残酷的道理——很多时候，阻碍产品体验提升的根本不是需求不清晰、也不是设计方案不够好，而是部门墙和技术债在暗中绞杀一切。 敢于做减法、砍项目、统一步调，永远是破局的第一步。说起来容易，真到了要砍掉一个团队用了五六年的技术栈的时候，那种政治压力和沉没成本的纠结，不亲历过很难体会。
02. 找到对手转不了身的那个死角
这里我想多说几句，因为这段经历跟我自己日常用 AI 工具的痛点直接相关。

熬过了底层统一之后，Google 掏出了 Gemini 1.0。说实话，当时的 GPT-4 在逻辑推理和代码上的表现已经很强了，Google 就算跑分打个平手，市场也不会买账——你是追赶者，平手就是输。

但哈萨比斯很聪明，他没有头铁地去跟 OpenAI 拼逻辑跑分。他盯上了 GPT-4 一个当时很多人还没意识到的短板：上下文窗口太短了。

128K 听起来不少，大概能塞进一本 300 页的书。对普通人聊天确实够了。但我自己在实际用 Cursor 做项目的时候，经常要丢进去几十页 PDF 让它转译成网页结构，或者在 Dify 和 Coze 里搭建比较长的工作流。128K 的窗口一旦不够用，模型就开始”忘事”，前面给的核心指令到后面直接丢了，幻觉一个接一个冒出来，体验直接崩掉。我相信很多重度用户都遇到过这个问题。

Google 就是看准了这个体验盲区。哈萨比斯把公司最宝贵的算力资源没有全部去堆参数量，而是集中砸向了超长文本（Long Context）处理能力。这不是加几台服务器的事，是要换底层算法架构的。

结果 Gemini 1.5 出来的时候，直接带着百万级甚至两百万级的上下文窗口。丢一整本厚厚的财报进去，能瞬间吃透并精准检索。这个体验差距，用过的人都知道有多大。

我之所以对这一步特别有感触，是因为它和做产品的逻辑太像了——资源永远是有限的，你不可能每个方向都追。与其在对手最强的地方拼命追赶，不如找到一个他因为架构包袱暂时转不了身的具体场景，然后把所有筹码都推上去。

不过话说回来，这种”非对称打法”也是有风险的。万一 OpenAI 迅速跟进把上下文窗口补上来了呢？事实上后来他们确实在追。所以这一步更像是争取了一个时间窗口，而不是一劳永逸的胜利。真正让 Google 能持续打下去的底气，其实在别的地方。
03. 算力供应链：这场战争里真正的胜负手
这部分我犹豫了很久要不要写，因为它离大多数产品经理的日常工作比较远。但想了想，还是觉得有必要聊一下，因为它彻底改变了我对”产品竞争力”这件事的理解。

我们平时聊 AI 产品，很容易把注意力放在模型效果、交互设计、功能对比上。这些当然重要，但在真实的商业世界里，还有一个特别容易被忽视的变量：计算成本。

训练大模型是一次性的巨额投入，这个大家都知道。但很多人没有仔细算过的是，模型上线之后，你发出的每一个 API 请求、用户问的每一个问题，背后都在持续消耗电力和算力。这是一笔永远停不下来的账单。

如果完全依赖英伟达的 GPU 来扛这些计算量，问题就大了。一方面是”卡脖子”的风险——全球 AI 都在抢算力的时候，排队等发货的周期长得离谱；另一方面是成本结构会非常难看，硬件溢价直接压缩利润空间。

这个时候 Google 的一张老底牌就翻出来了：自研 TPU。



这事儿其实可以追溯到 2013 年，Jeff Dean 就开始推动这条路线。2016 年 AlphaGo 打败李世石的时候，背后跑的就是 TPU。到了这轮百模大战，Google 自己的数据中心里已经部署了数十万颗自研芯片，还在持续迭代新一代的 Trillium。

说白了，Google 不需要排队等英伟达的货。TPU 24 小时全速运转，不仅支撑了 Gemini 的训练，更关键的是——它在处理大规模用户请求时的单次推理成本，是业界最低一档的。

这意味着什么呢？意味着在别人还在为服务器账单发愁的时候，Google 已经有余量去打价格战了。

我之前一直觉得”成本结构决定终局”这种话太宏观了，跟普通产品经理没什么关系。但深入了解完 TPU 这条线之后，我的想法变了。即便我们不做芯片，这个逻辑其实是通用的：当你的履约成本结构性地低于对手，你在定价、补贴、用户增长上的自由度是完全不同的。 反过来说，如果你的产品在体验上只是微弱领先，但成本比对手高出一截，这种领先是守不住的。
写在最后
其实本来想写得更收敛一点，结果第二、第三部分还是没忍住展开了不少，因为确实跟我自己每天在用 AI 工具时的体感强相关。

复盘完 Google 这一千天左右的过程，我自己最大的感受是：AI 时代的竞争真的不只是模型好不好用这一个维度。从组织怎么拧成一股绳、到选哪个战场去打、再到底层的成本基建够不够扎实，缺了哪一环都撑不起来。

我们当然没办法决定巨头的战略走向，但这些思路——怎么在内耗中破局、怎么在劣势中找到不对称的突破口、怎么在看不见的地方默默建立优势——放到自己做产品的日常里，其实是一样的。

好了，今晚夜跑的汗出透了，该洗个澡，继续切回我的Windsurf屏幕。继续优化小游戏《解救》，下一版游戏资产生成还要赶进度，毕竟在这个激荡的时代，与其焦虑，不如动手去创造。

本文由 @Percy 原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议

--------------------------------------------------
本文转载自：https://www.woshipm.com/it/6377936.html