#350.AI如何改变软件工程——Martin Fowler专访 - 跨国串门儿计划

本报告基于对知名软件工程师、《重构》与《企业应用架构模式》作者Martin Fowler的深度访谈，系统性地剖析了人工智能（AI）对软件工程领域所引发的根本性范式革命。作为2001年《敏捷宣言》的17位共同签署人之一，Fowler以其横跨四十余年的行业经验，将当前AI浪潮置于软件开发史的宏大叙事中进行审视，指出其影响之深远堪比“从汇编语言到高级语言”的历史性转变。这一变革的核心并非简单的抽象层级提升，而是从确定性系统向非确定性系统的根本迁移，这彻底颠覆了传统软件工程建立在可预测性假设上的方法论根基。Fowler强调，当前我们正处在一个“非常奇怪的阶段”：一方面全球经济面临萧条与大规模裁员的压力，另一方面人工智能泡沫却在膨胀，二者并行发生，相互掩盖，加剧了技术采纳的复杂性。尽管外部环境充满不确定性，Fowler对科技行业整体持积极态度，坚信技术和软件仍有巨大潜力未被释放，其核心驱动力在于需求远超想象。他明确指出，人工智能不会消灭软件开发，而是将以一种类似“从汇编到高级语言”的方式深刻重塑其形态，但核心技能——如理解需求、沟通协作、跨领域整合——依然至关重要。

报告深入探讨了AI带来的具体实践挑战与机遇。在工作流程层面，Fowler提出了“氛围感编程”（Vibe Coding）这一新兴模式，即开发者完全不关注生成代码的输出，仅将其视为一个“不靠谱的合作者”。他警示这种模式虽能加速探索性原型构建，但因其跳过了“学习的闭环”，导致开发者无法真正理解代码逻辑，最终产物往往结构混乱、难以维护，本质上是一种“有点傻的意识”。与此相对，大语言模型（LLM）在快速原型构建和遗留系统理解方面已展现出巨大价值，特别是通过语义分析与检索增强生成（RAG）技术，使开发者能够以自然语言查询代码库的内部逻辑，从而显著提升对复杂系统的认知效率。在重构实践上，Fowler认为尽管LLM本身无法进行真正的重构，但可以作为起点，与确定性工具协同工作，形成混合系统，未来重构的价值只会因代码规模和复杂性的激增而愈发重要。在架构思想层面，他观察到设计模式的讨论热度下降，其背后原因在于云计算的兴起使得AWS等平台提供了大量开箱即用的“架构良好积木”，从而内置解决了许多原本需要设计模式解决的问题，但其思想并未过时，而是转向了“领域特定语言”（DSL）的复兴，旨在弥合思维与代码之间的鸿沟。最后，报告揭示了Fowler对未来的深刻洞见：在认识论危机中，拥抱不确定性、进行“探究性”学习、寻找承认自身局限的信息源，才是应对AI时代的核心能力，而“专家型通才”（expert journalist）将成为未来杰出工程师的标志。

