开场
那大概是人类历史上规模最大的重构任务。代码有两亿到两亿五千万行 C++，其中两亿五千万行是自有代码，不包括外部依赖。当时一个月里大概有一万名工程师在修改这套代码。
什么是可读性审查？我离开 Google 时，算是整个可读性项目的总负责人。这可能是科技行业规模最大的教育项目：任何时候都有数万人参与。
大部分计算机科学课程自 2000 年，甚至更早以来，都没有实质性变化。课程里的典型内容，正是上世纪 90 年代构建数据库或操作系统所需要的东西。
听起来不太妙，对吧？
对一个以创新自豪的领域来说，确实不妙。我推动的很多事情，都是希望我们跳出代码，把视野和能力层级大幅提升。计算机科学专业的招生人数会大幅下降，但软件工程项目会兴起，因为说实话，在 AI 时代仍然重要、还能让人找到工作的，是……
如果一位曾参与定义当今软件工程课程内容的工程师说，其中大部分都该推倒重来，会怎样？一位真正的软件工程师确实这么说。2023 年，Titus Winters 是 ACM 和 IEEE 本科计算机科学课程指导委员会里唯一一位仍在业界工作的软件工程师。此前，他在 Google 工作了十多年，是《Software Engineering at Google》的主要作者，也负责过公司的可读性项目。
今天我们会聊：Google 为什么大约在 2006 年设立测试管理机制——当时旗舰搜索产品因为持续回归问题，已经无法按固定节奏发布；如何衡量开发者生产力，以及为什么 AI 的价值没有体现在今天的指标里；Titus 会怎样改变计算机科学教育，包括为什么他希望学生按提示词和测试评分，而不是按代码评分。还有更多内容。如果你想了解 Google 从大规模工程中学到了什么，或 AI 时代的现代计算机科学教育应该是什么样，这期节目适合你。
本期由 turbopuffer 赞助。它是构建在对象存储之上的向量和全文搜索引擎，速度快、价格低，而且极易扩展。
开始之前，我想聊聊本季赞助商 Linear。直到最近，我还以为 Linear 只是帮助规划和组织工作的工具，但它远不止如此。许多团队用 Linear 从想法到 GitHub 合并，一路交付变更，全程不必离开这个工具。
我和 Linear 的工程师 Dima 坐下来，看看他们如何用 Linear 构建 Linear。这里有个真实问题：提交代码审查时，如果还有未发送的草稿评论，Linear 会提醒你，但不会告诉你草稿具体在哪里。一位客户提出了这个问题，Dima 决定修复它。
修复前，Dima 没有打开 IDE，而是在 Linear 里把问题描述给智能体。智能体完成修复、创建 PR，还附上 Storybook 截图，方便验证。截图上标出了那些草稿评论，因此你可以看到修复效果。PR 里还有 Vercel 预览，你可以在 Linear 里点一下打开预览，试用这项改动，我们看到它确实奏效了。
我最喜欢的是正在开发中的引导式审查。这是一种新的代码审查体验，重要内容会直接凸显出来。审查页面顶部有改动摘要和示意图，拉取请求则分成几个章节，逐步带你了解改了什么。这些区块用更容易理解和审查的方式突出重要改动。
Dima 做完这一切后，直接自行批准代码，并将它合并到 GitHub，全程没有离开 Linear。如果只记住一件事：Linear 已不只是规划工单、组织工作的地方，所有工作都在这里发生——创建问题、启动智能体、查看预览、审查，再合并到生产环境。Linear 是面向团队和 AI 智能体的产品开发系统，我很喜欢它的这种演进。去 linear.app/pragmatic 看看，还可以领取六个月试用。
Titus，欢迎来到节目。
非常感谢邀请我。
我特别期待这次对话。很高兴能当面聊。
开场
是啊，能来很开心。
你是怎么进入科技行业的？小时候就知道自己会做计算机相关的事吗？
我最早的记忆里，自己觉得将来会当科学家。不过三岁孩子理解的科学家，大概就是白大褂、试管之类的，我也说不清。我父亲很有远见地意识到计算机会很重要，尽管那完全不是他的行业。他做的是木工、布景设计一类的工作。所以家里一直有台电脑，通常是我们能想办法凑钱买得起的低端设备。
我记得真正开始接触编程大约是十一二岁。有一年情人节，他没有给大家买糖果，而是去了书店。我不记得我兄弟拿到了什么，但我得到一本《学习 QBasic》。从那以后我就一路走上编程这条路。接下来的五六年，我大概一直在编程，自学编程成了我的爱好。偶尔也会遇到一些同龄人，他们也对此有点兴趣。后来我们搬到拉斯维加斯，我进了一所设有计算机科学项目的磁校。
那所高中现在其实很有名，我当时完全不知道。我最初就是自学，在互联网出现之前，想学这些东西得费很大劲。但那本书确实把我带上了这条路。
高中毕业后，读大学学计算机似乎顺理成章。
对。我去了 Harvey Mudd，那是一所很棒的学校，兼有科技和博雅教育。它会教你怎么造武器，也会教你不要使用武器，大概就是这种风格。我在那里认识了妻子，她比我低几届，我不想搬走，因为她还在读书。所以我后来在加州大学河滨分校读了计算机科学教育硕士。
嗯。
我的研究生经历有点特别。我在河滨分校花了四年读计算机科学教育博士，研究应用人工智能、教育数据挖掘和计算机科学教育。我在一些最早的计算机科学教育研究会议上发表过论文。
我的导师是系主任。他通常不带研究生，研究方向也不是他的重点，但他一直担任系主任。他是个很有魅力、善于社交和处理事务的人，知道各种来龙去脉。所以我的研究生经历里，有不少时间是在了解事情如何发展到今天的，也会在课程缺人时去教课。
我们之后大概会反复聊到计算机科学教育。我们以前聊过，所以我知道一些背景。那接着说：你大学毕业，开始找工作……
进入 Google 工作
你当时在找工作。
对。
找到了什么机会？
一开始我加入了一个咨询团队。那时我们还要考虑夫妻两地的问题：我妻子在圣迭戈读研究生。我博士毕业后没有拿到教职，于是做起咨询。我所在的是一家小型初创咨询公司，大约三十到五十人。我主要是间接为 DirecTV 工作，做机顶盒的嵌入式系统。
四年后，我们都读完了研究生，也结束了那段阶段。我接受了 Google 面试，拿到了 offer。我们决定不去湾区，于是 Google 把我们安排到了纽约，我们从那时起就一直住在这里。
那时 Google 正在纽约开办公室？
办公室那时已经开了，而且规模不小。那是 2010 年，我想当时那里有几千人。
Google 1998 年成立，2004 年上市。我记得大约 2005 到 2010 年间，Google 开始真正成为全球知名品牌，大家都觉得“哇，Google 是理想工作地点”。你申请的时候，它其实是最难进的公司之一，有点像今天的 Anthropic、去年的 OpenAI，或 2010 年代中期的 Uber。
是的。
你觉得面试体验怎么样？拿到 offer 容易吗？当时竞争一定很激烈。
确实很激烈。我拿到 offer 时有点惊讶，因为我觉得自己发挥得不怎么样。我记得有个挺傻的原因：我不想花掉很多宝贵的假期，于是面试当天早上才从圣迭戈飞过去，而不是……
他们其实会帮你付酒店之类的费用。
对，我知道。我就是不想……我也说不清。我是个容易焦虑的人，喜欢自己的习惯和日常安排。各位，早上五点起床去参加一场重要面试可不是好主意，给你们个小建议。
有几件事我还记得。有一轮面试题相对简单，像是时钟计算。题目具体好像是火星车上的摄像头角度之类的。有一刻我想：“我很累，脑子又被面试搞得一团糟，这不过是基础数学。先写个输入输出正确的函数；如果我今天早上没这么笨，它就能跑。”我就照这个思路做了。我觉得面试官反而挺喜欢这种处理方式（笑），像是在说：“这部分不是重点，我们直接聊聊吧。”后来他们还是给了我 offer，我就搬到了纽约。
你开始工作了。
嗯，没错。
你加入 Google 后做的是什么？
在 Google 找到自己的方向
刚加入时，我很快就发现，Google 给新员工安排岗位的方式未必特别理想。那段入职经历有点磕绊。我的兴趣在开发者效率、问题求解；我有网络方面的背景，也做过 API 设计之类的事。他们听说我懂网络，就把我分到一个监测 Google 网络边缘流量及其流向的团队。
实际上，那是一个数据库问题，只是所有数据的主题都是网络。我当时想：“我对数据库一窍不通，那从来不是我的方向。”所以岗位不太合适。入职大约两个月后……
我想先稍微反驳一下（笑）。你加入的是 Google，之前上过大学，也有四五年工作经验。进了一家热门公司，对方告诉你“去做 X”，你却想：“我不太……”你难道不想深入了解，看看这件事为什么对业务重要吗？我是在质疑你。
不，尽管质疑，当然可以。我确实尽力从那个团队学习。不过有些事情上，人与人之间已经有点紧张了。
所以一开始就有这种感觉，觉得哪里不太对？
对，我就是觉得：“这不太合适。”后来有封邮件发给纽约的所有工程师，说他们考虑组建一个新团队，接手维护那些古老的 C++ 底层基础设施代码。那些代码是员工编号只有两位数的人写的；他们有更重要的事，不该一直处理这些组件的补丁请求，所以公司想找人来维护。我和另外九、十个人举了手，结果第二次会议时只有我一个人出现。于是我就加入了那个团队。
我明白了。补充一点背景很重要，免得大家听到“我加入这个团队”就以为你不愿意做事。当时 Google 正快速增长，不断成立新团队，换团队也很正常。你是在寻找更符合自己优势的方向；你先尽力做好原来的工作，看到更合适的机会后就去争取。对你来说，就是 C++ 底层工作。
对。我以前在 DirecTV 做咨询时，写过一些 API，比如 UPnP，也就是通用即插即用，做本地网络上的 RPC（远程过程调用）之类的东西。
当时大家每次实现一个客户端调用，都得手动拼出请求所需的 XML 结构。我觉得完全可以做得更好。我设计那个 API 的方式可能有点自作聪明，但这正是我喜欢做的事。
这个团队最初是自发形成的吗？比如 Google 到处都有 C++ 代码，大家先在业余时间聚在一起看看能做什么？还是某位经理已经打算正式组建一个全职团队？
我想那是 Google 开始认真规定员工必须归属具体团队、并限制团队编制之前的最后一年。当时这方面有点混乱，也比较松散。当然我也可能记错了，因为那时我刚入职不久，不太了解内部编制是怎么运作的。
在 Google 找到自己的方向
我很快就转过去了。天哪，那个地方简直太适合我了。
那你说说，为什么适合？具体做什么工作？听你说要接手 Google 员工以前写的各种 C++ 代码，这对我这种工程师来说听起来像地狱：要理解某位可能已经离职的工程师写的东西，而其他团队还在依赖它。感觉怎么做都不讨好：你接手后改坏了，别人会怪你；做得很好，大家可能也不会注意，因为它原本就一直正常，现在仍然正常。
幸运的是，在这件事发生前几年，大家已经建立起相当可靠的安全网，降低了改动时的恐惧。具体来说，Google 已经经历了“是的，你必须写测试”这个阶段。
Google 为什么强制要求测试
2010 年时，整个行业还没有普遍把写测试当成理所当然的事。
对。不过故事得从 2006、2007 年说起。那时搜索产品已经无法按稳定节奏发布了。原本想每月发布一次，结果可能只能做到每季度一次。
所以 Google 对测试和质量的执着，就是从这儿来的？核心赚钱产品在 2006 年前后都被发布问题卡住了，真让人惊讶。
大约在 2006 年，你做的几乎任何事，都可能牵连到前端、搜索之类的东西。整个架构、系统隔离，以及多应用、多产品的格局都还不完善。你改 Gmail，仍然可能等于改了搜索。
所以所有事情都被拖住了。发布工程师们联合起来，直接规定：“没有测试，就不准合并这项改动。没有例外。我们不在乎副总裁怎么说，也不在乎这个功能多重要。没有测试就不行，我们会把它回滚。”
只要划下这条底线，即使有人觉得“我很聪明，凭什么要我写测试，这种事低我一等”，也得遵守。
这样一来，接手维护或修改 C++ 库时，就有测试让你更有把握：重构后测试都通过了，东西就能正常工作；或者测试会暴露出原来覆盖率不足。把覆盖不足暴露出来也有好处。今天出个故障没关系，明天或一年后流量可能会翻倍，早点发现问题才有价值。
没错。我有个很坚定的信念：如果你因为害怕而不敢改一个东西，那就必须着手解决这个问题。恐惧不能成为工程工作的基础。我想这句话就在《Software Engineering at Google》开头两三页里。我十年来一直在说：如果出现任何有价值的改动，你都能安全地完成它，那么你的代码库才是可持续的。
你当然可以选择不做某项改动，可能是技术债、产品优先级不同，或别的原因。但如果你根本无法应对变化，那就是在押注：这项变化不会重要，也不会关键。可我得告诉大家，过去几年安全领域的情况已经变得非常糟糕。没有什么是不会变化的。能够灵活改变，具有巨大的战略优势。
新工程师为什么害怕犯错
我可以这样理解吗：无论加入初创公司还是大公司，刚进团队、看代码库的头几周或头几个月，我都可能害怕提交改动，担心把东西弄坏、影响线上环境。这可能说明我在维护一个工程质量不好的系统。
可能是系统设计得不好，也可能是入职引导和导师指导没有做好。
所以问题可能出在其中一方。
是其中之一。我觉得这也和教育有关。本科教育以及我们描绘这份工作的方式，往往暗示有一个正确答案，有对错之分，而不是权衡取舍。别人每次看你的成果，都像是在给你打分。
尤其对刚毕业的人来说，很容易陷入恐惧：“我不知道自己做对了没有，也不知道这是不是你想要的答案。”他们被灌输了错误的观念，以为总有一个唯一正确答案；但实际情况当然是权衡，在设计空间里选择某个位置。
我想你也在说，新毕业生习惯了做一件很重要的事——通常是课程作业或考试——然后得到反馈，有分数、等级，至少也会知道通过还是不通过。我记得自己去第一份工作时，感觉特别奇怪：加入公司，做完一个项目，然后什么反馈都没有（笑）。接着我又做了一件事，还是没什么反馈。后来我和公司 CEO 一对一，我还以为自己要被开除了，因为我知道自己有时中午会摸鱼——其实是因为工作做完了。现在回头看，我效率挺高的，只是做完事后就在网上闲逛。我告诉他们“我已经准备好了”，还以为会被批评。结果 CEO 反而说：“做得太棒了！你上手这么快，我们对你非常满意。”我当时就是没反应过来，之前那些年我一直习惯直接收到反馈。
对。还有一点：本科生的代码通常只有在被评分、被评判时，才会有人来看。等你成为更有经验的工程师，你会定期主动征求反馈，但那只是确认方向对不对、方案是否说得通。你得到的非评判式反馈越多，工作效率就越高。可我们却让所有应届生和初级工程师养成了完全相反的本能。
回到 Google，当时是什么情况……
Abseil：Google 的 C++ 基础库
Abseil？应该怎么正确发音？
Abseil。
Abseil。它大约十年前开始出现，在 Google 最初转向云计算之后不久。当时有人提出：“我们有非常出色的开发者工具，也有很强的生产环境技术，也许开发者工具也可以对外开放。”与此同时，Google 正在逐步转为 Alphabet。于是有两个层面的问题：怎么让 Alphabet 旗下不同公司共享开发工具？又怎么在不再是一家单一公司的情况下，共享高价值的内部接口、API 和技术组件？
而且越来越不是一个单体代码仓库了。
对，越来越不是。于是有很多常规工作要做：怎样让开发工具支持多租户，不再完全绑定在 Google 自己的生态里？
这里的“多租户”在 Google 内部是什么意思？
当时指的是让 Alphabet 旗下其他公司也能使用，之后也许再扩展到云客户。
明白了。也就是说，理论上 Google 自己也可以使用它，类似这种方式。
多租户后来不再是最热门的议题，一两年后他们就基本放弃了这个想法。不过，那些底层组件怎么办？如果想把单体仓库里内部编写的东西分享出去，怎样才能有效地做到这一点？
Abseil 基本上就是一层通用的 C++ 编程习惯用法，也就是 Google 所有代码共同使用的语言。我们想把它开源，为整个 Google 技术栈提供共同基础。与此同时，大家也问：这些习惯用法里有些很糟糕，技术债也不少；在把它们永久固定下来之前，要不要先整理一下？答案是要，这得感谢当时做出这个决定的人。Abseil 开源项目，就是清理之后内容的公开版本。我会坚定地为其中大部分工作辩护：那大概是人类历史上规模最大的重构任务。
Google 的大规模 C++ 重构
不会吧？
是啊，我们有十到十二个人全职投入，使用当时别人还不理解的世界级工具，清理代码，并确保对外使用的惯用写法和 Google 内部的写法兼容。
你说的清理，显然是要动到 Google 搜索这类全球最高使用量服务中间的工具和组件。
对。
还有 Gmail、Maps，等等。
全都包括。
一旦弄坏了什么，某个服务可能就会中断。
当时我记得有两亿或两亿五千万行 C++ 代码。
两亿五千万行 C++？
是第一方代码，不包括外部依赖。我想那是当时公开的数据。那时大概有一万名工程师，每个月都会修改这套代码。我们开玩笑说，自己的工作就像 Google 发明了一种新的摩天大楼地基技术，要在不关闭大楼、不阻断交通的情况下，替帝国大厦更换地基，还发现地下室有核废料。没关系，伙计们，我们能搞定（笑）。那是一个非常棒的团队。
我想用今天的情况来说明两亿五千万行代码有多大。现在 AI 一小时能生成几万行代码，想要的话，甚至可以做到几百万行，一个智能体就能写出来。但在 AI 之前，Uber 的 iOS 和 Android 应用各自大约有一百万行代码，每个平台都是两百名工程师花了好几年写出来的。Anthropic 的 Bun 运行时最近重写了大约五十万或九十万行代码，具体数字我记不清了，那是一个小团队做的。AI 之前，超过三百万行代码的项目已经很少见，通常需要数百名工程师写上好几年。所以你说两亿五千万行，比我听过的代码库规模大约多一百倍。而且这些显然都是生产代码，不是随手搭的脚手架。你说的第一方代码，也不是把开源组件算进来凑数，对吧？
对，全都是 Google 员工写的。我们因此对事情如何运作有一些了解。
所以这很可能是当时人类历史上规模最大的重构？
我无法证明，但要是还有更大的，我会很惊讶。
你们十到十二个人面对这么庞大、几乎看不到边的任务，怎么着手？怎么拆分、规划和加速？纯手工显然做不完。
能实现这一切的原因之一，来自我之前在 C++ 底层基础设施团队的经历。我们想，如果能掌握 Google 所有代码依赖的底层接口和基础组件——比数据库还底层，比如缓存、容器、字符串处理、命令行标记——那改进它们就很有价值。但有五万处调用点，或者需要十万处修改才能更换 API，该怎么做？
幸运的是，我和编译器团队的人关系不错，后来组织架构上也算同一条线，尤其是 Clang、LLVM 团队。他们开始做 AST 转换。
Google 的大规模 C++ 重构
AST 是抽象语法树。也就是先取得语法解析树。你知道，这是 Google，会用 MapReduce。所以你可以对代码库运行 MapReduce：mapper 解析所有 C++ 编译单元，也就是所有构建目标，并生成解析树。接着可以匹配树里的特定结构——不是搜索文本，而是确认你确实在某个特定上下文里调用了某个函数——然后据此应用代码重写。
于是我们用编译器辅助的半自动重构来生成所有文本改动。刚开始有个特别难的问题：我们能生成代码改动，却没办法把空白字符放到正确位置。
不会吧？
真的。clang-format 的出现，就是因为我希望有这个工具。它现在是许多 C++ 及类似语言的自动格式化工具。但当时我真的没法完成重构，除非有人设法为 C++ 拼出一个自动处理空白的工具。
你可以生成一个很大的改动，但它大到无法一次放进代码库。任何代码库都有自然的日常变更量；如果你要改一万、两万个文件，很可能还没等你测完、重新同步，就已经有其他改动造成不同步了。
对，别人同时改了东西。
没错，会有合并冲突和并行改动。你不能要求一万多人的公司说：“所有人都停一小时，别碰代码库，我要做个改动。”这种办法根本无法扩展。
技术上，我们把重构拆开，让旧 API 和新 API 可以同时存在，只是拼写不同。然后再并行处理，按目录结构划分：“我把这一批更新发给你，你负责那一批。”这样推进。等所有地方都改好了，就要赶紧确认没人再复制粘贴旧写法。然后删除旧实现，让新版本成为默认，继续做别的。这样做几百次，代码库就会好很多。
而与此同时，其他工程师照常工作，使用这些东西，甚至不知道你们在背后做这些事，也不用他们改变工作方式。
正是如此。我们在某些改动上得到了很棒的反馈。一开始大家会问：“你们在干什么？为什么改我的代码？我不接受。”但很快就变成：“这太好了！我离开一会儿，回来代码就变好了。”他们不用再查“做这个该采用哪种写法”，因为如果原来的写法错了，你们早就清理掉了。
有人持续维护、整理代码库后，复制粘贴就可以成为正确做法：找到别人做过的例子，复制过来继续工作。你有证据说明它大概是合理的，因为如果错了，我们早就修好了。
很有意思。今天做大型重构，大家显然会想到 AI。很多公司已经用 AI 做出了很好的成果。你们当时面对的挑战，是代码库太庞大，手工重写根本做不完……
用 AI 重写代码
纯手工确实不可行。但你们在 Google 想出了非常巧妙的半自动方案，依赖深入的语言解析，找出新方法，在形式上证明、至少也能验证改动正确。大多数团队既没有资源，也未必有专业能力做到这一点。现在大家都能让 AI“去做这个、跑测试”。但用 AI 重写代码仍然感觉很粗糙，比你们当年那种更具确定性的做法差远了。
是的。
你们当年用的技术以后会普及吗？还是大家就接受 AI 有时做对、有时做错？
如果你留意的话，这类工具已经有了。特别是在 Java 领域，像 OpenRewrite 这样的工具，你每次运行时提供少量配置，说明要在 Java 代码里找什么模式，以及改写后应该是什么样。它就会扫描所有 Java 源文件并批量更新。
事实证明，AI 很擅长生成 OpenRewrite 配方。这种方式消耗的 token 少得多，准确度更高、速度更快，而且可以审计。这是明显更好的模式。我记得 Netflix 和 Uber 都有相关演讲，也可能我记错了；大家似乎都得出了相同结论：你需要一个确定性工具，明确声明改写意图。可以让 AI 写个小技能，告诉它如何为这些工具创建配置，然后就交给工具处理。在 C++ 领域，我有几位好朋友正在做一家初创公司，叫 Brontosaurus，专门做这种高层次、声明式的改写模式，对 C++ 很有用。
我喜欢让 AI 帮忙生成确定性的软件工具和转换规则这个思路。
对。Kelsey Hightower 最近有个很棒的演讲，讲“零 token 架构”。他的核心观点是——我觉得大家都在得出相同结论——不要让 AI 永远不断地推理，而是让 AI 生成真正执行工作的确定性工具；对于无法解决的问题部分，或决定何时调用工具这类事情，再让 AI 补上。如果整个架构一直在消耗 token，大概还有更便宜、更有效的做法。
我最近听一位工程主管说，他们在用 AI 代码审查工具，效果不错，但又贵又慢。
对。
这位主管就想，能不能告诉 AI：“隔一段时间做一次全面代码审查；但每次发现问题，就生成一条 lint 规则。”
太好了。
这样既便宜又可重复，也不用每次花三十分钟；而且 AI 审查本身是不确定的，下次未必还能发现同一个问题，这让人很烦。现在他们偶尔仍会跑这些审查，但每次发现问题，就启动几个推理模型智能体，问：“能不能改进我们的确定性 lint 检查？”这个想法来自一位听说过 Uber 的工程师。我记得他听我讲过刚加入 Uber 时，第一周几乎没法提交代码，因为 lint 一直拒绝通过。那是因为 Uber 的工程文化里……
对。
用 AI 重写代码
在 AI 之前，Uber 遇到什么问题就加一条 lint 规则。架构约束全都写进 lint 规则里。比如不能以错误方式继承：lint 会直接拦下你，说“不能从这个 builder 或 composer 之类的类型继承”，具体叫什么我也不记得了。
对。我觉得这完全合理：从艰难教训中学一次，把规则确定下来，用确定性的方式一致、公平地执行，然后让代码审查把注意力放在真正需要人来做的事情上。那时如此，现在也是如此。不是所有代码都值得人工审查，但确实有一些地方，投入人类注意力很值得。大家当年本应更多投入 lint 和静态分析，现在仍然应该这么做。
Titus 刚才说得很清楚：艰难的教训只学一次，然后写成规则，把人的注意力留给真正需要判断的事情。这也是你希望如何设置 AI 智能体权限的思路。接下来是本季赞助商 WorkOS。
WorkOS 为 B2B 和 AI 原生公司提供身份验证基础设施，帮助它们向企业客户销售产品，支持 SSO、SCIM、RBA，以及现在面向 AI 智能体的授权。WorkOS Airlock 是基于意图的访问控制。大多数访问控制只问你是谁；Airlock 还会在智能体试图执行操作的那一刻，检查它想做什么。
明确的规则，例如“智能体不得删除云资源”，会以普通代码运行。比较模糊的判断，则由 AI 在运行时评估策略。你可以用普通英文写策略，Cloth 也能从 Notion 或 Jira 里找出你已有的策略并导入。无论智能体是 Cloth 还是 Devin，都通过一个统一访问点连接，你的 MCP 服务器也置于这个访问点之后。Airlock 在现有权限体系上增加一层控制，因此智能体永远不会获得超过调用者本人的权限。遇到有风险的操作时，Airlock 可以升级给人类审批，比如通过 Slack 审批。这和 Titus 讲的理念一样：规则写一次，只把人的注意力用在确实需要的判断上。可以前往 workos.com/airlock 申请提前体验。
我还想介绍我们的冠名赞助商 turbopuffer。它是构建在对象存储之上的超快、超便宜、可大规模扩展的搜索引擎。你多久能看到一次重写项目实时推进？通过 TiKV 团队，我们终于能看到了。他们正在从第一性原理彻底重新设计存储架构，让搜索在大规模环境下更快、更便宜、更可靠。
新系统叫 Turbo Buffer V3，目前还没有投入生产，但已经通过持续集成测试。9 月开始重写时，它的性能远远不如现在的生产版本 V2。TiKV 团队一直在优化查询计划，直到速度达到或超过 V2；整个过程都会公开，直到 V3 上线。很酷的是，这个新系统起初在大多数指标上慢十到一百倍，如今在冷向量搜索、按“相似度”排序以及混合搜索等方面，已经快了好几倍。
V3 在全文搜索等方面仍然较慢，但现在只慢一到两倍，而性能优化刚开始时曾慢一百倍。TiKV 团队还在开发日志里详细分享优化过程，例如分组计数聚合、压缩列式编码、批量评分等。眼下很多提升是基础工作，接下来几周团队还会展示一些很酷的系统工程进展。
不过，为什么要整个重写？因为搜索正在变化，Turbo Buffer 也在变化。TiKV 起初是向量数据库，但如今已经演进为高性能搜索数据库。V3 去掉了向量主索引，所有索引都会共用同一套列式存储系统。每条查询都会在向量化查询引擎上执行。这在搜索数据库里并不常见，但会带来极快的速度，让数据库整体表现都很快。Turbo Buffer 团队正在记录这段旅程，可以在 turbobuffer.com/v3 跟进。
用 AI 重写代码
看着它一点点构建起来很有意思。说到艰难教训和把经验记录下来，我们能聊聊你很有名的那本《Software Engineering at Google》吗？这本书最初是怎么构思出来的？你们是怎样把它做出来的？你的动机是什么？
《Software Engineering at Google》这本书
这本书的想法，部分来自当时那波“也许我们要把开发者工具发布出去”的讨论。我们得解释 Google 的开发工具为什么是现在这个样子，否则就像外星人突然降临，递给你一个完全不符合你认知的东西。
我们之所以有点自信，觉得能接下这种任务，是因为此前一直在各处做大规模重构。只要碰到工程师为解决问题想出的各种巧妙办法，我们这群怪人就会见识到很多情况，然后说：“哦，我明白你为什么觉得这是个好主意，但别这么做。”这种见识，我们比行业里大多数人都多。
你们长期在大规模系统里工作，简直是行业里身经百战的人。
但那不是生产环境里的战斗经验，而是测试和本地代码设计方面的经验。行业里其他人有很多生产环境经验，我的工作则到代码合并为止。我比多数人更了解开发、API 设计、测试，以及如何让代码库本身持续可用。但从这个意义上讲，我也算个局外人。
有意思的是，这本书非常详尽地讲了代码怎样进入生产环境，却不涉及运维部分。这大概也和书的来历有关。
这可不是一本历史书（笑）。
要把运维也写进去，书可能就得长一倍。你是怎么组织这本书的？有些章节由你写，Google 里其他人也写了不同章节。
它很大程度上延续了 SRE 系列图书的做法：请某个主题的专家，或最了解该主题的人，贡献有用的内容。封面上有三位作者：我、Hiram Wright 和 Tom Limoncelli。Hiram 和我负责技术领导；Tom 当然也懂技术，多年来一直是我们的技术写作伙伴。
他负责了很多编辑、结构和组织方面的工作。Hiram 和我则一直搭档：Hiram 生成了数百万处代码修改，再交给我审查；我有权限审查代码库里几乎所有内容。大家都把我们当成那两个负责清理一切的人。所以我们有这样的经验，也由我们带头。接下来的关键是找到真正懂行的人来写高质量内容。有些章节一开始就很好，有些则经历了好几轮修改。
整个项目差不多花了两年，当然不是全职，大部分时间我们投入的精力大概只有四分之一到一半。我们把太多人的太多文字都汇集到了一起。直到看到印刷版，我才意识到书写得有多长。我当时想：“哇，这也太厚了。”
即使是今天，我仍然会推荐这本书，因为它能很好地说明当时 Google 是如何运作的。公司会不断演进，但它描述了一家公司如何从零开始构建重要的生产系统，其中有不少做法可能不容易理解。书里讲到单体仓库、严格的代码审查流程，以及 Google 的可读性流程。我们可以聊聊这个。就我所知，Google 过去的代码审查不只是由了解某个系统的工程师审查并批准，还另有可读性审查。这是什么？
《Software Engineering at Google》这本书
可读性审查是什么？
Google 的可读性审查
对于任何要提交的改动，作者或审查者中至少有一人必须有两种不同的权限。第一种是代码所有权：审查者必须列在获准修改这些文件的人名单里。第二种是经过认证，表明我们相信你知道如何用相应语言，在这个代码库里写出符合惯例的代码。
这样做是为了尽量保持一致，形成共通模式，避免每个人都重新发明轮子，因为一致性具有战略价值。可读性流程要求有人取得相应认证。那怎么认证呢？
最初是员工编号第三号的 Craig 亲自和每位新员工坐下来，带他们走完第一次改动。后来规模扩大不了，于是他们找了很多人来代替 Craig，带你完成第一次真正重要的改动。
随着时间推移，大多数改动已经不是从头写一个新组件，而是在现有产品里做些小调整、添加功能等等。要找到一个足够有分量、能一次证明你什么都懂的改动变得很难，整个过程也更像是某种入门仪式。后来我想是 Java 团队先开始，把一次性的考核明确转变成导师计划。
你正常做自己的工作，团队批准之后，我们会从 Java 导师池里轮流分配一位导师，看看有没有值得实质评论的地方，从而提升代码质量，并确保它符合其他代码的规范。你会发现，如果你所在的团队本来标准就很高，那可评论的内容就很少，你大概很快就能通过认证。
对。
如果你所在团队的标准不高，而你又选择不吸取任何经验，那你可能要很久才能通过，甚至根本通不过。整个流程逐渐发展成这样，我们又把导师制推广到其他所有需要可读性认证的语言。多年来这一直是常态；不过我至少有几年没再确认现状了。
有意思。在我看来，这让代码审查变成了深入学习编程语言的教育过程。这是有意设计的，还是意外结果？
我认为绝对是有意的，至少在我能影响的部分肯定是。差不多三年前我离开 Google 时，我算是整个可读性项目的总负责人。我会说，这可能是科技行业、甚至全世界规模最大的教育项目，因为任何时候都有数万人参与。
你加入 Google 后就自然参与了，没有可选项，对吧？不是自愿参加的。
对。有些人对此非常不满。
不过目标也不只是“第一步，你得处理可读性专家给你的意见”。第二步，如果你有自尊，可能会想少收到一些意见，因为一直被指出问题挺尴尬。第三步，你已经一个意见都收不到了，便会想自己也成为可读性专家。第四步，你开始给别人反馈。通过这些反馈，你也许会认识人，甚至建立导师关系或友谊。
是的。你会看到代码库的其他部分，了解其他人在做什么，知道别的技术项目。它是个非常庞大、隐蔽但影响深远的信息共享项目。
Google 的可读性审查
你在书里写到了团队的重要性，我想引用一下……
为什么团队依然重要
书里说，在编程领域，孤立的个人工匠极其罕见。即便有这样的人，也不会凭一己之力创造超人般的成就；成果总是始于灵感火花，随后靠一支英勇的团队共同努力。优秀团队善用明星成员的才华，但整体永远大于部分之和。只是打造一支明星团队极其困难。
对。这章我好像没写。
但你是这本书的合著者。我想结合 AI 来聊聊这段话。现在越来越多人说，以前我们谈“十倍工程师”，大概一直到 2023 年都是如此……
对。
但现在我开始听到“百倍工程师”的说法：一个能力出色的工程师，能非常熟练地使用 AI。我们也听说有人独自带着一堆 AI 智能体，做出了英雄式的成果。所以我想问，随着 AI 工具越来越多，团队的概念还成立吗？打造出色团队这件事呢？
不管你在 AI 信仰光谱上的什么位置，团队仍然至关重要。如果你认为智能体是唯一的发展方向，那我们仍然要管理这支智能体团队。我听到越来越多人指出，眼下的问题是：我们希望每位工程师都变成一支智能体团队的工程经理，可大家没有相应训练、技能或背景。我们让他们做一件事，却没有给他们方法框架或指导。
另一种看法是把 AI 和智能体当成你的工具、你的 IDE，但你仍然要和身边的人类团队一起工作，这依然是团队协作。你和智能体之间的社交动态当然会不同。我冒昧说一句，智能体没有感情。
它们肯定没有。
对，希望如此。先暂且这么说。不过，清楚地理解和沟通，能够把想法写下来、从脑子里拿出来，仍然非常重要。无论如何，团队始终是根本。软件工程就是团队运动，仅此而已。
还有个比较直观、甚至有点天真的证明方式：看看 Anthropic、OpenAI 这些领先 AI 实验室。我和那里的员工交流时，会看到杰出的人才以团队方式工作。比如 Claude Code 的创造者 Boris Cherny，他在外部成为了代表人物，做得非常好，让产品更有人情味——你会觉得这是一个人在做事，但 Boris 背后有整个团队。
是的。
我见过那支团队，可以看出他们合作默契、彼此信任。总有一天 Boris 会休假。
对。
但你不会察觉，因为工作照样推进。
对。
你说到关键词了：信任。
没错。心理安全是其中很重要的一部分。我认为 AI 实验室自然具备的另一点，其他行业还没有那么普遍，那就是边做边学。看看所有研究，例如 DORA 关于生产力、团队效能之类的研究，最终总会回到文化、心理安全，以及允许学习这件事。
为什么团队依然重要
也就是说，允许我承认自己不知道某件事，鼓励大家互相学习，也鼓励分享错误，这样团队只需要从错误中学一次。无论是把经验写进 lint 规则，还是 SRE 的无责复盘文化，科技行业里所有有效的结构和组织，根本上都在促进信息流动与学习。
我很喜欢科技行业心理学研究者 Cat Hicks 的观点。她的书《The Psychology of Software Teams》写得很棒。还有几位朋友正在编写《Platform Engineering at Google》，早期章节已经在 O'Reilly 上发布。我可能写了其中关于教育的一章。
所以这既出人意料，也一点都不意外（笑）。
对。教育是强大的根基：让同样的错误尽量少犯几次，把经验总结成规则，让人有空间承认自己不知道、继续成长。因为这不是只玩一轮的游戏，而是要重复进行的游戏。如果团队下次变得更强，长期表现就会更好。
我想回到心理安全。大约五到十年前，工程领导圈子里经常讨论它……
心理安全
当时大家普遍理解，一支优秀的团队应该让人感到安全。比如工程师犯错导致服务中断，确实是你提交的代码造成了故障，但我们应该做无责复盘，不要说“Gergely 提交了这段代码，是他造成了故障”，让人觉得更糟。我们应该讨论怎样从系统层面避免问题：为什么测试没触发？为什么一个刚加入团队的人提交的改动会立刻上线？是不是入职辅导本来可以帮上忙？你怎么定义心理安全，为什么它重要？尤其我们面对的是聪明、懂技术的工程师，心理安全真的那么重要吗？我们不是应该把自己的工作做好吗？我这是故意站在反方说，暂时把情绪放到一边。
对，我们当然应该把自己的工作做好。不过这个统计数据我很难精确溯源，但和 DORA 研究人员交流时，我最喜欢的一点是：根据团队在心理和文化问题上的得分，我们可以解释团队能否达成目标这一结果中 30% 的差异。也就是说，给团队做一份 15 道题的判断题或李克特量表，就能预测团队是否会完成目标的 30%。这简直不可思议，比其他任何信号都强。
你觉得大家都是工程师，做的只是计算机和技术，情绪不相干？那请找出任何一个同样强的成功预测指标。归根结底，这就是人的问题。
再回到这不是单轮游戏，而是重复进行的游戏。我经常引用 Fred Brooks 的《人月神话》。其中“外科手术团队”那章是我最不喜欢的章节，因为它假设我们只做一个项目：找最优秀的人来做，其他人给他造工具、写文档。这种模式等级森严，权力关系也很重。如果你只做一次任务，也许说得通。
但从博弈论角度看，我们面对的不是一次性的囚徒困境，而是重复囚徒困境，策略就不一样了。策略应该是：找一个能够在监督下完成任务的最初级成员，让他学习成长，同时交付不错的结果。更资深的人就可以去解决自己还不会、或其他人无法处理的问题。只有这样安排，才能让成长发生。
但要成长，人们必须愿意承认自己不知道某件事。这又直接回到心理安全和学习型文化。如果一种文化重视信息分享、学习和成长，你就会成功。
你提到 AI 实验室已经把这些视为理所当然。我想……
因为他们也不知道啊。
我来转述一下：AI 实验室有几件事在顺风顺水。首先，业务蓬勃发展，公司、收入、客户、融资和员工人数都在增长，团队一直扩张，处于高速增长期。Netflix 和 Uber 也曾高速增长，但这些实验室的速度更快，股权价值也在上涨。所以你不用太担心绩效评估，因为绩效评估通常关系到奖金多少；但在这种增长环境下，只要专注于帮助公司成功，无论头衔是什么，经济回报都能得到保障。
第二，因为他们在建设新技术，他们知道没人什么都懂，所以会直接说……
心理安全
“我不知道，我正在学习，这是我学到的东西。”这很自然。相比之下，在增长没这么快的公司，即便也在使用 AI，人们说“我不知道”的动力会弱一些，因为绩效评估快到了。你想显得最聪明，不想让人觉得你总是不懂。否则奖金可能更低，甚至会被放进绩效改进计划，因为公司每年可能要淘汰 6% 的人。
对。
你的目标突然变成“我只想保住工作”，而不是继续成长。
嗯。
你还会提防队友，因为出现内部竞争。你想把项目抓在自己手里。
是的。
这差异就很大。
非常大。如果你相信团队的成果决定个人成功，就更容易接受：不必非得由我来做那件耀眼的任务。有人完成它，团队就会成功，也许下次轮到我。如果团队退化为个人主义，你不相信身边的同事，即使肩并肩工作也互相提防、争夺关注和成绩，这就不是创新和成长的配方，而是停滞，结果只会很糟。
其中一个明显……
裁员与企业文化
有件显而易见的事会伤害心理安全，那就是裁员。根据你的观察，裁员会怎样改变软件工程师的工作状态、工作方式和思维？2022、2023 年我们都经历过一波裁员；现在公司又在裁员。当时的原因是利率、零利率时期过度招聘以及增长放缓。现在有些公司公开说是 AI 导致的，有些没说得那么明白，但我们后来发现，例如 Meta 曾经想缩小团队规模，因为他们认为 AI 会接手这些工作。
这会带来压力。我经历过周边团队被裁员，之后几周甚至几个月里，每次一对一会议都会从“你最近怎么样？”“你还好吗？”开始。大家得先互相提供大量情绪支持，才能重新开始工作，这对表现有很大的负面影响。
我很怀疑高管在核算裁员账目时，是否算进了那种巨大的生产力损失和时间成本：大家压力很大，花时间更新简历，担心自己是下一个；一对一会议变成了情绪辅导，而不是工作规划。这是巨大且隐形的成本，也会严重打击积极性。它会让人意识到：“这只是工作，不是生活方式的选择。如果我额外付出也不能更安全，那我为什么要这么做？”这会留下很多文化包袱。
我很喜欢 Adobe 的一点是，公司长期由同一位 CEO 领导；他最近刚卸任，现在有了继任者。那位 CEO 经历过大衰退时期的金融危机，也经历过当时的裁员。他看到裁员对士气和公司生产力造成多大伤害，于是认识到：“我们当时觉得从数字上算是合理的，但它伤害了公司的灵魂。这不是我们想成为的公司。”所以过去几年 Adobe 没有大规模裁员。随着业务优先级调整，个别团队会有局部变化，但没有那种席卷全公司的大规模裁员。
不过大多数大型科技公司都经历过，尤其是 2023 年。
是的。
说到 Adobe，你几年前加入了 Adobe。你在那里主要关注什么？
我是非常资深的个人贡献者，关注开发者体验。我常说这是一种礼貌性的说法：开发者体验其实就是生产力，只是我们足够谨慎，不会声称自己能测量生产力。
这和 McKinsey 不一样，我和 Ken 对他们的说法深有共鸣。
对，那太糟糕了。
我们会在节目说明里放链接。
我们关注的是需要怎样的工具、文化和其他条件，才能改善开发者的工作体验，让人更高效、更有生产力，因为大多数公司的最大支出就是工程师薪酬。
所以你今天一直在关注这个问题，也在 Adobe 和一定程度上的 Google 都做过相关工作。接下来……
衡量开发者生产力
你现在对开发者生产力了解多少？它和 AI、编程工具、产出、指标有什么关系？哪些东西可以测量、值得测量，哪些又很难弄清楚？
我们一直把“生产力很难测量，甚至不可能测量”当作公理，因为连单位是什么都不知道。我之前有个自认为挺聪明的想法——我说“自认为”，是因为我对这个形容词的用法有所保留（笑）。如果我们不知道单位，经济学里有先例：建立一个指数指标，把可能影响结果的各种因素都测出来，再想办法把它们汇总成一个篮子。这样就能得到一个没有单位、但能显示方向、也能随时间追踪的数字。
我的想法是，把所有正面或负面的信号都测出来，看看事情是否进展良好：发布次数、测试覆盖率、PR 数量，什么都算上，尽量广泛收集。最初的设计借鉴了“群体智慧”：一个人猜不出罐子里有多少颗糖，但找一百个人就能很接近答案。
我们可以做一系列“两者选哪个”的比较：你更希望每周多发布一次，还是多写 X 个测试？让有经验的工程师反复玩这个选择游戏，从而算出这些因素之间的线性权衡，搞清楚什么更重要。然后去掉一些重复指标——它们可能只是同一项统计的不同包装——找出非线性的因素，把所有东西汇总起来，形成一个生产力总指标。Adobe 正在做类似的事，而且比我最初的设想更聪明。之后就可以观察这个指标在某个人群中随时间上升或下降。
但我后来意识到，在 AI 热潮之后，这类指标无法涵盖所有变化。我最近发表了一篇《Develop, Deploy, Operate》论文，其中提到科技领域有四种影响。第一种是产品成功，这类事大家都会谈，而且其他人比我更擅长，所以不是我的工作。
比如人们是否购买或使用产品。
对，比如净推荐值、收入，等等。第二种是计算效率，例如 AWS 花了多少钱。
或者发货传感器之类的事，我对此很熟。
对。比如 Android 团队可以把应用下载包缩小一兆字节，这会影响很多指标。
是的。
这些都属于影响。第三种是工程生产力，也就是我们论文里称的工程产能。即使我们帮你提升 5% 的生产力或产能，你也不能把它换成其他账户里的钱；你只是拥有更多时间做更多工程工作。
或者留出余量去创新、遇到突发情况时应对，诸如此类。
但这不能直接折算成美元。第四种影响和 AI 有关……
衡量开发者生产力
第四种影响是改变游戏规则，也就是战略创新。研究能让原本不可能的事变成可能。
没错。
安全则能让极其糟糕的事情不可能发生。如果改变了我们所做事情的性质、成本结构等等，那就是换了一场游戏。我觉得 AI 带来的问题是，即使你有个聪明的指数指标，试图概括生产力全貌，如果你没有关注某项改动的价值是否发生了巨大变化，就永远无法从指标信号中捕捉到它。我们没有指标可以说明：“这种规模的改动，其价值已经变了。”
举例来说，我经常出入安全领域，也做很多底层 C++ 库工作。现在你可能只花几周，就能写出一个 JPEG 解析器。
对。
还可以带上你需要的各种附加功能。三年前，说出这种话还会显得不可思议。
所以你是说，现有衡量方式都捕捉不到重大创新的可能性、影响和工作量，而 AI 正在让这些事情发生。我也举个例子，你看是不是你说的这个意思。一位朋友是某家中型工程公司的 CTO，公司处在一个细分行业。他们一直看发布频率等常见指标，也会和工程团队交流，了解大家是否满意。现在他们也在采用 AI，发现员工效率更高。那位 CTO 私下告诉我：“我知道我们可能用一半的人做同样多的工作，这样就能实现现金流转正。”但士气也很重要。他喜欢这些员工，不确定自己想不想承担裁员带来的情绪负担。他们也看到有人上手快、有人慢，话题就暂时放下了。
几周后我又和他聊，他说：“你不会相信，我们可能就要实现现金流转正了。”我问：“怎么做到的？你们裁员了吗？”他说没有。一名工程师找他说：“我们给某个组件付授权费。你可以把它想成一个库，提供商是这个行业里的另一家公司；他们的软件里有一个高性能组件，是产品的核心功能。我们需要按收入分成，大概要把 5%、10% 或 15% 的收入付给他们，因为这东西太重要了。它是闭源授权组件，确实很关键。我们自己写至少要一个五到十人的团队花几年时间，而且不保证能成功，所以不值得。”
那位工程师接着问：“如果我们把规格交给 AI 呢？”他们有大量测试和测试框架，把它们交给 AI。AI 在没有领域经验的情况下，为他们写出了一个更快、更好的组件。起初他们考虑把它开源，但供应商告诉他们，这对供应商来说是笔大生意；他们愿意付钱让这家公司不要开源，而是把实现交给他们，他们可以重新授权。局面一下子就完全改变了。如果 CTO 当时选择裁员，那名工程师可能就被裁掉了，也没人会发现 AI 能彻底改变这场游戏。
AI 有时会让一些疯狂的事情成为可能。
正是如此。我觉得这能解释一个落差：我还没看到基于研究的数字显示，AI 之后生产力提升超过 20% 或 30%，但大家都在讲那些十倍体验。我完全不认为实际提升真有十倍，不过……
衡量开发者生产力
嗯。
怎样解释这个落差？我觉得关键就在这里：AI 的很多价值不在于更快地做同一件事，而在于完成更难、更有价值、过去你甚至不会考虑去做的事。如果你的生产力衡量方式，就像数工厂产出多少个标准零件，然后你开始生产镀金豪华版零件，那你根本无法衡量或追踪这些变化，因为我们没有记录组件或功能价值的指标。
这也符合我和资深工程师交流时听到的情况：代码量增加了 70%，故障增加了 30%，功能数量没变。我们不知道的是这些功能的价值有没有提升，因为这要怎么衡量呢？
AI 正在带来一个挑战……
重新思考计算机科学教育
AI 带来的一个挑战，是新毕业生进入就业市场。公司很愿意招聘会用 AI、具备品味和判断力的资深工程师。AI 实验室越来越常告诉我，他们会看重品味、判断力、主动性之类的特质。回到计算机科学教育：你怎么看今天的计算机科学教育？尤其产业正在变化，我们应该怎样教？又有哪些地方可能需要调整？
我先讲讲自己的资历，为这番话增加些分量。写完那本书后，我受邀参与 ACM、IEEE、AAAI 制定计算机科学本科课程要求的工作。专业学会要界定：“本科应该教这些东西。”我进入了指导委员会，是里面唯一一位仍在业界工作的工程师，其他人都是学者。我主要负责软件工程相关要求，因此我很清楚课程要求是什么，这些年来也一直在参与其中。
说得直白一点——我在 AI 出现前就做过相关主题的演讲——大部分计算机科学课程从 2000 年，甚至更早以来，都没有实质性变化。课程里常见的内容，正是上世纪 90 年代构建数据库或操作系统所需要的东西。
这听起来不太妙。
对一个以创新自豪的领域来说确实不妙。有很多课程内容，我真的想问：我们教它，是因为它相关且重要，还是因为它是传统？或者只是因为我们知道怎么教？计算机科学系的历史只有五六十年，最早的系也不过如此。这个领域还太年轻，不应该靠传统来决定课程。甚至在 AI 出现之前，我就觉得很多内容都该推倒重来，因为课程要求和教学内容大多是累积出来的：只往里面加东西，现有内容的深度只减少一丁点。
我觉得这行不通。AI 出现之前，我就希望学生花更多时间练习和操练，真正成为熟练的程序员、算法思考者，而不是对一百万个主题都只懂一点皮毛。
现在有了 AI，你可以让本科生把所有作业都交给 AI，而 AI 对这些程序和作业也能做得不错。因此我主张，我们需要跳出代码，大幅提升讨论层级。你需要会读代码、具备系统思维，从算法角度理解结构和执行；但没人需要亲手实现链表，我们可能甚至不该教链表。那样太慢了，内存本身就是慢速资源。我们越能把重点转向设计规范、精确描述预期行为……
重新思考计算机科学教育
……以及测试、验证、确认，确保 AI 确实完成了你要求的事情，就越能让这些课程与专业工作直接相关。关键问题是，这还算计算机科学吗？还是我们会看到计算机科学专业招生人数大幅下降，而软件工程项目兴起？说实话，在 AI 时代仍然重要、还能让人找到工作的，是团队合作、沟通、设计、规范编写、测试和验证。
这些都属于软件工程。
还包括构建生产级软件，尤其是在 AI 时代。
我之前和 Cockroach Labs 联合创始人 Peter Mattis 聊过。他告诉我，大学期间他还在课外做过一个项目。
嗯。
后来这给他带来了很多机会，他还做了 GTK+。我就想：这些东西都是他在计算机科学学位之外做的。既然我们都读过计算机科学，如果要设立软件工程学位，为什么不从第一天就开始做项目，尤其现在有 AI？学生入学之后，第一门课做一个软件，第二门课和团队一起做软件，第三门课扩展现有软件。我的计算机科学课程大多是理论，四年里最喜欢的课是唯一一门团队一起构建软件的课——四年就这么一门。
很常见。
我还额外选了一门课学 .NET。进入职场时，却感觉自己要从头开始。那时想到的很多东西，当年学校没教；现在可能会教，但缺少练习。我有理论，但绝对没有足够的实操次数。
我认为这也是白板编程面试的来源：公司怎么判断一个人做过足够多的练习？参加编程竞赛的学生就是一类信号，他们在任务上投入了足够时间。
那可能是当时比较常见的实操方式。
是，而且对没有软件工程经验、但喜欢编程的人开放。
对。
从这个角度看，采用编程竞赛风格的白板题是合理的，并不是因为我们真的需要有人再写一个广度优先搜索，或者反转链表之类的解法；而是因为这能间接说明你曾在一个环境里投入很多练习。一般学位课程里的实际编程时间其实很有限。你可以想想 Malcolm Gladwell 提到的“一万小时练习成就大师”——我想那是 Gladwell 说的。问题是，你从哪里得到这些时间？
重新思考计算机科学教育
……他们会版本控制，懂 Git、pull request、数据库、前端，也懂 Chrome 开发者工具。所以短短三个月里，他们就学到了不少实用技能；而读完四年计算机科学的人，未必掌握这些东西，结果很难说。
是啊，我算过，计算机科学学位的学习时数，大约相当于平均全职工作十五个月。这还包括所有理论内容，以及那些是否相关都值得怀疑的东西。学位课程的目标也是把毫无经验的人培养成可以进入行业或学术界工作的人。它和六个月训练营之间的差距其实不算太大，尤其训练营会集中讲马上用得上的内容；相比之下，另一种课程可能讲一些“也许能帮助你思考这些问题”的东西。说得不客气点，就是“我当学生时学这个挺有用”。
我还想提一些最成功的学校其实在美国以外。MIT、斯坦福等当然声誉很高，但加拿大滑铁卢大学让我很惊讶，很多硅谷公司都有不少滑铁卢毕业生。我在社交媒体上问过：“滑铁卢有什么特别？它在加拿大，为什么大家都从那里招聘？”结果发现，它有一个项目，计算机科学或软件工程课程我不确定，但关键是设有固定实习安排。学生毕业时，已经在不同公司完成四次实习。学校和公司有合作关系，实习单位常包括 Shopify、Meta 等。这样一来，工程师差不多已经在这些公司工作过四次、每次三个月，总计一年。
对，这就是它的价值。
正是。我不是说理论不重要，但从招聘经理的角度，我会选有这些经历的候选人：他们很快就能上手，熟悉不同环境，甚至第一天就能带来新想法。
我很羡慕这种模式。我觉得不只是滑铁卢，加拿大很多学校都这样。
滑铁卢只是一个例子。
是，不过加拿大不少计算机科学项目的实习和合作教育确实做得更好，因此学位可能要读五年。我认为这是更好的教育体验。有些经验无法放进软件工程课程要求，因为学术环境根本教不了；有些教训必须在真实工作中学会。虽然你举了做项目的例子，我也希望学生多做项目，但我担心很多学位只有一门项目课。你知道从来没有哪支团队是所有人背景都完全相同的，但课堂项目常给人错误印象，让人以为团队合作就是这个样子。即便如此，有一门总比没有好……
新毕业生应该学什么
……是啊。
我们只能从现有的教育体系出发，希望你这样的人和其他人能推动改变，或至少让它适应时代。
但 AI 已经到来。资深工程师现在会思考一个大问题：我们是在没有 AI 的时代学会构建软件的。很多人学过计算机科学，掌握了基础，也有很强的理论理解，尽管未必实际用到所有部分。对于即将进入职场的新毕业生来说，他们应该重点学习哪些基础？哪些事情可以直接交给 AI？“到底是问 AI，还是自己学基础”这个问题一直存在。
我觉得“学习基础”这个说法本身就很有争议，因为没人能就基础是什么达成共识。
这倒也是。
几个月前 Kent Beck 和我上次见面时说过类似的话：如今所有在职的人都成长于一个有操作手册的时代，至少理论上，我们知道正确的做法是什么。但现在已经没有操作手册了。所以我们都得适应不知道答案的状态，何况我们甚至不知道今天的基础是什么。
我认为初级工程师应该关注几件事。第一，要有足够的韧性，别只是把工单直接塞进 AI 提示词，再把结果提交上去。如果你只做这件事，写个很短的现成脚本就能取代你，这绝不是你留在团队里的可靠优势。
我觉得用 AI 提升自己、拓宽输入非常重要，但不要立刻让 AI 生成你所有的输出。一年前左右，我在一个智库听到一个很喜欢的比喻，叫“Andrew 的斧子”：如果我用斧子砍倒一棵树，我不会说是斧子砍倒了树，而是我砍倒的。即便我们偶尔把 AI 拟人化，它仍然只是工具。
IBM 1979 年的一份培训手册里有句话：计算机永远不会承担责任，因此计算机不应该做管理决策。AI 仍然不承担责任，AI 实验室也不会替我们承担这些工具造成错误的责任。因此，对于自己署名提交的每一个 PR，你都必须能够负责。这需要更严谨，不能走捷径；我认为这种关注细节的能力很难培养。
再说本科教育，很多教授告诉我一个令人担忧的现象：成绩在 B、B+ 以上的优秀学生，现在比过去表现得更好。
嗯。
因为他们不必依赖每周只有几个小时能找到、成绩只比自己高一两级的助教；他们有一个无限耐心、随时在线、读得很多、偶尔会产生幻觉的导师，随时能帮忙。他们总能让它解释、学习和解决问题。
而且他们有自主性，也有动力去用它。
对，他们也有元认知能力，不会只想着复制粘贴。最差的学生多少也变好了一些，因为他们以前什么都做不出来，现在至少能生成一些垃圾内容。
对，就是在不停地产出垃圾。
这确实更难识别，但我明白你的意思。中间那一大批学生却好像整体掉下去了，因为他们没有那种韧性。他们宁愿去参加派对、打电子游戏，也不想做作业……
新毕业生应该学什么
他们会说：“去参加派对、打电子游戏也比做作业强。”于是就想：“这次先这样吧”，逐渐养成习惯，恶性循环越来越严重。有不少不错学校的教授说，他们也不知道怎么办；可能 B 以下的多数学生根本不理解代码是怎么工作的，整个系统根本没有办法跟踪这些情况。
至少也没有提供反馈或提醒他们。
对。一开始很多讨论都在问，怎样阻止学生使用 AI 工具。我觉得这完全没道理，就像高阶语言和编译器出现时，人们说：“现在你就不学汇编了？”行业已经在用这些工具。
学生就业后，某些地方甚至会被要求更积极地用 AI。
一个应届生如果说自己从来没用过这些工具，肯定会让人觉得不对劲。你是不想在这个行业工作吗？大家怎么用这些工具早就是公开的秘密，到处都有人写博客。
我本月和一些学者在《ACM 通讯》共同发表了一篇文章。开头大意是：想象来到 2040 年，我们仍坚持把所有 AI 使用都视作作弊，但这一代学生从小就和 AI 一起长大，就像互联网原住民从小接触网络一样。如果我们还继续问传统问题，比如“找出这个字符串中的回文”或“计算这张图里的降雨量”，传统计算机科学学位还能教会他们什么吗？我觉得答案显然是否定的。
我们不能停在原地，还有很多事需要修正。应该推倒重来，做真正重要的事情，并弄清楚如何恰当地使用 AI。课程应该假设学生会用 AI，然后重新思考新的学习目标；同时，作业仍需有足够的挑战，让他们思考、学习不同内容，只是层次可能更高。这其实是本科教育、课程设计和评估的关键。
听起来，设计课程的教授、助教和其他人也得投入很多工作，因为没人已经掌握答案。要自己试验、先亲自用这些工具，然后设计新的作业：必须用 AI 才能解题，但 AI 本身还不够。之后怎样给学生反馈？可能还要投入更多时间，比如坐下来让学生解释自己的做法。
面试也在变。有一种看起来有效的方式是结对工作，无论线上还是面对面，允许使用 AI，但要求候选人解释自己在做什么、为什么这样做。这样你就不能把任务假装做完后交给朋友，或者直接让 Claude 全做。你得展示自己的认知能力。面试官可以不断把你推向不舒服的边界，判断你的专业水平，再继续深入追问。
对。本科阶段已经有一些口试和类似做法，但还有一个非常简单的办法：不要只给最终结果打分……
新毕业生应该学什么
……把重点放在过程上。即使不设计难得多的评估作业，也不要只给学生交上来的代码打分。应该看他们用了什么提示词才得到结果，也看他们写了什么测试，怎样确保程序真的按要求运行。
当你开始评估得出结果的过程，而不只是结果本身，这不仅适用于计算机科学，也适用于大多数其他学科。我们一直让学生“再写一篇《麦田里的守望者》论文”——我们不需要更多这本书的论文；或者“再写一个链表”——我们也不需要更多链表。过去我们把产出的作品当作代理指标，以为学生投入时间、经历挣扎、克服摩擦，就能证明他们学到了东西。也许更合适的办法，是直接寻找证据：你是否经历了困难，并从中学到了东西？把完整的过程和成果一起交上来。
Titus 理想中的软件工程课程
课程由委员会制定，这有它的道理。不过如果由 Titus 来开办一所软件工程学院，亲自设计本科三到四年的课程，会是什么样？我们的目标是培养出能进入软件公司就立刻上手的工程师，会用 AI 工具、会构建软件。你会怎么安排？
我想第一门课，也就是第一个学期，应该先不借助 AI。至少要让学生达到能读懂代码、大致知道发生了什么的程度，比如理解控制流。与此同时，我认为可以设计有充分框架和约束的 AI 教学工具：我们不会直接把答案给学生。如果评估的是完整的创作过程和成果，就不必担心学生去问 ChatGPT、直接拿到全部答案。
说实话，我不知道该怎么做。没人知道，现在没有现成的操作手册。
我还是想请你明确表达观点。
我有个想法：给所有学生开一门“计算机科学入门”，不论主修与否，讲程序和接口设计。具体来说，怎样描述程序的输入、输出、结构，以及接口？
例如，复选框和单选按钮有什么区别？什么时候用按钮，什么时候用其他 UI 控件？对于非 UI 的东西，命令行标记和位置参数该如何设计？组件之间怎样交互？即使学生只上过这门课，他们用 AI 写出来的那些“氛围编程”垃圾程序，也会有更连贯、合理的设计，更符合实际用途。
我住在纽约，公寓楼的洗衣房有个应用，界面用了菜单而不是按钮，设计语言完全不对，简直让人抓狂。先从这些基本的设计原则开始。然后逐步进入你刚才说的项目、团队合作等内容，让学生自己产生解决更大问题的动力。之后，当他们需要背景知识时，再讲“网页是怎样工作的”“Web 远程 API 的 RPC 调用如何运作”等内容。你无法把一个人还没意识到的问题的解决方案直接交给他。在他们真正尝试解决问题之前，我们讲的理论只是零散的学术知识，和实际情境没有联系。先让他们进入确实需要这些解决方案的情境，再提供相应背景。
我也特别希望增加项目课程，理由有两个。第一，我不希望作业只有一个正确答案，因为行业实际工作并非如此；研究工作大多也不是这样。第二，我希望把评价同伴的能力也纳入成绩。看他们的成果、代码，或两者，然后能说：“做得很好，你有没有考虑过另一种做法？”还要评估他们能不能不当讨厌鬼、好好给别人反馈，因为团队合作中的心理安全很重要。
这听起来工作量很大，但 AI 可以帮忙分析其中一部分，例如做情感分析……
Titus 理想中的软件工程课程
……“这句话是不是很没礼貌？”之类的分析。我觉得我们可以设计出更实用、更重视动手实践，也更有效的教育体系。但我担心，这最终会由软件工程系来做，而不是计算机科学系。
给想进入科技行业的人建议
最后，给现在的应届生和正在读计算机科学或软件工程的大学生一些建议吧。大家看到进入行业的竞争更激烈、工具也在变化。你会建议他们采取哪些策略、做哪些事，才能提高进入行业并做好的机会？
这话也许有风险，但我人生中大多数成功，都来自于没有去做所有人都在做的事。如果你只追逐热门话题和每个人都在追逐的新鲜事，要脱颖而出真的很难。
我觉得要忠于自己。找一件你真正感兴趣的事，投入时间去做你在乎的东西，尤其是周围人都不太做的、比较特别的事情。这样你就有独特的故事可以讲给面试官听，在鸡尾酒会上也会是个有意思的交谈对象，创业公司的创始人可能会想：“我愿意冒险招这个年轻人。”投入越多时间，你能带来的专业经验就越多，结果也会更好。
我担心，AI 辅助工程会降低大家对纯工程技能的重视。现在技术深度不用那么高，似乎也能完成很多工作。但要弥补这点，你就得更深入地理解自己所在的问题领域。我认为这可能会降低行业内的流动性。今后不只是“我是 C++ 工程师”或“我是后端工程师”，而可能是“我是嵌入式音频领域的工程师”。你必须深入理解这些问题领域，那才是你真正的优势。
作为结束，你推荐哪本书？当然，除了你那本很棒的书之外。
书籍推荐
我前面提过，这里还是推荐它：Cat Hicks 写的《The Psychology of Software Teams》。其中有几章，如果能直接下载到每位领导者的脑子里，我会非常高兴。书里“装在罐子里的大脑”这个比喻让人挥之不去。这本书真的很好。
Titus，非常感谢你参加这次对话。
非常感谢邀请我，聊得很开心。
很高兴终于能和 Titus 坐下来聊聊，这次对话没有让我失望。首先，我知道 Google 的代码库很大，但没想到竟有两亿五千万行 C++，而且全部是在 AI 出现之前写的，不是 AI 生成的冗长代码。作为比较，2016 年前后，Uber 的 iOS 和 Android 应用各自有一到两百万行代码，Uber 还把大量业务逻辑塞进了这些应用里。
Titus 和团队不用 AI 就清理这些基础代码的过程也很有启发。他们构建了确定性代码生成工具，解析代码、匹配模式，再生成改动。即使在今天，这种方式仍可能比直接让不确定性的 AI 重构代码库更加可靠，尽管实现高级解析逻辑显然更难。
我也很认同 Titus 对 AI 现阶段作用的看法。他提到一位资深工程师说：“代码量增加了 70%，但故障也增加了 30%，功能数量却没有变化。”这听起来不怎么样，那 AI 的价值在哪里？Titus 认为，价值不是更快地做过去做的同一件事，而是变得更有雄心，去做以前根本不会尝试的、更困难的事。
最后，我经常听到大家担心科技行业的新毕业生能不能找到工作，尤其 AI 智能体已经广泛使用，而计算机科学课程还没把它们纳入教学。Titus 是少数参与计算机科学课程指导委员会的工程师之一。他认为课程需要大幅改变、更加注重实践，否则计算机科学专业的招生人数会大幅下降。他也说，也许现在终于该有一套软件工程课程，让学生使用现代工具获得更多构建软件的经验。
我想我们都还没有现成答案，但让更多行业人士参与更新计算机科学和软件工程课程，听起来是正确方向。节目说明里有相关内容链接，包括 Google 工程文化、开发者生产力衡量，以及 AI 对软件工程的影响。如果你喜欢这期播客，欢迎留下评分，也可以写下评论。非常感谢，我们下期再见。