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

“当全行业都在狂热高喊'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）：你在 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 设定了清晰的准则，告诉它：“这是我希望你遵守的约束条件”，它就能交出好得多的答卷。

主持人：在实际开发中，应该由人手动编写只让 AI 辅助，还是让 AI 尝试端到端实现一整套功能？

Venkat Subramaniam：首先要明白“开发者”角色的本质。曾有人问我："AI 这么厉害，你担心失业吗？”我的回答是：“当我让 AI 去做一件我完全是外行的事情时，我对 AI 的表现充满敬畏；但当我让 AI 去做一件我是专家的工作时，我觉得它生成的代码糟糕透顶。”

如果一个对软件系统构建毫无经验的人心想“反正有了 AI，我直接用 AI 就能把代码生成出来”，这是非常危险的。但如果使用者是一位架构师或资深开发人员，情况就完全不同了。我喜欢 AI 的一点在于：AI 可以替我们剥离软件开发中最枯燥的体力劳动。

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

前几天有个真实案例：有人向我提出一个功能构想，我直觉认为这主意太糟了。过去要证明这一点需要耗费大量时间写 Demo，但现在有了 AI，我几分钟内就拼出了一个原型。带着原型演示给对方看，他们看完后恍然大悟，很快达成共识并放弃了这个糟糕的方案。

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

主持人：现在的学生越来越频繁地用 AI 来写作业、交项目，跳过了排查错误、踩坑排错的成长历程。初级开发者该如何才能真正成为一名专家？

Venkat Subramaniam：这个问题的本质和学习的规律几十年前就已经存在了。在没有 IDE 的年代，我们必须用 Vi 或 Emacs 打开源码纯手工编辑。后来有了现代 IDE，生产力大幅提升，但我经常告诫年轻开发者：不要过度依赖 IDE。抽出时间去尝试在命令行下编译和运行程序，否则你根本不知道底层的各部件是如何组装运转的。

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

关键在于：在今天，甚至比以往任何时候都更重要的能力是“批判性思维（Critical Thinking）”。工具的便利决不能让我们产生“不再需要深度思考”的错觉。如果新入行的开发者一味走捷径，认为人生的唯一目标就是输出结果，而不关心结果是如何产生的，这部分人必将陷入巨大困境。

主持人：但在整个软件行业里，大家普遍面临着巨大的交差压力，往往只看重结果产出，没有足够的时间去深挖底层运行机制。

Venkat Subramaniam：这种压力确实存在，而这恰恰体现出一个团队的成熟度。成功的团队懂得什么是可持续的交付节奏。走向任何一个极端都是糟糕的：一个是陷入“分析瘫痪”，整天钻研细节却不交付；另一个是永远处于盲目冲刺状态，不顾代码质量。这两种极端都不可取。

我非常喜欢时间盒（Timeboxing）的概念：既不要草率赶工，也不要无限期拖延。我常问自己：“我愿意为这个具体任务分配多少时间？”时间一到，就必须拿出实质性进展。这也是我对学生要求：给自己一个小时，穷尽一切办法去探索解决方案。一小时后，告诉我你尝试了什么。这样做才能真正建立内在的思维力量。

关于这一点，我最近在开车时经历过一个类似 AI 场景的顿悟时刻。有人在电话里报出一组业务报价数字，我一边开车一边下意识地说：“等等，直觉告诉我这几个数字对不上。”我不需要精通高深数学，就能凭直觉察觉出其中的破绽。这种直觉来自常年保持的敏锐度与清醒思考。如果我们放弃了思考，奉行“垃圾进、垃圾出”，那些保持清醒的人就会迅速超越我们。

这种评估与甄别能力，正是我们需要培养的核心资产。优秀的管理者绝不会只盯着眼前的速成结果，他们看重的是可持续的长期成效。

主持人：有没有注意到这样一种现象：现在有些人不再和同事进行头脑风暴，而是把 AI 当作最主要的交流对象？

Venkat Subramaniam：我注意到了，我认为这是个非常糟糕的做法。这也是为什么我一直在提倡一个不同的口号：很多公司高喊"AI 优先”，而我说要"AI 第二（AI Second）”。

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

以前出版社审稿时，所有审稿人都在同一个页面下发表评论。我立刻抗议：“我绝不在这种大家都能看到彼此留言的平台下审稿。”因为如果我的思维事先受到了其他人评论的先入为主的干扰，我就很难再对书稿进行纯粹、深度的独立审视。我需要先通读内容，甚至离开屏幕，对着墙壁静静思考几分钟。

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

