最近听了一期很有意思的播客，嘉宾是Martin Fowler。可能很多人对这个名字不太熟悉，但在程序员圈子里，他绝对是殿堂级的人物。他写的《重构》和《企业应用架构模式》是无数开发者的入门必读书，他还是2001年敏捷宣言的签署者之一。可以说，他见证了软件行业过去四十年的几乎所有重大变革。

这期访谈主要聊的是AI对软件开发的冲击。有趣的是，作为一个从汇编语言时代走过来的老兵，他对AI的态度既不盲目乐观，也不一味悲观，而是带着一种经历过大风大浪之后的冷静。

这可能是我职业生涯中最大的变革

访谈一开始，主持人就问了一个很直接的问题：在你几十年的职业生涯中，有什么变革能和AI相提并论？

Fowler的回答很干脆：这是我职业生涯中最大的一次。如果要在整个软件发展史上找一个可以类比的，那就是从汇编语言到高级语言的那次跃迁。

这个类比挺有意思的。当年从汇编转向高级语言，程序员不再需要关心每个寄存器、每条机器指令，可以用更接近人类思维的方式写代码。这是一次巨大的抽象层提升。

但Fowler紧接着说了一句让我印象深刻的话：这次变革最大的特点，不是抽象层又提高了，而是我们从确定性的世界进入了非确定性的世界。

什么意思呢？以前写代码，同样的输入永远产生同样的输出。跑一遍是这个结果，再跑一遍还是这个结果。但现在用大语言模型，同样的提示词，今天生成的代码和明天生成的可能完全不一样。这种不确定性，是软件工程师从来没有面对过的。

我们需要学会像造桥一样写代码

Fowler提到他妻子是结构工程师，负责设计桥梁和建筑。结构工程师在工作中有一个核心概念叫容差。木材、钢铁、混凝土的物理性能虽然大致已知，但你不能按照理论最优值去设计，必须留出足够的余量，为最坏的情况做准备。

软件工程师以前不太需要这种思维。代码要么对，要么错，没有什么中间状态。但现在，当我们越来越依赖AI工具来辅助写代码，这种确定性就被打破了。

Fowler担心的是，很多人还没意识到这个变化的严重性，还在用老思路来用新工具，总想着滑得更靠近边缘。他预感在安全领域会出现一些很明显的翻车事故，因为人们对AI工具的非确定性太大意了。

这让我想到一个更普遍的道理：当游戏规则变了，老玩家的经验有时候反而会变成包袱。那些习惯了确定性世界的资深工程师，如果不调整思维方式，说不定比新手更容易踩坑。

Vibe coding很爽，但有个致命问题

访谈里聊到了现在很火的vibe coding。简单说就是你告诉AI想要什么，它直接给你生成代码，你甚至不用完全看懂它写了什么，只要能跑起来就行。

Fowler讲了一个亲身经历的小故事。他的同事用AI生成了一张简单的示意图，就是那种用几条曲线说明问题的伪图表。Fowler想微调一下，比如把标签挪得离曲线近一点。结果打开SVG文件一看，傻眼了。他自己以前手写过类似的图，也就十几行代码。但AI生成的这个，复杂得离谱，完全没法改。

这就是vibe coding的问题：你可以让AI快速生成一个能用的东西，但你完全不理解它是怎么实现的。想改一点点？做不到。只能整个扔掉重新生成。

更关键的是，Fowler指出这种方式会切断学习循环。编程的本质是什么？是你有一个想法，写成代码，看电脑的反馈，再调整想法，如此反复。这个过程中你在不断学习。但如果你从来不看AI生成的代码，你就什么都没学到。

所以他的结论是：vibe coding适合做原型、做一次性的小工具、做探索性的尝试。但任何需要长期维护和迭代的东西，都不能这么干。

这个思路其实可以延伸到很多领域。无论是写作、设计还是其他创意工作，工具可以帮你提速，但学习的过程不能外包。你省下来的时间如果不用来思考和理解，那省下的其实是自己的成长。

理解遗留系统，AI真的很在行

访谈中有一个让我很惊喜的观点：Fowler说Thoughtworks已经把用AI理解遗留代码放进了他们技术雷达的采纳环。这是最高级别的推荐，意味着他们强烈建议在这个场景下使用AI。

这个应用场景是这样的：对于一个复杂的老系统，你可以对代码做语义分析，把结构信息放进图数据库，然后用类似RAG的方式让AI帮你回答问题。比如，这段数据从哪里来？经过了哪些模块的处理？谁在用这个接口？

