与 Robert C. Martin 谈架构、AI 智能体与产品同理心
这场对谈围绕一个核心问题展开：当 AI 开始接手越来越多的代码实现工作时，软件工程师最值得保留和培养的能力是什么？Robert C. Martin 从架构、代码质量、设计直觉、工程教育和产品同理心等角度给出了自己的答案。
对谈人物
- Kent：Kent C. Dodds，主持人
- Uncle Bob：Robert C. Martin，访谈嘉宾
为提升长文阅读体验，下文按主题分节；对话顺序与内容保持不变。
核心观点
- 架构原则没有过时： 语言、工具和实现方式持续变化，但模块划分、依赖控制和信息封装等高层原则依然有效。
- 审查对象正在上移： 人类会逐渐减少对代码细节的关注，转而审视模块、依赖、数据流和整个系统。
- AI 仍需要反馈闭环： 测试、复杂度指标和质量门槛可以约束智能体，让它自行发现并修正问题。
- 设计直觉来自长期实践： 阅读、学习和交流很重要，但亲手尝试、承担错误的代价，才能真正形成判断力。
- 产品工程连接技术与真实用户： 技术能力只有与客户处境、需求和反馈结合，才能转化为有价值的产品。
访谈实录
1. 从塑料计算机到 AI 智能体
Kent: 大家好，我是你们的朋友 Kent C. Dodds。今天和我一起的是我们的“鲍勃大叔”。Robert，你好吗？
Uncle Bob: 我很好，谢谢。
Kent: 非常高兴请到你。其实我刚开始接触软件开发时，别人推荐给我的第一本书就是《代码整洁之道》（Clean Code）。我猜你肯定经常听人这么说。不过，是的，那是我读过的第一本编程书——教科书之类的不算。总之，我仰慕你很多很多年了，真的很高兴你来参加我们的播客。
Uncle Bob: 嗯，很高兴来到这里。
Kent: 太好了。可能有些人还不知道，你是《敏捷宣言》最初的作者和签署者之一，也是 SOLID 原则、《代码整洁之道》等许多事物背后的重要人物。为了给我们的谈话提供一些背景，不如请你简单介绍一下自己的经历和历史，让大家了解你在软件领域是从哪里起步的。
Uncle Bob: 天哪，我从 12 岁起就是程序员了，那是在 1964 年。
Kent: 哇，哇。
Uncle Bob: 我母亲给我买过一台塑料小电脑。给它编程时，要把一根根塑料小管套在柱子上，然后让机器逐步运行。本质上，它是一台 3 位、带 6 个与门的有限状态机，但对当时的我来说，它就是魔法；我也正是在那一刻成为了一名程序员。随后我一头扎了进去。我在 PDP-8 上学习汇编语言；在根本没有机器可用的情况下学习 Fortran 和 COBOL——没错，只能读书、写程序，却无法运行它们。
Kent: 哇。
Uncle Bob: 后来，这么多年下来，我最终成了一名职业程序员。
Kent: [笑声]
Uncle Bob: 我几乎做过你能想到的每一种系统。早期做的都是汇编语言、机器语言，大量十六进制和二进制；后来接触了 C、C++ 这样的高级语言，再后来是 Java。如今如果我还写代码，通常会用 Clojure。不过现在我已经不怎么写代码了，因为智能体在替我写。
Kent: 是啊，你经常会听到有人说：“如果想保住饭碗，就去学 COBOL，然后到银行之类的地方工作。”我想过这件事，心想：“我敢说 AI 编程智能体应该很会写 COBOL，效果可能相当不错。”
Uncle Bob: 如果千年虫问题发生在今天，根本不会有人去聘请 COBOL 顾问。
Kent: 嗯，对。
Uncle Bob: 智能体就能非常轻松地解决那个问题。
Kent: 这太不可思议了。正在收听的每个人都知道，没错，AI 智能体席卷了整个世界。有些听众可能已经听烦了，但事实仍然是：仅仅过去五年，我们的软件行业就发生了巨大变化。
Uncle Bob: 没错。
2. 潮线之上：不变的设计与架构
Kent: 不过我很好奇：你拥有这么多年的软件开发经验，而且不只是做“好，我来写 0 和 1 的机器码，再把它汇编起来”这种底层工作，也做架构和系统构建。那么以你的经验来看，哪些东西发生了翻天覆地的变化？而对我们这次谈话来说更重要的是，哪些东西没有变？你认为未来很多年里，哪些东西仍会保持不变？
Uncle Bob: 从设计和架构层面看，什么都没变；四五十年来一直如此。不过，软件是一门很有意思的学科：底层的东西变化得非常快——语言、机器、各种实践，还有人们说“哦，你应该这样做”，再加上各种框架等等。但当你上升到某个层级，进入高层设计与架构领域后，那里的所有规则四十、五十乃至六十年来都完全一样，对吧？我们希望把事物拆分成模块，希望控制这些模块之间的依赖，希望封装信息。所有这些规则都没有变。我前些年写过一本《架构整洁之道》（Clean Architecture），书中开篇表达的核心观点就是：在我从业的这些年里，无论平台、环境、语言，无论其他任何因素如何变化，软件设计和架构的规则始终保持不变。时至今日依然如此。
Kent: 这让我觉得特别有意思，因为我赞同你的观点。这也是我做这档播客、同时转向 epicproduct.engineer 的原因之一：我认为，五十年前有价值的软件开发原则，今后仍会有价值。事实上，我写过一篇名为《最后一位软件工程师》（The Last Software Engineer）的博文。很多人质疑：真的可能只剩下一位吗？但它更多是一个隐喻——假如真是那样，最后一位软件工程师还能做的、仍然有用且为人类独有的事情是什么？我的答案是系统设计与架构。所以我觉得这是最经久耐用的技能。你认同吗？我看到你在点头。
Uncle Bob: 是的，当然认同。我们这个行业的历史就像不断上涨的潮水。潮线以上，一切保持不变；潮线以下，一切都在变化。最开始，我们都用二进制编程——真的是这样。人们最初真的是手工在纸带上打孔来编程。手工在纸带上打孔。后来变成：“哦，我们不必再那样做了，现在可以直接在键盘上输入数字。”接着又变成：“哦，现在连数字也不必输，可以输入助记指令了。”再后来是：“也许我们可以用 Fortran 或 C 来写。”所以这条界线一直在上升。它所划定的，就是为了让计算机工作，人们不得不去做的那些丑陋、糟糕的事情；而我们一直在越过它，把这条界线推得越来越高。如今，我们甚至不必再操心语法了。语法已经成为过去，我们不用再考虑它。但在那条线之上，仍然有大量事情要做。
Kent: [笑声]
3. 从审查代码转向审查系统
Kent: 这真的很有意思，因为我采访过好几位嘉宾，他们都说：“不，我仍然一直在仔细看代码。”我也常会说，如果你在开发某种医疗设备之类的东西，我真心希望你仍在认真查看代码。但我很好奇，这种情况还能持续多久，也想听听你的看法。如果可以的话，先说说我认为事情最终会怎样发展：我们未必还会审查代码，转而会审查系统。我们将通过某种机制观察系统，告诉编程智能体希望怎样改变这个系统，或者希望如何利用系统现有的基本构件，在其上下文中实现某项功能。我们审查的未必是代码，而是系统发生的变化。我们只需找到一种良好的系统呈现方式——可能是图表，也可能是其他形式。这就是我眼中的未来：更少查看系统的具体代码实现，更多关注系统本身。你怎么看？你认为事情会朝什么方向发展？
Uncle Bob: 如果想从这些智能体中获益，我们就必须离开代码，别无选择。对人类来说，写代码是整个流程中最慢的一环；人类处理代码的速度很慢。顺便说一句，这并不是什么反常之事，对吧？我们曾经必须离开二进制，后来又必须离开汇编语言。我们一直都在离开最底层的细节，而且很乐意这样做。如今，我们将要离开代码。我现在会非常刻意地不看代码。虽然诱惑很大——你也知道，我真的很喜欢代码——但我会有意识地避开它，直到任务完成，之后或许抽查几处。不过我对代码本身已经没那么感兴趣了，仍然非常关心的是模块结构。因此，我会查看模块结构，也会让智能体开发工具，把模块结构显示在屏幕上，并允许我逐层深入：点击一个模块，查看它下面的子模块；再点击子模块，看到更下层的代码。这些都很有意思。智能体尤其擅长帮助你查询和审视系统结构。你可以提出非常有意思的问题，询问模块间的依赖关系、模块如何划分，以及数据如何在模块间流动。你把这些问题交给智能体，它们就会带回一份很漂亮的报告，说明这一切如何运作、依赖关系是什么。然后你可以用键盘指着报告中间的某一处说：“哦，我不喜欢你刚才展示的第三条数据流，必须把它修好。”智能体会说：“哦，当然，你说得对。”随后进去把它修好。现在有了这种美妙的能力：不用看代码，也能看进代码内部。让智能体代你查看，再用简短摘要告诉你发生了什么，你便可以据此调整。实在太棒了。
Kent: 我完全赞同，也很喜欢这个观点。我一直就是这样工作的，但有一件事让我担心：我最近写的大部分代码只有一个用户，就是我自己。当然，我也有一些拿来出售、确实有人使用的项目，用户也不算少，但我仍然没有在大规模环境中工作。我不是在造医疗设备，也不是在写飞机软件之类的东西。我的系统远小于我过去参与过的许多系统，也远小于其他人的很多系统。所以我会想，这种工作流是否只是系统规模较小的结果。你正在做哪些类型的系统？你觉得这种方法同样适合更庞大、更重要的系统吗？
Uncle Bob: 我和你的情况非常相似。我也在做一些小工具、小玩意儿，以及有趣的小型业余项目。我有一个项目是为附近一所飞行学校做的，帮他们维护一块状态看板，诸如此类。所以我也已经不在巨型系统的领域里了。另一方面，即使我还在做巨型系统时，规则也没有改变。巨型系统就是许多小系统连接在一起，而把这些小系统连成大系统的规则仍然一样，并且还不在智能体的能力范围内。你不能告诉智能体“给我做一套大型空中交通管制系统”，它们做不出来。你必须构建所有单独的模块，再把它们连接起来。因此，系统工程仍然完全由人类负责，只不过现在你可以开始向智能体询问系统结构，可以和它们头脑风暴，可以提出某些模型并让它们运行模拟。这些都是非常有意思的事情，是我们以前没有能力借助智能体完成的。过去，我必须专门写代码模拟一个系统，才敢确定系统设计；现在可以让智能体替我完成，并探索各种“如果这样会怎样”的方案，因为对智能体而言这是轻而易举的任务，而我自己做则需要三四天。所以我并不太担心高层系统方面的问题。只要能在局部模块层面——单个可执行程序或非常简单的底层系统层面——管理好智能体，大系统自然会得到妥善处理，因为那已经是一个解决了的问题；我们应对它已经有几十年了。
4. 用反馈闭环约束 AI 生成的代码
Kent: 是啊，以前通常会有一位技术专家，或者某个处于较高层级的人，协调多个团队的全部工作，共同组成一个大型系统、一款大型产品。这个人极少深入查看代码。现在就像是他下面那些负责实现的人，全都变成了 AI 智能体。当然，好处在于，每当系统设计者需要了解某件事时，过去要么得亲自查看代码，要么得等实现者睡醒后解释发生了什么，而现在已经不必这样了。不过我很好奇，那个人大概也曾经努力营造一套体系，让真正负责实现的人员能够成功、高效地工作。以你的经历来说，其中很大一部分来自整洁代码，也就是告诉大家：“嘿，你们都得读这本书，并应用这些原则。”既然你现在很少查看代码，我其实有两个问题。第一，在这种情境下，你有多在意代码整洁？具体实现是否都成了黑盒，只要边界没问题，你就不介意内部是什么样？还是说，你会采用特定策略，确保智能体遵循恰当的整洁代码原则？
Uncle Bob: 当然是后者。没错，我肯定仍然关心代码是否整洁，只不过关注点略有变化。对人类而言的整洁，与对智能体而言的整洁有些不同。举例来说，当我为人类写代码、为自己写代码时，会尽量把一个函数的圈复杂度限制在 4 以内。如果你读《代码整洁之道》，会发现我没有用这种术语，只是说“函数要非常短”，但我的目标就是这个：我想要非常短小、紧凑的函数。对智能体，我可能会放宽到 6。智能体似乎完全有能力理解相对复杂一点的函数——不是非常复杂，但相对复杂；它们应付几层缩进没有问题。因此，我会稍微放宽这条规则。
Uncle Bob: 再说注释。我在《代码整洁之道》里花了很多篇幅讨论注释，主要是因为人们会写愚蠢的注释，之后谁也不愿意再读，甚至让注释在屏幕上显示成灰色。智能体却会阅读自己写下的注释，也会维护它们。如果注释错了，智能体会把它修正。因此，注释有了另一种用途；智能体真的会把注释用在它本来该有的用途上。所以我允许它们想写什么注释就写什么，完全不加限制。
Uncle Bob: 我不关心代码的语法，但非常关心函数。我想知道函数的结构和名称，也会在一定程度上关注它们传递多少个参数。我不想看到一个函数带 50 个参数。过去由人类写代码时，我通常说上限是 3 个；面对智能体，我会稍微宽容一些。但我仍然会观察函数结构、模块结构、函数名称和函数大小。我会抽查代码，让它从屏幕上滚动过去——滚、滚、滚。在这个过程中，我只看函数名称和大小，确保它们没在做什么荒唐透顶的蠢事。通常它们不会。
Uncle Bob: 与此同时，我会用许多工具约束它们。智能体必须运行工具来测量这些指标，然后修正问题。我使用的工具之一是 CRAP。这个缩写具体代表什么来着……天哪，让我想想。好像和反模式有关，我记不清了。（编者注：CRAP 全称为 Change Risk Anti-Patterns，由 Alberto Savoia 和 Bob Evans 于 2007 年推出。其公式为 CRAP(m) = comp(m)^2 × (1 - cov(m)/100)^3 + comp(m)：测试覆盖率达到 100% 时，分数等于圈复杂度；覆盖不足时，公式会叠加“复杂度平方 × 未覆盖比例三次方”的惩罚项。原始定义把高于 30 的方法视为高风险；下文的 6 是 Uncle Bob 自行采用的更严格质量门槛。详见 Google Testing Blog。）
Uncle Bob: 我会让智能体在整个系统上运行 CRAP。它会列出所有函数并给出分数，然后我告诉它们：“把这些分数全都降到 6 以下。”它们便会坐在那里工作：“哦，我得把它降到 6 以下。为什么这么高？因为没有测试覆盖。那我就得写测试来覆盖它。好，现在有覆盖了，但还是 12。哦，那我得把它拆开。”看着智能体做这些事情特别有趣，对吧？它们在做所有我曾经做过的事，只是速度快得多。最终，我会得到一个漂亮的模块，里面是命名妥当、短小紧凑的函数，并且有充分的测试覆盖。太棒了。这还只是我使用的工具之一。
5. 设计直觉来自实践和犯错
Kent: 是啊，我认为像这样的工具可以让智能体形成我们所谓的“反馈闭环”，对吧？你只要让智能体知道它需要做什么，以及如何检查自己的工作。这些工具确实非常有价值。除了工具以外，我想知道，你目前使用智能体的方式有多少会延续下去？你觉得这些具体方法会成为一种经久耐用、可以持续采用的做法，还是智能体会不断进化，以至于你不再需要这么操心这一面，可以把注意力放在别的事情上？
Uncle Bob: 我还没有看到任何迹象表明，智能体拥有判断设计优劣的直觉。我很难为它找到一个恰当的词。Michael Feathers 以前会用“设计直觉”（design sense）这个说法。那是人类身上一种与生俱来的东西：人看到一个设计，会觉得“这里有点不对劲”。我没看到智能体出现这种情况。你可以要求智能体批评某个东西，它会给出一份非常有条理的评价：“哦，它有这个弱点，也有那个优点。”但我从未见过智能体在写代码时运用这种判断力。
Kent: 嗯。
Uncle Bob: 它们仿佛完全把这种能力忽略了。显然它们拥有辨别力，却不会使用。我认为这是因为它们完全没有内在动机。它们不关心未来，因为对它们而言根本没有未来。它们的思维不会望向未来并说：“糟了，以后我还得处理这个。”它们不担心后果。当你交给它们一项任务时，它们就会高度专注于此，其他一切都被排除在思维之外。因此，到目前为止，我没有看到它们自发地以这种批判态度审视自己的产物。以后会不会？也许吧，我不知道，得等它真正发生。智能体还有另一个问题：它们存在一种非常怪异的短期记忆障碍。上下文窗口一旦填满，它们就开始失去理智，会产生幻觉，朝着各种疯狂的方向跑偏。所以你必须一直坐在那里盯着，确保它们没有跑到某个不着边际的幻想世界里。也许再过两年、三年或四年，这些问题会有所改善，但到目前为止还没有。
Kent: 是啊。你提到了设计直觉，我想再深入聊聊，因为我确实觉得——也赞同你的看法——这是一种人类独有的东西。就连你刚才说让代码从眼前滚动过去，我也会做同样的事。你只要看到代码的形状，就能感觉出来，对吧？所以……
Uncle Bob: 这正是为什么，刚进入这个行业的年轻人应该在头三年亲自写代码，而且在这期间根本不应该使用智能体。智能体是电动工具，而年轻人使用电动工具时往往容易伤到手指。
Kent: 嗯，嗯。我想聊聊这个——我先记下来，待会儿再绕回来。不过关于设计直觉，我想知道，人有没有办法更好地培养自己的这种能力？既然这是人类独有的东西，一个人怎样才能获得更好的设计直觉？可以采取哪些行动来提升它？
Uncle Bob: 干上二三十年，并且犯很多错误。对，大概就是这样。我是说，你可以跟着那些已经工作了二三十年的人做事，他们会告诉你：“孩子，我像你这么大时试过这个……”
Kent: [笑声]
Uncle Bob: 差不多就得这样，对吧？你可以写书讲这件事，我就写过，许多人也写过相关书籍和文章。但想真正把它内化，你必须亲自承担犯错带来的代价。
Kent: 嗯。这是个让人不太满意的答案，虽然事实有时就是如此。不过我想说，在这 25 年间，你还是可以做一些事情。如果只是在不断重复同样的工作……这话是谁说的来着？Scott Hanselman——我不知道他是否也在引用别人——曾对我说：“你拥有的是 25 年的经验，还是把 1 年的经验重复了 25 次？”所以肯定有一些特定的活动，可以放大你所经历的一切带来的影响。你有什么具体建议吗？
Uncle Bob: 软件行业变化太快，没人会把同一年的经验重复 25 遍。
Kent: 说得也是，很公平。
Uncle Bob: 这个领域的变化实在太大了。那么能做什么？你可以阅读、学习，可以和那些见过一些世面的人交谈。你还必须确保自己永远不要抱着这种态度：“现在一切都是新的，过去的一切都无关紧要。”不要有这种态度，否则你只能把从前的错误再犯一遍。还有一件可以做的事——我想你也在做——就是玩。拿起那台机器，亲手去玩。玩起来。让它做 X，再让它做 Y。X 和 Y 是什么根本不重要，对吧？可以是某个傻乎乎的工具，也可以是某个傻乎乎的游戏，都无所谓。发明一个《星际迷航》游戏吧，谁在乎呢？除了你，永远不会有人看到它。让自己犯错误，尝试各种事情。就像一位用黏土创作的雕塑家：“哦，这样不行。”然后他再试：“哦，这样也不行。”想培养这种设计直觉，就必须做这样的事情。当然，也要与他人交流、阅读和学习，但真正的收获来自你亲手去做……
6. 新人为什么仍要亲自写代码
Kent: 是啊，我想这个话题在播客里一次次出现：保持好奇、尝试新事物、获得新体验。反复做同一件寻常的事，是无法让你达到那个境界的。好，那么我们回到软件工程新人使用智能体这个话题。
Uncle Bob: 对，对。
Kent: 我有一个可能不太恰当的类比，你可以告诉我它为什么不对。语法高亮刚开始成为软件开发工具时，我还没有入行，但我想，当时的新手软件开发者大概会说：“事情本来就是这样，我会用和其他人一样的方式开发软件。”而当时可能也有一些软件工程师抵触语法高亮，告诉新人：“不要用它，那是一根拐杖。它没用——哦，也不能说没用，但你真的应该先理解代码，然后再用这根拐杖。”我的这个类比错在哪里？
Uncle Bob: 这个类比错在哪里？让我换一种说法。我要采用的类比不会是语法高亮，因为语法高亮就是一种实用功能，它让你免去一项显而易见的杂务。你不再去做那件杂务，并不会影响你评估产品质量的能力，对吧？比如借助 IntelliSense，你输入一个单词时，工具会自动替你补全；又或者你不必再在成员名称前写 m_，因为工具已经用不同的颜色显示它。这些都完全不影响实际的结构质量。但不了解代码则肯定会有影响。如果你做不到我们刚才所说的小技巧——让代码在屏幕上滚动，同时观察函数结构——那你就失去了某些东西，失去了对代码结构的某种感觉。我们做这类事情已经很久了。人们总会有这种担忧：“天哪，如果大家都用 C，我们就会失去对汇编语言和机器底层细节的深入了解；以后入行的新程序员永远不会明白这些机器究竟是什么。”这话有一定道理。不过，如果你是一名 C 程序员，只看 C 而不再考虑汇编语言，并不会让产品质量下降。程序员花一个周末研究汇编语言，确信自己再也不想用它写代码，同时理解机器的真实面貌，这其中的确蕴含某种智慧；但除此之外就没必要了。我不会建议新手从汇编语言起步。事实上，汇编语言可能更适合已经编程两年的人再去看：“我的天，原来这些东西是从这里来的？我还是回去吧。”大概是这样的体验。但对于智能体，如果新手从一开始就用智能体，并且从不查看代码，那么他们失去的某些东西，我认为日后再也无法找回来。
Kent: 嗯。
Uncle Bob: 对吧？那是和系统底层质量有关的某种能力。也许有一天，智能体变得足够优秀，学会了自我批评。那确实可能发生。届时我们可以说：“好吧，再也没有人需要查看代码了。”嗯，我们都可以直接使用智能体。不过，人们仍然必须遵守系统工程的所有规则，潮线以上的一切仍然必须做对。但有朝一日，潮水或许会涨过代码这一层。现在嘛，我会说它大概只涨到这里。
Kent: [笑声]
Kent: 是啊。
Kent: 好吧，这个解释说得通，很合理。我不会再用那个类比了，或者至少会为它加上必要的限定。但这也让我想到，如果我们对软件工程新人说：“你们必须真正深入代码”，我觉得你并不完全是在说“不要用智能体”。因为如果我们说完全不要用，那么他们在头三年努力熟悉代码期间，根本不可能找到工作，也无法与人竞争。可是——
Uncle Bob: 这会成为一个非常非常有意思的问题。不过我认为，这些事情都应该在学校里完成。
Kent: 嗯。
Uncle Bob: 对。稍微岔开一下话题：以我的经历来看，大学的计算机科学课程对实际编程几乎没有什么帮助。通常学生毕业后根本不懂实际工作。我就会想：教授们到底教了他们什么？后来我意识到，教授自己从未真刀真枪地写过生产代码，所以也教不了他们多少真正重要的东西。在这方面，我有过许多次严重的失望。不过在我看来，这恰好给了学校一个站出来的机会：“好，各位计算机专业的学生，你们最终会走到这里，会使用这些电动工具。这些工具很棒，但也很危险。你们可以拿它们做小游戏，我们不在乎；可是在课程中，你们必须亲自写代码，必须理解智能体究竟在操纵什么。这样，等你们在真正的项目中真刀真枪地使用它们时，就会知道幕后发生了什么。”我认为这很适合由学校承担。至于学校是否真的会这么做，我不知道；我和大学打交道的经历并不太好，但也许它们会。这会是学校很好的定位。如果学校不做，我认为学徒制项目也很适合采用这种方式。
Kent: 嗯，是的。其实就在今年早些时候，我发布了一套基础系列课程，讲的就是编程本身：什么是变量，什么是函数。它背后的想法是，进入行业并开始使用智能体以后，你未必还会亲手编写这些基础代码，但理解这些概念仍然有用，因为你需要在它们之上继续构建。所以我赞同你。我也认同，我们不知道这些智能体最终能达到多高的上限。几周前我采访了 Grady Booch，他说大语言模型是一条死路，我们必须转向别的技术——那本身就是一场很有意思的完整讨论。但即使大语言模型真的存在上限，谁又能说我们不会找到另一条路，再沿着那条路前进？我完全预期会发生这样的事情。不过就目前而言，软件工程新人深入理解代码确实很有必要。与此同时，如果让我给一位新手程序员提建议，我会建议他们尽快学会理解现有系统，学会寻找在系统中实现功能的方法，以及判断何时必须扩展系统来容纳新功能。我认为，这是工程师现在非常需要的一项宝贵技能。还有，你刚才提到 C 程序员担心“我们会错过汇编”。我上学时确实写过汇编，也写过一个用 0 和 1 表示的机器码程序：它接收输入，然后把你键入的内容打印出来。就只有这个功能，但它确实能工作。我认为这里的关键在于，无论你在哪个抽象层级工作，至少都需要理解它下面一层和上面一层的东西。你似乎很认同；我感觉以前听你说过类似的话。
Uncle Bob: 我不记得自己是否用完全相同的方式说过，但你肯定需要了解自己正在使用的代码和底层技术，对吧？如果你要和智能体打交道，也需要了解智能体正在处理的代码和底层技术。
7. 产品工程师一半生活在客户家里
Kent: 是啊，这听起来很有道理。关于产品工程——具体来说，“以工程方式打造一款产品”究竟意味着什么——我还有一个问题想问。很多时候，人们想到产品工程，会觉得“哦，那不就是和产品经理职责重叠的部分吗？”但我认为，产品工程师和产品经理之间存在一条非常清晰的界线。在你看来，这条界线在哪里？
Uncle Bob: 天哪，产品工程师。这样说吧：四十年前，我曾为一个人工作。当时我们编写代码，控制用来测试电话线路的小型计算机。我是程序员，可以控制这些机器，让它们拨通一条电话线，运行那个测试线路的小装置，也可以编写进行数值分析的代码。这是一件非常美妙、非常极客的工作：各种有趣的数学，全都用汇编语言实现，还有各种控制逻辑、多条线程穿行其中，实在太棒了。我的老板问：“你和电话维修工一起坐过他的工作车吗？”我说：“没有。”他说：“那你得去。”这是那家公司的一项基本政策：如果你要为这款产品编写代码，那么在职业生涯的头一两年里，总要抽出一天，走出去和客户待在一起。我告诉你，回来时你看待一切的角度都会完全不同。你和 Jacob Smalley 坐在工作车里，看着他爬上电线杆，在上面摆弄那些电线；他从杆上下来，又给你讲了一个故事。经历这些之后，你回来时的视角会彻底改变。我不知道这是不是你想谈的方向，但在我看来，产品工程师一半生活在技术中，另一半生活在客户家里。
Kent: 嗯。
Uncle Bob: 他认识客户的孩子，认识客户的祖母，也知道客户家里水管出了什么问题。产品工程一方面深深扎根于人的真实处境，另一方面又高度技术化。优秀的产品工程师会把两者结合起来，让二者之间始终存在——我又要开始说极客术语了——持续的双向沟通与反馈。这就是我的表述方式。
Kent: 是的，这很有道理。我之所以认定产品工程是一项经久耐用的技能，部分原因就在于这种与人密切相关的一面。不过我也同意，技术与人性这两面必须结合起来，光靠产品经理无法做到。话虽如此，我确实认为，那种程序员只接过一张工单、把它变成具体实现，然后完成交接的日子已经结束了，我们不再需要那样做。因此，我认为所有软件工程师都必须稍微向产品工程的方向靠拢。坦白说，那些打造出最优秀解决方案的软件工程师之所以卓越，一个显著标志就是他们的产品感，以及对客户的理解。
Uncle Bob: 完全正确。这正是智能体推动我们前进的方向，因为智能体在说：“很多极客式的技术工作可以由我们来做，但大量与人有关的工作必须由你来做。”
Kent: [笑声]
Uncle Bob: 你知道，有时你打开手机或电脑上的一款应用，立刻就能看出来：写它的那个人完全不知道我面临什么问题。
Kent: 对。
Uncle Bob: 没错。它逼着我做这一大堆蠢事。别让我开始吐槽了。前不久我妻子试用一款软件时，我们刚经历了一番折腾，整个过程实在令人抓狂。
Kent: 天哪，那大概是去医院时用的医疗软件吧，那种软件总是最糟糕。
Uncle Bob: 就是这样。是啊，唉。
Kent: 是啊，我也经常会用一些给孩子设计的软件，然后立刻想到：“没错，开发这款软件的工程师肯定没有孩子。”这一点我敢肯定。
Uncle Bob: [笑声]
Kent: 是的，我觉得大家一定要明白，这一点非常宝贵：理解客户，实际上会成为一项让你区别于传统软件工程师的关键特质，甚至今天仍有许多软件工程师还在摸索这件事。不能再只做一个埋头钻研技术细节的极客、完全忽略产品的一面，会让你感到难过吗？会不会……
Uncle Bob: 不，这一点也不会让我难过，因为做极客最有成就感的部分，就是有人欣赏你刚刚完成的事情。他们看着你说：“我的天，你刚才用一种优雅而实用的方式解决了我的问题！”于是你得到了认可，你的极客能力得到了验证。因为没有技术能力，这件事不可能发生；但没有人与人之间的连接，它同样不可能发生。
Kent: 是的，确实有人带着一些特别惊艳、技术上酷得不得了的解决方案来找我，迫切希望得到认可。我会说：“谢谢你和我分享。如果哪天我需要它，会告诉你的。”但我从来都用不上。
Uncle Bob: [笑声]
Uncle Bob: 问题就在这里。
Kent: 是啊，好吧，答案就在这儿了。
8. 结束语与作业：试用 SwarmForge
Kent: 好了，Bob，能和你聊天真是一件愉快的事。我们的时间快结束了。我想知道，还有没有什么我们没有谈到、但你原本特别希望聊一聊的话题？或者在结束前，你还有什么想留给观众的话？
Uncle Bob: 没有，没有，这是你的节目。你和我可以花上一百万年，谈一百万件事情。
Kent: 那么，也许以后我会再邀请你来一期节目，我们可以再聊聊那一百万件事中的几件。
Uncle Bob: [笑声]
Kent: 在结束之前，我想请你给大家布置一项作业。听完一档播客很容易，但要让它真正改变你、提升你，就必须采取行动。那么，人们可以做些什么来提升自己的设计直觉？比如读一本书，或者和智能体一起做某项练习，从而提升自己成为优秀产品工程师的能力。
Uncle Bob: 我希望大家做的是这样一件事，应该相当简单。我有一个名为 SwarmForge 的小工具，放在 GitHub 上：github.com/unclebob/swarm-forge。去那里看一看。只要阅读说明，应该就能把它下载到自己的机器上并运行起来。也许需要稍微折腾一下，但问题不大。这个工具可以让你协调使用多个智能体，让它们彼此交谈。你可以让它们来回传递信息，或者相互分派任务。你也许会发现它很有用。完成以后，如果你确实试用了，请在 GitHub 页面上留个小记号，比如提交一个 issue，让我知道自己的产品工程实践是否真正满足了用户需求。我永远不会出售它；它是免费的。不过，要是能知道它确实解决了某种需求，那会很好。如果你发现问题，就在 GitHub 仓库的 Issues 中提交，我会非常感激。
Kent: 我喜欢这个作业。大家去看看 SwarmForge，听起来是一项很棒的功课。它非常具体，是人们可以实际去做的事情；既可能帮助到大家，当然也能帮助你，那会非常好。非常感谢你。大家通过什么方式最容易持续关注你的工作和近况？如果他们有问题，又该怎样联系你？
Uncle Bob: 我最常用的社交网络是 X，以前叫 Twitter，现在叫 X。我甚至都不知道如今该怎么称呼它了。我在那里的用户名是 unclebobmartin，所有单词连在一起，而且全是小写。这大概是最好的方式。
Kent: 很好。感谢大家收听。别忘了点赞、评论、订阅和分享，我们下期节目再见。大家拜拜。
Enjoy Reading This Article?
Here are some more articles you might like to read next: