谷歌12年工程师：CS课程该推倒重来，AI时代要走出代码

一个定义过课程的人，说课程该烧掉

如果你花四年读完了计算机科学，却发现所学内容是为上世纪90年代构建数据库和操作系统准备的，会作何感想？

Titus Winters 的答案是：大部分 CS 课程应该被烧掉重来。

这个判断来自一个并非局外人的人。Titus 在谷歌工作了12年，是《Software Engineering at Google》的第一作者，曾掌管谷歌的 readability 项目；2023年，他是 ACM/IEEE 本科 CS 课程指导委员会中唯一一位仍在写代码的一线工程师。据他在播客中的说法，课程体系里"平均的那门课"，恰好是九十年代造数据库和操作系统所需要的东西——对于一个以创新自居的领域，这显然不是一个好听的说法。

他的核心主张可以浓缩成一句话：我们需要走出代码，向上提升一个层级。

250万行C++：人类历史上最大规模的重构

理解 Titus 的工程观，绕不开他在谷歌主导的那场重构。

当时谷歌的 C++ 代码量约为2亿到2.5亿行（仅第一方代码），一个月内约有1万名工程师在这个代码库上提交修改。Titus 团队的比喻是：谷歌发明了新的摩天大楼地基技术，要在不关闭帝国大厦、不阻断交通的前提下，把地基换掉——然后还在地下室发现了核废料。

他们没有用蛮力，而是构建了确定性的编译器辅助工具：基于 Clang/LLVM 的 AST（抽象语法树）变换，对代码库做 MapReduce——mapper 解析每个编译单元生成语法树，在语法树上精确匹配函数调用上下文，再由工具生成改写。有趣的是，最初最大的障碍之一竟是"生成的编辑无法把空白字符放对位置"，这直接催生了 clang-format。

即便强大如谷歌，也有做不成的事：一次性编辑上万文件注定产生合并冲突。解法是让新旧 API 共存，按目录分批并行推进，清理干净后再删除旧接口。

AST（抽象语法树） 是编译器在解析源代码后生成的一种树状数据结构，它用节点表示语法结构（如函数调用、变量声明、表达式），而丢弃了空格、注释等不影响语义的信息。正因为 AST 只保留程序的结构本质，基于 AST 的代码变换可以精确匹配“某个函数在特定上下文中被调用”这类模式，而不受代码格式差异干扰。谷歌的重构工具正是遍历 AST 找到目标调用点，再在树层面生成改写，最后由工具序列化回源码。这种“解析—匹配—重写”的流程之所以具备确定性，是因为同样的输入永远产生同样的输出，且变换规则可被审查、可被复用，避免了让大语言模型直接改代码时可能出现的随机偏差。

AI 重构的正确姿势：让AI写规则，而不是让AI干活

Titus 的观点与当下很多团队的实践形成了鲜明对照。用非确定性 AI 直接重塑大规模代码库，远不如让 AI 生成确定性工具。

他提到 Java 生态中的 OpenRewrite：你声明"我要在代码里找这种模式、这样改写"，工具会以可审计、可重复的方式跑完全部源文件。而 AI 极其擅长生成 OpenRewrite 的配方（recipe）——token 消耗更低、准确率更高、速度更快。他提到有团队甚至让 AI 代码审查工具在发现问题后，直接生成 lint 规则：规则便宜、可重复，不再需要每次花半小时跑一遍昂贵且不确定的推理。

这背后是一种共识：推理用于一次性判断，确定性工具用于长期执行。 所谓"零 token 架构"的思路，正是让 AI 生成工具、只在工具无法覆盖的缝隙里做推理。

OpenRewrite 是 Java 生态中一个开源的自动化代码重构框架。它的核心思想是“配方（recipe）驱动”：开发者用声明式代码描述一条变换规则——例如“把所有对旧版 API 的调用替换为新版签名”——而不是手写脚本去逐个文件修改。OpenRewrite 会解析源码为 Lossless Semantic Tree（一种保留格式信息的 AST），在树结构上应用配方，再写回源码，因此变换是可审计、可重复、可回滚的。由于配方本质上是结构化的规则描述，它比自然语言更接近代码，AI 生成配方时所需的 token 更少、准确率更高，生成结果也能被人工逐条审查，这与让非确定性模型直接编辑海量源文件形成了根本区别。