在软件开发的历史长河中，人工智能（AI）的出现被广泛认为是继汇编语言向高级语言演进以来最具颠覆性的技术变革。作为职业生涯横跨数十年的资深从业者，Martin Fowler在其访谈中明确表示，这是他职业生涯中遇到的最大变革，其重要性可与“从汇编语言到第一批高级语言的转变”相提并论。这一判断并非基于技术的表面进步，而是源于其对软件工程本质的深刻洞察。Fowler指出，这次变革的最大特点是“从确定性到非确定性的转变”，这与历史上任何一次技术跃迁都截然不同。在传统编程中，开发者可以精确地预知每一条指令的执行结果，代码的行为具有高度的可预测性和一致性。然而，大语言模型（LLM）生成的代码却呈现出显著的非确定性特征：相同的提示（prompt）在不同时间或不同上下文中可能产生截然不同的输出；即使经过多次迭代，最终结果也可能偏离预期。这种不可预测性迫使开发者必须重新思考其工作流程和质量保障机制。例如，一个令人震惊的案例是，当Fowler在配置文件中要求添加一个带有“今天日期”的注释时，大语言模型不仅没有正确识别“今天”，反而复制了上一个条目的日期，甚至在后续修正中错误地写成了“昨天”。> “我告诉大语言模型，请帮我添加这个配置项，并加上今天的日期。它添加了，但日期却复制了上一个的。我说那不是今天的日期，他说哦，非常暴速，让我为您更正。结果他写了昨天的日期，我觉得你得亲身经历一下才能体会到。” 这一事件生动地揭示了大语言模型在处理看似简单、常识性的任务时的脆弱性，凸显了其输出结果的不可靠性。因此，开发者不能再将大语言模型视为一个可靠的、可信赖的合作者，而必须将其视为一个需要持续验证、不断校准的“不靠谱的合作者”。这种思维方式的转变是应对非确定性挑战的第一步。此外，Fowler还敏锐地捕捉到当前宏观环境的矛盾性，他形容我们正处在一个“非常奇怪的阶段”，即一方面面临全球范围内的经济萧条和大规模裁员，另一方面又目睹人工智能泡沫的膨胀，二者并行发生，相互掩盖。这种宏观环境的不确定性进一步加剧了技术采纳的复杂性，使得企业投资意愿下降，从而影响整个软件行业的进展。然而，尽管存在这些外部压力，Fowler对科技行业整体持积极态度，坚信技术和软件仍有巨大潜力未被释放，其核心驱动力在于需求远超想象。他强调，人工智能不会消灭软件开发，而是将以一种类似“从汇编到高级语言”的方式深刻重塑其形态，但核心技能——如理解需求、沟通协作、跨领域整合——依然至关重要。

人工智能最深远的影响在于它彻底改变了开发者所处的工作环境的本质。Fowler明确指出，这次变革的最大特点是“从确定性到非确定性的转变”，这与历史上任何一次技术跃迁都截然不同。在传统编程中，开发者可以精确地预知每一条指令的执行结果，代码的行为具有高度的可预测性和一致性。然而，大语言模型（LLM）生成的代码却呈现出显著的非确定性特征：相同的提示（prompt）在不同时间或不同上下文中可能产生截然不同的输出；即使经过多次迭代，最终结果也可能偏离预期。这种不可预测性迫使开发者必须重新思考其工作流程和质量保障机制。例如，一个令人震惊的案例是，当Fowler在配置文件中要求添加一个带有“今天日期”的注释时，大语言模型不仅没有正确识别“今天”，反而复制了上一个条目的日期，甚至在后续修正中错误地写成了“昨天”。> “我告诉大语言模型，请帮我添加这个配置项，并加上今天的日期。它添加了，但日期却复制了上一个的。我说那不是今天的日期，他说哦，非常暴速，让我为您更正。结果他写了昨天的日期，我觉得你得亲身经历一下才能体会到。” 这一事件生动地揭示了大语言模型在处理看似简单、常识性的任务时的脆弱性，凸显了其输出结果的不可靠性。因此，开发者不能再将大语言模型视为一个可靠的、可信赖的合作者，而必须将其视为一个需要持续验证、不断校准的“不靠谱的合作者”。这种思维方式的转变是应对非确定性挑战的第一步。此外，他将此与工程学中的“公差”概念类比，提出我们必须为非确定性设定一个“公差”范围，意识到不能过于接近系统的边界，否则可能导致灾难性后果，正如桥梁设计中必须考虑材料的极限强度一样。他担忧未来可能出现因过度依赖非确定性工具而引发的“引人注目的崩溃事件”，尤其是在安全关键领域。Fowler进一步指出，这种非确定性是前所未有的，因为过去虽然也有神经网络等非确定性技术，但其应用领域要小众得多，没有像现在这样无处不在。> “我猜这是我们第一次看到一个如此广泛应用于软件工程的非确定性工具吧，因为我们过去也有神经网络，它们也不是确定性的，但我感觉它们的应用领域要小众得多，没有像现在这样无处不在。” 现在每个开发者如果在用代码生成，就必然在使用非确定性的东西。这种普遍性意味着我们正面临着一个全新的挑战，需要发展出一套全新的思维方式来应对。

