“编程水平越高，越会觉得AI糟糕透顶！”40年Java老兵：程序员敲代码有多快毫无意义，核心是交付敏捷

休斯敦大学教授 Venkat Subramaniam 是全球软件工程界的传奇：Java Champion（Java 领袖）、三届 JavaOne RockStar 得主、软件业“奥斯卡” Jolt 大奖获得者，著有十余本畅销技术专著。在这场深度访谈中，这位技术泰斗把 AI 的真实边界扒得一清二楚：拒绝形式主义的刷 Token 与失业恐慌，看清 AI 时代程序员最核心的生存壁垒。

编译 | 王启隆

出品丨奇点折射（ID：rgznai100）

“当全行业都在狂热高喊「AI 优先」时，我一直在倡导一个完全相反的口号：「AI 第二」（AI Second）——在把问题丢给工具之前，先给自己的大脑 15 分钟的纯粹思考。”

写了 40 年代码，后裤兜里永远揣着一张折叠便签纸，讲了上万场技术演讲从不排练、登台前却依然会紧张得在后台大口喘气——在 Java 和软件工程界，Venkat Subramaniam 是一个极具号召力的传奇老兵。在技术圈，他最招牌的标签就是从不用 PPT，全程在空白屏幕上纯手工实时敲代码（Live Coding）。

这期访谈来自 JetBrains 资深开发者布道师 Marco Behler 主持的技术播客《The Marco Show》。在慕尼黑的录音棚里，两位工程师把 AI 的真实边界扒得一清二楚：为什么 AI 搞生产不行、挑毛病却是一流？为什么说“起重机越强大，按错按钮造成的灾难越无法估量”？

以下是核心要点速览：

• 外行与专家的反差： “当我让 AI 去做一件我完全是外行的事情时，我被它的表现深深震撼；但当我让 AI 去做一件我是专家的工作时，我觉得它写出来的东西糟糕透顶。”

• 技能门槛： “在泥水里手递手挖泥是低技能劳动；但操控重型起重机的人，按错一个按钮就是一场灾难。在 AI 时代，我们需要的专业技能不是变少了，而是变多了。”

• “威胁驱动开发”与 Token 狂热： “用失业来逼大家用 AI，这不是测试驱动开发，这是‘威胁驱动开发’。至于疯狂刷 Token 排行榜，随他们去吧—— 愚蠢是无法持续的（Stupidity is not sustainable） ，撞了南墙自然会回归常识。”

• 应试做题 vs 求知探索： “我童年几乎没有哪门功课及格过。多年后我才想明白：我痛恨的是‘应试做题（Studying）’，但我极度热爱‘求知探索（Learning）’。应试会禁锢你，而真正的探索才能解放你的心智。”

• 虚拟线程的工程美学： “Java 没有跟风搞 async/await 把所有函数强行‘染红’，而是把重构成本抹平为零。Java 的创新不是炫技，而是以一种前所未见的优雅，把架构决定权留到‘最后负责任时刻’。”

以下是采访全文：

用 AI 编程像开重型起重机

主持人（Marco）：平时我总会说“欢迎来到 Marco Show”，然后隆重介绍嘉宾。但今天我们就直奔主题了，毕竟在座的同行应该都认识你。

你在 Java 领域可以说是无人不知的名人。我看了你最近的行程：今天你在慕尼黑，我们正在这间新录音棚里录制，因为老录音棚今天人手不够；你昨天刚从保加利亚飞过来，今天在慕尼黑，之后还要赶往好几个地方。我注意到你最近做过一场主题演讲，标题叫《It's AI, It Ain't So》（译注：借用俚语表达“看似神奇的 AI，实则并非如此”）。具体来说，究竟“不是那么回事”是指什么？AI 和我们以往认知的新技术相比，究竟有何不同？我们正处在一个非常振奋人心的时代，手里握着一个产出效率极其惊人的工具。

Venkat Subramaniam：就像面对任何新技术一样，我们还在逐步理解 AI 真正的能力边界。

问题在于，在此之前，开发者所接触和享受的大多数技术工具，基本上都是确定性（Deterministic）的。而 AI 具有极强的非确定性（Nondeterministic），它生成的内容确实令人惊叹，但其质量究竟如何？可靠性又有多高？

我认为当前的一大挑战在于：那些对 AI 最狂热、最兴奋的人，往往恰恰是极度不了解我们软件工程底层逻辑的人。我做这场演讲的初衷，就是既要展示这一工具的强大力量，同时也要揭示盲目使用它背后的危险。

AI 在处理某些特定任务时确实表现出色。对我而言，AI 最让我着迷的地方在于它发现问题、排查 Bug 和进行风险分析的能力。打个半开玩笑的比方：我自己在写代码上其实没那么厉害，但我特别擅长审视和挑剔代码；我发现 AI 也是这样——它自己写代码的能力不算顶尖，但在找代码漏洞方面却极为出色。

我认为这正是我们需要厘清的地方：明白它能做什么、不能做什么。一旦我们对 AI 的真实能力有了清醒认知，就能更好地利用它，同时也能消除对这项技术的无端恐慌。

主持人：你说它写代码“没那么厉害”，具体指的是什么？是指它生成的代码过于繁琐冗长、代码量太大，还是纯粹就是劣质代码？你会如何定义？

Venkat Subramaniam：全都有，就像人类程序员一样。我自己也一直在和这种倾向作斗争。

我和大家一样，人性使然——人类总喜欢把事情复杂化。我们写出的代码往往超出了实际所需，吃的东西超出了身体所需，就像我现在指着自己——说的话可能也比该说的要多。

我一直推崇极简主义（Minimalism），AI 其实也具备极简的能力。但就像我们每个人一样，如果能获得明确的约束和指引，在有“护栏”和框架的前提下工作，产出的质量就会好得多。

因此，使用 AI 的核心在于：如果你直接把一个模糊的问题扔给 AI 任由它自由发挥，那绝对会是一场灾难；但如果你为 AI 设定了清晰的准则，告诉它：“这是我希望你遵守的约束条件，在这些限制范围内去生成代码”，它就能交出好得多的答卷。这就是我们必须认识到的现实。

主持人：举个例子，假设我正在为一款在线银行应用开发一个新功能。你会建议大家自己先梳理出一份详尽的设计方案和规范（Spec），甚至借助 AI 来迭代完善这份规范，直到最后让 AI 去实现整个功能吗？你是否赞成让 AI 尝试端到端实现一整套功能？还是说应该由人手动编写，只让 AI 在旁辅助？实际开发应该是什么样的形态？

Venkat Subramaniam：首先我们要明白“开发者”这个角色的本质是什么。之前有个素不相识的人走过来问我：“听说你是程序员，现在 AI 这么厉害，你担心自己失业吗？”

这是一个突如其来的问题。在一个完全非技术的日常场合，我没料到会有人跑来问这个。这让我思考：面对一个非同行的路人询问我是否担心饭碗不保，我该如何回答？

当时我的回答是：“当我让 AI 去做一件我完全是外行的事情时，我对 AI 的表现充满敬畏；但当我让 AI 去做一件我是专家的工作时，我觉得它生成的代码糟糕透顶。”

所以回到你的问题，我反过来问你：如果一个对软件系统构建毫无经验和技能的人（比如初级开发者，甚至某个业务分析师），心想“反正有了 AI，我直接（Just）用 AI 就能把代码生成出来”，这其实是非常危险的。

