跨国深谈← 返回←Addy Osmani：从造浏览器到对抗认知投降

Addy Osmani：从造浏览器到对抗认知投降

关联

人物 Addy Osmani

公司 Chrome DevTools

概念 智能体 · 认知投降 · 认知债务 · 循环工程 · 软件工厂 · Core Web Vitals · 互相放大 · 护栏

Addy Osmani 在爱尔兰农村长大，拨号上网时代网速慢到下载一首歌要等几小时，他十几岁时研究下载管理器的多线程分块下载原理，想：能不能把这套方法用在浏览网页上？于是他从零开始读 HTML、CSS、JavaScript 规范，自己写了一个浏览器。

最难的倒不是解析文档，而是开发者往浏览器里扔的各种不规范的代码——真正的浏览器对这些东西有极大的容错能力，他必须模仿这种行为。后来他还给这个浏览器加了 Flash 和 Applets 支持 。

这个项目拿了全国科学竞赛总冠军，引来了华尔街日报和 CNN 的采访 。但他清醒地认识到：能跑起来不等于理解了背后的每一层，这反而激发了他”剥洋葱”式的终身求知欲 。

Chrome DevTools：从 Firebug 的阴影到接近 IDE

2012 年加入 Chrome 团队时，前端调试的标配还是 Firefox 上的 Firebug，IE 几乎没有调试工具 。Chrome DevTools 的技术负责人 Pavel Feldman 带团队走了一条以开发者为中心、贴近生态系统的路线 。Addy 和 Paul Irish 等人作为”半路出家的构建者”，把一线摩擦反馈给 DevTools 团队——有时候不是工具不够好，而是底层缺少插装能力（instrumentation），工具根本做不出来 。

性能面板是 Addy 特别骄傲的部分：点一下录制、跟页面交互，就能拿到火焰图和极深的时间追踪 。但内存调试是至今没被很好解决的硬问题——他认为很少有开发者真正理解内存管理，这让内存问题的调试难上加难，而且这么多年进展不大 。

框架时代到来后，一个关键挑战是：页面用了大量库，调试时你只关心自己写的代码，不想被 React 库本身的问题淹没。团队通过 source maps（一种把编译后代码映射回源代码的技术）和”黑盒视图”解决这个问题——让你可以屏蔽掉第三方库，只看自己写的部分 。

移动端崛起后，他们又在 DevTools 里加了设备模式，可以快速预览不同视口尺寸下的效果 。后来 PWA 兴起，离线缓存、推送通知、后台同步这些能力都需要调试，团队建了应用面板来覆盖这些场景 。

至于”DevTools 是不是 IDE”这个问题，团队内部的共识是：不争这个标签，而是”在开发者所在的地方与他们相遇”——你用你的编辑器，DevTools 在浏览器里给你补齐调试能力 。Pavel 之后的下一任技术负责人 Yan Gao，带领团队进入了 AI 阶段：一方面用 LLM 帮开发者快速消化巨大的堆栈跟踪、定位修复点；另一方面让智能体能连接到 Chrome 和 DevTools，自动化调试流程 。

Core Web Vitals：把”感觉慢”变成一个数字

以前衡量网页性能的方式很模糊——“页面加载好了吗？""好了”是什么意思？

能看到内容？还是能点击？Chrome 团队觉得是时候给出一套更细致的指标了 。

LCP（最大内容绘制）对应的是”用户看到有用内容的时刻”——可能是首屏图片，也可能是文章正文 。INP（交互到下一次绘制，取代了早期的 FID）对应的是”点了按钮之后多久有反应”——Addy 举了电商场景：点”加入购物车”没反应，因为 JavaScript 还没加载完或者事件处理器没挂上，用户就会反复点，结果事件处理器终于挂上之后可能触发了两三次 。CLS（累积布局偏移）针对的是另一个痛点：你正在读文章，广告突然加载出来把内容推下去了 。

这些指标不是拍脑袋定的。团队做了大量实验，跟标准社区和开发者反复验证：这些数字真的跟你们认为的”页面价值”对齐吗？

在 Google 从 L4 到 L8

Addy 最初以 L4（中级软件工程师）加入 Google UK，做开发者关系工程师 。在 DevRel 路线上升到 L6（Staff 级）后成为管理者 。

大约五六年时，他发现自己骨子里还是个构建者，转回工程管理路线 。团队后来扩到 40 多人到 50 人，分布在全球各地 。

他管理哲学的核心是：把组织带到”近乎自运转”的状态——不需要你放手不管，而是建立足够的系统，让信息和阻塞点能快速浮到你面前，你做航向修正就好。这样你才能腾出手去思考下一阶段的问题 。

后来他从 L7 升到 L8（总监），这是 Google 第一个高管层级 。变化在于问责感大幅增加：你要每两周向上报告年度顶级目标的进展，确保数字朝正确方向走 。但不是完全放手——而是确保技术工作跟业务目标之间那条主线清晰可见 。

他观察到过去一两年有个有趣现象：随着模型和工具变好，很多总监、VP 甚至 SVP 级别的人开始亲自动手尝试构建东西，每周互相交流”周末做了什么”——这在以前是不发生的 。

认知投降与互相放大

Addy 提出两个概念。认知债务：越用 AI，你对问题的记忆和理解能力越被侵蚀。认知投降：盲目接受 AI 的输出作为自己的答案，批判性思维退场 。

