skip to content
Yucheng (YC)'s Blog
Table of Contents

2025 年 12 月，AWS CTO Werner Vogels 站上了他最后一次 re:Invent 演讲的舞台。

他没有发新产品。他聊了一个更大的问题：在 AI 时代，开发者到底还有没有用？

他的回答是用一整场演讲，构建了一个他称为 Renaissance Developer（文艺复兴开发者） 的框架。

这篇文章不是 keynote 笔记。我想借 Vogels 的框架，聊一个我自己更关心的问题：在 AI 文艺复兴时代，什么样的人能活得好？

每一代恐慌都一样

Vogels 开场放了一个短片：从打孔卡时代开始，每一代新工具出现，都有人喊”开发者要完了”。

COBOL 出来了——“人人都能写代码了，程序员要失业了。” 拖拽式编程出来了——“以后不用写代码了。” 云计算出来了——“工程师要被裁了。” AI 出来了——“这次是真的。”

四十年，同一句台词，换了四次道具。

但 Vogels 指出一个反复被验证的模式：每一次工具降低了”写代码”的门槛，却同时提高了”设计系统、定义问题、承担责任”的门槛。 编译器没有消灭程序员，它制造了软件架构师。云没有消灭运维，它制造了 SRE。

AI 不会消灭开发者。但它会消灭只会写代码的开发者。

文艺复兴的四个条件

Vogels 把当下类比为文艺复兴。不是随便类比——他给出了具体的映射。

文艺复兴之前是黑暗时代：瘟疫、战争、思想停滞。然后好奇心爆炸了。人们开始质疑旧的权威，重新观察自然。伽利略、哥白尼、达芬奇这些人不把”艺术”和”科学”分开，他们在同一张桌子上讨论透视、力学和美学。

更重要的是，工具在同一时期进化了：

  • 铅笔降低了记录与修改的摩擦
  • 消失点让平面画作有了三维深度
  • 显微镜和望远镜把人类感知扩展到肉眼不可见的尺度
  • 印刷术实现了知识的规模化复制

Vogels 的核心洞察是：文艺复兴成功的关键不只是伟大人物，是人物与工具的共振。 创造力和技术共同进化。

映射到今天：

旧秩序在崩塌。 传统软件开发靠分工——产品经理写需求、设计师画稿、工程师写码、QA 测试、运维部署。AI 让这套流水线开始松动。

新工具在爆发。 AI 模型、云基础设施、机器人硬件——就像文艺复兴的印刷机和显微镜，是超级扩展的”工具集”。

知识获取成本暴降。 以前学一门新语言要几个月，现在边用边学。以前做一个 MVP 要几周，现在几天。

多个黄金时代在交汇。 航天、AI、机器人、生物技术——不是单一赛道的突破，是多领域交织。任何一个领域的进步都被其他领域放大。这更像文艺复兴，而不是上一个十年的移动互联网。

四个条件全部成立。但文艺复兴也持续了两百多年。前面几十年，大多数人还在做中世纪的事情。我们现在可能就在这个阶段。

从 Developer 到 Builder

Vogels 说的是 Renaissance Developer——写代码的人。他的五个品质——好奇心、系统思维、精确沟通、所有权、博学——都很扎实。

但我认为他说小了一个级别。

AI 真正改变的不只是写代码。是整个”造东西”的过程。一个人可以同时是产品经理、设计师、工程师、运维、市场。不是因为他什么都精通，是因为 AI 把每个领域的门槛都降到了一个人可以够到的程度。

所以我更愿意叫它 Renaissance Builder。

但 Builder 不是”什么都自己干的人”。是”知道什么该做、什么不该做”的人。

看三个例子就清楚了。

三种判断力

Peter Steinberger 退休后用 AI 一个人做了数十个开源项目，横跨 Swift、TypeScript、Python、Rust。OpenClaw 48 小时 34,000 stars，60 天突破 157,000。一月份一个人 6600+ commits。

“From the commits, it might appear like it’s a company. But it’s not. This is one dude sitting at home having fun.”

他几乎不写代码。“I ship code I don’t read.” 他判断的是架构：几十个模块，哪些该拆成独立项目、接口怎么设计、什么样的抽象会在三个月后变成技术债。这些判断来自 13 年做 PSPDFKit 的经验——iOS、Android、Web、Server、PDF 标准、企业销售全部经历过。AI 写得出代码，写不出这种跨领域的直觉。

