Jeff Dean 最新万字对谈：别去做模型能做对20% 的事，去找它0%或1% 成功率的问题

来源：智慧的痕迹

出处｜Jeff Dean: The 1% Rule for Building in AI，Y Combinator Startup School 2026（2026 年 7 月 25–26 日，旧金山，约 6000 名创始人到场）现场炉边对谈，全长 57 分钟。 对谈人｜Jeff Dean，Google DeepMind 与 Google Research 首席科学家。MapReduce、BigTable、Spanner、TensorFlow、TPU、Google Brain、Gemini 背后的关键人物。

1. 「1% 法则」——去找模型成功率是 0% 或 1% 的问题，不是 20%。这是全场最锋利的一句话，也是标题的由来。Jeff 的逻辑是反直觉的：如果通用模型在你的问题上已经能做对 20%，那恰恰是危险信号——说明这个能力已经在模型里萌芽了，再多一点训练数据、再大一点规模，六个月到十二个月内就会被它自己吃掉。反过来，模型彻底失败的地方，才可能是你的护城河。

2. 大多数人还没内化：Agent 可以连续跑几天甚至几周。被问到「这个房间里 6000 个人普遍相信、但其实已经不成立的假设是什么」时，Jeff 的回答就是这个。他说人们以为 Agent 只能跑一两个小时，但在某些问题域上，配上足够强的底层模型，它可以跑上几天几周去啃真正复杂的任务——比如把一整套软件用另一种语言重写成安全性或性能更好的版本。

3. 计量单位已经从「时间」换成了「能量」：搬一次数据的能耗，是做一次乘法的 1000 倍。一次乘法大约 1 皮焦耳，而把这个数从加速器的 HBM 搬进处理器要贵三个数量级。这个 1000 倍的鸿沟安静地决定了哪些产品做得出来、哪些做不出来。很多创业者以为自己撞上的是「模型问题」，其实撞上的是能耗和数据 IO 问题——batching 之所以存在，就是为了把这笔搬运成本摊薄成「1000 倍 ÷ batch size」。而低延迟场景恰恰最不适合 batching。

4. 2026 年的「索引装进内存」时刻，是低功耗、低延迟的推理专用硬件。2001 年 Sanjay 和 Jeff 算出搜索索引已经能塞进全部机器的内存，几天之内就把搜索换成了内存版，这是 Google 快起来的起点。主持人问 2026 年的对应时刻是什么，Jeff 的答案是推理硬件的专用化。他补了一句让全场安静的话：想象一下延迟好 50 倍以后，你能做什么。

5. 上下文工程（context engineering）是普通团队唯一能和大厂站上同一起跑线的战场。训模型需要天量算力和数据，但上下文工程只需要一个 API。Jeff 强调，模型看到的上下文比训练数据「清晰得多」——训练数据是几万亿 token 搅成一锅汤，糊在几千亿参数里；而上下文是模型此刻直接看见的东西。变强的办法很朴素：拿模型去真刀真枪解问题，观察它在哪里失败，然后把你自己作为人类会用的方法，写成模型能用的形式。

6. Jeff 自己写的那个 skill，是这条建议最好的注脚。他和 Sanjay 几周前给模型写了一个 skill：教它跑微基准测试、改代码、再测、扩大基准集、量 cache footprint，然后自己迭代——把两个人做底层性能优化的完整工作流交给了 agent。他还提到他俩公开过一份约 30 页的《performance hints》文档，有人把它压缩后喂给模型，模型对代码性能问题的推理能力立刻上了一个台阶。这份文档是公开免费的。

7. Agent 在第 30 步脱轨，本质是「跑出了分布」+「开环」。两个解法：skills 和推理时搜索。Jeff 说 agent 崩掉常常是因为它在做一件训练时没什么经验的事，一旦偏离熟悉的分布，性能就断崖式下跌，越偏越糟。对策一是用 skills 和提示把它按在「照得亮的那条路」上；对策二是多 agent 并行试不同路径，再让另一个模型/agent 当评估器，留下有希望的、砍掉跑偏的——本质是用推理时计算（inference-time compute）在解空间里做搜索。

8. 当代码都由 Agent 写完，稀缺的技能只剩「品味」。「研究员可以有全部的工具和技术，但大半场仗打的是：你要把时间花在哪个问题上。」Jeff 认为模型在这件事上未必会很强，所以未来是人在掌舵大量 AI 辅助的算力。怎么练品味？除了经验，他给了一个可操作的土办法：写下你认为未来 12 个月重要的一堆事，挑一件去做，12 个月后回头逐条复盘——哪些真的重要了、哪些别人做出来了、哪些至今没人碰。这是在给自己的品味刷样本。

二、全文编译 01 开场

主持人：我们开始吧，Jeff？

Jeff Dean：好，没问题。

主持人：Jeff，欢迎你。真的非常感谢你能来——尤其我自己刚感冒，也谢谢你今天到场。

Jeff Dean：是啊，我恐怕嗓子也废了。我平时不是这个声音，但我们尽力吧。

02 去年的预言：AI 已经到「初级工程师」水平了吗

主持人：你做了 MapReduce、BigTable、TensorFlow、TPU、Gemini。光是把你做过的事聊一遍就能占满一小时。但我最欣赏的是，你到今天还在公开场合下大胆的判断。去年，2025 年 5 月，你在 AI Ascent 上说，AI 已经到了初级工程师的水平。那是大约一年前。现在离那个判断有多近？

Jeff Dean：我觉得模型在基于 agent 的、长周期运行的编码任务上已经好了非常多，而且很明显它们现在确实相当能干了。取决于你对「初级工程师」的定义具体怎么划，我会说这个判断相当准。

主持人：那当时你低估了什么？

Jeff Dean：我想是，处理越来越复杂任务的能力，增长得比我预期的更快。另外我也认为，在编码之外，这些基于 agent 的系统真的开始在别的领域发光了。我觉得这会是未来一个很重要的趋势。