氛围感编程（Vibe Coding）是人工智能赋能下涌现的一种新兴工作模式，其核心特征是开发者对生成代码的输出结果采取一种近乎无视的态度。Fowler定义其为“完全不看输出的代码，也许出于好奇会瞥一眼，但你真的不在乎，也许你根本不知道自己在做什么，因为它只是在为你吐出东西”。> “当我用氛围感编程这个词时，我试着回到它最初的含义。基本上就是你完全不看输出的代码，也许你出于好奇会瞥一眼，但你真的不在乎，也许你根本不知道自己在做什么，因为你没有任何编程知识，它只是在为你吐出东西。” 这种模式在特定场景下展现出巨大的价值，尤其适用于探索性工作和一次性的小型项目。它极大地加速了原型构建的速度，使开发者能够在几天内完成过去需要数周才能实现的探索性任务。对于那些不认为自己是专业软件开发者的用户，如业务分析师或设计师，这种低门槛的编程方式开辟了一个全新的创作领域。然而，Fowler对这种模式持谨慎的批判态度，明确警告：“如果你想要做一个需要长期维护的产品，就千万别用它。”其根本原因在于，氛围感编程跳过了学习的闭环。传统的软件开发是一个动态的反馈循环：开发者提出想法，通过编码实现，观察结果，根据反馈调整思路，再进行下一轮迭代。这个过程本身就是一种深度的学习。而氛围感编程则直接绕过了这一关键环节，导致开发者无法真正理解生成代码的内在逻辑和潜在缺陷。一旦出现问题，开发者往往束手无策，只能选择“从轨道上用核弹把它炸掉，然后重新开始”。> “当你用氛围感编程时，你其实跳过了一个非常重要的环节——那就是学习的闭环。” 他以自己与同事合作创建一个伪图表为例，展示了这种模式的危险性：大语言模型生成的复杂SVG代码，其结构之混乱、冗余之严重，远超人工编写水平，以至于他不得不放弃修改，转而重新生成。这表明，虽然氛围感编程能快速产出“看起来像样”的结果，但其产物的可维护性和可理解性极低，本质上是一种“有点傻的意识”，无法支撑长期的软件产品开发。Fowler还指出，这种模式的危险性在于它会让人产生虚假的安全感，导致开发者在审查代码时变得懈怠。> “我也从其他软件工程师那里听到同样的情况，那些在采用这些工具的公司工作的工程师。我发现自己到某个点就会开始有点累，然后就放过去了。” 这种“疲劳效应”使得开发者更容易忽略代码中的错误，从而埋下隐患。

尽管存在风险，大语言模型在软件工程领域已展现出多个极具价值的应用方向。其中两个最为突出的领域是快速原型构建和遗留系统理解。在快速原型构建方面，大语言模型极大地缩短了从想法到可运行代码的时间，使得探索性工作成为可能。> “有一个领域已经获得了很多关注，那就是能够在几天内搭建出一个原型，这比以前快多了，这就是所谓的氛围感编程（VIBE CODING）。” 这种能力对于那些“用完就扔的探索性工作、一次性的小工具”提供了前所未有的便利。在另一个极端，大语言模型在理解复杂的遗留系统方面表现出了惊人的能力。其基本原理是：首先对现有代码库进行语义分析，将代码的结构和关系信息填充到一个图数据库中；然后，利用类似检索增强生成（RAG）的技术，通过自然语言查询来探索代码的内部逻辑。例如，可以询问“这块数据在程序流转过程中被哪些代码接触过？”或“某个函数的调用链是什么？”。这种能力已被ThoughtWorks正式纳入其技术雷达的“采纳环”（Adoption Ring），表明其已被证明是有效且值得推荐的实践。> “事实上，如果我没记错的话，我们已经把理解一流系统放进了技术雷达的采纳环。” 这标志着该技术已从实验走向成熟应用。此外，大语言模型在探索新领域方面也扮演着重要角色。当开发者面对一个不熟悉的编程语言或API时，可以通过提问的方式快速获取入门知识，例如“我该如何在某某引擎里做某某事？”。这种探索性学习的能力，结合了大语言模型的即时响应和人类的主动思考，形成了高效的“认知杠杆”。Fowler特别提到，他的一位同事JAMES LEWIS在使用C语言和GOLDOT游戏引擎时，正是通过这种方式快速掌握了新环境。> “他正在MAC上用C语言工作，这不是他非常熟悉的语言，并且在使用一个叫GOLDOT的游戏引擎。是的，狗斗他对这个一无所知，对吧？但是有了大圆模型，他可以学到一点。” 这种能力使得开发者能够迅速进入新领域，极大地降低了学习成本。