但如果使用 AI 的人是一位架构师、资深开发人员或有着丰富工程交付经验的人，情况就完全不同了。我喜欢 AI 的一点在于：AI 可以替我们剥离软件开发中最枯燥的体力劳动。

我在软件开发中最享受的是解决问题的过程、设计思维、批判性审视与架构演进；而我最不享受的部分——尽管我打字飞快——恰恰是“敲代码”这一纯体力操作。

我给你举个前几天刚发生的真实案例，它让我非常兴奋。我们在脑海里往往都是挑刺的高手。以往有人跑来跟我提议：“我们要不要做这个功能？”我脑海里的第一反应往往是：我该拿出什么理由来证明这是个好点子，或者拿出什么证据来证明这是个极差的主意、我们千万不能做？通常在试图说服别人时，大家往往停留在理论争辩，甚至带着各自的主观偏见。

大概一周前，有人向我提出了一个功能构想。我当时的第一直觉是：“天哪，这主意太糟了，根本行不通。”

主持人：但要说服对方、证明你的判断，最好的办法就是把原型做出来。

Venkat Subramaniam：没错！但过去的问题在于：亲自去实现、去写 Demo 太耗费时间了。但现在有了 AI，我几分钟内就迅速拼出了一个原型，然后带着原型演示给对方看。他们看完后恍然大悟：“噢！原来做出来是这种效果。”

我说：“对，这就是你们设想的方案，但你看，这些就是为什么我们不能这么做的具体原因。”有了实物原型，讨论起来顺畅得多，大家很快达成共识并放弃了这个糟糕的方案，继续往前推进。

所以关键不在于 AI 本身的能力有多大，而在于使用 AI 的人具备怎样的能力。如果使用者拥有把系统推向生产环境并长期维护的实战经验，他就更能驾驭 AI。因为在当下，验证与评估方案的能力，远比单纯写出代码的能力要重要得多。

因此，当今的技术门槛实际上更多地落在了使用 AI 的人身上，而不是 AI 工具本身。

主持人：那随之而来的问题就是：现在的开发者该如何成长为专家？我和很多大学教授聊过，他们反映现在的学生越来越频繁地用 AI 来写作业、交项目。这带来了一个隐患：大家开始用 AI 来走捷径，跳过了我们当年那种在排查分号错误、踩坑排错中痛苦摸索的成长历程。

如果我现在是一名初级开发者，既然 AI 总能给我快速答案和廉价的即时满足，我该如何才能真正成为一名专家？

Venkat Subramaniam：这个问题的本质和学习的规律，其实几十年前就已经存在了。我们不妨先退一步，把 AI 暂时放到一边。

你、我以及身边的很多资深工程师，在没有 IDE（集成开发环境）的年代就开始写代码了。年轻时没有 IDE，我们必须用 Vi 或 Emacs 打开源码纯手工编辑。后来有了现代 IDE，大家的生产力大幅提升。

但我经常告诫刚入行的年轻开发者：不要过度依赖 IDE。抽出时间去尝试在命令行下编译和运行程序。IDE 确实能减少重复劳动，但如果你只依赖 IDE，你根本不知道底层的各部件是如何组装运转的。

今天面对 AI，情况如出一辙。去使用 AI，这很好；但千万不要忘记打牢基本功，必须去钻研底层原理。

这种认知差距随时随地都在发生。我曾在一家大型保险公司讲授内训课。课上一位负责该项目全职开发的工程师遇到问题，我走过去说：“来，我们看一下你的 Classpath（类路径）。”他一脸茫然地看着我说：“我听不懂你在说什么。”这个人已经用 Java 开发了几年应用程序，却连怎么排查 Classpath 都不清楚。

但与此同时，我也见过很多熟练运用 IDE、同时能在几秒钟内徒手拆解并排查底层机制的优秀开发者。

因此关键在于：在今天，甚至比以往任何时候都更重要的能力是“批判性思维（Critical Thinking）”。工具的便利决不能让我们产生“不再需要深度思考”的错觉。

如果新入行的年轻开发者和学生依然愿意花时间去理解底层原理，我们就完全不用担心未来；但如果他们一味走捷径，认为人生的唯一目标就是输出结果，而完全不关心结果是如何产生的，这部分人必将陷入巨大困境。优秀的开发者终会明白：要想精进技艺，自己究竟该付出什么。

主持人：确实如此。但在整个软件行业里，大家普遍面临着巨大的交差压力，往往只看重结果产出，没有足够的时间去深挖底层运行机制。这种现实逼着许多人不得不去走捷径。

Venkat Subramaniam：这种压力确实存在，而这恰恰体现出一个团队的成熟度。我个人非常幸运，在过去的职业生涯中（虽有少数例外），我遇到的大多数上级都极具大局观。他们同样承受着业务交付压力，但他们足够成熟，明白“欲速则不达”的道理，懂得什么是可持续的交付节奏。

你在职场中会遇到成熟的管理者，也会遇到不成熟的管理者。但从长远来看，成功永远属于那些懂得平衡之道的人。

走向任何一个极端都是糟糕的：一个极端是陷入“分析瘫痪（Analysis Paralysis）”，整天钻研底层细节却从不交付任何业务结果；另一个极端是永远处于盲目冲刺状态，不顾代码质量、不顾长期维护，只求尽快交差。这两种极端都不可取。

我们很快就会意识到“中庸之道”的重要性。我个人非常喜欢时间盒（Timeboxing）的概念：既不要草率赶工，也不要无限期拖延。我常问自己：“我愿意为这个具体任务分配多少时间？”时间一到，我就必须拿出实质性进展。

这也是我平时兼职教学时对学生的要求。我告诉他们：“你来问我问题，我不会在第一秒就直接把答案丢给你；但我绝不会让你无休止地卡在那里痛苦挣扎，因为那毫无意义。我希望你们学会设定时间盒：给自己一个小时，穷尽一切办法去探索解决方案。一个小时后，来告诉我你尝试了什么。这不是考试，也不是给你们打分，而是告诉我这一个小时里你做了哪些推演。如果你依然卡住，我再来告诉你解决之道。”

这样做才能真正建立内在的思维力量。如果一味索取即时答案，我们自身的思考能力就会日渐退化，最终彻底丧失评估方案优劣和验证结果真伪的能力。

关于这一点，我最近在开车时经历过一个类似 AI 场景的顿悟时刻。当时我在开车，双手握着方向盘，手头没有任何计算工具。有人给我打电话谈一笔业务报价：“总金额是这么多，能拿到多少折扣，折后最终金额是这个数。”

我们这代人大部分时间都在使用计算器，甚至如今更多是靠计算机来做运算，很少有人在纸上手算复杂的数学题。但当对方报出那组数字时，我一边开车一边下意识地说：“等等，你能把这几个数字再念一遍吗？直觉告诉我这几个数字对不上。”

我不需要精通高深的数学运算，就能凭直觉察觉出其中的破绽。这种直觉从何而来？来自常年保持的敏锐度与清醒思考。如果我们放弃了思考，奉行“垃圾进、垃圾出（Garbage in, garbage out）”，那些保持清醒的人就会迅速超越我们。

电话那头的人停顿了一下说：“噢，等等，我核对一下……你说得对，数字确实算错了。”你看，我不需要借助任何计算设备，就能敏锐察觉到问题所在——因为逻辑上感觉不对劲。