03 那么，2027 年版的预言是什么

主持人：那再给我们一个大胆的判断吧。2027 年版会是什么？

Jeff Dean：我认为你会看到机器学习系统自身的大量自动化。基本上就是：让 ML 系统通过跑大量实验来提升自己的能力——把问题拆成子问题，把这些子问题丢进一个紧凑的自动实验循环里跑，再把结果拼起来，然后从中得到一个改进过的系统。这种全自动的问题分解 + 自动化实验，我觉得会非常令人兴奋。

而且我认为这不只适用于 ML，也适用于科学和工程的其他领域。基本上任何存在可度量目标的地方，我觉得今天你都能取得很大进展。

04 2001 年「索引装进内存」的那一刻，2026 年的对应物是什么

主持人：我们往回看一点历史。很早以前，2001 年，Google 搜索还跑在硬盘上。你和 Sanjay 算了一笔账，意识到在某个时间点，整个搜索索引终于能塞进你们所有机器的全部内存里。你们做出了那个激进的判断，然后基本上在几天之内，和 Sanjay 一起把一个全新的、跑在内存而不是硬盘上的搜索版本推上了生产环境——那件事让 Google 变得那么快。

历史总是在押韵。2026 年的现在，那个「它能装进内存了」的时刻是什么？这屋里的人现在应该在想、应该在设计的东西是什么？

Jeff Dean：嗯，情况有点不一样，但我认为你会看到越来越多高性能、低能耗的推理硬件系统。因为现在所有人都意识到了：推理才是让这些 agent 系统能被越来越多人用上的关键，延迟真的很重要，而硬件的专用化是让东西比 GPU 这类更通用的计算设备更省电、更低延迟的关键路径。

主持人：因为我想在座每个人都已经习惯了等模型返回。

主持人：等待可不好玩。

主持人：速度就是一切。所以你的意思是——如果我们不用再等了呢？

Jeff Dean：对。我想我们会的。想象一下，如果延迟好上 50 倍，你能拿它做什么。

05 这个房间里 6000 人普遍相信、但已经不成立的假设

主持人：有意思。那么，这屋里 6000 个人当中，有哪个关于 AI 的假设其实已经是错的了？

Jeff Dean：这问题问得好。我想有一件事是：人们没有意识到，基于 agent 的系统不只能在你关心的问题上跑一两个小时——对某些问题域，只要底下的模型足够强，你可以让它们连续跑上几天甚至几周，去完成真正非常复杂的任务。我觉得现在有一部分人开始看到苗头了，但我不认为所有人都真正内化了这件事。而这会是相当大的一件事。

主持人：你自己跑过的、真的跑了几周的任务是什么？你让 agent 去解的是什么？

Jeff Dean：你可以让 agent 去用另一种编程语言，把某个软件完整地重新实现一遍——新版本可能有更好的安全性质，或者更好的性能。它们真的能相当严肃地把这件事做完。

06 餐巾纸计算，和 TPU 的起源

主持人：挺酷的。你有一件特别出名的本事，就是你的「餐巾纸计算」（napkin math）特别厉害。说来有点好笑。关于你有个故事：2013 年，语音识别在 Google 开始真的能用了，你做了一个餐巾纸计算——如果每个 Google 用户每天用手机对着语音识别说三分钟，就三分钟，你算出来这个系统需要的算力，意味着你得把整个服务器机队翻一倍，光为了做语音识别，那会贵到离谱。

主持人：然后你没那么干，你去做了一颗定制芯片——那就是 TPU 的起源故事。

Jeff Dean：是的。当时我们开始在基于深度学习的语音系统上看到非常好的质量结果。但相比老的语音系统，它们计算上很贵——不过它们把错误率砍掉了一半。那基本上相当于语音识别领域二十年的进展，而我们只花了几个月：调调模型、把规模放大一点、拿到更好的数据。

于是我们开始担心：如果语音识别效果好得多，人们就会用得多得多。那个信封背面的计算，问的就是这件事——如果人们开始更多地用语音去口述邮件、去跟手机说话，会怎么样？结果我们意识到，当时跑在 CPU 上这条路，需要一个更好的解法。

所以我们搞出了 TPU。它本质上是为低精度稠密线性代数高度专用化的东西，而低精度稠密线性代数正是我们今天几乎所有现代机器学习算法的核心。如果你造一颗只会做低精度稠密线性代数、别的什么都干不了的专用芯片，那它对机器学习推理来说会非常有用——哪怕它跑不了 Chrome，也跑不了 Word。

那个项目在两年后产出了一颗芯片，它比当时的 CPU 和 GPU能效高 30 到 80 倍，而且延迟也低得多，大概低 20 到 30 倍。

主持人：TPU 今天已经成了这么基础的东西，太不可思议了。你当年绝对不可能预料到，TPU 会在今天如此关键——Transformer 架构是在你造 TPU 之后很久才被发明出来的。

Jeff Dean：是的，这其实正是我们要造一个通用线性代数系统的原因，TPU 本质上就是那个东西。因为我们知道 ML 算法还在演化，你不想过度专用化；但你又要专用到足以拿到那些戏剧性的性能收益——我们可以放非常大的乘法单元，可以配高速内存，可以做高速互连；到了后来的 TPU，可以把很多很多颗芯片高效地并到同一个问题上。这么多代下来，我们一直在把它们的规模和性能往上推。

07 今晚该做的那道餐巾纸计算题

主持人：不可思议的餐巾纸计算。

Jeff Dean：餐巾纸是个好东西。

主持人：那么，在座每一个想成为创始人的人，今晚该做的那道「餐巾纸计算」是什么？怎么才可能算出一个像 TPU 一样有分量的东西？

Jeff Dean：这总是很难讲。我觉得是：想想你正在琢磨的那件事里，你看见了什么问题、什么瓶颈；然后问，有没有一种完全不同的解法思路，能让你拿到一个数量级、甚至两个数量级的性能或能力提升。

