起因

8 月 5 日,Google 宣布 AI 组织调整,Jeff Dean 在待了 27 年之后离职。他和 Sanjay Ghemawat、Quoc Le、Oriol Vinyals 一起出去做一家叫 Discovery Loop 的公司,Google 以创始投资人和 Cloud 合作方的身份继续支持。Alphabet 股价当天跌了大约 4%。

我是看到这条新闻,才回头去翻 YC 在 7 月底放出的那场访谈:《Jeff Dean: The 1% Rule for Building in AI》,Startup School 2026 现场录的,播客版 8 月 1 日上线,57 分钟(录制的具体日期我没查到,只能确认发布时间)。

看完我记下的第一句话是:他在这场访谈里已经把 Discovery Loop 要做的事整个讲完了,只是当时没人往那个方向听。

Diana Hu 问他「2027 年版的大胆预测是什么」,他的回答是:让 ML 系统自己跑大量实验来提升自己的能力,把问题拆成子问题,每个子问题丢进一个自动化的实验循环,再把结果拼回去。五天后公布的 Discovery Loop,官方说法是用 AI 自动化科学与工程里的实验流程,让机器并行地提出、执行、分析上千个实验。

同一件事,说了两遍。

所以这篇读后感我会写得具体一点。先摆两个人的资历——不摆清楚,后面那条 1% 规则的分量就出不来;然后是我真正抄走的三条判断,以及我要给 1% 规则加的两个前提。

这两个人的资历,得先摆一下

Jeff Dean

1999 年加入 Google,当时公司二三十人(Diana 在访谈里说 20 人,CNBC 的报道写「大约第 30 号员工」,我没能核实到底哪个准)。他自己在 X 上说,这段旅程里 Google 从大约 25 人长到 19 万人以上。今年 58 岁。

他的东西你大概率每天都在间接用:MapReduce、BigTable、TensorFlow、TPU、Gemini。2011 年联合创办 Google Brain。离职前的头衔是 Google 首席科学家。

还有两份不算论文但流传更广的东西:

  • 「Latency Numbers Every Programmer Should Know」——一份延迟数字清单,cache miss 多久、磁盘寻道多久、一个网络包从加州到荷兰多久。Diana 说这份东西被无数分布式系统工程师打印下来贴在工位上,当《圣经》用;
  • 《Performance Hints》——他和 Sanjay 写的内部性能调优文档,内部版约 30 页,2025 年 12 月对外公开在 abseil.io/fast/hints.html,里面的示例改动最早能追到 2001 年。

访谈里有个细节我挺喜欢:他是带着感冒来的,开场第一句就说 I'm afraid I've lost my voice. I don't normally sound quite like this, but we'll do what we can. 嗓子哑着讲了 57 分钟。

Diana Hu

主持人不是来念题的,她的资历得单独说。

智利人,Carnegie Mellon 电子与计算机工程本硕,方向是计算机视觉和机器学习。之后在 Intel Labs 做 ML 研究,在 OnCue 做数据科学(OnCue 后来被 Verizon 收购)。

2017 年她联合创办 Escher Reality(YC S17),做的是 AR 后端。2018 年被 Niantic 收购,她进去负责 AR 平台,把 AR 交付给了 1 亿以上的 Pokémon GO 玩家。她自己形容那次收购像是从 Seed 直接跳到 Series B。

2021 年以 Visiting Group Partner 的身份回 YC,2022 年转全职 Group Partner,2026 年 6 月升 Managing Partner。YC 的数据:带过近 230 家公司、18 个 batch,2100 多小时 office hours,这些公司加起来价值约 70 亿美元。

我把她的资历写这么细,是因为这场访谈的质量有一半来自她。后面我会单独讲她的提问手法。

判断一:0% 是机会,20% 是陷阱

这是整场访谈里唯一一条能直接拿去做决策的判据。Jeff 的原话:

So look for something where the model succeeds 0% or 1% of the time, not 20%.

我的翻译:去找通用模型成功率 0% 或 1% 的问题,不要去碰 20% 的。