一年前，智能体还会发”我在思考”的消息，你能跟上它的推理节奏。现在用 Claude Code 或 Codex，可能 20 到 30 个子智能体已经跑完了，你不可能逐个点开看 。他的应对策略是两步：第一，确保拿到最终决策摘要并通读——如果没有，就主动要求生成；第二，警惕模型因为上下文窗口用完而对决策过程”胡说八道” 。

更根本的解法他叫”互相放大”（mutual amplification）：让智能体记录每次会话中的决策、遇到的摩擦、处理问题的独特方式。你作为工程师保持好奇心去读这些东西——不是逐 token 跟踪，而是把握重要决策 。

循环工程与软件工厂

循环工程是”软件工厂”路线的一个环节。软件工厂的意思是：你不只是写 prompt 让模型生成代码，而是构建一个系统，能自动完成 prompt、生成、测试、验证 。这是软件抽象层的又一次上升 。

但 Addy 强调必须有护栏：哪些变更触及系统关键部分、需要人工审查，系统要能标记出来。如果让循环无限制地构建一切，不控制爆炸半径和质量，就是灾难配方 。而且软件不像汽车——造完就完了；软件发布到生产环境才是bug真正出现的时候，所以工厂必须连上生产环境的遥测数据、用户反馈，形成闭环 。

他自己的一个实际案例：有个应用允许用户提交 bug 报告，以前他手动逐个看、挑优先级。现在把 Google Analytics、托管商日志、用户报告等多维数据接进去，系统能综合判断——比如某个视图在印度用户中特别慢、而印度流量又很大——自动调整优先级并实施修复 。

工程师的 alpha 是什么

Ryan Dahl 说”人类写代码的时代结束了”，Addy 不否认写语法这件事在消失 。但他用”alpha”（优势）来定义工程师的核心价值：当前模型不擅长的事情就是你的 alpha，而且这个 alpha 会随着模型升级而衰减，所以你必须不断找到新的 alpha 。

他认为”品味”是当前最抗衰减的 alpha 之一：智能体能判断代码是否匹配规范，但没法判断一个东西是否”好”——好意味着用户体验出色、让人想回来用 。更深层的 alpha 是”问责”（accountability）：Chromium 代码库里每个关键目录都有 owner’s file，上面列着对那部分系统负责的人。他们不一定写了每一行代码（以后更多是智能体写的），但他们理解这个领域、决定什么能发布什么不能、什么该推迟 。

最后，他认为工程职业不会消亡，因为历史上每次自动化都消灭了一些工作又创造了新的工作；而且每当我们让创建软件变得更简单，软件的总量就指数级增长——构建者的总可触达市场正在扩张 。他对职业转型的建议是：不要只盯着工程这个狭隘视角，去培养产品感、技术布道能力、市场意识——当角色边界变得模糊时，跨界能力就是优势 。

本集带走

• 防认知投降的两步法：拿到智能体的决策摘要并通读；让智能体记录决策和摩擦，你保持好奇心去读，而不是逐 token 跟踪。
• 循环工程必须有护栏：让系统自动标记触及关键部分的变更、要求人工审查；不控制爆炸半径的自动化是灾难配方。
• 工程师的 alpha 在品味和问责：智能体能判断”对不对”，但判断不了”好不好”；代码可以由智能体写，但必须有人对每个模块理解、把关、负责。
• 连接多维信号做优先级：不要只靠单一反馈源，把遥测数据、用户报告、流量分析接在一起，让系统综合判断该修什么。
• 职业建议——跨界：不要只做工程师，去培养产品感、UX 感、布道能力，角色边界正在模糊。

我想说有时，我不知道这是否有争议，很少有开发者理解内存管理。
I would say sometimes, I don’t know if it’s controversial, that very few developers understand memory management.
—— Addy Osmani · [28:45]

人类惊人地简单。
Humans are shockingly simple.
—— Addy Osmani · [42:35]

所以你越多地使用 AI，它就有点像是对你拥有良好记忆力和理解你正在解决的问题的能力的一种侵蚀。
The more that you use AI, it’s sort of the erosion of your ability to have good memory and have good understanding of the problems that you’re working on.
—— Addy Osmani · [60:53]

现在如果你正在使用 Claude Code 或 Codex，很有可能已经启动了 20 或 30 个子智能体。
And now if you’re using Claude Code or Codex, it’s very possible that 20 or 30 sub-agents have fired.
—— Addy Osmani · [63:04]

但是如果只是让你的循环构建所有东西，而在爆炸半径周围没有任何护栏，在关于你如何看待质量的周围没有任何护栏，我认为这是灾难的配方。
But simply just having your loops build everything without having some guardrails around the blast radius, without having guardrails around how you think about quality, I think is a recipe for disaster.
—— Addy Osmani · [66:33]

智能体可以告诉你一件事看起来是否正确，它是否匹配规范。它不一定意味着它能告诉你什么是好的。
An agent can tell you if a thing looks correct, if it’s matching a spec. It doesn’t necessarily mean it can tell you what’s good.
—— Addy Osmani · [73:05]

你知道，每当我们让创建软件变得更容易时，我们就指数级地创造了更多的软件。
Every time that we’ve made it easier to create software, we’ve exponentially created more of it.
—— Addy Osmani · [75:53]

我们很可能会在接下来的工程职业生涯，以及产品和其他角色中看到这些职业生涯的解绑。
What we’re very likely to see happen next with engineering careers, as well as product and other roles, is the unbundling of these careers.
—— Addy Osmani · [88:08]