因为有时候你眯起眼睛看一个问题，不要被「今天这个问题是怎么解的」锚定住，而是想「如果从第一性原理出发我会怎么解」——你会想出真的很好、而且可能没什么人在想的点子。

主持人：好建议。

08 「每个工程师都该知道的延迟数字」的 AI 版

主持人：给不知道的人介绍一下：很多年前，Jeff 写过一份非常著名的清单，叫「每个工程师都该知道的延迟数字」。上面是一些数字，比如一次 cache miss 要多久、一次磁盘寻道要多久、一个网络包从加州飞到荷兰要多久——一大堆关于分布式系统和系统工程的数字。

主持人：这份清单被打印出来贴在墙上，成了很多分布式系统工程师的圣经。

Jeff Dean：好吧，是的。

主持人：快进到今天，这份清单该更新了。给我们一个 AI 版本吧。

Jeff Dean：我觉得如果你看今天 AI 系统里什么最重要，你会想知道这些数字：

• 你的加速器上，主存系统到片上内存、再到乘法单元之间的带宽是多少；

• 做一次乘法操作要花多少能量；

• 芯片之间的互连带宽是多少，以及在那个带宽下你能连多少颗芯片；

• 再往外走一层——当你需要和10000 颗芯片通信、而不是 500 颗时，网络带宽的衰减曲线是什么样的。

我觉得这些都是非常重要、值得去学的数字，而且它们真的会影响你思考特定类型问题该怎么解。

09 能量：搬数据比算数据贵 1000 倍

主持人：还有一件我听你讲过的、很有意思的事：现在你衡量一切的单位是能量。你指出，做一次计算、一次数学运算，大约花 1 皮焦耳；但搬数据、做数据 IO，要花它的一千倍。

Jeff Dean：对。就是把数据从加速器上的 HBM 搬进处理器，好让它真的能算。

主持人：这个差距悄悄地决定了哪些产品是可能的、AI 里这些算法是怎么被造出来的。那么，有哪些问题是创始人一直当成「模型问题」，但其实是能量问题或数据 IO 问题？

Jeff Dean：你刚提的那个例子——搬数据 vs 真正算它，能量上差一千倍——就是相当重要的一个，它塑造了我们在机器学习里做的很多事情。

因为如果没有这一千倍的差距，你根本不需要做 batching。但正因为有，你必须把很多样本、或者很多 token 一次性攒成一批，好把那笔数据搬运成本摊薄——这样你付的就不是一千倍的减速，而是一千倍除以 batch size的能量成本。

而对真正的低延迟场景来说，batching 并不好用。所以我觉得，我们用的计算硬件里，各种决策背后的能量账，真的深刻影响着我们在更上层建系统时做的很多决定。

主持人：一个非常具体的例子就是模型是怎么训的。有一整套关于 batching 数据集、跑 epoch 的概念。人们可能会误以为这是个模型问题，但它其实是个系统、数据 IO 问题，对吧？

Jeff Dean：对。你必须组装出 batch，才能让硬件的效率更高。理想情况下你可能想做 batch size = 1 的训练，但那在效率上不够好。所以现在大家用的 batch 都相当大。

主持人：你以出去待一个长周末或一周、然后带回一个绝妙解法而闻名。有没有可能出现「Jeff 出去搞了几周，回来把 batch size = 1 的训练解决了」这种事？

Jeff Dean：其实我最近想得更多的是推理。我觉得推理是个相当有意思的问题，因为你确实想要非常低的延迟。训练的话，你不见得需要低到离谱的延迟。而我认为，在为推理做硬件专用化这件事上，还有很大的空间没被利用。

10 推理，以及「压缩即理解」

主持人：在推理上，你现在想得比较多的有意思的点是什么？

Jeff Dean：就是尽量减少数据搬运。还有考虑低精度运算——而且也许不要去支持一大堆不同的精度格式。如果你觉得自己对「到底需要哪几种精度」已经有了一个好答案，那就干脆把那几种直接做进硬件里，别的都不做。

主持人：这让我想到一个我从某位著名计算机科学家那里听来的核心类比：AI 的整个过程本质上是一个大的压缩问题——因为要把数据压下去、再还原回来，你基本上必须先理解它。

Jeff Dean：对，如果你真的理解了数据，你就应该能把它压得很好。

主持人：而现在 Transformer 架构基本上就是被证明特别管用的那条路。

Jeff Dean：是的，我会说，到目前为止效果相当好。

Jeff Dean：我同事们干得不错。（笑声）

11 上下文工程：所有人都能上桌的战场

主持人：我们往外拉一层。以前 AI 的进步就等于更好的模型：更多数据、更大参数量。但最近一年多，越来越是模型周围的一切——不只是模型大小、参数量或者更多数据，而是检索、工具、记忆、agent 工具这些东西。它们可能正在被收敛成一个词，叫「上下文工程」（context engineering），对吧？

Jeff Dean：对。我认为模型只是你真正想做的事情里的一块——你想做的是造一个能解决真正有意思的问题的整体系统。这里面包含：一个知道怎么用各种工具的模型；它也许知道怎么检索相关信息；也许还有它为过去的问题检索过的信息的历史，而它能把这些信息放进模型的上下文里。

这件事好在哪？这些信息对模型来说是非常清晰的。不像训练数据——训练数据是几万亿 token 搅成一锅汤，糊进几千亿甚至上万亿参数里，那比模型为这个具体问题、这个具体用例直接看到的上下文要模糊得多。

然后我觉得还有：能够搞清楚有哪些工具可用、哪一个能帮模型解决问题的下一阶段、怎么把一个问题分解成一串工具调用。也许还要尝试多条路径去解，看哪条走得通，并且能对此做出评估。这就是整个复杂 agent 系统和多 agent 系统的编排问题——我认为它会越来越重要，是非常令人兴奋的时代。