前阵子我发了条推，说他是 AI 文艺复兴时代的达芬奇。他本人也点了赞。

steipete 点赞截图

Pieter Levels 的技术栈简单得不像话——PHP、jQuery。但月入 $138K（2025 年 11 月），NomadList、RemoteOK、PhotoAI 全部一个人做。他判断的是需求：十年间做了无数项目，大部分失败了，活下来的是他最准确地读到了一群人痛点的。AI 加速了试错循环，但”试什么”这件事，AI 帮不了。

Simon Willison 用 AI 做以前”不值得做”的小工具：Datasette、llm CLI、shot-scraper… 他的判断力在选题——在无数可以做的东西里，挑出真正有人需要的。二十年跟开发者社区打交道练出的眼光。AI 能帮你一天内做出一个工具，但它不知道哪个工具值得做。

Peter 判断架构，Pieter 判断需求，Simon 判断选题。三种完全不同的判断力，AI 都执行不了。

Verification Debt：AI 时代的新型技术债

Vogels 在演讲里提出了一个概念，我认为是整场最有穿透力的：Verification Debt（验证债）。

AI 生成代码的速度远快于人理解代码的速度。代码可以”瞬间出现”，但理解和验证无法瞬间完成。这意味着系统在还没被真正理解之前，就已经接近了生产环境。

这不是一个 coding 问题，是一个 building 问题。

Renaissance Builder 一个人做十几个方向。Peter Steinberger “ship code I don’t read”。效率惊人，但验证债也在累积——你不读的代码，出了问题还是你的。

再加上 hallucination（幻觉）——模型给出看起来自信但实际错误的设计，引用不存在的 API，提出过度工程的方案——这些输出”看似合理但无现实基础”。你不仔细看，根本发现不了。

执行变快了，但验证没有变快。这个落差就是验证债。

怎么还这笔债？Vogels 的答案不是”更小心”。

机制 vs 善意

Vogels 讲了一个 Amazon 早期的故事。有个供应商打包桌子老出问题，70% 退货率。所有人都”不想再发生了”。但善意没有改变任何东西。

直到他们做了”Amazon 版安灯绳”——给客服一个按钮，直接把问题商品标记为不可售，触发相关团队报警。从此这个问题消失了。

“Good intentions don’t work. Mechanisms do.”

这对 Renaissance Builder 同样成立。你不能靠”我会注意质量”来对抗 AI 幻觉。你需要机制。

Vogels 列了几种机制：

  • S3 团队的 durability review：任何涉及数据持久性的变更，必须停下来系统性建模风险，列出所有威胁和防护栏
  • Code review——他反而主张在 AI 时代增加人对人的 review。理由很简单：AI 可以无限快地产出代码，review 成了最关键的控制点，是把 human judgment 拉回 loop 的地方
  • Andon Cord：在关键链路前挂上”紧急拉绳”，让任何人都能在发现问题时停下整条线

对一个人做产品的 Builder 来说，“机制”可能更轻量，但原则一样：

不要依赖自己的注意力，要设计流程让正确行为成为阻力最小的路径。

写完代码跑一遍测试。每次发布前过一遍 checklist。用 spec 约束 AI 的输出空间，而不是靠 vibe coding 的运气。

用规格驯服自然语言

说到约束 AI，Vogels 演讲里有一段非常实操的内容。

Kiro IDE 团队的 Clare Liguori 发现一个问题：vibe coding 的隐性成本极高。你对 AI 说”build me a web trivia game”，它会在巨大的结果空间里取一个”最可能”的点——但极大概率不是你心中那个点。然后你花大量时间让 AI “改代码”，而不是在”澄清需求”。

她的解法叫 spec-driven development：不直接让 AI 写代码，先让它输出三层结构——

  1. Requirements（需求）：系统做什么、不做什么
  2. Designs（设计）：架构、数据流、组件责任
  3. Tasks（任务）：拆成可执行的小步

先在规格层迭代，直到跟你心中的 mental model 一致，再让 AI 基于规格生成代码。

