夜雨聆风
一个老兵重回战场，带来一个不安的预言
Rod Johnson 不是第一次站在历史的转折点上了。
二十多年前，他写下 Spring 的第一行代码，那时的 Java 生态一片混沌，EJB 架构笨重、难用、让人抓狂。他用一本书、一套框架，重新定义了企业级 Java 应用该怎么写。不夸张地说，他改变了全球几百万开发者的日常。
然后他离开了。去做董事会、做投资，离代码越来越远。
直到 ChatGPT 出现。
他重新回到了键盘前，创办了 Embabel——一个面向企业 AI Agent 的开源框架。按理说，这是一个老兵归来的励志故事，见过大风大浪的人，重新入局，一定胜券在握。
但他说出的那句话，却让我停了很久：
"这可能已经是最后一代由人类主动选择的框架了。以后越来越多的技术选型，都会由我们的工具替我们完成。"
注意，这不是一个 AI 布道者在讲 AI 替代论。这是一个亲手参与过"框架时代兴起"的人，在重新入局时说出的话。
他不是预言家。他是见证者。
框架，从来不只是技术问题
你可能会想：技术选型而已，AI 帮我选不好吗？
这个问题值得慢慢想。
框架不只是工具。它是一种世界观的外化。
选择 Spring，你在说："我相信依赖注入、相信关注点分离、相信代码应该可测试。"选择 LangChain，你在说："我相信链式调用、相信快速原型比架构优先。"选择自己写一套，你在说："我相信没有人比我更了解我的业务边界。"
每一次技术选型，背后都有一套价值判断：什么是好代码？什么是可维护的系统？什么是我们愿意为之付出学习成本的方向？
Rod 在访谈中提到，他最多只写 5% 的代码，其余都交给 AI Coding Agent——但他牢牢掌握着架构的控制权。他会盯着 diff 看，经常打断 Agent："不对，这里应该是一个策略，提取出来。"
他把这种工作方式类比为指挥：指挥家不需要亲手演奏每一个音符，但他必须知道这首曲子应该是什么样子。
问题是：如果连"这首曲子应该是什么样子"这个判断，也逐渐被外包出去呢？
失控是怎么发生的：三个不同场域的故事
职场场景：Vibe Coding 的温水效应
一家中型互联网公司的后端团队，三年前有十二名工程师。现在还是十二人，但产出翻了三倍——因为大量代码由 AI 生成。
起初，大家都很兴奋。AI 帮我写样板代码，我专注于核心逻辑，这不是最理想的状态吗？
但慢慢地，出现了一些微妙的变化。
新来的工程师开始把理解代码的时间，花在了"调整 AI 提示词"上。代码 review 的重点从"设计是否合理"变成了"AI 有没有漏掉什么"。当系统出现一个从未见过的 bug 时，没有人能第一时间判断问题出在哪一层——因为没有人完整读过那段代码是怎么一步步写成现在这个样子的。
Rod 在访谈里说得很直白："一旦你进入复杂的应用程序，如果你不保持那种架构上的监督，你很快就会陷入一团乱麻。你的 Agent 会愉快地添加新功能，但每添加一个新功能，设计就会退化，代码就会变得非常糟糕。"
失控不是突然发生的。它是一种渐进的、让人舒适的退化。
家庭场景：导航 App 与失忆的空间感
这个例子不在访谈里，但你一定有同感。
十年前，你去一个新城市出差，靠地图和问路，第二次去就大概知道方向了。
现在，你用了三年导航的那个城市，还是不知道东南西北。每次打开 App，它告诉你"前方左转"，你左转；"前方右转"，你右转。你到达了目的地，但你的大脑里没有留下任何地图。
空间感是需要主动建构的。一旦外包给工具，它就开始萎缩。
技术直觉，也是一样。
你可以问 AI："用 Java 还是 Python？"它会给你一个有道理的答案。但这个答案背后涉及的判断——团队现有能力、系统的邻接性、未来的维护成本、技术债的偿还路径——这些只有你知道，只有你能判断。
如果你把这个判断也交出去，你获得了一个答案，但你失去了做出这类判断的能力。
社会场景：算法推荐与品味的消失
还记得你上一次主动去找一首歌、一本书、一部电影是什么时候吗？
不是因为算法推给你，而是你自己说："我想听这个。"
流媒体平台的推荐系统，本质上是一套"技术选型系统"——它替你决定你接下来消费什么内容。
一开始，它的推荐很准，你很满意。
但慢慢地，你发现你的品味开始变窄：你只喜欢"算法认为你会喜欢的东西"。你开始在推荐之外感到茫然，不知道自己喜欢什么。
这不是比喻。这是一种真实发生的认知萎缩。
当工具持续替我们做选择，我们的选择能力本身，就在悄悄退出。
命名这个困境：选择权萎缩定律
我想给这个现象一个名字：选择权萎缩定律。
当一项能力被持续外包给工具，做出这项判断的内部能力就会同步退化——即使工具的输出质量很高。
这不是工具的问题。工具本身是中性的。
问题出在：你用工具的方式，是否保留了你自己的判断介入点。
Rod 的用法是这样的：AI 写 95% 的代码，但他审每一个 diff，他提出架构批评，他知道系统应该是什么样子。他用工具，但他没有把判断权交出去。
而失控的用法是：AI 写代码，AI 选框架，AI 决定技术路线，人只负责"看起来能跑就行"。
区别不在于用了多少 AI，而在于：你是否还保有对核心判断的掌控。
这个框架有三个层次：
第一层：执行外包（安全）把具体的、重复的、低判断性的任务交给 AI。写样板代码、生成测试用例、格式化文档。你的判断介入点清晰：你决定做什么，AI 决定怎么做。
第二层：批评外包（警戒）用 AI 审视你的决策，但决策本身仍由你做出。Rod 说 AI 更擅长批评而不是原创，这是一个很好的用法——但前提是你先有一个东西让它批评。如果连"要批评什么"都交给了 AI，你只是在做一场没有主题的对话。
第三层：判断外包（危险）框架选谁？架构怎么设计？这个业务逻辑该不该用 LLM？这些判断，一旦习惯性交给工具，你的判断肌肉就开始萎缩。你会变成一个"能执行工具输出结果"的人，但不再是一个"能独立判断技术方向"的人。
反转：你以为是效率提升，其实是能力转移
这里有一个认知陷阱，需要点破。
大多数人在谈论 AI 工具时，用的是一个"效率框架"：我原来一小时写 100 行代码，现在 AI 帮我写，我一小时能出 1000 行。效率提升了十倍。
这个框架是对的，但不完整。
Rod 提到了一个更深的问题：他完全理解 Embabel 的架构，完全熟悉 Kotlin 和 Spring，正因为如此，他才能有效地掌控 AI 的输出。如果一个开发者选择了"不理解架构"那条路，"就会很麻烦"。
换句话说：AI 工具的放大效应，放大的是你已有的能力，而不是替代你没有的能力。
如果你有扎实的架构判断力，AI 让你如虎添翼。
如果你没有，AI 帮你快速构建了一个你自己也不懂的系统，你会在第一次出问题时完全手足无措。
这就是为什么"AI 让初学者飞速入门"这件事，有时候反而是个陷阱。你看起来能做很多事，但那些事背后的判断力，并没有在你身上生长出来。
Rod 说了一句很有意思的话："每个开发者原则上都应该每隔一两年学一门新语言，因为它真的会改变你的思维方式。"
学一门新语言，不是为了多一个技能点，是为了保持主动建构判断力的习惯。
学语言的过程，就是你在主动形成关于"什么是好代码"的判断的过程。这个过程是不可以外包的。
工具清单：如何在 AI 时代保留判断主权
这不是一篇劝你不用 AI 的文章。Rod 自己就是 AI 工具的深度用户。问题从来不是"用不用"，而是"怎么用"。
以下是一个自检框架，每隔一段时间问自己：
关于执行层
• 我让 AI 做的事，我自己能做吗（哪怕慢十倍）？
• 如果 AI 的输出有问题，我能看出来吗？
关于判断层
• 最近一次重要的技术/架构决策，我是自己做出的，还是 AI 建议后我点了确认？
• 我能用自己的话解释这个系统为什么这么设计吗？
关于成长层
• 我还在主动学新东西吗（不是因为 AI 建议我学）？
• 我上一次感受到"这个判断只有我能做"是什么时候？
尾声：选择权是一种肌肉
Rod 最后说，他不知道五年后 Embabel 是否还存在。
他不确定的，不只是商业前景，而是更根本的东西：五年后，人们还会亲手选框架吗？还是说，这件事已经完全交给了工具？
他用了一个让我觉得很沉的表达——"最后一代由人类主动选择的框架"。
不是因为 AI 会强制接管。而是因为，选择是需要主动行使的。不主动行使，它就会自然萎缩。
就像一块长期不用的肌肉。
你不是突然失去了它。你只是，慢慢不再需要它了。
然后有一天，你发现你动不了。
在你自己的工作和生活里，有哪些判断，你觉得自己还牢牢握在手里？有哪些，你已经不记得上次独立做出是什么时候了？
结尾互动
👇 看到这里了，说明你是真爱！
如果这篇文章对你有启发，点个「推荐」，让更多人看到它。
关注「思维体系」，持续输出让你看透世界的底层逻辑。
你的点赞、收藏和转发，是我持续创作的最大动力 🙏
