Werner Vogels' Last Lesson: The Renaissance Developer in the AI Era
Werner out. (江湖再见)
这并不是一场隆重的告别,更像 Werner 把麦克风放下,告诉大家:这部分我讲完了。
2025 年的 AWS re:Invent 上,Amazon.com 副总裁兼首席技术官 Dr. Werner Vogels 做了自己在 re:Invent 舞台上的最后一场 keynote。AWS 官方 recap 把这场演讲概括为关于 “renaissance developer” 的分享。
Werner 没有顺着 AI 热点去讲当时最热门的概念。他讲的很多东西,其实还是软件工程里那些老问题,只是换到了 AI Coding 这个场景里。
AI 会不会抢走开发者的工作,Vibe Coding 会不会让写软件变成自然语言魔法,Spec-driven development 是不是新的工程范式,这些问题都可以讨论。需求应该怎么被理解,风险怎么判断,我们应该如何看待结果,AI 时代的问题或许仍旧是以前的扩充。
这是一场有价值的 talk ,简单留一份笔记拯救一下我目前鱼一样的记忆,
为什么是文艺复兴开发者
Werner Vogels 是 Amazon 的 CTO,也是 AWS 技术文化里很醒目的一个人。在加入 Amazon 之前,他曾在 Cornell 做分布式系统研究;加入 Amazon 之后,他长期围绕云计算、分布式系统、机器学习展开研究。
如果只从产品发布看 Werner,那他是 AWS 历史上的技术代言人,非常多具备里程碑意义的产品和理念都由他发布。也可以把他看成一种工程气质的代表:不太沉迷技术本身有多炫,更多时候在追问系统会怎么失败、怎么变简单,以及客户实际会遇到什么。
文艺复兴开发者这个说法也在这里变得有意思。
文艺复兴不只靠某个工具突然出现,印刷术、显微镜、透视法、新的航海技术都在场。在那段历史里是一批人开始跨过学科边界,把科学、艺术、工程、商业和社会放在一起。
今天的开发者多少也站在类似的位置。AI、云计算、具身智能、生物工程、空间技术、能源系统正在彼此紧密耦合。软件工程不再只是屏幕上的应用,它越来越多地进入医疗、物流、教育、能源和公共治理以至于人类生活的方方面面和人类本身。在这些系统里,我们将迎来全新的风险。
文艺复兴开发者的五条特质
一、保持好奇心:别急着跳过理解
Werner 把好奇心放在很靠前的位置。我喜欢这个顺序。优秀工程师当然要熟悉工具和框架,但真正拉开差距的,常常是遇到现象时愿意多停半拍:它为什么会这样?
我在《从设计师到 Agent Builder:看、做、想》里写过类似的意思。看和做会给人手感,想才会把手感沉下来。否则看再多案例、做再多 demo,也很容易只是把别人的形式搬过来,遇到新问题时还是不知道该怎么判断。
AI Coding 让这个问题更明显。过去遇到错误,你要读文档、查源码、打日志、缩小复现范围。慢,烦,但系统的结构会在这个过程里一点点进脑子。现在你可以把报错丢给模型,让它很快给一个看起来还不错的修复。问题解决了,可你未必真的学到了什么。
我当然用 AI,而且用得不少。只是有时候用完以后,我会想一下:这次我有没有真的多理解一点东西,还是只是更快地绕过了麻烦的部分。
AI 很容易制造一种错觉,好像答案出现了,理解也就发生了。其实没有。理解常常发生在比较方案、质疑输出、追问边界、自己重推一遍的过程中。
Werner 用学语言来类比这个过程:掌握一门语言,不是只靠读语法书,而是在真实对话里犯错、被纠正、再说一次。软件工程也差不多。一次构建失败、一个错误假设、一个上线前暴露出来的边界,通常比一段顺利生成的代码更容易留下记忆。犯错本身就是学习和成长的过程。
对事情的原理与本质好奇,继续追问模型为什么这么写、它省略了什么、它有没有把某个旧 API 当成了新写法。这是成长和变强的核心。
二、系统性思维:先看影响范围
Werner 用黄石公园的狼群故事解释系统性思维:狼少了,麋鹿多了,看起来像是生态更繁荣;再往后看,植被被过度啃食,河岸失去保护,河流形态也跟着变化。一个局部变化,会沿着反馈环路跑很远。
软件里这种事太常见了。
一个重试策略的修改,可能让下游服务在故障时被打爆;一个缓存 TTL 的变化,可能改变整个系统的一致性表现;一个团队边界的调整,可能让问题从代码耦合变成沟通耦合。甚至一个看似节省成本的降级策略,也可能在事故里把麻烦转嫁给用户。
系统性思维听起来很大,落到日常工作里,可能就是多问几句:这个变化会动到哪些反馈?压力有没有被挪到别处?根因有没有碰到?
对于 AI Agent ,系统性思维可能变得更加重要,任何 Agent 都是系统。单个模型能力要看,但系统是否可靠,常常取决于上下文供给、工具权限、状态管理、验证机制、失败恢复和人类审查怎么配合。问完模型能不能做以后,还得继续看模型犯错时,系统会怎样退化。
这其实接上了 Werner 很早就讲过的 “Design for Failure”:别期待组件永远正确,先假设它们会坏,然后在系统层面留好余地。
AI 让局部生成变快,也让局部决策变多。保持系统性思维和对整个系统的控制,不要让人类失去对系统的决策与掌控。
三、有效沟通:把需求说具体
在 AI 编程时代,沟通能力被放大了。而且不仅是人与人之间的功能,还有人与 AI 的沟通,以及 AI 带来的人与人之间的新沟通形式。
以前,开发者主要用编程语言和机器沟通。编程语言严格、啰嗦,但歧义少。现在,我们越来越多地用自然语言描述意图,再让模型把意图转成代码。门槛下降了,模糊性也一起进来了。
一句帮我做一个通知系统,可以对应很多实现:站内信、邮件、短信、Webhook、推送、订阅偏好、去重策略、幂等键、重试队列、频控、审计日志、数据保留、权限边界。短 prompt 会让模型替你先决定一堆隐含约束。后面你再修,很可能是在和它的默认选择打架。
这也是 Werner 谈到 Spec-driven development 和 Kiro 时,我比较认同的地方。Kiro 的 specs 文档把 spec 描述为一种结构化工件,用 requirements、design、tasks 等文件,把高层想法变成可跟踪、可审查、可执行的开发过程。它有点像给自然语言加脚手架。
我不认为 Spec 会成为所有软件开发的新范式。这一点我在《Spec 不是新范式:Vibe Coding、SDD 与 AI 时代的软件工程转向》里已经写过。探索期仍然需要快速原型和反馈,很多约束只有系统跑起来后才会显形。但在高风险、多人协作、长期维护的场景里,把意图、边界、验收标准和设计取舍写清楚,后面返工会少一些。
需求、边界、验收标准写得越具体,模型乱猜的空间就越小,因为沟通产生的返工就自然越少,这就是沟通的意义。
四、主人翁精神:责任还在开发者这边
这场演讲里我最喜欢的一句话,是“工作是你的,而不是工具的”。
AI 可以生成代码、生成测试、生成设计草稿,甚至替你解释一段系统行为。但一旦东西进了生产环境,责任不会落在模型身上。客户不会因为这是 AI 写的就少受一点损失,事故复盘也不会因为工具建议这么做就结束。最后要站出来解释的人,还是构建系统的人。
这也是 Werner 那句 “You build it, you run it” 在 AI 时代的新版本。过去它强调工程团队不能只把代码扔给运维,而要对运行结果负责。现在还要再加一句:不能只把意图扔给 AI,再把 AI 的输出扔给用户。你需要理解、审查、验证,必要时推翻它。
Werner 在演讲里提到 Amazon 的 Andon Cord 实践,让最接近问题的人有机制把问题暴露出来,让系统停下来,推动修正。这里让我在意的是机制本身:看到问题的人能行动,系统允许他行动,组织也尊重这次行动。只说每个人都要有责任心不太够。
这一点在 AI Coding 里很明显。AI 会让代码生成速度超过理解速度,也会让看起来能跑的东西变多。代码审查、测试、可观测性、回滚机制、权限隔离和数据保护不能因为用了 AI 就被省掉。很多时候,AI 生成的代码更需要这些东西。
五、成为博学者:把相邻领域补起来
文艺复兴开发者的最后一个关键词是博学。
这当然不是要求每个人都成为达・芬奇。现实一点说,它更像 T 型能力:在一个领域扎得足够深,同时对相邻领域保持基本理解。
软件工程越来越不适合只盯着自己那一小块。数据库工程师如果理解前端性能和用户等待时间,设计索引时会有不同取舍;后端工程师如果理解产品分发和客户支持,就不会只追求架构上的漂亮;Agent 开发者如果理解安全、交互、评估和组织流程,就不会把模型能做直接等同于系统能用。
我理解的博学,不太像收集很多知识点。它更像是知道相邻领域在关心什么,遇到问题时能把几个视角放到一起看。困难的问题经常出现在边界处:技术和业务之间,模型和工具之间等等。
AI 会重新定价一些单点技能。会写某个框架的样板代码,可能越来越不稀缺。能把模糊问题拆成可验证路径,能理解几个系统之间的相互影响,还是要花时间练。
先有一个能站住的专业底盘,再慢慢把感知范围往外扩一点。懂得多一些相邻约束,很多设计决定会少一点自信过头。
Builders 的真实样子
这场 keynote 里,Werner 还讲了不少现实世界里的 Builder。
这些案例横跨农业、环保、医疗和能源:在亚马逊河流域,有公司通过可持续供应链支持当地社区,让年轻人不必离开家乡才能获得收入;Ocean Cleanup 用无人机、AI 图像分析和 GPS 追踪理解塑料垃圾在河流里的路径;卢旺达的健康数据系统帮助政府根据疾病暴发和妇幼健康等指标做公共决策;内罗毕的 KOKO Networks 用云计算支撑城市级清洁燃料分发网络,让普通家庭用更低成本获得更清洁的能源。
这些故事不太像发布会里常见的技术改变世界说法。它们更具体:有人少跑一段路,有人不用离开家乡,有人能用更干净也更便宜的能源。
这也是我觉得 Werner 和很多技术布道者不太一样的地方。他当然关心分布式系统、云计算、AI 和架构原则,但他讲到最后常常会回到人身上:谁在用,谁承担成本,谁因为这个系统过得稍微好一点。
我不太想把 Builder 精神解释成更快 ship。Werner 讲的这些例子里,很多工作发生在用户看不见的地方。数据库没有崩,用户不会发感谢信;清洁能源网络稳定运行,很多人只会觉得今天做饭很正常;健康数据系统提前发现风险,最好的结果可能是灾难没有发生。
这类工作不容易被写进发布稿里。
乔布斯评价约翰·斯卡利时说,他得了一种“精英病”:以为有了一个绝妙的点子,工作就完成了 90%。可从伟大的想法走到伟大的产品,中间隔着的是巨量、枯燥的手艺活。Builder 的工作也在这个间隙里。AI 改变的是其中一部分劳动的成本,并没有抹平这个间隙。今天的 Builder 不必亲手熬过所有琐事。AI 助手已经可以补样板代码、写测试初稿、翻日志、整理文档、批量跑检查。省下来的时间可以拿去处理那些更难被自动化的事:用户到底怎么用,一个看似局部的改动会把成本挪到哪里,上线以后出了问题谁来收拾。
那九成工作的重点,也不在于把每一颗螺丝都自己拧一遍。人在细节里才会慢慢发现,原来的点子哪里不对,哪些妥协值得,哪些不能接受。AI 能做掉不少手艺活,判断还在我们这里。这也把前面那五条特质拉回到同一个现场:好奇心让人不满足于一个能跑的版本;系统思维提醒人继续看代价最后落在哪儿;沟通能力决定 AI 接到的意图够不够清楚。到了出错的时候,主人翁精神让人不往后退;而理解产品、运营和用户分别在关心什么的那点博学,也会在这里派上用场。
Now Go Build
Werner 说了很多年的 “Now Go Build”,在 2025 年这场最后 keynote 里听起来多了一点收尾的感觉。
联合国《World Population Prospects 2024》显示,全球人口在 2024 年约为 82 亿,预计会在本世纪中后期继续增长,并在 2080 年代中期达到约 103 亿的峰值。人口预测会随着数据更新而变化,但未来几十年,医疗、能源、教育、基础设施、气候适应和经济机会都会面对持续压力。这一点不难判断。
这类压力最后会落到具体的技术问题上:更可靠的医疗数据系统,更低成本的清洁能源分发,更容易使用的高级计算能力,以及不只服务注意力经济的 AI 应用。
AI 会继续变强,开发工具也会继续变化。但有些理念正确了十几年,或许也会再正确下去。
Werner out. (江湖再见)
参考资料
- AWS Events, AWS re:Invent 2025 - Keynote with Dr. Werner Vogels
- AWS News Blog, AWS Weekly Roundup: AWS re:Invent keynote recap, on-demand videos, and more
- AWS, re:Invent 2025 on demand
- Amazon Science, Werner Vogels
- Kiro Docs, Specs
- United Nations Population Division, World Population Prospects 2024
- United Nations Population Division, Data Portal
- Classmethod, [リアルタイム更新] A Special Closing Keynote with Dr. Werner Vogels
- Title: Werner Vogels' Last Lesson: The Renaissance Developer in the AI Era
- Author: Hyacehila
- Created at : 2026-07-01 07:30:00
- Link: https://hyacehila.github.io//blog/2026/06/30/2026-07-01-renaissance-developer-werner-vogels-reinvent-2025/
- License: This work is licensed under CC BY-NC-SA 4.0.