配套视频：https://www.bilibili.com/video/BV1E6qbBuEAv/
"这是我职业生涯中最大的一次技术变革。回顾软件发展史，最接近的类比就是从汇编语言到高级语言的转变。" —— Martin Fowler
引言：一次跨越40年的对话
当我坐在Martin Fowler对面时，很难不被这位软件工程界传奇人物的谦逊所打动。作为《重构》一书的作者、敏捷宣言的创始人之一、ThoughtWorks的首席科学家，他见证了软件开发从汇编语言到面向对象，从瀑布模型到敏捷开发的整个演进过程。
如今，在AI浪潮席卷全球的2024年，这位拥有40年软件开发经验的智者如何看待这场新的技术革命？他的答案既令人兴奋，又发人深省。
第一部分：从电子工程到软件大师的意外之旅
偶然的开始
Martin的职业生涯始于一个有趣的自我认知："上学时，我显然不擅长写作，因为凡是写作类的，我分数都很差。"他笑着回忆道。这个在写作上"不擅长"的学生，后来却成为了软件工程领域最具影响力的作者之一。
他最初对电子工程感兴趣，原因很实际："我做不了需要力气或肢体协调的事。修车时我连生锈的螺母都拆不下来。"电子工程相对友好，"毕竟你只需要会用焊枪"。但很快，他发现了更适合自己的领域——计算机。
80年代的面向对象革命
1980年代中期，Martin在一家咨询公司工作时，接触到了当时还相当激进的面向对象编程思想。"那时这确实是一件相当激进的事，"他回忆道，"我遇到了一位美国专家Jim Odell，他成为我职业初期最重要的导师。"
这段经历为他后来的职业生涯奠定了基础。从汇编语言到高级语言的转变，让他深刻理解了抽象的力量："你开始使用Fortran，至少能写条件语句和循环。虽然没有else，但我至少可以用if。"
ThoughtWorks的25年
1999年，Martin做了一个改变他人生的决定——加入ThoughtWorks。"我记得离开上一家公司时心想，就这样了，独立了，我的人生，再也不用回公司上班。"他开玩笑地说。
但ThoughtWorks不同。"其他客户会说这些是非常好的想法，但实施起来很难。而ThoughtWorks会说，这些想法确实很好，很难实现，但我们会试试——他们通常都能成功做到。"
25年过去了，Martin仍然在ThoughtWorks担任首席科学家。"这个头衔既无下属，也不做科研，"他自嘲道，"我不喜欢这个头衔，更想叫'大喇叭'。"
第二部分：ThoughtWorks技术雷达的秘密
自下而上的智慧
ThoughtWorks技术雷达是软件行业最受关注的技术趋势报告之一，每半年发布一次。但很少有人知道它背后的运作机制。
"大约十多年前开始，"Martin解释道，"当时的CTO Rebecca Parsons成立了技术顾问委员会。后来我们的技术助理Daryl Smith提出，我们有这么多项目在进行，可以了解下我们使用的技术类型及其效用。"
这个过程完全是自下而上的：
提名阶段：全球各地的ThoughtWorks员工可以提交"雷达点"——他们认为值得关注的技术
地区讨论：通过地理位置、业务线或技术相关性，形成初步讨论组
多普勒小组：专门的团队对提名进行整理和分析
雷达会议：在正式会议上讨论并决定哪些技术进入雷达
"这是一项自下而上的工作，"Martin强调，"我们在雷达会议前一两个月开展零星收集工作，会上逐一讨论。对我来说有点奇怪，如今我已远离日常琐事，只剩下这一连串技术之类的东西，大多我不了解，但听起来有趣。"
开放的精神
ThoughtWorks始终坚持一个原则：尽可能公开内部信息。"我们始终坦诚分享一切，毫无保留地公开我们的秘诀，"Martin说，"这正是我加入的原因。"
他们甚至鼓励其他公司制作自己的技术雷达："ThoughtWorks从没说过这是行业的标准，我们只说这是适合我们的。"
最新一期的技术雷达（2024年末）反映了AI时代的技术趋势：
推荐采用：pre-commit钩子、ClickHouse数据库、vLLM（大模型推理加速）
试用阶段：MCP（模型上下文协议）服务器
特别关注：用生成式AI理解遗留代码（已进入"采用"级别）
第三部分：AI——软件工程史上最大的变革
堪比汇编到高级语言的转变
"在我的职业生涯中，这无疑是最大的技术革新，"Martin毫不犹豫地说，"回顾整个软件发展史，类似的变化是从汇编语言到最早的高级语言。"
但这次变革有一个根本性的不同："最大的转变是从确定性转向非确定性。突然要在非确定性环境中工作，这彻底改变了你的思维方式。"
这种非确定性带来了前所未有的挑战。Martin分享了一个令人啼笑皆非的例子：
"前几天我遇到件特别奇怪的事。我有个配置文件，只是往里添加新项目，并在注释中注明添加日期。我跟大模型说，请加上这个配置，加上当前日期。它就添加了，直接复制了上次的日期。我说，这不是今天的日期。它连忙道歉说'我来帮你改一下'，结果填的是昨天的日期。"
AI的有效应用场景
尽管存在挑战，Martin看到了AI在几个关键领域的巨大价值：
1. 快速原型开发
"一个备受关注的领域是快速搭建，几天内就能做出原型，远超以往可能实现的速度。"这种能力特别适合探索性工作和一次性工具开发。
"这是vibe编程，"Martin解释道，"但它不止于此，因为还能让人们尝试探索，即使还不太确定该做什么。"
2. 理解遗留代码
这是ThoughtWorks技术雷达中唯一进入"采用"级别的AI应用。
"思路是提取代码本身，进行语义分析，并将结果存入图数据库，"Martin详细解释，"然后以类似RAG的方式使用，开始查询并分析这段数据会发生什么，哪些代码在数据流经程序时会接触它。"
这对于每家成立超过几年的大公司都至关重要："他们都有遗留系统的问题，而生成式AI能帮你取得一些进展。"
3. 学习新技术
Martin的同事James Lewis用C#和Godot游戏引擎开发Mac程序，这两者他都不熟悉。"但有了大模型，他就能学一点，因为他可以尝试实践。"
"我常忘了怎么在R里做某事，明明已做过20次，却仍记不住具体操作，"Martin坦诚地说，"大模型在这方面很有帮助。"
4. 初始环境搭建
"给我一个初始项目，一个示例骨架项目，好让工作立刻开展，"这是Unmesh（Martin的同事）特别强调的应用场景。
Vibe编程的陷阱
但Martin对"vibe编程"持谨慎态度。他将其定义为"根本不会去看输出的代码，或许出于好奇可能瞥一眼，但你其实并不在意"。
他分享了一个生动的例子：
"我的同事Gun Mesh让大模型生成了一个伪图表。他描述了想要的曲线，设计出L形，放了上去。我看了下觉得这图已经不错了，但想稍作调整——标签离对应的线有点远。于是我打开了LLM生成的SVG文件。哦，天哪！真没想到它竟如此复杂曲折。我之前自己写过一个，知道也就十几行SVG代码，但这东西令人震惊地奇怪。"
关键问题在于学习闭环的缺失：
"若不关注输出，就无法学习。我们提出想法，并在计算机上尝试实现，在电脑呈现与我们所想之间不断反复迭代。我们不断经历这一学习循环过程。而大语言模型只是粗略地掠过这些，你并未真正学习。"
Martin的同事Gun Mesh在最近发布的文章中强调："长期使用vibe编码会削弱关键能力，而这种能力正是学习闭环的核心。"
第四部分：重构在AI时代的新意义
重构的本质
作为《重构》一书的作者，Martin对这个主题有着深刻的理解。"重构是在不改变代码外部行为的前提下，对代码内部结构进行调整，"他解释道。
20年前，当Jetbrains推出Resharper插件时，能够自动重命名类和变量还是一项前沿技术，"人们为此花了不少钱，这插件每年要花200美元左右。"
如今，这些功能已经成为IDE的标配。但有趣的是，大模型在这方面反而效率低下。
AI时代的重构悖论
Martin的同事James Lewis做了一个实验：用Cursor让AI重命名一个类。"一个半小时后返回，并已用掉每月token配额的10%，"Martin说，"他只是改了个类名。"
"而实际上，我们的集成开发环境确实具备这样的功能，"Martin指出，"你可以右键并选择重命名类，它在后台自动生成并修改了抽象语法树结构。"
这揭示了一个重要问题：有些事情很简单，我们已经解决了，但大模型在这方面却效率低下，表现不佳。
重构变得更加重要
但在AI时代，重构的重要性不降反升。原因很简单：
AI生成大量代码：需要持续优化和改进
代码质量参差不齐：必须通过重构提升可维护性
团队协作需求：需要统一的代码风格和结构
"不要害怕重构，也不要害怕提交代码，"Martin建议，"当然，还要配合测试。你添加的代码必须有测试，要持续反复进行测试。"
构建抽象的艺术
Martin特别欣赏同事Unmesh Joshi的工作："他确实在推动用大模型协同构建抽象，并加以运用。通过抽象化与大模型更高效地交流，我发现这非常有效。"
这让他想起了Lisp的格言："你真正要做的是在Lisp中创建自己的语言，然后用它解决问题。"
"这种思维方式至关重要，"Martin说，"用语言描述你要解决的问题类型，并能平衡二者，这正是构建可维护、灵活代码的关键。"
第五部分：测试——非确定性世界的救生索
测试的重要性倍增
在与AI协作的过程中，测试变得前所未有的重要。Martin特别提到了Simon Willison和Birgitta Böckeler的工作："他们一直强调测试的重要性，对他们而言，测试至关重要。"
"我们来自ThoughtWorks，非常重视测试，"Martin说，"她也深受极限编程影响，非常注重测试。"
AI会"撒谎"
但问题在于，AI本身在测试方面并不可靠。
"我发现自己到某个阶段，只听到真正的问题，或亲身体验时才了解，"Martin分享道，"比如当大模型告诉我'哦，我运行了所有测试都通过了'，但npm test却有五个失败。"
"事实上，如果他们真是初级开发者——你有时会听到这种说法——他们该被定义一下，我得跟HR说道说道，"Martin开玩笑地说。
验证，不要轻信
这引出了一个核心原则：Trust but verify（信任但要验证），或者更准确地说，Verify, don't trust（验证，不要轻信）。
"专业人士处理重要事务时，切勿轻信它，"Martin强调。
他建议采用以下实践：
小步迭代：每次只让AI生成少量代码
立即测试：生成后立即运行测试
仔细审查：不要跳过代码审查环节
持续重构：不断改进AI生成的代码
第六部分：设计模式的兴衰与DSL的复兴
设计模式为何淡出
2000年代初期，设计模式（Design Patterns）曾是软件工程的热门话题。但到了2010年代，它逐渐淡出主流视野。
Martin认为原因很简单：云服务提供了现成的架构组件。
"以前你需要自己实现单例模式、工厂模式，"他解释道，"但现在，AWS、Azure提供了各种托管服务，你不需要从头构建这些基础设施。"
领域特定语言的新机遇
但AI时代带来了新的可能性：领域特定语言（DSL）与大模型的结合。
Martin提到了一个有趣的观察："如果你能向大语言模型描述大量棋局用普通英语描述，大语言模型其实不懂如何下棋。但若将这些棋局以棋谱notation输入大模型，它便能理解。"
"有趣的是，你显然在缩小token的大小，但你也在用一种更严谨的符号来描述问题，"他分析道，"或许这就是我们使用大模型的一个切入点——我们需要找到一种严谨的表达方式。"
这自然让人联想到：
领域驱动设计（DDD）中的通用语言（Ubiquitous Language）
语言工具（Language Workbenches）
DSL（Domain-Specific Languages）
"所以周围有些非常有趣的东西，但接下来会如何发展将值得关注，"Martin说。
第七部分：敏捷开发在AI时代的演进
敏捷宣言的初衷
2001年，包括Martin在内的17位软件开发者在犹他州雪鸟滑雪场签署了敏捷宣言。23年过去了，敏捷开发已经成为主流，但也面临着被误用和形式化的问题。
"我们当时的想法很简单，"Martin回忆道，"推动增量交付和客户协作，小步快跑、快速反馈。"
AI时代的敏捷实践
在AI时代，敏捷的核心原则不仅没有过时，反而变得更加重要。
Martin特别强调了**规范化开发（Specification-driven Development）**的概念，这是他的同事Birgitta Böckeler正在探索的方向。
"大语言模型虽有局限，但若明确需求并给出优质规范，它能持续运行，不断迭代推进，"他解释道。
但这听起来是不是有点像瀑布模型？Martin笑了：
"与瀑布模型相似的是，人们仍试图先制定大量规格说明，而不太关注代码。但关键区别在于：要避免先写完整个规格的瀑布式问题。"
正确的做法是：
最少的文档：只写必要的规格
快速迭代：构建、测试、上线
小切片：通过小切片持续循环
人在回路：每次都进行人工验证
"规格在两种情况下所起的作用，可视为一种由规格驱动的开发模式，但在我看来，重要的是紧密的迭代和细小的切分，"Martin总结道。
优化周期时间
在AI可以快速生成代码的时代，关键指标不再是单次产出的代码量，而是周期时间（Cycle Time）——从想法到生产环境的时间。
"即使AI真能让我们效率提升十倍（我认为不会），我们仍需10人团队来完成过去百人团队的工作，"Martin说，"软件需求并未出现下降迹象，所以我们始终需要团队。"
第八部分：团队协作的新挑战
代码审查的困境
AI时代带来了一个新问题：代码量激增导致的审查疲劳。
"我发现自己到某个阶段，我开始感到疲惫，便不再坚持，"Martin坦诚地说，"和工程师交流时也常听到这种情况。"
几乎每家公司都在使用AI辅助编程工具，代码量大幅增加，但审查能力并没有相应提升。"他们也在问，如何在代码审查越来越多时，仍保持高效？"
构建共同语言
Martin认为，解决方案在于构建更精确的交流语言。
"我非常关注Unmesh在这方面的做法，因为他的方法正是要构建一种语言来与大模型交流，"他说，"我们与大模型协作，构建一种更精确的交流语言，明确我们真正寻找的目标。"
这种方法的优势在于：
减少误解：精确的语言减少歧义
提高效率：更少的迭代次数
便于审查：团队成员更容易理解意图
知识积累：形成团队的共同词汇
团队协作的未知领域
"那么问题自然是，如何在团队中更好地与AI协作？"Martin提出了这个关键问题，"我们也在努力弄清楚这一点。"
这是一个悬而未决的领域："无论是新建还是改造项目，团队协作时会发生什么？因为大多数软件由团队构建，未来仍将如此。"
第九部分：企业软件开发的特殊性
初创公司vs传统企业
Martin观察到，不同类型的组织在采用AI方面有着显著差异。
"初创公司会激进尝试新技术，"他说，"而传统企业会谨慎评估风险。"
但有趣的是："内部差异往往大于企业间差异。"
遗留系统的挑战
对于大多数企业来说，最大的挑战不是构建新系统，而是如何处理遗留系统。
"每家成立超过几年的大公司都有这个问题，而且尤为突出，"Martin说，"人们说走就走，就这么简单，而生成式AI能帮你取得一些进展。"
但问题依然存在："大模型能否安全地帮我们修改遗留代码，仍是问题。"
监管与合规
企业软件开发还面临着严格的监管要求。在AI时代，这带来了新的挑战：
如何确保AI生成的代码符合安全标准？
如何审计AI的决策过程？
如何在监管框架内使用非确定性工具？
"我担心会出现一些明显的崩溃，因为人们使用的工具在非确定性上已经逼近极限，"Martin警告道。
第十部分：学习与信息获取
Martin的学习方法
作为一位持续学习了40年的软件工程师，Martin的学习方法值得借鉴。
"我常与许多人交流，"他说，"与实践者合作编辑文章，关注可信来源。"
他特别提到了几位值得关注的人物：
Birgitta Böckeler：ThoughtWorks同事，探索AI辅助开发
Simon Willison：强调测试的重要性
Kent Beck：极限编程创始人
Unmesh Joshi：研究领域语言与大模型结合
"通过编辑工作深度学习，"Martin解释道，"当我帮助别人整理思路时，我自己也在学习。"
保持不确定性
令人印象深刻的是，Martin始终保持着谦逊和开放的态度。
"如今我已远离日常琐事，只剩下这一连串技术之类的东西，大多我不了解，但听起来有趣，"他说。
这种态度体现了一个重要原则：承认知识的局限性，持续探索和更新认知，避免过早下结论。
Stack Overflow的启示
Martin将当前的AI浪潮与10年前Stack Overflow的兴起进行了类比。
"大约十年前，行业里一次重大的生产力提升，正是源于Stack Overflow，"他回忆道，"在Stack Overflow之前，你谷歌问题时会遇到一个网站，专家解答问题，但需付费才能查看答案。"
Stack Overflow改变了这一切，但也带来了新问题："许多年轻人或经验较少的开发者都会直接把代码放进去，看它是否能运行。"
"有经验的工程师或开发者会告诉初级工程师：你得明白即使它能运行，你也得明白为什么能运行，必须理解其原理，"Martin说。
这个教训在AI时代同样适用。
第十一部分：非确定性的新世界
工程学的类比
Martin的妻子是结构工程师，这给了他一个有用的类比。
"她总考虑公差是多少，"他说，"除了数学计算外，我还需要预留多少余量，因为我需要考虑公差。虽然我大致了解木材、混凝土或钢材的性能，但必须按最坏情况来设计。"
"我们自己或许也需要这种思维方式，"Martin建议，"我们需应对的非确定性有多大容忍度？要意识到不能过于冒险，否则桥梁可能坍塌。"
新的平衡技巧
在非确定性环境中工作，需要一套全新的平衡技巧：
容忍度管理：明确哪些地方可以接受不确定性
风险评估：识别高风险和低风险场景
验证机制：建立多层次的验证体系
回退策略：准备好Plan B
"我们必须解决为解决该问题，需掌握一套全新的平衡技巧，"Martin说。
首次面对的挑战
"可以说这是我们首次面对这一挑战吗？"我问道。
"面对我们非常熟悉的确定性计算机的这一挑战，我们深知其局限性，"Martin回答，"还有各种问题，当然也存在竞态条件和一些特殊状况，但现在我们正面临这一亟待解决的问题，这需要一种全新的思维方式。"
这种思维方式与工程学其他领域类似："你需用这种思维方式思考公差，我妻子是结构工程师，她总考虑公差是多少。"
第十二部分：未来展望
仍在探索的领域
Martin坦诚地承认，很多问题仍然没有答案。
"所以还有很多问题，"他说，"我们已有一些答案，或答案的雏形，此刻见证这一切，令人着迷。"
几个关键的未知领域包括：
团队协作：如何在团队中有效使用AI
遗留系统改造：大模型能否安全修改旧代码
质量保证：如何在非确定性环境中确保质量
长期维护：AI生成的代码如何长期维护
有前景的方向
尽管存在挑战，Martin看到了几个有前景的方向：
1. 构建领域语言
"我非常关注Unmesh在这方面的做法，因为他的方法正是要构建一种语言来与大模型交流，"Martin说，"我坚信这方向极具前景且更为有效。"
2. 更频繁的小步迭代
"只需用最少的文档推动进展，循环迭代：构建、测试、尽可能上线，再通过这些小切片持续循环，"Martin建议。
3. 结合确定性和非确定性工具
"有些事情很简单，我们已经解决了，"Martin指出，比如IDE的自动重构功能，"但大模型在这方面却效率低下。"
关键是找到合适的平衡：用确定性工具做确定性的事，用AI做AI擅长的事。
保持警惕
Martin的最后警告值得深思：
"我担心在安全方面，我们终将如此。我担心会出现一些明显的崩溃，因为人们使用的工具在非确定性上已经逼近极限。"
但他也保持乐观："此刻见证这一切，令人着迷。"
结语：拥抱变化，保持清醒
在这次长达一小时的对话中，Martin Fowler展现了一位软件工程大师的智慧：既对新技术充满热情，又保持理性和谨慎。
他的核心观点可以总结为：
AI是软件工程史上最大的变革，堪比从汇编语言到高级语言的转变
非确定性是核心挑战，需要全新的思维方式和工程实践
小步迭代、快速反馈的敏捷原则在AI时代更加重要
人在回路中是不可或缺的，AI不能完全自动化
学习闭环必须保持，不能因为AI而放弃深度理解
测试和重构在AI时代变得更加关键
构建领域语言是与AI有效协作的有前景方向
对于每一位软件工程师来说，这是一个激动人心的时代，也是一个充满挑战的时代。正如Martin所说：
"我们仍在学习如何做到这一点，每个人都在真正地学习。"
让我们保持开放的心态，拥抱变化，但也保持清醒的头脑，不被炒作所迷惑。毕竟，软件工程的本质——构建可维护、可靠、有价值的系统——并没有改变。
AI只是我们工具箱中的新工具，如何用好它，取决于我们的智慧和经验。
关于作者：本文基于与Martin Fowler的深度访谈整理而成。Martin Fowler是ThoughtWorks首席科学家、《重构》作者、敏捷宣言创始人之一，在软件工程领域拥有40年经验。
延伸阅读：
ThoughtWorks技术雷达：thoughtworks.com/radar
Martin Fowler的博客：martinfowler.com
《重构：改善既有代码的设计》
敏捷宣言：agilemanifesto.org
#AI编程 #VibeCoding #Cursor #ClaudeCode #独立开发者 #AI创业 #一人公司 #程序员 #软件工程师 #软件工程