重构（Refactoring）作为软件工程的核心实践，在人工智能时代面临着新的机遇与挑战。Fowler回顾了自己1999年出版的《重构》一书，该书详细阐述了通过一系列微小、安全的步骤来改善代码质量的方法。他强调，重构的关键在于“每一步都小到不值得做，但你把它们串联起来就能做出惊人的事情”。这一原则在人工智能时代依然成立，但其实施方式发生了根本性变化。大语言模型本身无法进行真正的重构，因为它缺乏对代码语义的深层理解，也无法保证操作的安全性。然而，Fowler认为，大语言模型可以作为重构的起点，帮助开发者快速生成初步的重构方案。例如，它可以被用来描述“这些是我想要的改动类型”，从而启动一个自动化流程。更先进的方法是将大语言模型与确定性工具结合，形成一个协同工作流。> “我认为这种结合的方式可能是一个很好的途径，但毫无疑问，重构的思维方式以及思考如何通过基本上把改变分解成可以轻松组合的非常小的步骤来完成，这真的是它的诀窍。” 一家大型公司曾利用此类组合工具，成功完成了对API的重大变更和代码清理，尽管实际执行主要由其他专用工具完成，但大语言模型在其中起到了关键的引导作用。这表明，未来的重构可能不再是单一工具的功劳，而是一个由大语言模型提供智能建议、由传统工具执行精确操作的混合系统。然而，Fowler也指出了一个核心矛盾：随着AI工具能更快地生成更多代码，代码库的规模和复杂性必然急剧增加，这反过来使得重构变得更加必要和紧迫。他预言，重构的价值在未来只会变得越来越重要，因为它是在海量、质量存疑的代码中保持软件健康状态的唯一途径。> “AI工具能更快地生成更多代码，所以我们只会越来越多的代码。我们已经有了很多代码了，你认为重构的价值？……我不能说我已经看到了，但我完全可以预见它会变得越来越重要。”

设计模式（Design Patterns）在2000年代初曾是软件架构领域的主流话语体系，Fowler本人也是其重要推动者之一。然而，自2010年代以来，设计模式的讨论热度明显下降，许多技术人员不再频繁提及。Fowler对此现象进行了深入剖析，认为其背后的原因是云计算的兴起。以AWS、Google Cloud为代表的超大规模云服务商，提供了大量架构良好、开箱即用的服务（如DynamoDB、托管PostgreSQL）。这些服务就像乐高积木一样，让开发者能够快速搭建系统，而无需从零开始设计复杂的架构。因此，许多原本需要通过设计模式解决的问题，现在被这些成熟的云服务“内置”解决了。Fowler引用了一位同行的观点，认为“架构问题被这些架构良好的积木解决了，你不需要再重复造轮子了”。> “他说他认为发生的事情是从大约2010年代开始，因为模式从主流行业中消失了。……它的观察是：也许架构问题被这些架构良好的积木解决了，你不需要再重复造轮子了。” 然而，他同时指出，这并不意味着设计模式本身过时，而是其应用场景发生了转移。在现代分布式系统中，设计模式的思想依然适用，只是形式更为抽象。Fowler认为，未来的发展方向是领域特定语言（DSL）的复兴。他提到，他正在与同事合作撰写一本关于分布式系统模式的书，其目的正是为了创造一套通用的语言，以便更精确地描述和讨论这类系统。> “我确实看到的一种模式，是每家公司都会给他们的系统命名。有些名字很古怪，有些很合逻辑。” 这种语言不仅是技术上的抽象，更是沟通上的桥梁。他强调，理想的状态是“我们脑子里的语言和代码里的语言是相同的”，即开发者在思考问题时使用的术语，与代码中实际表达的术语完全一致。大语言模型为实现这一目标提供了强大的工具，因为它可以帮助开发者构建和表达这种更严谨、更精确的“规范”或“语言”，从而弥合思维与代码之间的鸿沟。