这种评估与甄别能力，正是我们需要培养的核心资产。而要掌握这种能力，就必须花时间去不断追问和质疑。优秀的管理者绝不会只盯着眼前的速成结果，他们看重的是可持续的长期成效。

这也是我从 40 年前的第一批老领导身上学到的宝贵经验。我至今记得初入行时，我还是个急躁毛糙的毛头小伙，只想以最快的速度把代码写完交差。老工程师会坐下来耐心辅导我：“你确实能很快做完，但如果你稍微慢下来一点，你不仅能完成任务，还能产出易于长期维护的优质代码。”随着时间的推移，行业自然会优胜劣汰，那些能真正驾驭工具的人会聚在一起，而不是随波逐流被时代淘汰。

主持人：你有没有注意到这样一种现象：现在有些人不再和同事进行头脑风暴，也不再花时间彼此交流探讨，而是把 AI 当作最主要的交流对象，把所有想法第一时间都抛给 AI 去碰撞？

Venkat Subramaniam：我注意到了，我认为这是个非常糟糕的做法，原因有以下两点。

这也是为什么我一直在提倡一个不同的口号：很多公司高喊“AI 优先”，而我说要“AI 第二（AI Second）”。

如果一个人一拿到问题，第一反应就是立刻扔给 AI，他就会丧失两个至关重要的东西：第一，他没有让问题在自己的大脑里真正沉淀与发酵。

举个例子：在这个行业待久了之后，经常会有出版社找我审阅即将出版的技术书稿。有一家长期合作的出版社经常委托我审阅大量书稿。我非常喜欢审阅初稿，一来我能以最快速度向一线作者学习（我对新知识极度贪婪，渴望抢先了解）；二来我能通过提出修改建议，为打磨一本好书贡献自己微薄的力量。

以前这家出版社采用了一种审稿系统：他们发来一个在线链接，所有审稿人都在同一个页面下发表评审意见，大家可以互相看到彼此的评论。从作者的角度来看，这很方便，能在一个地方集中查看所有反馈。但我看到这种机制的第一天，就立刻向出版社抗议：“我绝不在这种大家都能看到彼此留言的平台下审稿。”

为什么？因为如果你们需要我的审稿意见，你们要的是我独立思考的结果。如果我的思维事先受到了其他人评论的先入为主的干扰，我就很难再对书稿进行纯粹、深度的独立审视。我需要先通读内容，甚至离开屏幕，对着墙壁静静思考几分钟。

这种独立思考的过程极其宝贵。因此，当我拿到一个问题时，我的做法依然是时间盒：我给自己设定 15 分钟，纯粹靠自己的大脑去深入剖析这个问题。想清楚之后，我再去和同事交流讨论，带着我自己的见解去倾听他们的看法；在这之后，我才会引入 AI，看看 AI 又能提供哪些补充视角。

如果遵循这样的顺序，我所收获的思想成果，会比一开始就直接丢给 AI 要丰富得多。

对我来说，核心永远是质量——质量永远重于数量。我追求的是真正有深度、有力量的方案。而且我对这一观点拥有充分的实证数据支持。

几天前我主持了一场工作坊，专门验证了这个现象。我们挑选了一个具体的业务难题，我对现场的软件开发者们说：“请大家先独立分析这个业务问题，提炼出它的核心特征与技术诉求。”工程师们花了大约一个小时完成了分析。

随后我说：“现在把大家刚才的分析结果放到一边。把同一个原始问题输入给 AI，看看 AI 给出的分析是什么。”

我们将人类团队的成果与 AI 的成果进行比对，结果非常耐人寻味：两者有一部分重叠；但人类开发者识别出了一些 AI 完全遗漏的关键业务点；与此同时，AI 也指出了几个开发者们未曾考虑到的盲区。

最终，我们将两者结合，得到了一个比单独依靠任何一方都更为全面、深刻的解决方案。在场的工程师们也感叹：“哇，AI 指出的这一点确实很有启发，刚才我们讨论时谁都没注意到；但同时你看，我们发现的这几个核心矛盾，AI 也完全没看出来。”

顺便说明一下，为了确保严谨，我们在测试中并行使用了三种主流的大语言模型，而不是单一模型。事实证明，一群工程师的集体智慧与三个不同 AI 模型的交集与并集，其产出质量远超单纯的人类团队或单一的 AI 工具。

这就是我们必须认清的真相。如果我们整天处于浮躁与盲目冲刺的状态，只想把问题甩给工具、拿到结果就跑，固然能拼凑出一些东西；但所有人都知道，软件工程的目标绝不仅仅是“让程序跑起来”，而是要构建出可靠、易维护、高质量、符合用户体验预期且能创造实际业务价值的系统。

甚至我认为：既然 AI 降低了软件开发某些环节的机械成本，我们为什么不顺势把节省下来的时间，投入到以往想做却没有精力做好的架构质量与工程细节上呢？与其用 AI 来全面压缩工程标准，不如把它当作提升软件各维度品质的绝佳契机。

我不在乎程序员写得多快，我只在乎业务敏捷

主持人：说到这里，你怎么看网上那些鼓励员工疯狂“刷 Token（Token Maxing）”、甚至按 Token 消耗量给员工排排行榜的公司？

Venkat Subramaniam：我觉得他们很快就会撞墙并掉头回归理智。

这确实是个典型的反面教材，因为愚蠢是无法持续的（Stupidity is not sustainable），绝无可能。抱歉我话可能说得有点重，但事实就是如此。

当我第一次听说有人搞“Token 消耗排行榜”时，我说：随他们去吧，这挺好的！因为人在愚蠢的事情上能挥霍的资源终究是有限的，撞了南墙之后，人类最终还是不得不回归常识与理性。既然他们非要经历这种狂热，就让他们去试，免得以后天天抱怨“当初要是使劲刷 Token 就好了”。现在他们试过了，行不通，那就老老实实回到正确的轨道上来。

技术的发展从来不是线性的。回顾人类走过的路，我们本在这里，目的地在前方，但我们从来不会笔直地走过去，总是左右摇摆、反复试错。这种试错本身也是必不可少的。正如爱因斯坦的名言：“疯狂的定义就是一遍又一遍地重复做同一件事，却期待得到不同的结果。”

只要能吸取教训，犯点傻并不可怕。有时那些看似意料之外的傻尝试，反而会碰撞出意想不到的绝妙成果；但如果不去尝试，你永远无法预知。所以我完全赞成去尝试一些看似愚蠢的想法，但前提是：在某个节点上，我们必须有能力将其标记为死路，然后果断转向合乎逻辑的正轨。

只要运用批判性思维，把它们当成工具，追问我们究竟能从中获得什么真实的价值，而不被它表现出来的蛮力所迷惑，这些工具就会发挥出不可思议的威力。

这让我想起多年前在印度和美国休斯敦看到的一个极具对比性的场景。

当时我在印度旅行，坐在大巴车上从一个城市前往另一个城市。车停下来时，我望向窗外：大约有 50 个人在齐胸深的浅水区排成一条长队，正在进行人工清淤。他们赤着身子浸在水里，一个人潜下去挖起一篓淤泥，手递手传给下一个人，一路传递到岸边倒掉。

我坐在车上久久地看着这一幕。

从社会生计的角度来看，这 50 个人当天靠出卖体力领到了工钱，养活了 50 个家庭，这自然有其积极的一面；但从工程角度来看，这种纯体力劳动极其原始而低效。