反直觉的地方在后半句。20% 听起来是好事——说明路子对了,再优化一下就能到 80%。Jeff 的判断正好相反。他的原话是,如果模型「kind of able to do some of it but not very well」,那大概率说明这个能力已经开始在模型里出现了,接下来只要更多训练数据或者更大规模,它自己就会变好。

换成我的说法:20% 是通用模型已经踩进你这块地的信号。你在上面盖的东西,下一个版本发布就被平掉了。

0% 是机会,20% 是陷阱。

顺手澄清一件事:标题里的 1% 和复利那个 1% 完全不是一回事。我自己以前写过「每天 +1%,一年以后就是 37 倍」,那是讲积累。Jeff 这个 1% 是一条筛选阈值,讲的是别去做模型已经会做一半的事。两个 1%,方向相反。

他给了两种具体的 0% 形态:

  • 你有模型拿不到的数据。 他举的例子是帮用户整理他自己的个人信息——通用模型没有这个访问权限,你的产品有,这就是优势;
  • 你能训一个很窄但很准的模型。 他举 AlphaFold:一个只解蛋白质折叠的模型,别的什么都不会,但在那个域里准到能重塑整个学科。他说材料科学、芯片设计这类地方还有同形状的机会。

判断二:taste 听起来最虚,但他给了唯一能练的方法

Diana 问:如果每个创始人都学会同时跑上百个 agent,代码都由 agent 写,那时候稀缺的技能是什么?

Jeff 的回答是 taste——挑什么问题给 agent 做的品味。他把这个类比成做研究:一个研究者可以有全部的工具和技术,但大部分胜负在于你决定把时间花在哪个问题上。他的原话是,把一个相当无聊的问题研究得赏心悦目,远不如挑对问题然后解掉它。

到这一步我还嫌虚。让我抄下来的是 Diana 追问「how do you make it concrete」之后,他给的第二种练法:

Another way you can get more experience for yourself is to just write down a bunch of things you think might be important in the next 12 months. Maybe you pick one of them to work on, but go back and evaluate in 12 months which of these other things actually seemed important.

写下你认为未来 12 个月重要的一批事。挑一件去做。12 个月后回来看剩下那些:哪些真的重要了,哪些被别人做出来了,哪些根本没发生。

我认为这条是整场访谈里最可执行的一句。因为它把 taste 从「天赋」改成了「样本量」——你判断得准不准,取决于你手上有多少条已经结算过的判断。大部分人从来不结算,所以永远在攒第一条样本。

我今晚就建了这个清单。写了 9 条,2027 年 8 月回来打分。

他还给了第三种练法:做疯狂的思想实验。他现场举的那个例子挺震撼——芯片行业 60 年来的默认假设是「同一设计造出来的每一颗芯片都必须一样,一个 bit 都不许翻」,但在分布式系统这一层,我们从来不这么假设,我们是拿不可靠的零件搭出可靠的大规模文件系统。所以:如果你故意去造一种一天出 20 次错的晶体管,而不是一百万年出一次,整个设计方法会变成什么样?他自己补了一句 I'm not saying we should go do this,但这就是那种值得每隔一段时间回去捅一下的假设。

判断三:写清楚要什么,这件事的价值反而涨了

这条对我做交付和 QA 的日常最有用。

常见的想法是:agent 越聪明,我就越不用把需求写清楚。Jeff 的判断反过来。他说计算机科学从一开始就在教「写软件之前先说清它要达成什么」,现在有了能替你写的 agent,把要什么说清楚的重要性其实上升了——因为以前你是交给一个有上下文、还会反过来问你问题的聪明人。

他给的例证很硬:为什么今天的模型做跨语言迁移做得那么好?

In that case, you actually have an incredibly detailed specification. You have the whole software that says what the system is supposed to do.

因为那种任务里,你手上有一份完整到极致的 spec——整套代码,加整套测试。Python 实现要转 Go,模型可以把 Python 的测试翻成 Go 的,跑通,再逐条比对两个实现的行为差异直到没有差异为止。

所以「agent 在第 30 步跑飞了」这个问题,很多时候要往规格上查:你给的那份东西只够撑 10 步。