作为2001年《敏捷宣言》的17位共同签署人之一，Fowler对敏捷思想的起源和演变有着深刻的洞察。他回忆道，敏捷宣言的诞生源于一群实践极限编程（XP）的人士，他们希望将这一理念扩展到更广泛的软件开发社区。会议的选址曾一度在犹他州和加勒比海的安圭拉之间争论，最终在犹他州的滑雪胜地举行。> “我们当时还争论过是在犹他州开会，因为 ALISA 想在犹他州，而 DAVID THOMAS 想在加勒比海的安圭拉。” Fowler坦言，他对会议的具体细节记忆模糊，但清晰记得当时的想法：这份宣言本身可能“完全没用被人忽略”，但写作过程本身充满了乐趣，因为它促进了参与者之间的理解和共识。他最初并未预料到这份宣言会产生如此深远的影响。然而，随着时间推移，敏捷思想被广泛接受，但也遭遇了严重的滥用和误解。> “然后当然他大部分时间都被滥用了，因为ALICE COPPER有一句很棒的名言：你的绝妙想法要么被忽略，要么被误解，你没得选。” 他批评那些声称“你应该总是用微服务”或“你永远不应该用微服务”的绝对化论断，认为这些观点都应被忽略。真正有价值的是那些能指出“这个在这些情况下有效”的细微差别。在人工智能时代，敏捷的核心思想——增量改进，且越短越好——依然有效，但面临着新的挑战。客户不再满足于缓慢的增量交付，他们期望一开始就看到高质量的成果。Fowler认为，人工智能有望通过加速每个“小切片”的构建速度，来弥补这一矛盾。他强调，提高频率（faster cycles）而非单次迭代的体量，才是我们能获得最大收益的地方。他分享了一个来自CLOUD CODE团队的案例：一位工程师为一个功能构建了20个原型，仅用两天时间就完成了所有测试和反馈，这在传统模式下几乎是不可想象的。> “在CLOUD CODE团队，CLOUD CODE的创造者之一Boris分享了他如何为一个功能做了20个原型，就是那个进度条。当你做一个任务时，它会列出不同的步骤，并显示你进行到哪一步了。它构建了20个不同的原型。全都试用过，并获得了反馈，然后决定用哪一个。而这只花了两天时间。” 这表明，人工智能正在将“快速试错”从理论变为现实，从而极大地压缩了反馈循环周期。

面对人工智能的冲击，Fowler对初级软件工程师提出了至关重要的建议。他反复强调，学习是核心，而过度依赖人工智能会严重阻碍学习进程。他引用了同事UNMATCH的观点，指出氛围感编程之所以危险，正是因为其跳过了“学习的闭环”。对于初学者而言，如果总是依赖AI生成代码，而不去理解其背后的逻辑，那么他们将永远无法建立起对软件的真正掌控力。> “当你用氛围感编程时，你其实跳过了一个非常重要的环节——那就是学习的闭环。” Fowler建议，初级工程师应采取“探究性”的学习策略：每当AI给出一个建议或代码时，要追问“为什么”、“你的来源是什么”、“你是基于什么背景得出这个结论的”。这不仅能帮助理解AI的局限性，更能培养独立思考和批判性分析的能力。他特别推崇寻找一位有经验的导师，认为这是“价值千金”的事情。他个人的职业生涯就受益于早期导师JIM O'DELL的指导。> “一个好的有经验的导师价值千金。事实上，在很多方面，这比你职业生涯中的许多其他事情都更值得优先考虑。” 他建议，即便年龄相仿，也可以将思想领先的同行（如KENT BACK）视为导师。在人工智能时代，这种“探究性”思维尤为重要，因为AI本质上只是复述其训练数据中的内容，其输出的质量取决于其“看到”的是好东西还是垃圾。因此，找到通往优质信息的路径，比盲目信任AI更为关键。> “所以问题是他看到的是网上的好东西还是网上大部分的垃圾？对吧？但如果你能找到通往好东西的路，那就会更有用。” Fowler还提到了“专家型通才”（expert journalist）的重要性，即具备深厚专业知识的同时，又能跨越领域进行有效沟通的人才，这正是未来软件工程师的核心竞争力。