任何在大公司待过的人都知道，理解遗留系统有多痛苦。代码是十年前写的，当时的人早就离职了，文档要么没有要么过时，你只能一行一行去读。有了AI的辅助，至少可以更快地建立起对系统的整体理解。

Fowler还提到一个故事：有人从创业公司跳槽到一家老牌银行，任务是推动技术现代化。干了三年之后，这人说了一句话：我觉得我现在大概能理解这个问题了。

三年，只是理解问题。还没开始解决。

大公司的复杂性很多时候不是技术造成的，是人造成的。张三和李四当年关系好，所以选了A方案。后来张三调走了，王五上来喜欢B方案。这些决策层层叠加，最后就变成了一团乱麻。AI不能帮你解决这种人为的复杂性，但至少能帮你更快地看清代码层面发生了什么。

把AI当助手，而不是魔法棒

在如何与AI工具协同工作这个话题上，Fowler的建议很实在。他说，要把AI生成的代码当作是一个能力很强但不太靠谱的实习生提交的PR。

这意味着什么？意味着你需要仔细审查每一处改动。不能因为AI生成的代码看起来挺像那么回事，就直接合并进主分支。

他提到几个具体的做法：用非常小的切片来工作，每个切片都要经过人工审查；保持测试覆盖，AI生成的代码尤其需要测试来验证；不要怕重构AI生成的代码，往往它生成的东西结构很混乱，需要你整理。

有一个很有趣的细节：Fowler说他的同事James Lewis用Cursor尝试重命名一个类，结果花了一个半小时，用掉了10%的月度token配额。这个任务如果用传统IDE的重构功能，也就几秒钟的事。

这说明什么？说明AI在处理某些传统工具已经解决得很好的问题时，反而效率低下。知道什么时候该用AI，什么时候该用传统工具，这本身就是一种需要培养的判断力。

Stack Overflow的教训还在重演

我想到一个有趣的类比。十几年前，Stack Overflow刚出现的时候，也引发过类似的讨论。

在Stack Overflow之前，网上搜代码答案是件很痛苦的事。你可能会进到Experts Exchange这种网站，看到问题，但答案要付费。大部分学生和初级开发者根本不会付费，就只能干着急。

Stack Overflow出现后，情况完全不同了。你搜一个问题，几乎总能找到可以直接拷贝的代码片段。于是很多人，尤其是新手，就养成了一个习惯：遇到问题，搜一下，拷代码，跑起来，搞定。

资深工程师看到这种情况会说什么？你需要理解这段代码为什么能工作，不能只是拷过来用。

但很多人做不到。有一个著名的例子：Stack Overflow上有个关于邮箱验证的问题，得票最高的答案其实不完全正确。结果大量软件都用了那段代码，导致某些合法的邮箱地址被错误拒绝。

Fowler说，AI辅助编程和当年的Stack Overflow是同一种问题，只是规模更大了。Stack Overflow是拷贝一个函数，现在是AI生成一整个文件。风险也更大了，因为AI生成的东西更复杂，更难看出问题。

但解决方案还是一样的：你必须看懂代码。必须理解它在做什么。必须保持学习。

重构在AI时代变得更重要了

有一个反直觉的观点：当AI能快速生成大量代码时，重构反而变得更重要了。

为什么？因为AI生成的代码质量参差不齐。它能跑起来，能通过测试，但内部结构可能一团糟。Fowler讲了他自己的经历：同事用AI生成了一个简单的伪图表，SVG格式。Fowler想微调一下，打开文件一看，完全没法改，复杂得离谱。他自己手写类似的图也就十几行代码，但AI生成的版本根本看不懂。

这就是vibe coding的问题：你能快速得到一个能用的东西，但你完全不理解它的实现。想改？做不到。只能推倒重来。

重构的价值在于，它让你能够在保持功能不变的前提下，改善代码的内部结构。AI生成一堆乱七八糟的代码，你通过重构把它整理成你能理解和维护的样子。

Fowler一直强调重构的两个关键特征：小步骤和可组合性。每一步改动都极其微小，小到几乎不值得做。但这些小步骤可以组合起来，完成很大的改动。而且因为每步都很小，所以不容易出错。

他提到一个有趣的对比：20年前，JetBrains推出ReSharper插件，提供自动重构功能，大家愿意花200美元一年去买。现在这些功能已经成为IDE的标配。但AI工具在重构方面还远远不如这些传统工具。

所以他的建议是：AI生成代码之后，人工介入，用小步骤重构成可维护的形式。这个过程也是学习的过程。

用AI生成的语言和AI对话

有一个很前沿的想法来自Fowler的同事Unmesh：与其让AI直接生成代码，不如先和AI一起构建一种抽象语言，然后用这种语言更精确地描述问题。