一周后，我回到了美国休斯敦。清晨在公园慢跑时，我看到河道边同样在进行清淤工程：现场只有两个人，一个人站在外围负责安全警戒，另一个人坐在巨大的重型起重机驾驶室里，神情专注地操控着几个控制按钮。

我停下脚步，站在那里陷入了沉思。我把这两个画面放在一起对比：在水里排队清淤的工人，属于低技能劳动，他们不需要掌握深奥的理论，只需把泥土挖出来、递过去；但操控重型起重机的那个人，必须极其清楚每一个按钮的功能与后果——如果按错了按钮，他所造成的破坏和灾难将是难以估量的。

因此我的论点是：在 AI 时代，我们需要的专业技能不是变少了，而是变多了。

这意味着我们需要重新定义什么是核心技能。开发者的角色不会因为 AI 的出现而消亡；相反，优秀开发者的专业技能会被打磨得更加锋利。我们或许不再需要庞大的劳动密集型初级编码队伍，坦白说——我个人完全赞成这种精简。比起 100 个人在泥水里手递手挖泥，我更倾向于由两名掌握专业工具的高技能人员来高效完成同样的工作。说到底我崇尚商业效率，至于是好是坏由大家评判，但我从不赞成单纯为了堆砌人力而维持庞大的研发团队。

我也必须强调一点：我个人对所谓的“程序员纯编码生产力（Programmer Productivity）”毫无兴趣，我根本不在乎这个指标。我真正关心的是“业务敏捷性（Business Agility）”。

我的目标是交付更出色的业务成果，而不是单纯让程序员敲代码敲得更快。尽管我自己写了 40 年代码，但我始终认为，工程的目标从来不是单纯让程序员产出更多代码行数，而是让最终的交付成果更具实效、更能解决问题。

我们手里的 AI 工具确实有助于实现这一目标，但前提是我们必须重新审视自身需要具备的能力结构。这是一个让我们重新思考的契机，既不必盲目恐慌，也不必应激抗拒。我对当下的技术变革持非常乐观的态度，但我们必须保持清醒和务实，看清楚未来究竟需要什么样的人才，而不是天真地以为工具可以包办一切。

主持人：如果你现在是一家大型保险公司的 CTO，管着十几个研发团队，你会怎么做？你会给每个团队划拨一笔专项 AI 预算，要求大家必须花掉吗？面对这股浪潮，CTO 和技术主管们究竟该如何落地你所说的这些理念？

Venkat Subramaniam：如果我处在那个位置，我的第一步行动是：找出组织内部那些正在以理智、有效的方式运用这些工具的优秀工程师。

切记不要盲目设定量化指标。正如古德哈特定律所言：当一个指标变成目标时，它就不再是一个好指标。

多年前我去波士顿拜访一家公司，他们告诉我：“我们团队的奖金是和修复的 Bug 数量挂钩的。”我说：“这也太糟糕了。”他们却笑着说：“不，我们可爱死这个制度了！因为我们可以在这个版本里故意埋下 Bug，下个版本修好它们，然后美滋滋地拿奖金。”

这就是指标扭曲带来的恶果。

所以千万不要设立什么“必须花掉多少 AI 额度”、“Prompt 提交量必须达标”之类的考核指标。首要任务是在组织内部寻找那些真正的“技术灯塔”：看哪些开发者正在脚踏实地地利用 AI 创造实际价值？他们交付了怎样的成果？

找到这些人之后，打破组织内部的信息孤岛。在很多企业里，同一栋大楼的这一端，有人在用极其惊艳的方式提升交付质量；而仅仅几米之外的另一组人却一无所知，依然在忍受低效的折磨。

CTO 应该搭建起跨团队的交流机制，让这些先行者把经过验证的实践经验分享出来，带动整个组织学会如何正确、高效地使用工具。

通过内部协作与自发学习，我们才能收获真正的成效，而不是逼着员工去做愚蠢的形式主义动作。

如果管理层直接下达死命令：“这是你们的 AI 额度，必须花完，不用的人就卷铺盖走人”，这本质上就是我所说的 TDD——威胁驱动开发（Threat-driven Development）。我们在用职场威胁来逼迫大家顺从。

在这种环境下，只有极少数资深、且在财务上拥有足够底气和退路的成熟工程师，才敢走进主管办公室据理力争：“恕我直言，这种搞法毫无逻辑。”但绝大多数普通开发者根本没有这种底气——不是他们缺乏判断力，而是背负着养家糊口的生存压力，冒着被开除的风险去顶撞领导并不现实。因此大多数人只能选择沉默和应付。

优秀的管理者会主动走到骨干员工面前说：“我最近有了这样一个关于引入 AI 的想法，你来帮我把把关，告诉我为什么我们不应该推进它？”

我至今难忘我的一位老领导对我的启发。有一次他来找我：“我们打算引入某套技术方案，你怎么看？”我为他详细拆解了该方案的利弊权衡：“如果采用它，我们能获得这些收益；但它带来的技术债务和潜在风险有这些。”

领导听完后沉思道：“嗯，这里面的很多深层问题我之前确实没考虑到，这太有价值了。你给了我充分的理由来重新审视原先的决定。”

这就是成熟管理者的胸怀与智慧。

总结来说，企业应当做的是：挖掘团队内部善用工具的明星员工，深入了解他们的实际收益，让他们带领大家共同交流演进。同时也要明白，适合 A 团队的做法，未必适用于 B 的业务场景。我们必须因地制宜，找到适合具体业务的最佳路径。

真正的顿悟都在远离键盘时

主持人：聊聊个人技术进阶吧。如果我现在想精进自己的 Java 水平，或者学习一门全新的框架与技术，从你个人的经验来看，你会推荐去系统地读一本书、让 AI 帮我定制专属学习路径，还是自己亲手设计练习题？在如今这个时代，你最推崇的学习进阶路径是什么？

Venkat Subramaniam：对我来说，学习的核心是探寻自己的未知盲区。最大的挑战往往在于：“我甚至不知道自己不知道什么（I don't know what I don't know）”。如果你连盲区的存在都不清楚，又何谈去有效利用它呢？

知识的价值在于应用。无法落地的知识毫无意义。经常有人问我：“Venkat，我接下来该学什么？”我总是回答：“学习很重要，但把学到的东西应用到实际中去，比单纯输入更重要。”

这也是为什么我至今依然热衷于参加各地的线下用户组（User Groups），依然频繁奔走于各大技术大会，依然喜欢和一线软件工程师朋友聚在一起吃饭聊天。

因为当大家坐在一起吃午饭、喝咖啡，或者在用户组探讨技术时，别人的某句话往往会瞬间激发我的灵感，让我意识到自己知识图谱中的盲区，或者带给我一个前所未有的全新思考维度。

实不相瞒，我的后裤兜里永远揣着一张折叠的便签纸，上衣口袋里永远别着一支笔。昨天我在保加利亚参加大会，午餐时三四个人站在一起闲聊，大家在交流中随口提到的几个观点，立刻让我产生了灵感。我当场就把它们记在了便签纸上：“这个技术点非常值得深入阅读”、“那个工具的设计思路很有意思，我得好好琢磨一下”。

你必须将自己暴露在多元的未知信息源中。当我向 AI 提问时，我的思维往往是结构化和收敛的，因为我是带着预设的问题去检索答案；但在用户组、技术社交、甚至在通勤火车上与同行的偶遇交谈中，各种意外的思想火花会以非线性的方式涌现出来，指引我读一本从未听过的好书、探索一个全新的领域。