Diana 也问了 agent 跑飞的事。Jeff 的解释是:模型被训过的东西是一个分布,你一旦稍微走出那个分布,性能就会开始骤降,离舒适区越远掉得越快。他给的两个对策,一是用 skills 和 hints 把模型往它熟悉的亮路上引,二是搞多 agent:几个 agent 各试一种路子,再让另一个模型评估哪条有戏,砍掉跑飞的。

他自己也在写 skill。他说前几周和 Sanjay 一起,把他俩做微基准性能优化的那套人肉流程——测当前性能、改、重跑、跑更大一组基准、量 cache footprint——写成了一个 skill 教给模型,让它自己迭代。他的原话是 It really just is us giving the approach we would use as people to the model in a form that it could use.

然后 Diana 直接问了一句我很欣赏的话:这个 skill 别人能拿到吗?Jeff 说,那份《Performance Hints》已经公开了,有人把它喂给模型,模型在性能推理上就变好了。

那份文档因此有了第二种用法。你可以自己读,也可以塞进 CLAUDE.md 或者 skill 里给 agent 读。

我要给 1% 规则加两个前提

到这里都是我认同的。下面是我不太认同、或者我认为他没说透的部分。

第一,1% 规则是第二道筛子,不是第一道。

大家传播这条规则的时候,普遍把它当成选题公式:跑一遍模型,成功率 0% 的就是好机会。但 Jeff 自己在同一段回答里,把它明确放在了第二位。他的第一条是:

The most important thing is to pick something you're super excited about and want to build and you think would be useful in the world.

漏掉这句,1% 规则就会变成一台专门生产「无人区里的无人问题」的机器。模型成功率 0% 的问题海里去了,绝大多数是 0% 是因为没人要,不是因为没人做得到。这两种 0% 长得一模一样,但一个是机会,一个是坑。

1% 规则筛掉的是会被模型平掉的题,它筛不出值得做的题。

第二,0%/1% 是一张快照,快照守不住明天。

Jeff 自己给了对冲:他说通用模型正在覆盖越来越广的范围,你得判断你做的这件事,是前沿模型未来 6 到 12 个月就会做好的,还是两三年都做不了的。

所以真正要算的不是今天的成功率,而是这个成功率的爬升速度。今天 0%、明年 60%,和今天 0%、三年后还是 5%,在快照上完全一样。这一层他点到了但没给方法,我也没有。这里我承认没底:我暂时不知道怎么在事前可靠地估出爬升速度,只能想到一个笨办法——把同一组测试用例,每次模型发新版就重跑一遍,攒自己的曲线。有更好的做法欢迎来告诉我。

Diana Hu 的提问方式,我单独学一段

这场访谈里她做了三次同样的动作,我认为这是采访的手法,值得单独拆出来。

她每次都是:先把 Jeff 的一段历史,压成一个可复用的动作,然后原样抛回去问「2026 年的版本是什么」。

  • 2001 年他和 Sanjay 算出整个搜索索引能装进全部机器的内存,几天就把 RAM 版搜索上了线,Google 搜索从此变快。她压成一个问句:2026 年那个「it fits in memory」的时刻是什么? Jeff 的答案是高性能、低能耗的推理硬件;
  • 那份延迟数字清单。她压成:给我们一个 AI 版的。 Jeff 现场给了——加速器主存到片上内存到乘法单元的带宽、一次乘法的能耗、芯片间互联带宽、能连多少颗、以及从 500 颗扩到 1 万颗时带宽的衰减;
  • TPU 的餐巾纸计算。她压成:今晚在座的人应该算一道什么样的餐巾纸算术? Jeff 的答案是去找你眼前的瓶颈,别被「今天它是怎么解的」锚住,从第一性原理想有没有一两个数量级的做法。

对照我以前写评审 PPT 那篇里的判断,她做的正是同一件事:不让概念停在概念层,一定要落回听众明天能动手的那一层。区别是她在现场做,一小时里做了三次。

如果你要采访人,这个手法可以直接抄:别问「你怎么看 X」,去问「你当年那件事的今年版本是什么」。

顺手记几个数