这个想法源于一个发现：如果你用自然语言描述一堆国际象棋对局，AI很难学会下棋。但如果你用标准的棋谱符号描述同样的对局，AI就能理解了。

原因很简单：棋谱符号是一种精确的、无歧义的领域专用语言。每个符号都有明确的含义。相比之下，自然语言太模糊，同样的意思可以有无数种表达方式。

Unmesh的方法就是把这个思路应用到软件开发：先花时间和AI一起定义一套术语和概念，建立一个小型的领域专用语言，然后用这套语言去描述需求和指导AI生成代码。

这和领域驱动设计的统一语言理念是一脉相承的。在DDD中，开发团队和业务专家要建立一套共同的语言，这套语言既能准确表达业务概念，又能直接映射到代码中。

现在的区别是，这套语言不仅用于团队内部沟通，也用于和AI工具沟通。而且因为AI的存在，构建这套语言的成本降低了——你可以让AI帮你快速生成和验证这些抽象。

Fowler说，这可能是未来的方向：我们不是简单地用自然语言给AI下命令，而是用一种介于自然语言和编程语言之间的精确语言，与AI协作。

让AI驱动确定性工具

还有一个很实用的思路：不要让AI直接生成最终代码，而是让AI生成输入，然后用确定性的工具来执行。

什么意思呢？比如说，你不太会写SQL，但需要对数据库做一个复杂查询。你可以用自然语言描述你要什么数据，让AI生成SQL语句。生成之后，你检查一下，觉得没问题，再让确定性的数据库引擎去执行。

这样做的好处是什么？AI只负责理解你的意图和生成查询，真正的执行是由完全确定性的系统完成的。你能清楚地看到AI生成了什么，也能预测数据库会做什么。

Fowler提到，有人在用类似的方法做代码重构。用AI分析代码，识别需要重构的地方，生成重构建议，然后用专门的重构工具去执行这些改动。AI提供智能，确定性工具保证准确性。

这种混合模式可能是未来的一个重要方向：充分利用AI的理解能力和生成能力，但在关键步骤上仍然依赖我们能够完全理解和控制的确定性工具。

这也呼应了他之前说的，要像结构工程师考虑容差那样思考。木材、钢铁、混凝土的性能虽然不是完全确定，但工程师知道如何为不确定性留出余量。我们也需要类似的思维：在某些地方容忍AI的不确定性，但在其他地方用确定性工具来兜底。

敏捷在AI时代依然有效

2001年，Fowler和另外16个人在犹他州的雪山里开了个会，搞出了敏捷宣言。当时谁也没想到这个宣言会有那么大影响。

Fowler说他当时的想法很简单：写这个宣言的过程会很有意思，能让大家互相理解。至于宣言本身？估计没人会在意。结果完全出乎意料。

现在AI来了，有人问：敏捷那一套还有用吗？

Fowler的答案是：核心理念不仅有用，而且更重要了。

敏捷的本质是什么？小切片，快速循环，人在回路中验证。每次改动都很小，快速得到反馈，根据反馈调整方向。

AI应该让这个循环更快，而不是让每个循环变得更大。

这是个关键区别。很多人觉得有了AI，应该在每个迭代里做更多事情。Fowler说不对，应该是迭代变得更频繁。把原来两周的工作切成四个小片，每个小片三四天就上线，这才是正确的方向。

为什么？因为软件开发的核心难题从来不是写代码慢，而是搞不清楚该写什么。用户需求会变，市场会变，技术环境会变。你花两个月憋个大招，等上线的时候，可能方向已经错了。

小步快跑的好处是，你可以快速试错。这个功能用户不喜欢？没关系，才投入了一周。赶紧调整，试下一个想法。

他提到Anthropic的一个开发者，用Claude Code在两天内做了20个交互原型，每个都录了视频，记录了具体的prompt和输出。这就是敏捷精神在AI时代的体现：不是做一个完美的设计，而是快速尝试多个方向，从反馈中学习。

Fowler特别强调一点：不管工具多强大，人的判断不能缺席。每个小迭代都需要人来验证，确保走在正确的方向上。AI可以让你跑得更快，但方向盘必须握在人手里。

设计模式为什么淡出了

90年代末2000年代初，设计模式是个很热的话题。Gang of Four 的《设计模式》，Fowler 的《企业应用架构模式》，到处都在讨论工厂模式、单例模式、观察者模式。

面试的时候，面试官会问：你知道哪些设计模式？能现场写一个工厂模式吗？