我写的第一批技术书之一，灵感就来源于一次意外。当时我在一场技术峰会上做完自己的演讲，坐在台下听另一位讲师做分享。听着听着，大脑里的一个后台线程突然被触发了——讲师随口说的一句话，引发了我的连锁思考。我脑海里突然跳出一个念头：“等等！沿着这个切入点，我可以写一本关于另一个衍生主题的完整技术书！”

我立刻掏出纸笔把核心提纲记了下来。几个月后，那本书正式出版了。

对我而言，这是一种极其纯粹的快乐。你永远无法预设灵感会在哪一秒降临。

我前几天还在思考：我所做的大多数技术演讲和主题报告（Keynote），究竟是在什么时候构思出来的？答案是：几乎全都是在我远离键盘、离开办工桌的时候。

上周清晨 5:30，我在街道上慢跑，大脑在自由神游，构思着一年后要讲的一场主题演讲。跑着跑着，一个绝妙的叙事架构突然从脑海中蹦了出来。我立刻在慢跑道上放慢脚步，掏出手机把灵感快速记录下来，生怕它转瞬即逝。

在徒步时、在慢跑时、在与朋友面对面畅谈时，我收获了源源不断的灵感。因此，AI 固然出色，但对我而言，真正的学习不是工具驱动的，而是对话驱动、批判性思维驱动的。

多去拓展你的思维边界。不要只满足于听到了什么，多去关注你能思考出什么、能创造出什么。

每当我开始写一小段看似简陋的测试代码去探索某个语言机制时，代码往往会反抛给我上千个全新的疑问——而那才是我真正开始深度学习的时刻。

花时间去深挖底层。有人会抱怨：“天哪，这太花时间了！”没错，这正是核心所在。唯有你愿意投入时间去深入钻研，你才能真正迎来破局的顿悟。

主持人：顺着这个话题，我看过你的演讲日程表，你每年要在全球做几十场技术分享和主题演讲。你刚才提到，有些演讲主题甚至会在你脑海里沉淀整整一年。平均而言，你准备一场演讲通常需要多久？是像播种一样提前很久（甚至几年）在脑海里埋下种子，然后任由它慢慢生长成型吗？你的具体打磨流程是怎样的？

Venkat Subramaniam：我始终坚信：做一场好的演讲，本质上是在讲一个引人入胜的故事。这是我近年来演讲的核心理念。

起初可能只是脑海里迸发的一颗微小火种：“这个切入点太棒了，值得大做文章。”

如果是一场纯技术实战演讲，对我现在来说相对轻松一些，通常需要 3 到 4 个月的筹备周期。我会确定：“我要深入剖析这门语言、这个框架或这种架构设计思路”，然后开始全面收集高质量的代码范例，梳理出严密的逻辑脉络。

但如果是面向全场的大型主题报告（Keynote），我通常需要酝酿一到两年。

一旦我确立了一个主题方向，在接下来的日子里，正如我所说的——哪怕昨天在技术大会上和别人闲聊，对方的一句话触动了我，我就会立刻把这个灵感点记录到这个主题的专属素材库里。

我会把所有的案例、故事、见闻统统扔进一个纯文本文件里。在这个阶段，内容是非常原始而庞杂的，里面可能包含了三四十个零散的案例、隐喻和生活琐事。比如我在斯德哥尔摩参观诺贝尔博物馆时，顺手拍下的一些展品照片和感悟，后来就被我融入到了当时正在构思的一场主题报告中。

到了演讲前大约一个月，我会坐下来通读这个素材文件。这个阶段主要是做减法（Elimination）而非加法。很多当初觉得挺有意思的点子，此时会被我果断剔除。

最后，在登台的前一天晚上，真正的“香肠加工（制作成型）”才正式开始。我会坐在桌前对自己说：“好了，明天就要登台了，今晚把这些精华串成最终的故事线吧。”

主持人：真的是这样吗？所有大作都是在演讲前一晚最终成型的？

Venkat Subramaniam：千真万确，每一次都是如此。

我现在完全不做任何演讲彩排。

因为在一到两年的酝酿期（哪怕是技术演讲的 3 个月）里，这些知识与故事已经彻底内化到了我的血液和骨髓里。

这不是我登台前临时死记硬背的讲稿，而是我常年在脑海里反复推演、动手验证、与同行激烈辩论过的真实思考。到了临登台前，我唯一需要梳理的只有叙事弧线（Narrative Arc）。

纯技术演讲我早就不再使用任何 PPT 或 Keynote 幻灯片了（全程实时 Live Coding）；只有大型主题报告我才会做几张幻灯片。

我之所以不在很早的时候制作 PPT，是因为 PPT 的格式限制太大。一旦内容被固定在排版结构里，你就很难自由地调整、删减和重新组织逻辑。纯文本文件才是最佳的思考载体。

在纯文本里，我可以随心所欲地上下剪切、把备选素材暂存一旁、随时剔除不合适的内容。梳理出清晰的叙事脉络后，我才会在最后一晚把 PPT 做出来。

通常一场主题报告首讲之后，如果后续受邀在其他大会上再次分享（近些年很幸运经常如此），我会根据首场的临场反馈再做一次微调。

我把大量的时间倾注在前期的思考沉淀与素材打磨上，而在“练习登台表演动作”上的耗时是零。

主持人：讲过上万场演讲之后，你现在上台前还会感到怯场吗？

Venkat Subramaniam：会，依然会有一点——不对，不仅是一点，其实是非常紧张。

我永远忘不了几年前在瑞典 JFocus 大会上的经历。那是一场几千名开发者齐聚的盛会。

后台负责音视频的调音师在给我佩戴胸麦时，听到了我急促粗重的呼吸声。她抬头看着我问：“这是你第一次做公众演讲吗？”

我说：“不，这大概是我做过的第 10,000 场演讲了。”

她惊讶地说：“天哪，你听起来非常紧张！”

我说：“是的，我很紧张。”

她说：“放心，你一定会讲得很棒的。”

我说：“谢谢你。”

但我认为，适度的紧张感是人类身体给予你的正面反馈，它在提醒你：集中注意力，该全力以赴了。

如果哪一天我登台前连一点紧张感都没有了，那大概就是我该退休离开舞台的日子了。紧张是一种本能的警报，催促你屏除杂念、全神贯注。

因此每次登台前，尤其是做大型 Keynote 前的最后 5 分钟，我通常会一个人静静地在后台走动，不希望任何人打扰，让我能够彻底清空思绪，完全聚焦在即将开始的演讲上。

一场演讲的成败往往取决于开场的第 1 分钟。如果你无法在第 1 分钟内抓住听众的注意力，整场分享你基本上就很难再把他们拉回来了。

所以登台时该如何亮相？第一句话该如何切入？如何把这股紧张感转化为专注力？这正是我在后台调节的核心。而一旦真正踏上舞台开口说话，我就完全沉浸其中，甚至忘却了周围的一切。

主持人：在你的演讲生涯中，有没有遭遇过彻底翻车的至暗时刻？

Venkat Subramaniam：天哪，太多次了！不过有一段经历绝对堪称永生难忘。

这场事故甚至被完整录下来传到了 YouTube 上，成了一个名场面。我自己都没敢点开看过，但我知道它在网上很火。