访谈里砸出来的数,我认为都值得抄进笔记(以下全部是他在现场讲的,我没有二次核实):

  • 2013 年那次餐巾纸计算:如果每个 Google 用户每天对手机说 3 分钟话,服务器规模得翻一倍。这条算式最后长出了 TPU;
  • 深度学习语音模型把错误率砍了一半,相当于语音识别 20 年的进展,只用了几个月调模型、加规模、换更好的数据;
  • 第一代 TPU 比同期 CPU 和 GPU 能效高 30 到 80 倍,延迟低 20 到 30 倍;
  • 做一次数学计算大约 1 皮焦耳,把数据搬进来要一千倍。这个一千倍就是 batching 存在的全部原因——你没法消掉它,只能用 batch size 去摊薄它。也所以极低延迟和 batching 天生打架;
  • 他同事十年前做的一件事:拿密度泛函理论模拟器的输入输出去训一个神经网络近似,把一次要跑一整晚的验证变成快 30 万倍、精度接近的东西。他的评价是,这直接改变了做科学的方式——1000 万个候选,以前要凑半年算力,现在吃个午饭回来就跑完了;
  • 今天的大模型看到的数据量,大概是一个 18 岁的人的一千倍,但那个 18 岁的人在很多事上还是更强。所以他认为数据效率极高、能持续学习的算法,是一个很值得做的方向。

还有一条不是数字,但是我最想抄的:他说 2014 年他和 Geoff Hinton、Oriol Vinyals 那篇讲蒸馏的论文,被 NeurIPS(当时叫 NIPS)拒了,理由是 it's unlikely to have significant impact。他们放到 arXiv 上,然后全行业都在用,Gemini 的 flash 系列就是从更大的 pro 模型蒸出来的。

他对这件事的态度是 so it gets rejected every so often; that's fine,没有一句抱怨评审。这一点比那篇论文本身更值得学。

你明天能怎么用

我把这篇能落地的部分收成四件事,都是今晚或者这周能动的:

  1. 给你手上正在做的功能量一个成功率。 拿最强的通用模型,别接你自己的提示词工程,跑 20 到 30 个真实用例,数它成功几次。落在 20% 到 60% 这个区间的,认真想想值不值得继续投;落在 0% 到 1% 的,再问一句「它 0% 是因为难,还是因为没人要」;
  2. 建一个 12 个月清单。 写下你认为未来 12 个月会变重要的事,不用多,5 到 10 条。写上日期,明年同一天回来给每条打分:真的重要 / 别人做了 / 没发生。这是给你自己的 taste 攒可结算的样本;
  3. 挑一件你重复做过五次以上的手工活,写成 skill。 Jeff 和 Sanjay 写的就是他们做性能优化的那套流程。你的可能是复现一个 bug、发一次版、review 一类 PR。判断标准很简单:如果你能对一个新同事口述这套流程,你就能写成 skill;
  4. 把《Performance Hints》读一遍,然后喂给你的 agent。 它主要讲单个二进制内的性能调优,明确不覆盖分布式系统和 ML 硬件,示例大多是 C++。读完你自己的性能直觉会长一截,塞给模型之后它在性能问题上的推理也会好一截。

写在最后

如果把这一小时压成三句话,我会留下:

  1. 别去做通用模型已经会做两成的事,去做它一点都做不了的事——但先确认那件事有人要。
  2. taste 不是天赋,是你结算过的判断的条数。今晚就开清单。
  3. agent 越强,把要什么写清楚这件事越值钱。

最后回到开头那件事。他在访谈里说的 2027 年预测,五天后变成了他自己的公司名。我的判断是:这跟巧合没什么关系。一个人真正相信的东西,你问他任何问题,他都会绕回去。所以听访谈的时候,值得多留意一句——他反复绕回的那件事是什么。

以上是我的读后感。这三条判断里,你最不认同哪一条🤔 也欢迎你来吐槽我,尤其是第二个前提那里我确实没底。

原视频:Jeff Dean: The 1% Rule for Building in AI,文字版在 ycrootaccess.com。本文引用的英文原句都来自这份文字版,中文是我自己的翻译。