后来，这些讨论逐渐少了。现在的年轻程序员很多都不太了解设计模式，也不觉得有必要学。

为什么会这样？

Fowler和Grady Booch讨论过这个问题。Booch是UML的创始人之一，对软件架构有很深的研究。他给出了一个有趣的观察：可能是云服务商解决了架构问题。

什么意思呢？以前你要设计一个系统，得从头考虑很多东西。数据怎么存？怎么缓存？怎么处理并发？怎么容错？每个问题都需要你了解相关的模式，做出权衡，实现出来。

现在呢？你用AWS或者Google Cloud，直接用Dynamo或者Cloud SQL存数据，用Redis缓存，用Lambda处理事件。这些服务都是精心设计过的，架构问题它们已经帮你解决了。你只需要知道怎么用这些构建块就行。

这是个有意思的视角。某种程度上，云服务商把一些通用的架构模式固化成了产品。你不需要自己实现观察者模式，直接用消息队列就行。不需要自己设计缓存失效策略，Redis已经提供了几种方案。

但Fowler也指出，模式思维并没有消失，只是转移了。在组织内部，人们仍然在创造术语和模式。只不过这些术语是针对具体业务的，而不是通用的设计模式。

比如在Uber，可能有银行emoji服务、Gulfstream系统、Payment Profile服务这些名字。每个都代表了一种特定的架构决策和职责划分。新人加入需要学习这套内部语言，才能融入团队。

模式的本质是什么？是一套共享的词汇表，让人们能更有效地讨论复杂的概念。这个需求永远存在，只是形式在变化。

如何识别靠谱的信息源

在这个信息爆炸的时代，如何判断一个信息源靠不靠谱？

Fowler说了一个反直觉的标准：当有人告诉你这要看情况，涉及很多权衡因素，你反而应该更相信他。

这听起来很奇怪。我们不是应该相信那些给出明确答案的人吗？

不是。至少在软件开发这个领域不是。

因为软件开发中几乎所有重要的决策都涉及权衡。没有银弹。你选A，放弃了B的好处。你优化了性能，牺牲了可读性。你提高了灵活性，增加了复杂度。

那些斩钉截铁告诉你应该永远用微服务或者永远不用微服务的人，要么是不懂，要么是在误导你。真正懂行的人会问：你的团队多大？系统的规模如何？变更的频率怎样？不同模块的生命周期是否一致？

根据这些具体情况，才能给出建议。

Fowler提到他很欣赏一个瑞典开发者Jimmy Nielson。90年代末他在找关于微软技术栈的架构书籍，大部分书都在告诉你应该怎么做。只有Nielson的书充满了这样的表述：这是我目前的理解，这是我在这种场景下的做法，但情况可能会变。

这种不确定性，这种对语境的敏感，反而让Fowler觉得可信。因为这说明作者真正在思考问题，而不是在背教条。

AI时代这一点更重要了。AI最擅长给出看起来很有道理的确定性答案。如果你问它微服务好不好，它会给你一个洋洋洒洒的回答，列举优缺点，最后可能还会得出一个结论。

但这个结论对你的具体情况是否适用？AI不知道。

所以你要学会问追问：为什么你建议这么做？你这个建议基于什么前提？如果前提变了会怎样？

好的信息源会主动告诉你这些。不好的信息源会让你觉得答案很简单。

软件行业的寒冬与泡沫

聊到现在的行业形势，Fowler说了一个出人意料的观点：真正冲击软件行业就业的不是AI，是零利率时代的结束。

过去十几年，利率极低，钱很便宜。创业公司疯狂烧钱，大公司疯狂扩张。Thoughtworks一度每年增长20%。

2021年之后，一切都变了。利率上升，融资困难，客户收紧预算。裁员潮开始的时候，AI还没有现在这么火。

现在的情况很诡异：一边是软件行业的萧条，大量工程师失业，找不到工作；另一边是AI领域的狂热，融资动辄几亿几十亿美元，估值疯涨。

两个世界，同时存在。

Fowler经历过90年代末的互联网泡沫。他说现在的AI泡沫规模更大。泡沫是不是一定会破？会。什么时候破？不知道。破了之后会怎样？也不知道。

但他相信AI里面确实有真东西，不像当年的区块链和加密货币那么虚。关键问题是，泡沫消退之后，什么会留下来？

这很难预测。互联网泡沫破裂后，无数公司倒闭，但活下来的那些，比如亚马逊和谷歌，后来改变了世界。AI领域也会如此。

对个人来说，现在入行的时机确实不如2005年。但Fowler认为，软件开发作为一个职业，长期来看是安全的。

为什么？因为需求永远大于供给。