主持人：而这个问题域有意思的地方在于，它是这屋里每个人真的能上手做的。因为在此之前，要训一个模型，你需要难以置信的资源、难以置信的 GPU 和数据获取能力。但对上下文工程来说，这里每个人都做得了——你只需要一个类似 Gemini 的 API，然后就可以去打磨你自己的那一套：你自己的检索、你自己的工具调用，等等。

那么，给在座的人一些建议吧：怎么才能在上下文工程上变强，甚至变得出类拔萃？

Jeff Dean：我觉得一个很好的办法是：去用这些模型、这些 harness 和工具，真刀真枪地解决问题，然后你常常能看见模型是在哪里失败的。

而且很多时候，你真的可以让模型在那类问题上表现更好、成功解出来——不是靠调模型参数（那从外部很难做到），而是靠为模型写更好的指引、为模型写 skills，让它知道怎么使用那些对解决这一类问题极其有用的工具。

我认为在你这么做的过程中，你会进入一种自我改进的循环——你在不断改进你用来解决问题的那套装置。这是一个非常好的途径，让你越来越懂：模型到底还想要什么额外信息，才能变得更强。

12 Jeff 自己写的那个 skill

主持人：你自己做过的上下文工程能举个例子吗？比如你写过的 skill、工具，真正让你的工作流发生了巨大变化的那种。

Jeff Dean：几周前我和 Sanjay 在做一件事。我们经常会做一些非常底层库的性能优化。我们在 Google 内部写过一个微基准测试库，你可以用它写微基准，测各种操作要花多长时间、填充某个数据结构要多久之类的。而有些数据结构会被 Google 内部几百万个进程用到，所以确保它们高性能其实相当重要。

所以你可以写微基准。但如果没有 agent 系统，你通常的做法是：先测出你关心的那些基准上当前的性能；然后做一些你希望能提升性能的修改；接着重跑基准，看哪里改善了；再跑一套更广的基准；量一下 cache footprint。

于是我们写了一个 skill，基本上就是教模型怎么按各种顺序把上面这些事做完——这样它就能自己完成「跑基准 → 改代码 → 测性能提升 → 再迭代」这个自我改进的循环。对某些类型的问题，这个效果相当好。

它本质上就是：我们把作为人类会采用的方法，以模型能用的形式交给了模型。

主持人：哇，这太厉害了。你是说你有一个 skill，谁要是拿到它，就能像 Jeff Dean 一样做性能优化。感觉全世界都想要这个，对某些人来说这值无限多的钱。

Jeff Dean：噢。我们其实在几个月前公开过一份文档，叫performance hints，是我和 Sanjay 写的，大概30 页，讲各种各样的性能技巧。已经有人把它拿去、以摘要的形式喂给各种模型，然后发现模型对代码里性能问题的推理能力确实变强了。

主持人：大家都听到了。你们真的可以像 Jeff Dean 一样优化自己的代码，只要你去拿他发表的这份 performance hints。

Jeff Dean：它是完全免费公开的，所以你们都该去试试。

主持人：非常酷。

13 Agent 为什么在第 30 步脱轨

主持人：你刚才在讲 agent。在座的大概都在做、或者做过 agent。我相信每个人都见过自己的 agent 在第 30 步、第 40 步左右跑飞。agent 大概到第 10 步之前都挺好，到第 50 步就开始摇摇欲坠。你觉得今天的约束在哪？是评估器不行，还是因为它本质上是个开环系统、误差在累积？

Jeff Dean：显然我们希望 agent 能跑非常长的时间，因为那才是它们解决越来越复杂问题的方式。但正如你观察到的，它们有时候和工具交互个十来轮之后就不工作了。

有时候是因为模型在做一件它没什么经验的事。它是在一整套东西上训出来的，一旦你稍微偏离它知道怎么做的那个分布，那么——像大多数机器学习模型一样——它的性能会突然开始劣化；而且你离它的舒适区越远，它出问题的概率就越大。

所以你可以做一些事：

一是给模型 skills 和提示，让它尽量待在那条「它确实知道怎么走、被照得比较亮」的路上。

二是多 agent 系统：让多个 agent 尝试不同的路径，然后你可以做评估——也许再有一个模型或者另一个 agent，去评判哪些路径看起来有希望。这在某种意义上就是在可能解的空间里做搜索，留下看起来最有希望的，丢掉那些看起来走不通、或者已经跑飞了的。

这是一个非常非常有用的通用技巧：用推理时计算（inference-time compute）去搜索可能的解法路径，可以让长时间运行的 agent 拿到高得多的性能、或者高得多的可靠性。

主持人：你们自己是怎么为 agent 实现这套工作流的？

Jeff Dean：我们有 harness，还有一整套 skills，特别是在 Google 内部的开发环境里。我们做了 skills，让 agent 知道怎么使用我们大量的内部工具——写代码的、做 code review 的、量性能的、抓日志文件的。

这些就是你可以加上去、让基础模型变得更强的 skills。哪怕它并没有专门被训练过「Google 内部工程师是怎么从我们的专有系统里抓日志的」，只要有合适的 skill 定义，你就真的能让它做到。

14 创业公司在哪里赢：1% 法则

主持人：这确实提升了 agent 的可用性。现在我们聊聊创业公司能在哪里赢。这一节我个人特别在意，因为在座每个人都得决定，作为未来的创始人要做什么。

Google 的特点是你们把从处理器到产品的整个系统全部协同设计（co-design）。那么，哪些层是 Google 这样的公司会持续投入、持续复利变强的？哪些地方还留给两三个人的小团队？

Jeff Dean：很明显，Google、我们的 Gemini 模型、我们的硬件基础设施，都在努力造几乎什么都能做的极通用模型。

但很多时候，这意味着我们没法在某些特定领域上投入太多注意力。而在那些领域，一个设计得非常好的界面、也许再配上一个模型和一套 skills，或者一个不在我们通用模型能力组合里的专用模型，真的可以拿到显著优势——因为你能为一个你真正热爱的领域，做出一个令人愉悦、准确率非常高、质量非常高的东西。我觉得那就是两三个人在一个房间里、做他们真正兴奋的事能有优势的地方。