几天前我主持了一场工作坊验证了这个现象。我们将人类团队的分析结果与 AI 的成果进行比对，结果非常耐人寻味：两者有一部分重叠；但人类开发者识别出了一些 AI 完全遗漏的关键业务点；与此同时，AI 也指出了几个开发者们未曾考虑到的盲区。最终，我们将两者结合，得到了一个比单独依靠任何一方都更为全面、深刻的解决方案。

事实证明，一群工程师的集体智慧与三个不同 AI 模型的交集与并集，其产出质量远超单纯的人类团队或单一的 AI 工具。

软件工程的目标绝不仅仅是“让程序跑起来”，而是要构建出可靠、易维护、高质量、符合用户体验预期且能创造实际业务价值的系统。既然 AI 降低了软件开发某些环节的机械成本，我们为什么不顺势把节省下来的时间，投入到以往想做却没有精力做好的架构质量与工程细节上呢？

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

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

Venkat Subramaniam：我觉得他们很快就会撞墙并掉头回归理智。这确实是个典型的反面教材，因为愚蠢是无法持续的（Stupidity is not sustainable）。人在愚蠢的事情上能挥霍的资源终究是有限的，撞了南墙之后，人类最终还是不得不回归常识与理性。

技术的发展从来不是线性的，总是左右摇摆、反复试错。只要能吸取教训，犯点傻并不可怕。但只要运用批判性思维，把它们当成工具，追问我们究竟能从中获得什么真实的价值，这些工具就会发挥出不可思议的威力。

这让我想起多年前在印度和美国休斯敦看到的一个极具对比性的场景。在印度，大约有 50 个人在齐胸深的浅水区排成一条长队，人工清淤，手递手传递淤泥。从社会生计角度看，这养活了 50 个家庭；但从工程角度来看，这种纯体力劳动极其原始而低效。

一周后，我在美国休斯敦看到河道边同样在进行清淤工程：现场只有两个人，一个人负责安全警戒，另一个人坐在巨大的重型起重机驾驶室里，操控着几个控制按钮。

在水里排队清淤的工人，属于低技能劳动；但操控重型起重机的那个人，必须极其清楚每一个按钮的功能与后果——如果按错了按钮，他所造成的破坏和灾难将是难以估量的。

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

这意味着我们需要重新定义什么是核心技能。开发者的角色不会因为 AI 的出现而消亡；相反，优秀开发者的专业技能会被打磨得更加锋利。我们或许不再需要庞大的劳动密集型初级编码队伍。比起 100 个人在泥水里手递手挖泥，我更倾向于由两名掌握专业工具的高技能人员来高效完成同样的工作。

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

我的目标是交付更出色的业务成果，而不是单纯让程序员敲代码敲得更快。工程的目标从来不是单纯让程序员产出更多代码行数，而是让最终的交付成果更具实效、更能解决问题。

主持人：如果你现在是一家大型保险公司的 CTO，管着十几个研发团队，你会怎么做？

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

切记不要盲目设定量化指标。正如古德哈特定律所言：当一个指标变成目标时，它就不再是一个好指标。多年前我去波士顿拜访一家公司，他们的奖金是和修复的 Bug 数量挂钩的。结果他们在这个版本里故意埋下 Bug，下个版本修好它们，然后拿奖金。这就是指标扭曲带来的恶果。

所以千万不要设立什么“必须花掉多少 AI 额度”、"Prompt 提交量必须达标”之类的考核指标。首要任务是在组织内部寻找那些真正的“技术灯塔”：看哪些开发者正在脚踏实地地利用 AI 创造实际价值？找到这些人之后，打破组织内部的信息孤岛，搭建起跨团队的交流机制。

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

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

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

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

主持人：聊聊个人技术进阶吧。在如今这个时代，你最推崇的学习进阶路径是什么？

Venkat Subramaniam：对我来说，学习的核心是探寻自己的未知盲区。最大的挑战往往在于：“我甚至不知道自己不知道什么（I don't know what I don't know）”。知识的价值在于应用。无法落地的知识毫无意义。

这也是为什么我至今依然热衷于参加各地的线下用户组（User Groups），依然频繁奔走于各大技术大会，依然喜欢和一线软件工程师朋友聚在一起吃饭聊天。因为当大家坐在一起交流时，别人的某句话往往会瞬间激发我的灵感，让我意识到自己知识图谱中的盲区。