那是在疫情前，我去乌克兰基辅参加一场 Java 大会。因为航班原因，我落地基辅机场时距离演讲开场只有整整 2 个小时——这简直是给“墨菲定律”大开绿灯。我跳上出租车一路狂奔赶到会场，现场坐了大概六七百名开发者。

那是一场极罕见的大型技术主题报告，内容是关于“JVM 上五门主流编程语言的精髓对比（通过 5 门语言展示 JVM 的多语言特性）”。

我在后台刚掀开笔记本电脑，就听见机身内部发出一声极其诡异凄惨的异响，随后屏幕彻底黑掉。

电脑彻底暴毙，咽下了它的最后一口气。

我心想：“完了，这下彻底砸了。”

这时大会主办方负责人兴冲冲跑过来：“Venkat，现场准备就绪，全场坐满了，你可以登台了，我这就上台介绍你！”

我看着他说：“那个……我的电脑彻底报废了。”

他愣在原地：“什么？什么叫电脑报废了？是没电了吗？需要充电器吗？”

我说：“不，是硬件彻底烧毁了，完全开不了机。”

他当场脸色发白：“天哪！那……你的 PPT 呢？带 U 盘了吗？”

我说：“我从来不用 PPT。”

他崩溃地看着我：“你没带 PPT，现在连电脑也没了，底下六七百人等着，你到底要怎么讲？”

我能看出他整个人陷入了极度恐慌，其实我心里也慌得不行。但我深吸一口气对他说：“别慌，冷静点。帮我个忙：能不能现场帮我借一台 MacBook？只要有一台苹果电脑，我就能把这场演讲拿下来。”

他环顾全场，这时运气眷顾了我们——他在观众席第一排正中央看到一位小哥膝盖上正放着一台 Mac。

主办方冲过去喊：“嘿！那位穿黑衣服的朋友，请你过来一下！”

小哥指着自己：“我？”

“对，就是你，连人带电脑一起过来！”

小哥抱着电脑走上台，我握着他的手说：“朋友，实在万分抱歉，但也万分感谢你的救场。介意我借用你的电脑做演讲吗？”

小哥有些发懵：“呃……可以吧，给你。”

我说：“不不不，我不知道你电脑的环境配置和密码，你不能走，你得留在台上和我一起完成这场演讲！”

于是，一位完全随机的现场观众就这样成了我的登台搭档。

我对全场说：“既然大家都是 Java 开发者，我相信这位朋友的电脑里一定有基础环境。我没法用你的 IDE，因为我不熟悉你的快捷键和键位映射。你只需要帮我打开终端命令行（Terminal），我全程用 REPL（交互式命令行解释器） 进行纯手工 Live Coding。无论什么语言，只要有 REPL，就是我的主场！”

小哥说：“没问题，这个我熟。”

演讲正式开始。我一边对着全场纵横捭阖地讲解语言架构，一边突然意识到：这位小哥的电脑里怎么可能恰好装全了我要讲的全部 5 门 JVM 语言？

于是名场面诞生了：

我在舞台中央讲：“接下来，让我们看看 Scala 是如何处理这个问题的——”

我一回头，只见小哥在后面十指翻飞，当着全场几百人的面敲下：brew install scala……

在包安装完成的瞬间，他立刻启动 Scala REPL 并向我示意：“搞定，请！”

我走过去行云流水地敲完 Scala 代码，解释底层机制；然后我转过身面向观众继续讲：“接下来我们再来看看 Kotlin 的实现思路——”

小哥在背后疯狂敲下：brew install kotlin……现场安装编译器与运行库！

全场观众彻底看呆了，所有人都以为这是一场精心编排的行为艺术双簧秀，但实际上完全是毫无排练的临场生死时速！

最终，我们奇迹般地把整场演讲完美交付了。第二天小哥甚至继续上台帮我助演了另一场分享。回家后，我自费给这位可敬的小哥寄了一大箱我的技术签名书，由衷感谢他在绝境中给予我的慷慨解救。

主持人：在 YouTube 上搜什么关键词能看到这个名场面？

Venkat Subramaniam：搜“JEEConf Kiev Venkat”，再加上“JVM languages”应该就能搜到。如果我找到具体链接，录完发给你。

“我讨厌应试做题，但我热爱求知探索”

主持人：从漫步、徒步中捕捉思想火花，到从斯德哥尔摩博物馆的展品中汲取灵感，究竟是什么在背后驱动着你？你内心深处那种源源不断去探索、去创造的底层动力究竟是什么？

Venkat Subramaniam：我想是因为我骨子里天生容易对未知事物产生兴奋感。

但请允许我先回顾一段童年往事，这段回忆其实有些沉重。

我小时候在学校念书时经历过极其灰暗的时光——我曾是一个不折不扣的差生、全科挂科生。

主持人：挂科是指单纯卷面成绩不及格吗？

Venkat Subramaniam：对，纯粹是卷面成绩意义上的不及格。在我童年读书期间，我几乎没有哪门功课是及格通过的。回想起来，我能升学基本上全靠所谓的“按年龄连带升学（Social Promotion）”。

多年以后，当我一路拿到计算机科学博士学位时，当年那些看着我长大的长辈和熟人，没有一个人敢相信我能读完博士。

我非常幸运地遇到了一位伯乐教授。当我读完硕士研究生时，教授突然主动给我打来电话。我接起电话说：“教授，我刚办完硕士毕业手续。”

还没等我把话说完，教授在电话那头斩钉截铁地说：“Venkat，你不用多说了。我已经帮你安排好了，我要你立刻注册攻读博士学位，并且必须把它读完。”

这位教授在教我期间看到了我身上的潜能，给予了我无比坚定的信任。

多年后，有朋友问我：“Venkat，在培养和教育下一代上，你有什么好的建议？”

这句话瞬间勾起了我的回忆，促使我脱口说出了一句我此前从未总结过的心里话：

“我突然意识到，我痛恨‘应试做题（Studying）’，但我极度热爱‘求知探索（Learning）’。”

在此之前，我从未清晰地看清这两者之间的本质鸿沟。

应试做题（Studying）会束缚你、禁锢你；而真正的求知学习（Learning）却能解放你的心智。

我的童年充斥着被逼应试的压抑，我对此深恶痛绝；但当我走过那个阶段，真正进入到探索式的自主学习中时，求知成了一种无与伦比的享受。

回到你的问题：是什么让我永葆热情？正是探索未知时的敬畏与欣喜。

当我意识到自己对某个知识点一无所知时，我内心会感到极其谦卑，同时又会陷入由衷的兴奋。

举个例子：在 Kotlin 语言中，你可以编写一个 Lambda 表达式，把它作为“带接收者的函数字面值（Function Literal with Receiver）”直接挂载到任意一个外部类上，然后像调用该类自身的方法一样去调用这个 Lambda。

当我第一次看到这个特性时，我整个人都惊呆了：“这怎么可能？在这样一门严格的静态类型编译语言里，他们是怎么做到这一点的？”

我没有简单地把这个问题扔给 AI 去要一个现成答案，我渴望探究它背后的底层设计哲学。我坐在那里苦思冥想：“Kotlin 的这帮语言设计者是一群极其顶尖的天才，我由衷敬佩他们。但他们设计这个语法的原始动机到底是什么？”

突然我灵光一闪：“等等！我精通 JavaScript。在 JavaScript 里，你可以轻松地将一个函数绑定到任意对象并执行。难道……”