但我也要提醒一句：通用模型正在变得越来越强、覆盖越来越广。所以你必须搞清楚——你在做的这件事，它是持久的吗？还是说你觉得前沿模型在未来 6 个月、12 个月内就会做好它？还是说它们两三年内都做不到？你在决定做什么的时候，得把这个权衡进去。

主持人：我们深入一点。通用模型你们当然会继续做、继续变强。那台下的人该怎么推理出「哪些领域是它顾不上的」？创始人该怎么思考选什么方向？

Jeff Dean：最重要的一件事是：挑一个你自己超级兴奋、想做、并且你认为对世界有用的东西。如果你做到了这点，你已经领先很多了——总好过你每天醒来想「我其实不太想干这个」，或者你做的东西其实对世界、对很多人并没什么用。所以这是我给「下一个该做什么问题」的第一筛选标准。

第二，你要去看当前更通用的模型在这个问题域上能做到什么程度。你可以直接去测：它们能不能把这件事做得很好？

• 如果它们彻底失败，那大概是个好信号。

• 如果它们能做一部分、但做得不太好，那可能不是个好信号——因为这大概说明这项能力已经开始在模型里出现了，只要有更多训练数据、更大规模模型或者别的什么，它很可能就会变好。

所以，去找那种模型成功率是 0% 或者 1% 的问题，而不是 20% 的。

15 两条路径：私有数据，和 AlphaFold 式的专用模型

主持人：怎么找到这种问题？它们本质上是训练集之外的分布（out of distribution）吗？具体是什么样的问题形状？

Jeff Dean：有时候是这样：你做的产品可能能接触到某类通用模型接触不到的数据。比如你在做一个帮用户组织他们全部个人信息的东西，模型不见得有权限访问那些数据。那你就有很大优势，因为突然之间，你的产品能看到重要的数据。

也可能是某个极难的问题——如果你能拿到对的训练数据，你就能训一个比通用模型更专门的模型，而且成本可以很低。也许训一个针对这个特定问题的小众模型并不需要多少算力，但你能得到一个准确率极高的东西。那有时候会成为一块非常好的积木，去解决一个通用模型处理得并不好的重要问题。

主持人：有意思。我理解是基本上两条路。第一条有点好笑：你们（Google）在做的是组织全世界的信息——

Jeff Dean：那块大概已经覆盖得差不多了。

主持人：是啊，但组织「你个人的」信息——这块还开着，这挺有意思的。

主持人：然后第二条路，你提到了某些领域的专用模型。能多讲讲有哪些领域吗？

Jeff Dean：比如你看我同事们做的AlphaFold，那是一个针对蛋白质折叠的非常特定的模型，而且它把那个领域处理得相当好——突然之间你就有了一个了不起的工具和模型，能非常有效地回答关于蛋白质及其结构的问题。但它不是通用模型，它是个非常专门的模型。

还有别的领域，这种打法也能奏效。也许是材料科学，或者芯片设计这类。它们能让你利用一个非常准确但小众的模型的能力，去做今天很难做到的事。

16 AI 原生创始人（一）：把规格写清楚

主持人：好例子。所以如果你们中有人找到一个形状类似 AlphaFold 的问题，那可能是个好方向。

现在假设你已经找到了要做的问题。我们聊一点：怎么成为一个 AI 原生的创始人？怎么真正把这件事做好？你以前说过，管理一支 50 个、100 个 agent 的舰队，关键在于写出非常好、非常清晰的设计文档和规格（spec）。人怎么才能把这件事做好？它们长什么样？

Jeff Dean：我认为，如果你能清楚地说明你到底想要什么，你和虚拟 agent 一起工作时会顺利得多。你说得越清楚，agent 就越有指引、越有一套关于「它要完成什么」的规则和提纲。而如果你几乎什么都不说明，agent 就只能去猜你是什么意思——很多情况下，它猜出来的东西会和你想象的不一样。

我们从最开始就一直在告诉计算机科学家：在真正动手写之前，先说清楚你要写的这个软件是要完成什么，这非常重要。而现在，我们真的有了能替你写的 agent 系统，但**「说清楚你要什么」的重要性反而上升了**。因为在过去，你是把它交给一个很聪明的人类，那个人也许本来就有上下文，或者能反过来问你追问题。agent 有时也能做到这点，但我认为把规格写清楚仍然是个非常好的主意。

举个编码 agent 用得极好的例子：你今天可以让模型把软件从一种编程语言翻译成另一种，效果非常好。因为在这种情况下，你其实拥有一份极其详尽的规格——整个软件本身就说明了这个系统应该做什么。

所以如果你有某个东西的 Python 实现、想要一个 Go 的实现，今天的模型在这件事上能力强得惊人：它可以把 Python 里所有的测试拿过来，确保它们在 Go 版本里也通过，把测试翻译成 Go，然后对比两个实现之间的行为差异，直到没有差异为止——效率极高，正因为那份规格如此清晰。

17 AI 原生创始人（二）：品味才是稀缺技能

主持人：那么，假设现在每个创始人都学会了同时驱动几百个 agent，所有代码都由 agent 替他们写好了。那时候，稀缺的技能是什么？

Jeff Dean：我认为是你在「让 agent 去做什么」这件事上，有极好的品味（taste）。

这正是——从我做研究的背景来说——一个研究问题的关键所在。研究员可以拥有全部的工具和技术，但大半场仗打的是：你要把时间花在哪个问题上。如果你把问题挑对了，并且成功解决了它，那远远好过你把一个相当无聊的问题执行得赏心悦目。

所以，「该做什么」这种更高层的智慧，我认为极其重要。而且我认为模型在这件事上未必会很强。所以未来会是：人在掌舵大量 AI 辅助的计算，去更快地完成伟大的事情。而「你到底想让模型做什么」这个内核，才是你该聚焦的关键。