实不相瞒，我的后裤兜里永远揣着一张折叠的便签纸，上衣口袋里永远别着一支笔。昨天我在保加利亚参加大会，午餐时大家在交流中随口提到的几个观点，立刻让我产生了灵感。我当场就把它们记在了便签纸上。

你必须将自己暴露在多元的未知信息源中。当我向 AI 提问时，我的思维往往是结构化和收敛的；但在用户组、技术社交、甚至在通勤火车上与同行的偶遇交谈中，各种意外的思想火花会以非线性的方式涌现出来。

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

对我而言，这是一种极其纯粹的快乐。你永远无法预设灵感会在哪一秒降临。答案是：几乎全都是在我远离键盘、离开办工桌的时候。

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

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

多去拓展你的思维边界。不要只满足于听到了什么，多去关注你能思考出什么、能创造出什么。每当我开始写一小段看似简陋的测试代码去探索某个语言机制时，代码往往会反抛给我上千个全新的疑问——而那才是我真正开始深度学习的时刻。

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

主持人：你每年要在全球做几十场技术分享和主题演讲。平均而言，你准备一场演讲通常需要多久？你的具体打磨流程是怎样的？

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

如果是一场纯技术实战演讲，通常需要 3 到 4 个月的筹备周期。我会确定主题，然后开始全面收集高质量的代码范例，梳理出严密的逻辑脉络。但如果是面向全场的大型主题报告（Keynote），我通常需要酝酿一到两年。

一旦我确立了一个主题方向，在接下来的日子里，哪怕昨天在技术大会上和别人闲聊，对方的一句话触动了我，我就会立刻把这个灵感点记录到这个主题的专属素材库里。我会把所有的案例、故事、见闻统统扔进一个纯文本文件里。

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

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

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

Venkat Subramaniam：千真万确，每一次都是如此。我现在完全不做任何演讲彩排。

因为在一到两年的酝酿期里，这些知识与故事已经彻底内化到了我的血液和骨髓里。这不是我登台前临时死记硬背的讲稿，而是我常年在脑海里反复推演、动手验证、与同行激烈辩论过的真实思考。到了临登台前，我唯一需要梳理的只有叙事弧线（Narrative Arc）。

纯技术演讲我早就不再使用任何 PPT 或 Keynote 幻灯片了（全程实时 Live Coding）；只有大型主题报告我才会做几张幻灯片。我之所以不在很早的时候制作 PPT，是因为 PPT 的格式限制太大。一旦内容被固定在排版结构里，你就很难自由地调整、删减和重新组织逻辑。纯文本文件才是最佳的思考载体。

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

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

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

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

我永远忘不了几年前在瑞典 JFocus 大会上的经历。后台负责音视频的调音师在给我佩戴胸麦时，听到了我急促粗重的呼吸声。她抬头看着我问：“这是你第一次做公众演讲吗？”我说：“不，这大概是我做过的第 10,000 场演讲了。”她惊讶地说：“天哪，你听起来非常紧张！”我说：“是的，我很紧张。”

但我认为，适度的紧张感是人类身体给予你的正面反馈，它在提醒你：集中注意力，该全力以赴了。如果哪一天我登台前连一点紧张感都没有了，那大概就是我该退休离开舞台的日子。

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

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

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

Venkat Subramaniam：天哪，太多次了！不过有一段经历绝对堪称永生难忘。这场事故甚至被完整录下来传到了 YouTube 上。

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

那是一场极罕见的大型技术主题报告，内容是关于"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……现场安装编译器与运行库！

全场观众彻底看呆了，所有人都以为这是一场精心编排的行为艺术双簧秀，但实际上完全是毫无排练的临场生死时速！最终，我们奇迹般地把整场演讲完美交付了。

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

主持人：从漫步、徒步中捕捉思想火花，到从斯德哥尔摩博物馆的展品中汲取灵感，究竟是什么在背后驱动着你？

Venkat Subramaniam：我想是因为我骨子里天生容易对未知事物产生兴奋感。但请允许我先回顾一段童年往事，这段回忆其实有些沉重。我小时候在学校念书时经历过极其灰暗的时光——我曾是一个不折不扣的差生、全科挂科生。

在我童年读书期间，我几乎没有哪门功课是及格通过的。回想起来，我能升学基本上全靠所谓的“按年龄连带升学（Social Promotion）”。多年以后，当我一路拿到计算机科学博士学位时，当年那些看着我长大的长辈和熟人，没有一个人敢相信我能读完博士。