人们对软件的需求不会减少，只会增加。就算AI让开发者的生产力提高了10倍，我们仍然需要团队来构建大型系统。原来100人的项目变成10人的项目，但同时会出现100个新的项目需求。

而且，软件开发的核心技能不会过时。什么是核心技能？理解用户需求，与人沟通，把模糊的想法变成清晰的方案，在约束条件下做权衡。

这些能力，AI帮不了你。

给年轻开发者的建议

访谈快结束时，主持人问：对刚入行的年轻开发者，你有什么建议？

Fowler的回答很朴素：找一个好的导师。

这听起来像是老生常谈，但他说的很真诚。他自己职业生涯早期遇到Jim Odell，对他影响巨大。后来和Kent Beck共事，从Kent那里学到了极限编程和重构。

好的导师能帮你判断什么是好代码，什么是坏代码。能帮你理解为什么这样做，而不只是怎么做。

用AI工具的时候，这种判断力更重要。AI会给你答案，但答案是否合适？是否有更好的选择？这些问题，新手很难自己判断。

他建议，使用AI的时候要保持怀疑。把AI当成一个能力很强但会撒谎的助手。它给你一段代码，你要问：为什么这么写？有没有其他办法？这个方案的前提假设是什么？

多问为什么，多追问信息来源，多尝试理解背后的道理。

Fowler还推荐了一本书，《思考，快与慢》，作者是诺贝尔奖得主丹尼尔·卡尼曼。这本书讲的是人类思维的两个系统，以及我们在概率和统计方面常犯的错误。

为什么推荐这本书？因为软件开发中充满了需要用概率思维的场景。这个bug多久会出现一次？这个性能优化值不值得做？用户会怎么使用这个功能？

培养概率思维，能让你做出更好的决策。而且这不仅对写代码有用，对理解整个世界也有用。

他还推荐了罗伯特·卡罗的《权力掮客》，讲的是纽约一个从未当选的官员如何在40年间掌握了比市长和州长更大的权力。这本书展示了权力在民主社会中如何运作，同时也是写作的典范。

Fowler说，要成为更好的写作者，就要读真正优秀的作品。而清晰的写作能力，对程序员来说也很重要。

写在最后

听完这期访谈，最大的感受是：技术在巨变，但思考的方式比具体的技术更重要。

Fowler见证了从汇编语言到高级语言的转变，见证了互联网的兴起，见证了敏捷开发的流行，现在又在见证AI对软件行业的冲击。每一次变革都有人喊天要变了，旧的一切都要被淘汰。但他依然在做同样的事情：观察、思考、写作、分享。

他说自己学习AI的方式很简单：用它。遇到问题就试试AI能不能帮上忙，在实际使用中积累对工具的理解。不是先读一堆论文搞懂原理，而是边用边学。

这个方法听起来很朴素，但可能是面对任何新事物最好的姿态。不急着下结论，不急着站队，先用起来，在实践中形成自己的判断。

对了，Fowler今年应该快70岁了。他说自己当年进入这个行业纯属偶然，因为自己手笨，干不了需要体力的工程活，写代码刚好不需要力气。谁能想到，这个偶然的选择让他见证了人类历史上发展最快的行业的几乎全部历程。

而我们正站在又一次巨变的起点上。

---

最后，介绍一下，我的星球：「AIGC·掘金成长研习社」，主要分享什么内容呢？三个板块的内容：

1、副业赚钱领域的内容。我做自媒体十几年了，有很多副业赚钱方面的经验和干货，而且每周都会定期详细带大家拆解一个副业赚钱案例，持续更新的那种，目前，已经分享了上百篇跟副业赚钱相关的帖子和文章了。

2、AI 落地和实操相关的内容。我在里面也分享了很多 AI的各种玩法和落地场景，包括用 AI 做副业的案例也都有。

3、个人成长。我会分享很多我做超级个体和自由职业的一些思考和成长类的内容，目前我已经做自由职业 5 年了，有太多的感慨和内容分享。

如果你想学习如何搞副业，如何使用 AI ，甚至如何使用 AI 搞副业，那一定要加入我这个超值的星球。目前，已经更新了 1500 多条干货和文章了，加入成员 740+。感兴趣的可以加入。

最近限时最大优惠，原价 149 ，今天加入可以立减 50 元，只需要 99 元，春节后，会涨价到 199 元。我认为我的星球是目前副业和 AI 领域最超值和具有性价比的星球，价格不贵，同时内容也不比几千块钱的星球差。

大家可以扫码，查看，支持 3 天无理由退款，内容好不好，先进来看看再说，不适合自己退了也没毛病。