Fowler在访谈中反复强调，一个优秀的软件工程师最重要的品质，是能够拥抱不确定性，并在复杂的权衡中做出明智决策。他指出，我们所做的每一项技术决策几乎都是权衡的结果，没有放之四海而皆准的“银弹”解决方案。例如，是否采用微服务架构，取决于具体的业务场景、团队能力和运维成本。他批评那些声称“你应该总是用微服务”或“你永远不应该用微服务”的绝对化论断，认为这些观点都应被忽略。真正有价值的是那些能指出“这个在这些情况下有效”的细微差别。> “每当有人退后一步，说这是一个权衡，涉及到各种各样的事情。这里是你应该考虑的因素，这不会是一个简单的答案，你必须深入研究细微之处。” Fowler深受瑞典作家JIMMY NEWSON的启发，后者在其著作中始终谨慎地表明“这是我目前的感受，但明白事情可能会改变”。> “我记得我早期最喜欢的书之一，当时我正在写关于软件架构的东西。我记得我拼命地在微软的世界里寻找一些东西，而不是JAVA世界的东西。当我发现这个瑞典人JIMMY NEWSON时。他的书里充满了这样的内容，就是我对如何处理这些事情的感觉。他一直非常谨慎、非常清楚地表明这是他目前的感受，但明白事情可能会改变。” 这种对不确定性的坦诚，让他感到这是一个“我可以信任的人”。他认为，这种思维方式是抵御虚假确定感的最好武器。在人工智能时代，这种能力尤为重要。当AI给出一个看似完美的答案时，我们更应保持怀疑，因为其背后可能隐藏着训练数据中的偏见或错误。Fowler总结道，我们应当寻找那些能展示其思考过程、承认自身局限、并愿意探讨多种可能性的信息源。这种对“权衡”和“不确定性”的深刻理解，是超越技术本身、成为卓越工程师的基石。

Fowler的职业生涯是一部浓缩的软件工程发展史。他于1970年代末、1980年代初进入计算机行业，最初接触的是FORTRAN和汇编语言。这段经历让他深刻体会到从硬件层面操作的艰难与繁琐，也让他对后来高级语言的出现怀有深切的感激。他回忆道，自己大学时学过一点汇编，但那点经历“非常有用”，因为它让他“再也不想碰它了，非常明智”。> “我在大学里只学了一点点汇编，但那点经历非常有用。因为它让我再也不想碰它了，非常明智。” 正是这段经历，让他对“从汇编到高级语言”的转变有了切身体会。他的职业生涯始于咨询公司Cooper's and the Lie brand（他戏称为“骗子公司”），在那里他首次接触到面向对象编程的思想。他坦言，这并非源于公司前沿的定位，而是因为团队中有一位“有些很有趣的想法”的人，将这些想法包装成面向对象。这一机缘巧合，让他进入了面向对象的领域，并最终成就了其职业生涯。随后，他遇到了对他影响至深的导师JIM O'DELL，这位美国顾问成为了他早期职业发展的关键人物。在经历了咨询公司的“大公司疯狂”和创业公司的“小公司疯狂”后，Fowler于1990年代成为独立顾问，直到1999年加入ThoughtWorks。在ThoughtWorks，他见证了极限编程和敏捷的兴起，并参与了著名的克莱斯勒C3项目。他强调，正是在ThoughtWorks，他才真正找到了“我最喜欢的客户”，因为他们不仅认可理念，更愿意“试试”，并且通常都能成功。> “他们也想出了办法，从困境中恢复过来。后来他们就邀请我加入，我想嘿，再加入一家公司也不错，许就待个几年。他们人真的很好，是我最喜欢的客户。我一直觉得其他客户会说这些想法很好，但太难实现了；而SORT WORKS会说这些想法很好，是很难实现，但我们愿意试试。而且他们通常都能搞定，所以我想嘿。”