我非常幸运地遇到了一位伯乐教授。当我读完硕士研究生时，教授突然主动给我打来电话。还没等我把话说完，教授在电话那头斩钉截铁地说："Venkat，你不用多说了。我已经帮你安排好了，我要你立刻注册攻读博士学位，并且必须把它读完。”这位教授在教我期间看到了我身上的潜能，给予了我无比坚定的信任。

多年后，有朋友问我："Venkat，在培养和教育下一代上，你有什么好的建议？”这句话瞬间勾起了我的回忆，促使我脱口说出了一句我此前从未总结过的心里话：“我突然意识到，我痛恨‘应试做题（Studying）’，但我极度热爱‘求知探索（Learning）’。”

在此之前，我从未清晰地看清这两者之间的本质鸿沟。应试做题（Studying）会束缚你、禁锢你；而真正的求知学习（Learning）却能解放你的心智。

我的童年充斥着被逼应试的压抑，我对此深恶痛绝；但当我走过那个阶段，真正进入到探索式的自主学习中时，求知成了一种无与伦比的享受。回到你的问题：是什么让我永葆热情？正是探索未知时的敬畏与欣喜。

当我意识到自己对某个知识点一无所知时，我内心会感到极其谦卑，同时又会陷入由衷的兴奋。举个例子：在 Kotlin 语言中，你可以编写一个 Lambda 表达式，把它作为“带接收者的函数字面值”直接挂载到任意一个外部类上。当我第一次看到这个特性时，我整个人都惊呆了：“这怎么可能？”

我没有简单地把这个问题扔给 AI 去要一个现成答案，我渴望探究它背后的底层设计哲学。突然我灵光一闪：“等等！我精通 JavaScript。在 JavaScript 里，你可以轻松地将一个函数绑定到任意对象并执行。难道……"我立刻打开 Kotlin REPL，用我当年在 JavaScript 里的底层思维，在 Kotlin 中写了一段特殊的语法来绑定 Lambda——这段代码竟然真的完美运行了！

在那之前，我从未在任何技术文章或教程里见过有人这样写过。那一瞬间，我彻底看清了 Kotlin 这一现代特性的底层脉络是如何从早期脚本语言的动态思想中蜕变演化而来的。我的大脑里仿佛瞬间亮起了一盏璀璨的灯泡！

正是这种时刻让我痴迷。一旦我参透了底层的来龙去脉，我就有了向他人分享的故事。我不是语言规范的制定者，业内有太多令我敬佩的语言设计大师；我所能带给社区的，正是我自己在探索之路上的心路历程、顿悟时刻与纯粹的喜悦。

主持人：印度本土的基础教育体系，是否存在极其严重的“为了应试而应试”、把分数当作唯一衡量标准的内卷竞争倾向？

Venkat Subramaniam：何止是严重，简直令人心痛。虽然我已经离开印度 40 年了，对当地现状了解有限，但每次回国探亲听亲友讲述，那里的应试内卷只会比当年更甚。我认为这极其不幸。求知是一辈子的长跑，一旦你把探索的乐趣从孩子身上剥夺殆尽，学习就沦为了一种沉重的精神枷锁，孩子们也因此失去了童年。

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

回首往事，那样的教育评价体系是多么幼稚与狭隘。这也彻底塑造了我作为父亲的育儿观：我彻底抛弃了用“卷面分数”来衡量我孩子成长的标准。

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

在我的专业课上，我把大部分成绩权重从“单次考试表现”转向了"过程实践与演进记录"。只要你动手实践的频次足够高、探索足够深入，你就能拿高分。我布置大作业，考核的重点从来不是你最终交出来的那个完美运行结果，而是你在整个迭代演进过程中投入了多少思考与心血。

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

在动手创造中获得的快乐，远比冷冰冰的卷面成绩要广阔得多。我常对学生说：“抱歉，我不在乎你卷面上考了满分，因为很多拿满分的人在面对实际工程问题时根本无从下手，他们掌握的只是空洞的应试技巧。”

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

主持人：站在当下的时间节点，回顾过去十年 Java 的剧烈演进，你认为 Java 处于一个怎样的历史位置？

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