主持人：我们多聊聊品味，因为在当下这个 agent 编码的时代，这个词被谈得非常多。你到底怎么建立品味？这听起来太玄了，怎么把它落地？

Jeff Dean：这确实是件难事。很多情况下，品味并没有一个可度量的目标。

一部分来自经验。过去做过很多不同的问题，会教会你：未来什么样的问题可能有意思；什么样的东西，把过去的几种方法拼一拼，也许刚好就能做成；以及为了得到某个近乎魔法、或者极其有用的东西，你还得去攻哪些开放问题。

另一个给自己攒经验的办法是：把你认为未来 12 个月里可能重要的事情，写下来一堆。你也许只挑其中一件去做，但12 个月后回过头去，逐条评估——这些事里哪些真的重要了？哪些是世界上别人跑出去做出来了？哪些至今还没人做？

这能为你自己的品味生成能力提供多得多的样本。这是一项重要的技能。

18 疯狂思想实验：如果晶体管每天出 20 次错

主持人：我觉得第三个办法——我们刚才聊到的——是做非常疯狂的思想实验。

Jeff Dean：噢对，那是另一个好办法。我认为有时候，不要把大多数人视为理所当然的东西当成理所当然，这很有价值。

前几天我和几个同事做了一个疯狂的思想实验：六十年来，整个硅芯片设计和制造产业做了大量了不起的工作，把晶体管做得越来越小、错误率越来越低。因为我们默认想要的是：同一设计造出来的每一颗芯片，都应该和其他每一颗完全一致。

主持人：你不希望有任何比特翻转。

Jeff Dean：不能有任何比特翻转。为此有各种各样的容错余量，比如现在的内存都有 ECC。

但是——在宏观尺度上，我们建大规模分布式系统的时候并不做这个假设，对吧？我们是用不可靠的部件搭出可靠的大规模分布式文件系统：单块磁盘可以坏，但你的数据必须是安全的。所以我们在更高的层次上有各种机制，让数据在三台不同机器、三个不同机架上有三份副本，这样任何一个机架交换机、单台机器或者单块磁盘挂了，你的数据还在。我们还有 Reed-Solomon 编码之类的技术。

但我们似乎并没有在晶体管这个尺度上，把这个思路推到极致。所以一个有意思的思想实验是：如果你试着用「每天会出 20 次错」的晶体管去造一个系统，会发生什么？

主持人：我的天。

Jeff Dean：——而不是一百万年才出一次错，对吧？那会是一个完全不同的设计点，而且可能让你在制造这一侧做出真正有意思的事情。你会有非常不同的设计方法论：因为如果你想把一个信号从这里送到那里，而你手上的晶体管极其不可靠，你可能会有非常不同的信号传输方式——你可能会沿着多条冗余路径同时发送，以确保它至少从其中一条抵达。

我觉得这会是一组相当有意思的思想实验。我不是说我们该真的去做这个，但这就是那种你偶尔确实应该去质疑一下假设的事情。

而且很多时候这些思想实验并不会成立——因为过去五十年我们之所以这么做而不那么做，通常是有很好的理由的。但每隔一段时间回去重新审视一下，是好事。

主持人：这也太野了。我是说，它开始和神经形态计算、和人脑、和自然的工作方式非常押韵。

Jeff Dean：完全正确。我们大脑里的信号，从一个地方传到另一个地方，可靠性并不特别高。所以我认为在大脑里，当有些东西真的很重要、必须传到位时，会存在多条通路来保证这件事。

19 他自己扔掉过的假设：TPU 与 MapReduce

主持人：你的职业生涯这么厉害——有哪一个「被你扔出窗外」的疯狂假设，最后真的造出了一个有分量的系统？

Jeff Dean：我想，TPU 就是一个好例子：在某个问题域看起来还远没有今天这么重要之前，就为它把硬件专用化——那本身就是一次思想实验。

另一个好例子是 MapReduce 的起源。当时我和 Sanjay、还有另外一些同事，做过 Google 抓取和索引系统的很多版迭代。我们写了大量手工并行化的代码，配上大量 checkpoint 机制，好让它在跑在 100 台或 1000 台机器上、其中一些挂掉时，依然健壮可靠。

但那些代码，总是和你实际想做的、其实相当简单的那件事混在一起。比如我只是想看一遍所有网页的内容，然后在旁边算出一个从 URL 到「这个页面的文本是什么语言」的映射。而这件事会被所有那些并行化和可靠性的代码淹没掉。

于是我们想起了自己在函数式语言方面的训练，意识到我们可以眯起眼睛看这些问题，然后就发展出了MapReduce 这个抽象——你可以把它架在实现之上；而在实现之下，你可以把所有 checkpoint 和可靠性机制都塞进那个更底层的库里，让上面所有东西都建在它之上。

这后来成了 Google 内部处理超大规模计算、而且做得健壮可靠的一个极其成功的方式。它就来自那个思想实验：如果我们眯起眼睛看，能不能找到大量恰好能塞进这个抽象里的问题？

主持人：太厉害了。所以这个思想实验直接导致了 MapReduce。

Jeff Dean：是的。

20 AlphaChip、AlphaEvolve，与自动化的科学方法

主持人：我们回到你现在的兴趣——你在大量投入定制硬件。现在有AlphaChip在做芯片布局；你们还有AlphaEvolve，它会提出解法、评估它们、留下有效的那些。看起来你们已经开始建一整套能复利、能「用 AI 造 AI」的系统了。

Jeff Dean：是的。我认为更一般地说，这背后是科学方法的根基：你提出一个实验，你实现运行这个实验所需要的东西，你评估这个实验，然后你从中得到结果。

而我认为，现在有越来越多的问题，可以让整个循环不只跑几个实验、而是跑非常非常多的实验——因为你能把这个循环自动化，并且把它的延迟压得极低。这会变得极其重要。它会让我们能攻下科学、工程、机器学习模型设计本身，以及像芯片设计这样的工程任务里的大量不同问题域。