ThoughtWorks的技术雷达（Technology Radar）是其内部知识管理与外部影响力的重要体现。Fowler详细解释了其运作机制的演变。最初的灵感源于前CTO REBECCA PARSONS的构想：她需要一个顾问委员会，以确保高层管理者能与一线项目保持连接。这个委员会成员定期聚会，讨论技术趋势。在一次会议上，技术助理DARRELL SMITH提议，既然有这么多项目在进行，为什么不描绘出我们正在使用的技术及其效用呢？这个“雷达”比喻由此诞生。> “在一次会议上，当时是他技术助理的DARRELL SMITH提议说，我们有这么多项目在进行，如果能描绘出我们正在使用哪些技术以及这些技术有多大用处，那就太好了，这样能更好地交流想法。” 起初，雷达的制作是自下而上的，由一线项目人员提交“光点”（blips），然后在会议上集体讨论决定。如今，流程已更加完善，建立了专门的提交渠道，由区域、业务线或技术领域的负责人负责筛选。> “我们现在有了一套更完善的流程，让大家可以提交光点BLIP，也就是雷达上的一个点、一个条目。” 他们会把这些提交给某个负责人，可能是按地理区域、业务线或技术领域划分的。他们会说：嘿，我们觉得这个技术很有意思，然后简单介绍一下。接着他们会向现在的多普勒小组成员汇报，因为我们做的是雷达嘛，你懂的。> “他们会说：嘿，我们觉得这个技术很有意思，然后简单介绍一下。接着他们会向现在的多普勒小组成员汇报，因为我们做的是雷达嘛，你懂的。” 这一机制的成功之处在于它“把他们脑子里的一部分信息挖掘出来，在公司内部和整个行业传播”。他特别强调，雷达的初衷并非制定行业标准，而是“我们看到的是我们推荐给我们的团队或者客户考虑的东西”。> “我们从来没说这是整个行业的标准，而是说这是我们看到的是我们推荐给我们的团队或者客户考虑的东西。” 这种谦逊的姿态，使其更具可信度。雷达的“暂缓提醒”（Caution）部分，也体现了其审慎的态度。他指出，雷达之所以“让人感觉很新鲜”，很大程度上是因为ThoughtWorks在全球拥有数千名技术专家，他们接触的前沿技术本身就非常先进，使得雷达内容天然具有前瞻性。

尽管面临宏观经济的不确定性，Fowler对人工智能时代的未来仍抱有坚定的信心。他坚信，人工智能不会消灭软件开发，而是会以一种“非常明显的方式改变它”，其影响程度堪比“从汇编到高级语言”的转变。> “我并不认为人工智能会消灭软件开发，我认为它会以一种非常明显的方式改变它，就像从汇编到高级语言的转变一样。” 他强调，软件开发的核心技能——理解需求、与用户沟通、跨领域协作——永远不会过时。他特别提到了“专家型通才”（expert journalist）这一特质的重要性，认为这正是未来杰出软件工程师的标志。> “我认为这是一个很好的行业，只是时机不像在2005年进入这个行业那么好。但是你知道，我仍然觉得这里有一个很好的职业。” 他指出，我们正处在一场“认识论的危机”中，试图理解这个快速变化的世界。在这种背景下，他提倡一种“探究性”的学习和思考方式，即不要追求虚假的确定性，而要拥抱不确定性，关注事物背后的权衡和细微差别。他推荐的两本书——丹尼尔·卡纳曼的《思考，快与慢》和罗伯特·摩西的《权力经纪人》——分别从概率推理和权力运作的角度，为理解世界提供了深刻的洞见。> “我特别喜欢推荐的一本书是丹尼尔·卡纳曼的《思考快与慢》。我喜欢它是因为它做得非常好，试图给你一个关于数字的直觉，并指出我们在思考概率和统计时犯的许多错误和谬误。” 最后，他以一句充满哲思的话作结：“我们总是回到那篇50多年前的文章，没有银弹对吧？” 这句箴言，既是对他职业生涯的总结，也是对所有软件工程师的永恒提醒：在复杂的世界里，没有简单的答案，唯有持续的学习、深刻的思考和不懈的实践，才能引领我们走向更好的未来。