生产力度量的盲区：AI 的价值不在你测的地方

Titus 在 Adobe 负责开发者体验，他直言"开发者体验说到底是生产力业务，只是我们足够礼貌，不说自己能测量生产力"。

他援引过一位资深工程师的原话：代码量涨了70%，线上故障也涨了30%，而功能数量持平。这暴露了传统度量的无能——如果 AI 只是让你更快地做同样的事，价值其实很有限；真正的价值在于去做以前不会去想的、更难也更有价值的事。

他举过一个案例：某中型公司的工程师借助 AI，用大量测试套件作为规格，重写了一个供应商的闭源授权组件——更快更好，而团队原本毫无该领域知识。供应商反过来付费请求对方不要开源。这类"改变游戏规则"的收益，无法被任何"数零件"式的指标捕捉。

CS 教育：从"产出代码"转向"规格、测试与评审"

Titus 对教育的批评极其具体。他说大多数 CS 课程自2000年以来没有实质变化，且一直在做"增量堆叠"——不断往里加东西，再削减既有内容的深度。

他的替代方案是：

• 停止以代码产物为评分核心。与其再写一个链表、再写一篇《麦田里的守望者》书评，不如评你用的提示词、你写的测试、以及你如何验证 AI 真的做对了。
• 第一门课教接口设计。他甚至设想把 CS0 改成"输入输出与接口结构"课——复选框和单选按钮的区别、按钮何时该用、命令行标志怎么写。哪怕学生只上这一门，用 AI 拼出来的东西也会有更连贯的设计语言。
• 用项目驱动理论。你不能给一个还没意识到问题的人提供解决方案；先让学生遇到问题，理论才会从"孤立的知识点"变成答案。
• 评分包含对同伴的评审，并且评判的是"你能否不带恶意地给出反馈"——这与心理安全直接挂钩。

他预判：CS 招生人数将大幅下滑，而软件工程专业会上升——因为在 AI 时代真正还能让你拿到工作的，是团队协作、沟通、设计规格、测试与验证，这些恰好是软件工程的范畴。

他还提到滑铁卢大学的启示：通过多次带薪实习，学生在毕业前就积累了接近一年的真实工作经历，这从招聘经理视角看价值极高。

团队仍是底座，心理安全仍是最强预测器

面对"100倍工程师"的说法，Titus 的判断是：软件工程是团队运动，没有例外。即便把 AI 代理视为团队，工程师也需要成为代理团队的"管理者"，而行业目前并未提供任何相关训练。

他引用 DORA 研究的一个数据：仅凭文化问卷得分，就能解释团队目标达成率约30%的方差——他认为这比任何技术信号都更强。这也解释了为什么裁员对生产力的隐性伤害被严重低估：一对一沟通变成情绪支持，人们开始更新简历，"额外付出"与"额外安全感"之间的关联被切断。

DORA（DevOps Research and Assessment） 是始于 2014 年的一项长期实证研究，最初由 Nicole Forsgren、Jez Humble 等人主导，后被谷歌云收购并持续发布年度报告。它通过大规模问卷与统计建模，识别出影响软件交付效能的关键因素，提出了“交付吞吐量”与“稳定性”两组指标（如部署频率、变更前置时间、变更失败率、恢复时间）。DORA 研究的一个重要发现是：心理安全、学习文化、跨团队依赖管理等组织文化因素，对团队效能具有显著且稳定的解释力，其预测强度往往超过技术栈或工具选择。Titus 引用的“文化问卷解释约 30% 目标达成率方差”正是这一研究脉络的延续，也说明为什么单纯引入 AI 工具而不改变协作方式，很难带来根本性的效能提升。

给学生的建议：走一条没人走的路

Titus 的收尾建议带点风险，但很坦诚：他人生中大多数成功来自"不做大家都在做的事"。找一个你真正感兴趣、哪怕有点古怪的方向投入时间，你会有一个独特的故事，也会在面试中值得被认真交谈。

他也提示了一个隐忧：AI 辅助降低了原始工程能力的门槛，替代它的只能是对问题域的更深理解——这意味着行业流动性可能下降。未来你不再是"一个 C++ 工程师"或"一个后端工程师"，而是"一个嵌入式音频工程师"。