所以如果你真能把这些事自动化地做完，再配上一个编排框架：它能接收非常高层的目标，把目标拆成子问题；每个子问题都是这样一个探索「怎么解这个子问题最好」的自动化循环；然后编排框架再把子问题的解拼装成上层问题的整体解——那会非常有影响力，而且真的非常重要。

我认为它会让我们加速机器学习的进展、加速科学、加速工程。我觉得那会很了不起。

21 瓶颈常常在评估器：一个 30 万倍加速的例子

主持人：听起来很棒。这意味着很多领域——那些有很好的评估器、或者接近于能被形式化验证的领域——都已经成熟到可以做自我改进的 AI 系统了，对吧？

Jeff Dean：是的。不过很多情况下，你的评估器需要被做得快得多。

举个例子。我的同事们大概十年前做过一些量子化学的工作：你想理解某个特定分子的性质，你可以生成某种分子构型，然后想知道它有什么性质。为此你可以跑一个计算量极大的密度泛函理论（DFT）模拟器，那可能要算一整晚，才告诉你一个结果。

但我同事们做的是：拿一批这些模拟运行的输出——输入的分子构型，加上那个昂贵模拟器的输出——用它们训练了一个模拟器的神经网络近似。

这样一来，它就成了一个新的验证装置。但它不再需要一整晚，他们做出来的东西快了 30 万倍，而且几乎和跑全尺度模拟器一样准。

那就彻底改变了你做科学的方式，对吧？因为现在你有一千万个候选要筛，你可以在去吃个午饭的工夫里筛完，而不是变成一个六个月的工程——还得东拼西凑地攒算力来跑完所有这些模拟。

我认为在很多领域，更快的验证模型、可能是学出来的验证模型，都还有很大空间。它们能极快地给你一个对真实答案的近似。而这会改变那些实验循环的思考方式，以及你能多快地转完一圈。

22 这套加速版科学方法，最该去解什么

主持人：你最兴奋的是，这套被大幅加速的科学方法会解决什么样的空间和问题？

Jeff Dean：很明显，机器学习自己就是一个。我们能不能有一个模型，通过跑大量实验来递归地自我改进？

想想今天大型研究团队是怎么改进模型的：通常是人们想出一些点子，跑一批小规模实验，看这些小规模实验效果如何；如果不错，就挑最有希望的那些，在更大规模上试；然后再评估，再把结果整合成模型的新配方。

但我认为，没有什么真正的障碍阻止这个循环变得自动化得多：由模型自己决定要探索什么——也许在最高层有人推一把，比如「你要不要在模型架构上试试这些新点子」——然后它就跑出去做大量实验，看哪些有效，接着这些结果会以快得多的速率被整合进来。

而且本质上，你想优化的是「每单位算力投入所换来的发现数量」。

主持人：非常酷。

23 那篇被拒稿的蒸馏论文

主持人：回到台下——在座各位以后要么会创业、要么开始自己的职业生涯，你们大概率会收到很多拒绝。这一定会发生。它也发生在你身上过，Jeff。有个故事是，你和 Geoffrey Hinton、Oriol Vinyals 一起写了一篇关于**蒸馏（distillation）**的论文——

主持人：——就是用一个大的教师模型去训练一个小得多、效率高得多、参数更少、算起来便宜得多的模型。这现在已经成了业界所有人都在用的技巧。而问题是，这篇论文当年被拒了。

Jeff Dean：是的。我其实不怪程序委员会。因为很多时候一篇论文拿到三个评审意见，其中一位评审看了之后——这次的说法是——「不太可能产生显著影响」。

主持人：「不太可能产生显著影响。」

Jeff Dean：但我觉得，我们写那篇论文的时候，是真的看到了这是一个极其重要的问题。因为我们知道，从大规模模型里造出便宜而能力强的模型，是我们迫切想做的事——我们想把模型服务给越来越多的人，在语音、视觉等很多不同领域。

但那位评审可能没有那种经验，因为他们也许并没有在思考大规模 AI 服务，而是在想「这算不算一个基础性的突破」。

所以，时不时被拒稿，没关系。我们把它放到 arXiv 上，人们读了，人们用了，一切都很好。而且我们自己也在用它——比如我们的Flash 模型就是从更大的Pro 模型里蒸馏出来的。这也是为什么 Gemini 的 Flash 模型相对于它们的体积和速度来说，能力那么强。

主持人：在它们那个模型尺寸档位的基准上，它们是最好的几个之一。太厉害了。我想这里的教训是：哪怕被拒了，也要接着干。

Jeff Dean：是的。这就是我会从那件事里蒸馏出来的教训。

24 如果 25 岁的 Jeff Dean 穿越到今天

主持人：有意思的是，你加入 Google 的时候，它还是个 20 人的创业公司。如果我们把当年那个年轻的 Jeff Dean 传送到今天——

主持人：——带着你现在的技能，在这个时代。

Jeff Dean：我感觉自己精神抖擞、年轻力壮。

主持人：——你会做什么？加入一个前沿实验室？还是自己创业？今天的 Jeff Dean，25 岁的 Jeff Dean。

Jeff Dean：这总是很难说，而且这是一个非常个人的选择——你想把时间花在什么上面。

对我来说，最重要的问题是这几个：

• 你要做的，是不是一件你真的在乎的事？

• 如果你和一群你喜欢共事的同事一起，真的在这件事上取得了进展、甚至把它解决了，那会不会以某种正面的方式改变世界？比如，你会不会突然能做成某件事，并把这个能力提供出去——去帮到生物化学家，或者是更宽的东西，帮到程序员，或者帮到互联网上所有的消费者。

你该努力去做的，是在世界上产生正面的影响，和你享受共事的人一起工作，努力工作，做到最好。

至于你说的那个具体权衡——加入前沿实验室 vs. 和一两三个亲近的朋友一起创业——我认为这是两种不同的体验：

在一个成熟的大组织里，你有结构，你有非常非常多了不起的同事，他们懂很多你不懂的东西；你有很多有意思的问题可以做；而且你的工作天然就有一个影响力的平台，已经能影响到世界上非常多的人。