Clare 说得好：“Natural language doesn’t have to mean high ambiguity.” 自然语言不必意味着高模糊。

这对 Builder 尤其重要。你一个人做产品，没有产品经理帮你写 PRD，没有 tech lead 帮你 review 架构。如果你连 AI 该干什么都没想清楚就让它动手，验证债会指数增长。

Spec 不是官僚主义。Spec 是一个人做产品时最便宜的质量保障。

系统思维：一个人更需要看全局

Vogels 用了 Yellowstone 国家公园的狼来讲系统思维。

20 世纪初，公园里的狼被移除。看上去是好事——少了捕食者，麋鹿更多了。

但实际上发生了 trophic cascade（营养级联）：麋鹿太多 → 啃光植被 → 树木消失 → 河岸侵蚀 → 整个生态崩溃。2010 年重新引入狼群后，植被回归，河狸回来了，河流改变了河道。不是因为狼”直接推河”，是因为捕食者改变了整个系统的反馈回路。

映射到 Builder 的世界：每一个局部优化都在引入新的反馈回路，有些稳定系统，有些摧毁系统。

一个团队里有不同角色帮你看盲区。产品经理看需求偏移，设计师看用户体验退化，运维看系统稳定性。一个人做产品，这些反馈回路全部要你自己建。

Peter Steinberger 能一个人做几十个项目，不是因为他什么都自己盯，是因为他把系统拆成了模块化的小项目——bird、sag、gifgrep、mcporter——每个解决一个具体问题，接口清晰，互相组合。这是一种系统设计，不是一堆散乱的 side project。

Simon Willison 的路径也是一样。每个小工具都是独立的，但它们组成了一个工具生态。系统思维不一定是画架构图，有时候是选择做小的、可组合的东西，而不是一个大的、紧耦合的东西。

Vogels 推荐了 Donella Meadows 的论文 Leverage Points: Places to Intervene in a System。我也推荐。当你一个人做产品，找到杠杆点比在每个角落都投入精力重要一百倍。

“看不见的工作”

Vogels 演讲最后提到了一个容易被忽略的品质：对”看不见的工作”的职业自豪感。

用户不会为你的数据库优化鼓掌，不会为你的部署流水线写感谢信。他们只看到”点一下就能用”。但系统能在夜里稳定运行、故障前被提前规避、部署和回滚悄无声息——都是工程师在”没有观众时”做出的选择。

他认为这是最优秀开发者的共同特征：在没人看的时候，也把事情做到最好。

这对独立 Builder 尤其扎心。你一个人做产品，没有 code review，没有 QA 团队，没有 SRE。偷懒没人知道。但系统知道。用户最终会知道。

Renaissance Builder 的门槛不是工具。是在没人看的时候还愿意把事情做对的那份执拗。

怎么成为 Renaissance Builder

Vogels 的五个品质——好奇、系统思维、精确沟通、所有权、博学——是很好的自检清单。

但如果只能给一条建议，我会说：多做小东西。

Peter Steinberger 没有花三年做一个完美产品。他做了几十个小项目，每个解决一个具体问题，互相组合成了 OpenClaw 的生态。Simon Willison 的 Datasette、llm CLI、shot-scraper 也是同样的模式。Pieter Levels 十年间做了无数项目，大部分死了，活下来的几个养活了他。

每个小项目都是一次判断力的训练。做了才知道什么有人要，什么没人要。做了才知道哪些抽象是对的，哪些三个月后变成债。做了才有品味。

品味不是天赋。达芬奇也是从 Verrocchio 工坊的学徒开始的。品味是大量实践的副产品。

Werner Vogels 在告别演讲里穿的 T 恤印着 Metallica 的歌词：

“Trust I seek and I find in you. An open mind for a different view. And nothing else matters.”

信任、开放心态、不同视角。

文艺复兴给了我们达芬奇、伽利略、米开朗基罗。AI 文艺复兴正在给我们一种新的造东西的方式——一种一个人可以活成一支团队的方式。

这种方式正在被定义。被 Peter 这样退休后比退休前更猛的人，被 Pieter 这样用最简单的技术做到百万美元的人，被 Simon 这样把”不值得做”变成”值得做”的人。

工具在手。剩下的问题是：你愿不愿意进化？