在我看来，真正的破局转折点是 Java 8。我记得在 Java 8 正式发布的三四年前，我刚从外地出差回来，心里还在嘀咕："Java 加不加 Lambda 有什么大不了的？”回到家后，我随手下载了 Java 8 的早鸟预览版开始试玩。写着写着，我猛地从办工桌前站了起来，心里惊呼："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 个月一期的预览通道，全球成千上万的一线开发者可以在真实项目中试用并向官方反馈。Java 架构团队收集所有实战反馈后，再从容决定是继续演进、推倒重构，还是果断废弃。

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

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

我之所以对虚拟线程如此推崇，完全契合我刚才提到的架构设计哲学。回过头看，我们不得不承认：JavaScript 在 20 多年前做对了一件事——它在诞生之初就押注了异步非阻塞模型（Asynchronous Programming），而非高成本的多线程并发。25 年后的今天，在微服务与高并发业务系统大行其道的时代，我们深刻认识到异步架构对于吞吐量的巨大提升。

但 Java 团队引入异步的方式极其惊艳。他们没有盲目跟风："JavaScript 搞了 async/await，C# 搞了 async/await，Kotlin 搞了挂起函数 suspend……那我们也照猫画虎加个 async/await 吧！”Java 团队断然拒绝了这种破坏语言纯洁性的做法。

作为一个架构师，我始终追求极简的解决方案，并且极度推崇“延后到最后负责任时刻（Last Responsible Moment）”的决策原则——在对系统性能瓶颈拥有充分把握之前，不要过早引入复杂的架构。但是在 JavaScript、C# 或 Kotlin 里，作为架构师，我每天都在被逼着提前做决定：“这个函数未来需要做成异步的吗？”为什么你必须今天就做决定？因为一旦未来某一天你要把它改成异步，重构成本将极其高昂（即著名的“彩色函数/染红”问题）！

而 Java 团队说：我们需要异步的高吞吐，但我们绝不破坏原有函数的调用语法与结构！在虚拟线程下，代码依然按照最自然、最易读的同步阻塞方式编写，底层的运行时会在 I/O 阻塞时自动卸载和挂起虚拟线程，将底层的操作系统载体线程释放给其他任务使用。

凡事皆有权衡（Trade-offs）。有人会反驳：“在 C# 或 Kotlin 里，我一眼就能看出哪个方法是异步的；而在现代 Java 里，光看代码签名你分不清它是同步还是异步。”但对我这样的架构师来说，Java 将重构成本抹平为零！今天我可以安心写出最直观的同步逻辑；明天系统遭遇流量洪峰需要扩容伸缩时，我只需在最外层把线程池替换为虚拟线程调度器，业务代码一行都不用改，就能以近乎零成本获得海量并发吞吐！

这就是将决策延后到“最后负责任时刻”的极致工程美学。在我眼中，Java 的创新从来不是去发明别人从未见过的炫技语法，而是以一种前所未见的优雅工程方式，将强大的能力融入现有体系之中。

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

Venkat Subramaniam：我不是一个追求花哨语法糖的人，代码表现力固然重要，但我更关注它能否解决现实生产中的硬核痛点。多年前我为客户开发过一个涉及海量实时计算的企业级系统，那次经历让我刻骨铭心。项目中充斥着数十亿次的高频密集运算，我们在架构中重度使用了 Java 8 Lambda。

当时团队里有一位资深开发私下对我说："Venkat，我没想到你会在生产环境里这么重度地使用 Lambda。我一直暗自担心：这么大范围用 Lambda，会不会引发严重的性能衰退？”在小规模测试集下，系统运行得飞快；但当把几十亿真实计算量的数据集灌入系统时，程序耗时变得极长，性能急剧恶化。

我们立刻排查 Profiler 监控，结果发现：CPU 绝大部分时间全耗费在了垃圾回收（GC）上！原因在于我们使用了大量的双精度浮点泛型集合 List<Double>。Java 泛型的类型擦除机制，导致系统在计算过程中，将每一个基础类型 double 疯狂自动装箱（Autoboxing）成堆内存中的大写对象 Double，从而在内存中制造了天文数字级别的临时短命对象，瞬间挤爆了内存并引发频繁的全盘 GC 停顿！

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

因此，对于所有需要处理密集计算的现代应用来说，Java 最迫切需要的杀手级特性就是支持值类型的泛型（Generics with Value Types，即 Project Valhalla 项目）。如果能够让泛型直接持有扁平化、无对象头开销的基础值类型，无需任何装箱惩罚，Java 的性能将迎来又一次质的飞跃。

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