而作为一家非常小的创业公司，你必须有一件你真正热爱的事，而且风险很大——你要在那个特定问题上赌自己能成功、能把这份事业做大。但那也可能是极其有回报的，我想象。

所以我觉得这真的取决于个人的品味。但至少，不管你走哪条路，都问自己一句：如果我做这个问题，并且发生了最好的可能结果，世界会不会因此变得好很多？还是说世界只会「哦，这挺酷的」？后者不是你该把时间花上去的那种事。

25 怎么找人、怎么组队

主持人：我们多聊聊第二条路——和你真正喜欢的人在一个小团队里工作。你一直是很多很多工程师了不起的导师和管理者，也建成过庞大的系统。对在座的人来说，怎么和聪明人一起工作、怎么找到聪明人，有什么经验？

Jeff Dean：你当然总是想找那种在某个团队需要的领域里技能非常好的人，不管是在公司内部组队还是创业。

但你也想找那种你「待在他们身边会很愉快」的人。因为你要花大量时间和这些人一起做非常难的问题，你会希望他们低自我（low ego）、是团队型的、而且技能最好和你互补。

我一直觉得，在一个小团队里工作、里面的人懂我不懂的东西、而我也许有些别人没那么强的技能——这非常有意思。因为你们在共同建造一个谁都无法单独完成的东西；而在这个过程中，你自己会获得大量新知识和新技能，他们也一样。

你应该把自己的工程或研究生涯看成：你有一条了不起的工具带，上面挂满了各种技术。你要一直往这条工具带上加新工具——因为你永远不知道什么时候会碰上一个问题，需要的恰好是这四件专门的工具，而不是那三件。工具加得越多，你未来遇到的问题就越有可能被你解决。

26 他希望有人去解决的问题

主持人：最后一个问题。我很确定这屋里会有一个人、或者好几个人，最终做出像 MapReduce、TPU、蒸馏这样有分量的东西。你希望他们去做的是什么问题？

Jeff Dean：世界上有很多有意思的问题，我随口说几个吧。这绝不是穷举，因为世界很大，问题很多。

一、硬件的新路径。我对硬件的全新思路特别兴奋——刚才那个思想实验就是一种指向，或者说，效率高得多的推理硬件。

二、数据效率高得多的机器学习算法。我认为可能存在根本不同类型的 ML 算法，比我们今天用的方法在数据效率上高得多。想想今天的大规模模型，它们看到的数据量，大概是一个人类到 18 岁时所见数据的一千倍。然而这个 18 岁的人在很多事情上更强，而且与那些见过多得多数据的前沿模型不相上下。所以，你能不能造出数据效率高得多、并且能从自己的行为中持续学习的系统？

三、持续学习（continual learning）。这是个非常有意思的方向。

四、多 agent 交互。也很有意思。

五、让世界上的人有更好的对话。我觉得，创造某种方式，让人们之间的讨论质量更高，可能会很有意思。有没有办法让对话变得文明得多？以及基于兴趣，帮人们认识世界各地那些他们本该认识的人？我觉得这些都是挺有意思的事。

世界上有很多很酷的东西，我们都该出发去让更酷的事情发生。

主持人：太棒了。非常感谢你，Jeff Dean。今天就到这里。

Jeff Dean：感谢。

主持人：谢谢大家。

三、译注

1. 1 皮焦耳（picojoule）：原话是 "about one pico"，指一次乘法运算的能耗量级约为 1 皮焦耳（10⁻¹² 焦耳）。对照是把该数据从加速器的 **HBM（高带宽内存）**搬进处理器的能耗，约为其一千倍。字幕将 HBM 误听为 "HPM"，此处已还原。

2. 蒸馏论文：指 Geoffrey Hinton、Oriol Vinyals、Jeff Dean 合著的《Distilling the Knowledge in a Neural Network》（arXiv:1503.02531，2015 年 3 月公开）。现场只提到「被拒了」和评审意见「不太可能产生显著影响」，并未点名具体会议，本文不做补充。

3. Reed-Solomon 编码：字幕作 "read Solomon"，为里德-所罗门纠删码，大规模存储系统中用于以更低冗余度容忍磁盘/机架故障。

4. "latency numbers every engineer should know"：Jeff Dean 多年前流传极广的一份延迟数字清单（L1 缓存引用、分支预测失败、磁盘寻道、跨大陆网络往返等的数量级），至今仍是分布式系统工程师的常用参照。

5. AlphaFold / AlphaChip / AlphaEvolve：分别为 DeepMind 在蛋白质结构预测、芯片布局规划、算法/程序演化搜索三个方向的系统。字幕中的 "map produce" 为 MapReduce 的误听，"custom ship" 为 custom chip，"subpros" 为 subproblems，"10,000 strips" 为 10,000 chips，均已还原。

6. Sanjay：指 Sanjay Ghemawat，Google Fellow，Jeff Dean 长期的搭档，GFS、MapReduce、BigTable、LevelDB 等系统的共同作者。

原视频：Jeff Dean: The 1% Rule for Building in AI（Y Combinator，YouTube，视频 ID: CxXgV54KzpQ） 建议对照原片收听。本文为学习交流用途的中文编译，观点版权归讲者与主办方所有。

阅读最新前沿科技趋势报告，请访问21世纪关键技术研究院的“未来知识库”

未来知识库是 “21世纪关键技术研究院”建 立的在线知识库平台，收藏的资料范围包括人工智能、脑科学、互联网、超级智能，数智大脑、能源、军事、经济、人类风险等等领域的前沿进展与未来趋势。目前拥有超过8000篇重要资料。每周更新不少于100篇世界范围最新研究资料。 欢迎扫描二维码或访问https://wx.zsxq.com/group/454854145828进入。

截止到2月28日 ”未来知识库”精选的百部前沿科技趋势报告

（加入未来知识库，全部资料免费阅读和下载）