我立刻打开 Kotlin REPL，用我当年在 JavaScript 里的底层思维，在 Kotlin 中写了一段特殊的语法来绑定 Lambda——这段代码竟然真的完美运行了！

在那之前，我从未在任何技术文章或教程里见过有人这样写过。

那一瞬间，我彻底看清了 Kotlin 这一现代特性的底层脉络是如何从早期脚本语言的动态思想中蜕变演化而来的。我的大脑里仿佛瞬间亮起了一盏璀璨的灯泡！

正是这种时刻让我痴迷。一旦我参透了底层的来龙去脉，我就有了向他人分享的故事。

我不是语言规范的制定者，业内有太多令我敬佩的语言设计大师；我所能带给社区的，正是我自己在探索之路上的心路历程、顿悟时刻与纯粹的喜悦。

这就像当你看到一部震撼心灵的电影时，迫不及待想要和家人好友分享内心的感动一样。我对编程也怀揣着同样的狂热。每当我脑海中的灯泡被点亮，我就渴望把这份顿悟的喜悦传递给全世界的开发者。看到你此刻脸上的笑容，我就知道你完全能体会这种感觉。

主持人：我完全能感同身受。我也对学习的本质非常着迷。在 IT 行业与来自世界各地的工程师共事多年后，我想请教你：印度本土的基础教育体系，是否存在极其严重的“为了应试而应试”、把分数当作唯一衡量标准的内卷竞争倾向？

Venkat Subramaniam：何止是严重，简直令人心痛。虽然我已经离开印度 40 年了，对当地现状了解有限，但每次回国探亲听亲友讲述，那里的应试内卷只会比当年更甚。

我认为这极其不幸。求知是一辈子的长跑，一旦你把探索的乐趣从孩子身上剥夺殆尽，学习就沦为了一种沉重的精神枷锁，孩子们也因此失去了童年。

说到这里，我内心其实有些哽咽。因为今天让我在职业生涯中受益匪浅的几项核心特质——旺盛的求知欲、打破砂锅问到底的质疑精神、天马行空的想象力——恰恰是我童年在应试体制下每天被老师严厉惩罚的“缺点”，因为这些特质对“考取高分”毫无帮助。

回首往事，那样的教育评价体系是多么幼稚与狭隘。

这也彻底塑造了我作为父亲的育儿观：我彻底抛弃了用“卷面分数”来衡量我孩子成长的标准。

教育系统中的唯分数论不仅存在于印度，在世界很多地方也是如此。我平时兼职授课时常常对我的大学学生们说：“如果我有决定权，我会彻底废除打分制。因为打分制逼着学生把所有精力用来钻营‘如何拿高分’，而不是静下心来探索真正的知识。”

在我的专业课上（我可能在录像镜头前要保守一点说），我把大部分成绩权重从“单次考试表现”转向了“过程实践与演进记录”。

只要你动手实践的频次足够高、探索足够深入，你就能拿高分。我布置大作业，考核的重点从来不是你最终交出来的那个完美运行结果，而是你在整个迭代演进过程中投入了多少思考与心血。

这些教学理念全部源于我童年做差生时的惨痛教训。我从我的孩子们身上学到了真正热爱求知的模样：在我的家庭里，我们从不讨论“你这次考了多少分”，我们永远在探讨“你今天亲手做出了什么好玩的东西？”、“你最近对什么新事物感到好奇？能演示给我看看吗？”。

在动手创造中获得的快乐，远比冷冰冰的卷面成绩要广阔得多。

我常对学生说：“抱歉，我不在乎你卷面上考了满分，因为很多拿满分的人在面对实际工程问题时根本无从下手，他们掌握的只是空洞的应试技巧。”多年来我也从学生身上学到了很多。学生是好老师的明镜，孩子是好父母的灯塔。如果我们愿意向我们所引导的对象谦虚求教，整个社会都会因此受益良多。

主持人：这太令人动容了。当你聊到“动手创造的纯粹快乐”而不是冷冰冰的分数时，你整个人眼里都在放光。

Java 教科书级的敏捷，以及虚拟线程的工程美学

主持人：我想把话题切回到 Java 语言本身。站在当下的时间节点，回顾过去十年 Java 的剧烈演进，你认为 Java 处于一个怎样的历史位置？你如何评价它过去十年的变化？未来又有何展望？

Venkat Subramaniam：坦白说，在 2009 到 2010 年前后，我是站在反方阵营里最激进的批评者之一。如果你翻看我当年的演讲视频，你会发现我整天在台上公开炮轰 Java，抱怨它语法冗长、设计死板，劝大家不要用它。

在我看来，真正的破局转折点是 Java 8。

我记得在 Java 8 正式发布的三四年前，我刚从外地出差回来，心里还在嘀咕：“Java 加不加 Lambda 有什么大不了的？Scala、Groovy、Clojure 早就有闭包和 Lambda 了，Java 拾人牙慧而已。”

回到家后，我随手下载了 Java 8 的早鸟预览版（Pre-release）开始试玩。写着写着，我猛地从办工桌前站了起来，心里惊呼：“Java 从此彻底不同了！”

那是我生平第一次由衷地为 Java 感到振奋！

当我看到 Stream API 的惰性求值（Laziness of Streams），看到底层对 Lambda 表达式的优雅实现机制（通过 invokedynamic 指令而非简陋的语法糖），我意识到 Java 正在驶向一个完全不同的全新维度。

当我们审视一门语言时，往往只把它看作冰冷的代码工具；但语言的背后是鲜活的人。

今天掌舵 Java 演进的核心团队，早已不是当年设计 Java 1.0 的那一批元老了。元老们在他们的时代功勋卓著，但接棒的新一代语言架构师们，对 Java 的未来拥有截然不同的现代格局。

意识形态有时会成为进化的绊脚石。Java 早期的意识形态是不折不扣的“纯面向对象（OO）至上论”——一切皆对象。

正是在这种纯 OO 意识形态的桎梏下，Java 1.1 引入了极其别扭的匿名内部类（Anonymous Inner Classes）。为了传递一个行为逻辑，我们不得不定义只有一个抽象方法的 SAM 接口（Single Abstract Method），然后再用冗长丑陋的匿名内部类把它包装成对象传过去，仅仅因为“语言规定参数必须是对象”。

平心而论，当年这么做有其历史局限性，但从后世的视角看，这种设计让 Java 在函数式编程的道路上白白耽误了十几年。

我常跟同行感慨：想象一下，如果 Java 1.1 当年没有引入匿名内部类，而是直接推出了原生的 Lambda 表达式，整个软件工程历史的走向都会被彻底重写！

因此，当 Java 8 毅然打破旧有教条、正式拥抱 Lambda 和函数式范式时，我彻底爱上了这门语言。自那之后，我开始以前所未有的热情在全球布道现代 Java。

而在此之后，Java 展现出的最绝妙的工程智慧，莫过于——将 Java 的“底层研发节奏”与“版本发布周期”彻底解耦。

全世界所有张口闭口大谈敏捷开发（Agile）的人，我都恳请你们停下脚步，认真看一看 Java 核心团队的操作。这才是教科书级别的真正敏捷！

敏捷从来不是流于形式的两周一个 Scrum 冲刺或固定月度发版。Java 团队之所以能实现质的飞跃，在于他们把发版周期固定为每 6 个月一次，但特性的实际研发周期完全脱离 6 个月的限制。

