AI 编程助手承诺提升速度，但也几乎必然对质量、信任与架构师的工作方式造成影响。在本播客中，InfoQ 与 Gardy Booch 探讨了当机器与人类共同编写代码时，架构应当如何进化的原则性议题。讨论中剖析了软件工程的第三个黄金时代：生产力提升的真实价值与潜在风险所在，以及架构师应如何设计审查机制与实践，从而保障软件项目的长期完整性。
基于数十载的软件工程实践经验，此番探讨超越了炒作的表象，深入剖析了 AI 增强时代下哪些职责应由人类坚守，也阐明了为何架构判断、责任担当与创造性思维在当下比以往任何时候都更加重要。
内容摘要
我们已身处软件开发的第三个黄金时代，AI 只是其中的组成部分、而非驱动因素。行业正从算法时代迈向对象时代，继而进入平台时代与系统全球分布的时代。AI 工具作为抽象层被嵌入平台的时代，加速了架构师对非完全可控系统的组合与编排探索。
尽管设计流程已经实现自动化，架构决策的转换成本依然高昂。AI 虽能快速生成设计方案、模式与代码，但架构本质上仍是一整套涉及长期成本决策、弹性与进化选择的复合体。这些决策仍离不开人类在权衡、约束条件与风险因素层面的判断。
AI 通过提升抽象化程度以增强杠杆作用，而非取代人类思考。与当初的编译器类似，大语言模型同样将底层工作转交给机器，帮助人类在更高的概念层上工作。真正的收益仍源自经验丰富的从业者对输出结果进行指导、质疑与验证，而非粗暴将 AI 模式奉为圭臬。
最大风险在于技能退化、思维趋同与虚假自信。大语言模型往往在潜移默化中令开发团队更倾向常见的安全模式，侵蚀初级工程师的成长路径。对 AI 的过度依赖还会制造正确性幻觉，忽略了 AI 开发体系正愈发平庸、在新兴场景中往往失效。
AI 增强工程中，人类责任绝不可动摇。当 AI 生成或审查代码时，质量、安全与结果的责任仍由人类架构师与工程师承担。我们必须保持清醒、划定清晰边界，主动承担责任而非躲在工具背后。
第三个黄金时代并非始于 ChatGPT 的崛起
Shweta Vohra: 今天我们将开启一个全新的播客系列。这个系列想讨论的是，在 AI 时代，架构师如何重新思考设计方法、平台架构、API 体系，甚至整个交付模式。我们的目标不只是谈趋势，更希望把这些讨论变成对从业者真正有帮助的实践性指导，帮助大家把这些洞见落实到自己的架构设计和领导力实践中。也正因为如此，我们今天特别邀请到了 Grady Booch。
今天我们想探讨的是，在 AI 工具不断进入软件开发流程的今天，软件架构是否依然像过去那样重要？我们是否正从“软件架构”走向某种新的“AI 架构”？作为 IBM 院士兼首席科学家，Grady 在这个领域有着极其深厚的积累，我也很期待听听他会如何理解这些变化。
很多人可能并不知道，Grady 还是 UML 的联合创始人。就我个人而言，我几乎是从 UML 开始进入这个领域的。当我们最初开始理解“什么是设计、如何组织系统结构、又该如何把这些设计真正表达出来”时，Grady，你其实塑造了几代人对软件架构的理解，甚至可以说影响了软件架构演进的一个个世代。那么当我们再回头看今天这个 AI 辅助开发的时代，哪些东西依然是真实成立的？又有哪些地方，会让你觉得历史正在以某种方式重演？
Grady Booch: “世代”这个词真是让我颇有感触。要完整回答这个问题，我们可能得穿越时光，聊聊软件架构的整个世代更迭。目前我们正处于第三个世代，也是软件架构的第三个黄金时代。
第一个黄金时代可以追溯到上世纪四十、五十和六十年代。当时我们正尝试将软件和硬件区分开来——以往编程时需要直接操作硬件，之后则逐步转向高级编程语言。Grace Hopper 等先驱者在这个过程中发挥了关键作用。这批致力于构建软件产业的人们，在六十年代迎来了事业上的全面开花——IBM 最终决定将软件与硬件解耦，软件由此成立独立存在的实体产业。
现在回想起来，我们软件产业还真是蛮年轻的。萨根曾经把整个宇宙诞生的历程浓缩成今年一月一号到现在的过程，如果把计算发展史也同样这样看待，那我们只处于最后的 250 毫秒当中——也就是瞬息之间。如此浩瀚的文明进程居然浓缩于此，而深入这 250 毫秒，我们会发现连“软件”这个概念也是 1950 年代才诞生的术语。软件工程是由 Margaret Hamilton 于六十年代提出，那会我才刚刚出生。可见如今的辉煌成就，不过产生于两、三代人之间。但它已经将我们带向了惊人的高度，并在短短岁月间凭借创造的成果彻底改变了人类的文明形态。
回溯第一个世代，不知道大家了不了解当时的困境：大型机占据主流，且硬件造价甚至高于人力成本。因此那时候软件工程的大量实践，都是在优化计算机经济性、而非满足人性化需求。由于计算机的运行时间极其昂贵，大量工作需要在离线状态下完成，所以前期准备工作尤为重要——这正是瀑布开发模式最擅长的形式，因为前期投入成本更低。当然，如果想在前期修复错误，代价也相当高昂。
正是在计算机的第一个黄金时代，结构化分析的理念应运而生。这也完全合乎逻辑，毕竟软件工程面临的核心挑战就在于规模问题。此前我们从来没经历过这样的转变，这种从自动处理单一数学功能的小型独立程序到构建大规模系统，所以大家都没有经验。人类在面对这些问题时，解决思路肯定是抽象化。在早期计算机中，算法就是核心抽象单元，因此第一个黄金时代聚焦于算法拆分，也由此催生出 FORTRAN、COBOL、C 等语言及其衍生体系。
到了七、八十年代，世界开始改变——微型计算机开始异军突起。人们可以在个人设备上编程，分布式系统也由此崭露头角。之所以说“崭露”，是因为其真正开端源自冷战背景下的 SAGE（半自动地面环境）系统，相当于美国对于苏联军事威胁的战略回应。因此在七十年代前后，我们再次见证软件处理方式新的变革萌芽期——同样是一场根本性的颠覆。
这种变革不仅体现在单台计算机的复杂性提升，更标志着软件行业向着分布式系统的整体迈进——当然，这还只是互联网诞生的前夜。不知道大家还记不记得，自己的第一个电子邮箱是什么时候注册的。我敢说我应该是最早的：1979 年，我在 ARPANET 上注册了首个邮箱。当时甚至还有一本专门的小册子，收录了全球所有用户的邮箱地址。我恰好亲历了这项伟大发明的萌芽阶段。值得注意的是，当时分布式系统的研发并非源于工业领域或者商业部门，而是由军事系统驱动的软件工程创新。
于是整整一代人开始面临软件工程能力的严峻考验，好在研究领域涌现出诸多惊艳的突破：David Parnas 提出的信息隐藏理念、Simula 语言倡导的“通过类、而非算法来观察世界”的视角，以及抽象数据类型的构想等等。这些理念汇聚成一股力量，推动美国国防部开发出名为 Ada 的编程语言——尝试用一种统御所有语言的通用语言，以解决当时的软件危机。“软件危机”这词可不是我造的，它源自五十年代末的北约会议。当时人们意识到软件需求激增，但开发速度却严重滞后，由此引发了软件供应危机。
必须承认，我自己恰逢变革浪潮的中心，所以很幸运地获得了实践机会。我汲取了纳帕斯关于抽象内型的理论，意识到这能引领我们以全新视角思考编程——即面向对象的规划设计，而不再是结构化设计。由此，我们步入了软件工程的第二个黄金时代。
我认为咱们正处于软件工程的第三个黄金时代，而且不是从今年才开始的，甚至并非始于 ChatGPT 的崛起。这波浪潮大约是从十年产随着平台的兴起而诞生——因为当软件系统日益庞大时，我们再次看到了变革的迹象，而其中的关键就在于“系统”二字。现在不再是孤立程序的时代了，而且标志物不仅是分布式系统本身，而是一个个彼此交互的分布式系统体系——而我们对其他系统毫无控制权。正如 David Deutsch 所言，“何为分布式系统？”即一旦某台我们甚至不知道它存在的计算机崩溃时，我们自己的系统也会受到影响。这，才是真正的分布式系统。
似乎一夜之间，我们突然置身于真正的全球规模系统当中，也由此见证了技术浪潮的兴起。我们有了算法抽象、对象抽象，如今更要应对完整的平台体系——架构师的核心职责就是将这些元素编排、融合起来。比如需要消息传递功能，那就用这个库；需要授权机制，没必要亲自编写，直接调用某项 SaaS 服务。架构师们的职责突然变成了如何编排这些东西，这就是我们身处的当今时代。
只不过在这个过程中，我们恰巧碰上了 Claude 等工具的兴起。顺带一提，Claude 也是我首选的 AI 辅助开发工具。这些工具构成了第三次黄金时代的氛围和基调，我们也已经身处其中。这恰恰定位了 AI 的发展态势，成为当下新趋势的组成部分。其他行业也存在类似的现象，不过这里我们暂且打住，稍后再展开讨论。
Shweta Vohra: 没错。想到整个软件产业正迈向第三个黄金时代，我整个人都振奋起来了。但我想先重点讨论您特别提到的一个观点，也是我认为软件行业的架构师和创作者必须理解的：您早在 1979 年就理解了电子邮件的意义，但这项技术真正被大众接触可能要到 2000 年左右。如你所说，AI 的发展同样起步很早，而我们当下所见的其实是多年艰苦耕耘的结晶。正是这些努力，最终让构想成为了现实。
AI 应用的本质是人类跟机器之间协同工作
Shweta Vohra: 这就引出了个经常困扰开发团队的议题——如何区分架构与设计。我知道这个话题您已经聊过很多次了。在 AI 时代，设计能不能流水线化？您觉得哪怕工具再怎么演进，架构还是会承担哪些核心职责？方便的话，您可以先聊聊“架构与设计的本质区别”的问题，再结合当今的 AI 工具等技术进行解读。
Grady Booch: 这个问题提得很好，在回答之前需要厘清两点。第一：架构与设计有什么本质区别？第二：在设计与架构当中，创造力分别如何体现？我对此有个简单观察，当然只是个人的定义：一切架构都属于设计，但并不是所有设计都属于架构。架构代表着塑造系统形态与功能的一系列重大设计决策，而是否“重大”的衡量标准在于变更成本。
架构是更高的抽象层级，也对应着设计本身。事实上，设计之下还有更基础的层面，即惯例。比如“变量如何命名？”这类常见的模式，其本质上仍然是选择，而设计始终是选择的过程。如同工程师、设计师和程序员，在本质上都属于工程师。之所以有资格自称工程师，是因为我们致力于构建具有最优合理价值的系统，以抵御静态与动态的双重压力。
假设我是结构工程师，或者是像 Frank Gehry 那样的建筑师，当客户提出“我们要造一栋摩天大楼”时，需要考虑的就有静态荷载、地震等静态与动态因素。建筑物需要承重，地震偶尔会发生，人员也随时进进出出。还有动态荷载，比如风力作用等等。这些都是土木工程领域的建筑师们最关注的核心问题。
工程师们还需要顾虑其他要素：美学考量、成本控制、进度管理、系统可维护性等等。软件工程师们同样面临这些挑战，但我们所处的物理环境截然不同——软件本质上是极具可逆性的流动元素，我们纯粹凭思想就能构建系统。设计的核心始终是选择，底层是编程范式，再上一层则是设计模式等抽象概念。我们需要实现用户与数据间的职责分离，因此创造了 CRUD 模型——“后端处理数据操作，前端负责界面交互”。实践经验已经不断验证了这种职责分离的必要性，这些也都属于设计范畴。
我们这个领域最精彩的地方，在于设计空间的广阔性，海量用例为我们带来了无限可能。这为资深架构师、软件工程师和开发者们提供了大放异彩的舞台：凭借丰富的项目经验和实践积累，他们能够洞察问题的本质，精准运用特定设计模式。
作为更高层次的抽象，架构的本质就是在提醒工程师们做出最关键的决策。比如决定“我要用 React，而非其他语言”——这就是架构决策，而且会造成相应的成本。决策之间也有层级差异，比如选择“采用统计方法，而非经验方法”，这既是设计选择，也属于架构范畴。由此可见，架构涵盖了我们决策体系中的全部维度。
现在再聊聊创造力，也就是架构的第二重维度。人类的独特之处，就在于我们拥有创造力。那创造力究竟是什么？在 AlphaGo 击败全球顶尖围棋选手的比赛中，有位韩国棋手被这场对决彻底震撼，并感慨道“我仿佛在此刻见到了天神的面容，因为 AlphaGo 走出了无人预料的棋步。”创造力也是如此，试想某个空间的景观——比如说我们身处三维空间，我正漫步于乡野，探访山谷中的那座山丘。人类的围棋、历史、传统乃至体验层面，总会踏上相似的路径。关键在于，AlphaGo 并不受传统历史的束缚，它能从另一维度抽身审视整片旷野。它能探索更广阔的状态空间，凭借海量计算能力进行搜索——这与人类截然不同。
这算创造力吗？严格来讲不算。它只是在更广阔的空间中快速探索，但未必能称为创造力——因为创造力意味着在需求、渴望、欲望、情感等语境当中，将意料之外的事物组合起来。我们的 AI 还做不到这一点。它们只是卓越的搜索引擎，擅长处理大语言模型，堪称出色的、但完全不可靠的斜杠者。坦白讲，大模型本质上就是规模化的胡扯生成器——但人类创造力的核心机制，我们至今还是没搞清楚。
到这里，我们已经剖析了两大核心要素。现在回到 AI 的实际应用场景。我自己常用 Claude 处理 JS 项目，同时还负责 Swift、PHP 和 C++等其他项目。于我而言，AI 就像一位充满热情、不知疲倦的实习生——从不睡觉、天真无邪，但因为缺乏创造力而需要持续指导。我可以明确告诉它做什么、处理哪些任务，并收到完美的结果。整个过程我自己不需要投入多少时间成本，而且正确率相当之高——可 AI 本身并不知道。实际上，AI 就不存在“自己”这个概念，毕竟它并非拟人化的存在，我也不愿意把它拟人化。它真正擅长的是自动化，所以 AI 应用的本质就是我这个人类跟机器之间协同工作。
这种模式对我这类用户效果极佳——我没法代表其他人发言，只能说我自己在系统构建领域经验丰富，深谙各类设计模式与架构模式，也懂得从代码中发现问题。我能精准判断代码是否存在隐患，但持续运转的大语言模型就不具备这些认知，更缺乏上下文理解能力。因此我很乐意将一部分任务委托给它，再随后进行核查——就像里根总统在冷战期间所言：“信任，但需要核实。”
从辅助工具的角度审视，可以这样对 AI 做出总结：我对软件领域内的 AI 发展毫不畏惧，甚至为之欣喜，因为它解放了我——代劳了我本须亲力亲为的工作。但同时，它绝不会取代我的工作，因为 AI 在能力上存在根本性局限。
Shweta Vohra: 最近以来，我开始尽量避免将软件架构类比为“建筑”，因为人们常将两者混淆，导致思维僵化。其实 AI 领域充满动态变化，结构永无定态——绝不能说架构建成后，所有决策便已尘埃落定。它始终处于演进之中，如今变化速度更是远甚以往。但你刚才的阐释方式，特别是把 Claude 当作实习生的比喻，确实为创造力提供了绝佳的视角。那是不是可以这样说——这也是我一直在向软件和 AI 架构师们强调的观点：我们总以为是工具在变，却忽视了工具对于自身判断力的侵蚀，最终难以清晰阐述真正发生的变化。真正的变革在于：我们应当成为优秀的主人，而非优秀的奴隶。
Grady Booch: 恕我直言，我更倾向避免使用这些充满情感与历史包袱的术语。我更愿将自身视为导演，而舞台上的演员正是我们执导的对象。顺带一提，这种定位隐含着某种失控感——作为导演，我不可能、也不打算事无巨细地干预，但希望被指导者拥有自主权和自由度。这就引出了关于 AI 智能体的讨论，稍后我们还会涉及。
不过在继续之前，我想提出一个有趣的类比——你提到了土木工程等领域。虽然因为指向对象的物理特性差异巨大，将两个领域相提并论的确既困难又危险，但我仍想重提 Frank Gehry。他设计的迪士尼音乐厅以流畅的曲线著称，而这位建筑大师本身就是天才，但那些恢弘结构是如何诞生的？答案在于 AutoCAD 等工具。正是 AutoCAD 的出现，让 Gehry 这样的设计师得以大胆尝试新形态。AutoCAD 让设计师得以通过数学建模手段实验新形态与新材料，在实体建造前完成验证。因此工具并没有取代建筑师的工作，反而释放了新的创造力——他本人就是最好的写照。
当前 AI 领域正上演着同样的变革。或许有人会质疑：“可建筑业仍存在诸多弊端呀。”事实上，建筑业本身也拥有耐人寻味的历史。那我们就得回溯至 Frank Gehry 出现之前的时代，毕竟他也属于相对新锐的建筑师。让我们回到建筑本身充满争议的年代。在软件开发与软件工程的萌芽期——特别是首个黄金时代，当时的系统多为整体式架构，主要采用汇编语言编写。随着复杂度激增，人类越来越难以掌控自己打造的系统。
于是 David Wheeler、Maurice Wilkes 和 Stanley Gill——我记得是这些人——在五十年代末开始沉思：“我们该如何看待这个问题？是否该将软件拆解开来，而非直接面对冗长的代码列表？要不要创造名为'子程序'的东西？”这些想法当时极具争议。虽然如今这已是我们习以为常的思维方式，但当时他们提出需要这种机制，让人类能够在更高抽象层面上进行思考时，还是引发了很大争议。这是因为当时调用子程序并返回需要额外执行若干机器指令。而对于仅需几毫秒的操作而言，这确实代价高昂。但如今随着计算机性能提升，分布式系统已实现突破。由此可见，那些看似争议的架构决策，最终都将摆脱技术的桎梏。
为何“AI 架构”的本质，是如何用语言描述系统
Shweta Vohra: 现在我想把话题转向 AI 架构。您之前提到创造力与大语言模型的关系——它们能为我们处理混合任务时，但却并不具备真正的创造力。那么从您的视角看，遍布各处的 AI 架构究竟属于全新的架构学科，还是软件架构被迫应对新约束所产生的结果？您怎么看？
Grady Booch: 我完全不懂所谓“AI 架构”，甚至就没听说过这个术语。它具体指什么？
Shweta Vohra: 指的就像您刚刚讲过的，即运用 AI 建立软件架构的新方式。它本质上表明 AI 正在重塑规则。这些设计规则具体是什么？对架构层面有何影响？它究竟属于新兴学科，还是既有学科衍生出的全新原则、规则与防护机制？
Grady Booch: 字眼还是不能随意使用，因为人们总是把各种概念混为一谈，最终导致自己的表达中充斥着毫无意义的噪音。于我而言，“AI 架构”是个极其空洞的词汇。我更愿意讨论“由 AI 工具增强的架构”，这才是有实质性内涵的表述。
架构是永恒的。从古人用泥巴糊草屋的时代，到 Grank Gehry 创造的那些恢弘飞扬的建筑，我们始终见证着架构的演进。架构代表着一种高层次抽象的世界观。软件密集型系统亦是如此——哎呀，我又用了“软件密集型”这个词。其实不仅是软件，更是由硬件、软件、人员及社会共同构筑的系统——而架构师的职责正体现在此。
那么，AI 要如何融入其中？毕竟 AI 只是工具。事实上，我认为我们所见证的不过是抽象层次的新一轮跃升，这也代表着软件架构与软件工程长期发展的历史轨迹。软件工程史就是抽象层次不断提升的历程。早期我们主要致力于控制机器——差分机和 ENIAC 的诞生正是为此而生，旨在掌控机电或机械装置。在更高抽象层级，我们试图将高度抽象化的思维转化为可操控的机器形式，由此诞生了汇编语言。汇编语言本身就比机器语言抽象度更高。
随后我们又发明了高级编程语言，实现了又一次抽象跃升。我认为 AI 工具的兴起，对软件领域的影响将不亚于编译器的诞生。这两者都代表着抽象层次的提升，将大量原本需要人工处理的琐碎事务下放给机器本身。编译器为我们做了什么？在 Grace Hopper 那个时代，FORTRAN 发明之初也曾引发激烈争议，但其核心理念是加速人类工作效率，将编译事务推给机器处理。在 FORTRAN 和 COBOL 时代，困扰人们的仍是如何将数据最优分配到寄存器以提升速度。如今我们无需再为此烦恼，直接交给机器处理即可。
同样的，当我需要修改软件时，只需进行重构。由人掌控模式，机器可以代劳。我只需思考重构方案，让机器执行具体操作。因此我们实现了更高层次的抽象。其意外后果（或许也是预料之中的结果）在于：我们并未减少代码量，反而编写了更多代码——因为这使非专业人士能完成他们原本无法实现的任务。Visual Basic 兴起时同样如此。它让非程序员也能完成惊人创举，彻底革新了商业模式，但这并不改变架构本身的本质。
“Dario，计算机世界蕴藏的奥秘远超你哲学所能想象”
Shweta Vohra: 基于您的观点，我们来探讨下一个话题。当前被低估的领域是什么？又有哪些被过度炒作或高估？
Grady Booch: 先聊聊被过度炒作的部分吧，这个更简单。如果你关注我的推文，就会发现我经常抨击马斯克、特曼等人，比如说："天哪，你们疯了吧？我知道你们需要经营企业，也知道你们在项目上亏得一塌糊涂，但请务实点。AGI 不只不会突然出现，以后也不可能实现。”我建议大家去看看我十多年前的 TED 演讲，当时谈到超级智能的崛起，我的反应是：“我不担心这个问题”。
最近的事嘛，之前提到我用过 Claude、也非常喜欢，但我狠狠批评了 Anthropic 的 CEO 达里奥，因为这家伙在达沃斯论坛上说： “成果就在眼前，我们将用这些系统编写所有软件”。没错，就像编译器能用汇编语言和机器语言编写所有软件那样——但更高层次的编程远不止于此，只能由人类来完成。
有幅很棒的漫画，出自 xkcd，可谓一针见血地解答了这个问题。它这样讲：“当一种语言具备足够的表达力和精确度，能够生成可执行的产物时，你该称之为什么？”我们称之为编程语言。而提示词不过是另一层抽象——比如“把这个重构为命令模式”。这不过是抽象层级的提升——我将人类层面的理解提升到更高维度，以供机器理解并且代为执行。这固然美妙，但 AI 绝不会取代人类，因为正是我这个富有创造力的人类在引导它实现目标。
我不惧怕超级智能的崛起，真正令我胆寒的是掌控这些系统、借此扩张权力的亿万富豪阶层。这才是人类面临的危机，而非软件问题。
Shweta Vohra: 没错。许多问题的根都在人身上，对此我完全认同。但我想进一步探讨： 若按你所说的责任划分，即能将多少职责移交给硬件，我认为大语言模型已算得上取得了巨大进展。比如在创造力方面愈发符合我们的期望，且借此提升了工作效率，也让大众更容易获取各种成果。我想我们应当给予这项技术应有的认可，而且它本身正在不断进化。
Grady Booch: AI 的确已经渗透进大众的日常生活，也由此衍生出各种伦理与法律问题，特别是在文本转视频和文本转图像领域。就在此刻，欧盟正因这类问题对 Grok 提起诉讼，可见其存在诸多意料之外的后果。
在软件领域，我们受到的限制较少，因为被盗取的内容相对有限。大部分训练数据源自 Stack Overflow 等平台，其伦理性威胁确实值得商榷。开源软件同样存在争议，但至少没有直接窃取受版权保护的代码，因此引发的风险也有所不同。
Shweta Vohra: 确实如此，安全问题本身就是个值得深入探讨的方向。
Grady Booch: 没错，相当相当需要认真对待。
Shweta Vohra: 但在深入探讨前，我想听听您对另一个问题的看法。我们承诺将实现巨大的生产力提升。从微服务开始到云原生，如今又迎来 AI 编程辅助，智能编程技术正日益精进。您认为哪些领域能真正发挥优势？又担心哪些领域会为短期速度牺牲长期完整性？给大家讲讲吧。
Grady Booch: 我先从后半部分说起。我最担心的是技能退化现象。软件行业本质上是学徒制行业，与法律行业颇为相似。过去要想成为律师，大家必须埋头钻研法律书籍直至精通，更需通过参与各类案件与前辈并肩作战，汲取其战略洞见——这些都是必修课。如今随着 LexisNexis 等工具兴起，法律检索已演变为模式匹配问题。我认识的不少法律界朋友都忧心忡忡——初级从业者既无岗位可入职，更无成长空间，这正是技能退化的现实隐忧。
我担心软件行业也会出现同样现象——由于越来越多的工作被交给大模型，初级岗位正逐渐消失殆尽。那么新生代该从何处积累经验？对此我尚无答案，一切恐怕只能交给时间来验证。
另一个现实又要回到 Dario 的话题了。我曾引用莎士比亚的话对他说：“Dario，计算机世界蕴藏的奥秘远超你哲学所能想象”——这句话原是莎士比亚笔下霍雷肖的台词。我的观点是：计算机世界的疆域远比全球弹性规模的网络中心化系统更为广阔，而大多数大语言模型仅在这单一领域内训练而成——虽也不算狭小，但未来此类模型将愈发泛滥，这意味着普遍性的平庸正成为新的常态。
大语言模型往往将我们推向同质化的设计方向。诚然，这类设计也是我们所需要的，能够缓解之前提到的软件危机，但却无法解决两个问题：无法应对意外情况，也不再尝试截然不同的方法。大语言模型对此无能为力，因为这超出了它们的训练数据范围。其次，如果要构建基于最新云层与流体物理模型的气象系统，那这些模型没接受过相关训练，超出其能力范围，自然就无法提供帮助。虽然未来可能实现，但这类前沿领域始终存在，而专门为此训练大语言模型在经济上不可行，发展空间也将受到限制。
归根结底：软件世界浩瀚无垠，这些 AI 工具只是其中一环，既非唯一选择，也绝非永恒之选。面对不断涌现的技术选择，人类需要持续思考：我们需要哪些工具？哪些才真正合适？对我而言，AI 仅仅是工具。我敦促开发者学习使用这些工具，但切勿看淡人的意义。不要将创造力拱手让给工具，因为这正是我们的核心价值所在。
Shweta Vohra: 我也强烈建议听众——特别是创造者、工程师和开发者——谨记这条忠告：切勿盲目跟风，务必深入理解工具的运作机制。因为当问题出现时，终须有人来修复。这又引出了下一个问题：人类与机器的边界究竟在哪里？其原则又是什么？因为从架构师的视角出发，我总在思考：如今这些工具生成的内容如此庞杂，该由谁来评估它们？谁来真正划定这些边界？我们又该把边界设在哪里？
Grady Booch: 计算技术与人类本质的交汇处，正是值得深入思考的关键领域。对此我虽无定论，但目睹人类正面对前所未有的规模化、自动化浪潮，这个过程本身已然令人叹为观止。尽管没有答案，但我仍有坚持遵循的原则：创造力必须被掌控在人类手中，而非 AI 手中。一旦我将创造力交予它们，便犯下致命错误——因为创造力本非 AI 的职能、它们缺乏语境。说到底，根本不存在所谓的“智能”，因为 AI 跟我们并不存在于同一个世界。
它们既没有我们面临的约束条件，也不具备我们所处的情境——在我有生之年，甚至在我们子女的时代都永远无法具备。人类成长为如今形态的背景，远比我们所见的一切更为广阔。无论奥特曼拉来多少万亿美元的投资都无济于事。大语言模型始终是架构上的死胡同——Yann LeCun 对此也有类似论断——如今的 AI 产业正处于极其荒诞的迷茫期。
所以就这个问题，我的简短回答是："切勿泯灭人性。切勿泯灭创造力、独特性与跳出框架思考的能力。"从架构层面看，我们深知基于大语言模型的系统存在根本性缺陷——它们无法进行推理。我知道这个观点颇具争议，但我坚持这一结论。大模型虽具备推演引擎和演绎引擎，却缺乏归纳推理能力，即构建理论的能力。它们能进行概括，但这与理论构建截然不同。据我们所知，归纳推理目前仅存在于哺乳动物中。我之所以不限定于人类，是因为其他哺乳动物似乎也具备这种能力，例如鲸类、猿类等。但我们的大语言模型尚未掌握这项能力，这对整个人类种群的存续无疑是个好消息。
过去六年我在 IBM 任职期间，不仅在 AI 实验室工作，还与神经科学家团队合作。作为计算机科学家，我意识到自己对大脑的结构一无所知，因此过去六年致力于这一领域研究。大脑结构蕴含着惊人的美学，进化塑造的这种结构令人叹服。那些宣称“通用人工智能近在眼前”的人，其认知之天真令人咋舌——他们根本不理解人类大脑或有机大脑的运作机制，所以我根本不吃那套。
氛围编程一上来，责任就没人认了
Shweta Vohra: 我的核心认知是，架构设计如今比以往任何时候都更重要。过去我们可能依赖测试人员发现问题，或指望有人能在生产环境中及时修复——但如今代码部署范围如此广泛，这种依赖已不可行。我们必须建立人类参与的闭环机制，制定指导原则与防护措施。这点我深表认同，我们需要就此展开更深入的讨论。但我想强调一个核心问题：一旦 AI 生成代码在生产环境中出现故障时，架构责任究竟该由谁承担？
Grady Booch: 人类。答案很简单——责任在人，而非工具本身。这就像说“狗吃了我的作业本”，或者“是 AI 出错了”，同样没有说服力。
Shweta Vohra: 但产出的代码并不是完全由架构师经手，那责任也要由我们承担吗？
Grady Booch：没错。IBM 的 Tom Watson 在五、六十年代就说过，机器永远不该为错误负责。责任永远在人，因为机器是受指令驱动的，最终责任必然回归到下达指令的人类。我们深知在社会体系中，人类热衷于推卸责任。人们总想拥有权力却逃避责任，而 AI 领域很可能正走上这条老路。“我有权这么做，但要是出错，都是 AI 干的。”胡说八道，都是人干的，勇敢点把责任担起来吧。
Shweta Vohra: 明白。我们需要承担起责任，因为我们别无选择……
Grady Booch: 肯定呀。
Shweta Vohra: 而且我们需要明确划分这些边界。但在氛围编程领域，这种边界模糊的问题仍广泛存在，开发者自己、甚至是氛围编程服务商都不清楚 AI 到底在干嘛。
Grady Booch: 没错。这正是代码错误产生的根源——当我进行氛围编程时，总会感叹“架构师们可真了不起”。因为他们拥有极其丰富的经验和才华，深谙事物本质。能够敏锐察觉代码错误。相信大家都是如此，既会惊叹"天哪，AI 生成的结果真神了，但这里还是有问题，可以从这个角度切入”。这正是我使用 Claude 这类工具时发现的妙处——它堪称绝佳的结对程序员，但也是相当的不靠谱，犯错永远是家常便饭。它甚至无法意识到自己的错误，所以我必须时刻保持警惕，持续监督。一旦我放弃这份责任，当系统出错时，责任便瞬间落到我头上——不是机器的错，是我自己搞砸了。
Shweta Vohra: 综上所述，如果 AI 既负责代码编写、又负责代码审查，那就意味着人类责任边界的缺失。这可能正是我们需要填补的漏洞。
Grady Booch: 没错。容我补充一点，这本质上关乎人类信任问题。此刻我的手机里运行着五款大语言模型，它们可以说是性格迥异——姑且用这个词形容吧。我对它们的信任程度因工作领域而异，就像身边的朋友圈子。和某人交谈时，我期待他有这种能力、掌握那种知识，同时也清楚他存在某些认知盲区。
我身边的这些工具也同样如此。Claude 能完成堪称惊艳的工作，却也会做出令人抓狂的蠢事。因此作为人类，我对它们产生了某种“心理预期”，信任感也由此建立。
我建议读者们这样做："积极熟悉这些工具，就像木匠把玩自己买的锤子那样。不同的锤子总有细微的差别——份量不同、平衡点不同。要尽量习惯它、适应它、让工具配合你，而且在过程中千万别迷失了自己。"
Shweta Vohra: 一点没错。换个视角来看，这也是个激动人心的时代，因为新事物总会带来新的机遇和新的学习方式。
Grady Booch: 没错。变革的时代同样令人感到惶恐，毕竟在处于平稳期时没人想突然遭遇剧变，不确定性与错失恐惧症会因此蔓延——这正是 Dario 和奥特曼这类人最令我不齿的地方。他们总在嚷嚷“你必须适应一切”。不，我没必要。作为软件工程师，我的首要目标是打造有价值的酷炫产品，工具只在能帮助我达成目标时才值得关注。
Shweta Vohra: 是的，元宇宙炒作最厉害的那会，我发现你也一直在坚持自己的判断。
Grady Booch: 确实，那会简直了……
Shweta Vohra: 这段往事咱们日后再细品吧。总之我想说的是，对于今天收听播客的架构师们，你建议大家主动把握哪些 AI 机遇？更重要的是，哪怕工具能让某些环节变得轻松，他们又该抵制哪种用法？
Grady Booch: 古语有云：“通往数学的道路没有捷径”，架构设计同样没有捷径。这需要亲身体验、反复尝试，感受架构决策带来的后果。别当那种“下达指令就走人”的空降式架构师，你必须直面决策的后果。因此我的建议是：尽情把玩这些工具，它们很有趣。学会使用它们，因为它们将成为未来软件开发不可或缺的组成部分。
但同时，要精进架构师的本领。别只沉溺于特定领域的技术细节，去研读跨领域的代码，去读读 MacPaint 背后的原始代码，去剖析 Unix 内核——我们了解到的一切架构方案，终将反哺自己所在领域的实践。我所知晓的每一位顶尖作家，无不以阅读为本。
我所知晓的每一位顶尖软件架构师，不仅编写代码，更会研读他人代码——精进技能应该成为贯穿一生的习惯。
Shweta Vohra: 我完全赞同你的看法——别只顶着个架构师的名头，要真正为自己的建议和决策承担起责任。
Grady Booch: 没错。
Shweta Vohra: 还要为团队中的其他成员承担起责任。
“人生苦短，去尽情享受生活”
Shweta Vohra: 这期节目我们讨论了诸多议题，从架构、设计和责任角度剖析了现实与炒作间的差异，还涉及到生产力、速度、完整性以及人机协作关系。作为收尾，您还有其他想要补充的吗？
Grady Booch: 我觉得自己的人生经历非常神奇。我曾与 Grace Hopper 会面，与 J. Presper Eckert 相识。虽不能与图灵谋面，毕竟他去世时我还没出生，但也有幸接触过他的同事。我的职业生涯横跨计算机领域的萌芽期直到如今，也从这些前辈身上汲取了丰厚的养分。我自认在某种程度上推动了整个领域的发展，也尽情享受这段旅程。计算机是片神奇的天地，对于观看这期播客的朋友，我想说这既是殊荣、也是责任。殊荣在于我们每个人的工作都在改变世界，责任在于我们改变世界会造成后果。试问，还有哪个行业能够如此深刻且迅猛地影响文明的本质？
所以我敦促每位从事软件行业的朋友，请牢记这份使命。为我们从事的这份事业欢呼吧，大家正置身于文明变革的浪潮当中——这本身就是一份无上的荣光。
Shweta Vohra: 完全同意。每当我妈兴冲冲地告诉我她又学会用某项软件功能，或者解决了某个问题时，我都由衷心生喜悦。
Grady Booch: 这种感觉很神奇吧？
Shweta Vohra: 是啊，这种感觉超棒，让我觉得咱们这群架构师确实做了实事，但也应该承担更多责任。Grady，感谢您今天的分享、建议和指导。这期节目马上结束，给大家一句话建议好吗？
Grady Booch: 人生苦短，去尽情享受生活吧。
Shweta Vohra: 没错，绝对该尽情享受生活。天气这么好，下播我就去吃冰淇淋。Grady，再次感谢你的到来。
原文链接：