这赋予了语言架构师们极其从容的研发空间：他们可以花上三五年去潜心论证一个特性到底适不适合 Java，不必被发版死线赶鸭子上架，也不会被外界嘈杂的声音所裹挟（比如像我这样的大嗓门在台下整天嚷嚷着要加这加那）。

他们极其成熟克制，首先聚焦于“Java 应该成为一门怎样的语言”，花充分的时间去打磨验证方案的可行性，然后以预览特性（Preview Features）的形式推向社区。

什么是真正的敏捷？敏捷就是反馈驱动开发（Feedback-driven Development）！

通过 6 个月一期的预览通道，全球成千上万的一线开发者可以在真实项目中试用并向官方反馈：“这个 API 设计得很舒服”，或者“这种边界场景下存在严重隐患”。Java 架构团队收集所有实战反馈后，再从容决定是继续演进、推倒重构，还是果断废弃。

这种沉稳而高效的演进机制，让我对 Java 的未来充满信心。

主持人：在过去 5 年里，有没有哪一个具体特性能让你拍案叫绝？

Venkat Subramaniam：近几年的优秀特性很多，但如果只挑一个，我绝对把票投给虚拟线程（Virtual Threads，即 Project Loom）。

我之所以对虚拟线程如此推崇，完全契合我刚才提到的架构设计哲学。

回过头看，我们不得不承认：JavaScript 在 20 多年前做对了一件事——它在诞生之初就押注了异步非阻塞模型（Asynchronous Programming），而非高成本的多线程并发。

25 年后的今天，在微服务与高并发业务系统大行其道的时代，我们深刻认识到异步架构对于吞吐量的巨大提升。并行计算固然重要，但在 I/O 密集型领域，异步化才是王道。

但 Java 团队引入异步的方式极其惊艳。他们没有盲目跟风：“既然要搞异步，我们来看看其他语言怎么做的——JavaScript 搞了 async/await，C# 搞了 async/await，Kotlin 搞了挂起函数 suspend……那我们也照猫画虎加个 async/await 吧！”

Java 团队断然拒绝了这种破坏语言纯洁性的做法。

作为一个架构师，我始终追求极简的解决方案，并且极度推崇“延后到最后负责任时刻（Last Responsible Moment）”的决策原则——在对系统性能瓶颈拥有充分把握之前，不要过早引入复杂的架构。

但是在 JavaScript、C# 或 Kotlin 里，作为架构师，我每天都在被逼着提前做决定：“这个函数未来需要做成异步的吗？”

为什么你必须今天就做决定？因为一旦未来某一天你要把它改成异步，重构成本将极其高昂（即著名的“彩色函数/染红”问题）！你必须把调用链上的所有方法签名统统改成 async/await，在 Kotlin 里加 suspend，在 C# 里把返回值全部包装成 Task 。即便今天有 AI 辅助重构，整个测试验证的复杂度也会呈指数级上升。

而 Java 团队说：我们需要异步的高吞吐，但我们绝不破坏原有函数的调用语法与结构！

在虚拟线程下，代码依然按照最自然、最易读的同步阻塞方式编写，底层的运行时会在 I/O 阻塞时自动卸载和挂起虚拟线程，将底层的操作系统载体线程释放给其他任务使用。

凡事皆有权衡（Trade-offs）。有人会反驳：“在 C# 或 Kotlin 里，我一眼就能看出哪个方法是异步的；而在现代 Java 里，光看代码签名你分不清它是同步还是异步。”

但对我这样的架构师来说，Java 将重构成本抹平为零！今天我可以安心写出最直观的同步逻辑；明天系统遭遇流量洪峰需要扩容伸缩时，我只需在最外层把线程池替换为虚拟线程调度器，业务代码一行都不用改，就能以近乎零成本获得海量并发吞吐！

这就是将决策延后到“最后负责任时刻”的极致工程美学。

在我眼中，Java 的创新从来不是去发明别人从未见过的炫技语法，而是以一种前所未见的优雅工程方式，将强大的能力融入现有体系之中。

这种克制而深邃的工程匠心，就像在欣赏一件经得起时间淘洗的艺术品一样，令人赞叹不已。

主持人：在未来的 3 到 5 年里，Java 的版图上还有哪些最让你翘首以盼的新特性？

Venkat Subramaniam：我不是一个追求花哨语法糖的人，代码表现力固然重要，但我更关注它能否解决现实生产中的硬核痛点。

多年前我为客户开发过一个涉及海量实时计算的企业级系统，那次经历让我刻骨铭心。项目中充斥着数十亿次的高频密集运算，我们在架构中重度使用了 Java 8 Lambda。

当时团队里有一位资深开发私下对我说：“Venkat，我没想到你会在生产环境里这么重度地使用 Lambda。我们上一任架构师以前总念叨着想要 Lambda，后来他离职了；你来了之后把 Lambda 全面落地了，这也算圆了他的梦想。但我一直暗自担心：这么大范围用 Lambda，会不会引发严重的性能衰退？”

在小规模测试集下，系统运行得飞快；但当把几十亿真实计算量的数据集灌入系统时，程序耗时变得极长，性能急剧恶化。

我们立刻排查 Profiler 监控，结果发现：CPU 绝大部分时间全耗费在了垃圾回收（GC）上！

原因在于我们使用了大量的双精度浮点泛型集合 List 。Java 泛型的类型擦除机制，导致系统在计算过程中，将每一个基础类型 double 疯狂自动装箱（Autoboxing）成堆内存中的大写对象 Double，从而在内存中制造了天文数字级别的临时短命对象，瞬间挤爆了内存并引发频繁的全盘 GC 停顿！

那次性能调优最痛苦的过程，是我们不得不把优雅的泛型代码全部推倒重写，全部硬编码改回最原始的基础类型原生数组 double[]，通过彻底消除装箱与拆箱的内存开销，才最终跑赢了性能指标。

因此，对于所有需要处理密集计算的现代应用来说，Java 最迫切需要的杀手级特性就是支持值类型的泛型（Generics with Value Types，即 Project Valhalla 项目）。

如果能够让泛型直接持有扁平化、无对象头开销的基础值类型，无需任何装箱惩罚，Java 的性能将迎来又一次质的飞跃。

我常开玩笑说：“我只希望在我退休前，能亲手在 Java 生产环境里跑一次带有值类型的泛型代码。离我退休可没多少年了，Java 核心团队的伙计们动作可得麻利点！只要能让我赶在退休前跑通一次，我这辈子就可以心满意足地退隐江湖了。”

2026 奇点智能技术大会与 C++ 及系统软件大会 将于 11 月 20-21 日在北京万达文华酒店正式召开。

双会并行，上层应用的每一次狂飙，都在对底层体系提出更苛刻的挑战，而底层的每一次重构，也正在被 AI 重新定义。

70+ 全球技术专家、18 个前沿专题、1000+ 行业精英。

确认重磅嘉宾：OpenAI 资深研究科学家 Łukasz Kaiser——Transformer 八子之一，GPT-4/5、o1、o3、ChatGPT 核心共同发明人；京东集团副总裁、京东探索研究院副院长段楠、新浪微博首席科学家及 AI 研发部负责人张俊林、小米 AI 平台部语言模型推理负责人张晨、网易智企 AI 平台技术负责人裴明明等一线实战专家，更多重磅嘉宾持续公布中，欢迎访问官网 https://ml-summit.org/ 了解大会议程与购票信息。