原始访谈视频:youtu.be
原节目与官方转写:newsletter.pragmaticengineer.com
📝 本期简介
当 AI 可以快速生成大量代码,软件工程师真正需要守住的能力是什么?这期 The Pragmatic Engineer 访谈里,Gergely Orosz 与 Martin Fowler 面对面讨论 AI 给软件工程带来的根本变化,以及为什么测试、重构和理解业务仍然重要。
Martin 从汇编语言转向高级语言的历史谈起,把它与今天从确定性工具走向非确定性模型相比较。对话随后进入 vibe coding、测试、企业遗留系统、《重构》、设计模式和敏捷宣言:AI 可以帮我们更快地写代码,但它会不会也放大错误抽象、失控复杂度和维护成本?
本期是根据官方转写文本制作的完整中文译配,不是精华摘要;保留原节目内容并另加中文导听。原作发布于 2025 年 11 月 19 日。
👨💻 原节目嘉宾
Martin Fowler:Thoughtworks 首席科学家,《重构》和《企业应用架构模式》作者,2001 年《敏捷软件开发宣言》17 位签署人之一。
🎙️ 原节目主持人
Gergely Orosz,The Pragmatic Engineer 主持人。中文版本以两种 AI 合成男声区分对话,不是两人的中文原声。
⏱️ 成品时间轴
以下时间对应本期中文音频,按合成片段实测起点定位,个别主题会在片段内稍后进入。
00:00:00 本期导听:AI 改变软件工程的核心是什么
00:02:49 Martin 如何进入软件工程
00:08:28 加入 Thoughtworks
00:11:01 Thoughtworks 技术雷达如何运作
00:17:53 从汇编语言到高级语言
00:26:33 非确定性:AI 带来的根本变化
00:35:09 Vibe coding 的用途与学习代价
00:40:46 从 Stack Overflow 复制代码到 AI 编程
00:45:16 LLM 为什么必须配合严格测试
00:52:50 企业软件、规范与遗留系统
00:58:39 Martin 为什么写《重构》
01:04:39 AI 时代重构为何更重要
01:08:45 让 LLM 驱动确定性工具
01:10:03 《企业应用架构模式》与共同语言
01:21:03 敏捷宣言的起源与真实影响
01:31:22 Martin 如何学习 AI
01:37:51 给初级工程师的建议
01:40:29 软件行业的低迷与 AI 泡沫
01:45:37 快速问答:语言、书籍与桌游
🌟 值得带走的观点
• 非确定性改变了工程边界。
传统编程工具通常给出可重复的结果,而 LLM 的输出带有波动。Martin 认为,团队需要重新思考容错、验证和可接受结果的范围。
• AI 时代更需要测试和重构。
代码生成速度提高以后,验证行为是否正确、控制复杂度和持续改善结构不会自动消失,反而可能决定大量生成代码能否长期维护。
• Vibe coding 有用途,也有学习代价。
它适合快速试验,但如果开发者不理解生成结果,可能失去建立心智模型和判断质量的反馈循环。
• 设计模式没有简单地“死亡”。
Martin 回顾模式热潮如何被过度使用,也说明模式作为共同语言仍然有价值;关键是帮助交流与设计,而不是机械套用。
• 工程师的核心仍是理解要解决的问题。
工具可以加快实现,但需求、约束、业务语境和取舍仍需要人做判断。这是访谈中的观点与经验,不是所有团队都能自动获得的结果。
🔗 相关资料
《重构》《企业应用架构模式》、Thoughtworks Technology Radar、OpenRewrite 与《敏捷软件开发宣言》均在访谈中被讨论;原节目、官方文字稿和视频见上方链接。
🌐 制作说明
中文制作:《研发效能》。根据官方转写进行 AI 辅助翻译,使用预置 AI 音色,非官方中文版,未克隆原人物声纹。
官方转写共 2,493 个时间片段,本译配按原顺序覆盖;说话人依据标签与上下文推断,个别人物归属及专名仍可能有误。音频已做完整解码和代表片段自动内容对照,未完成全程人工听审,个别技术术语可能有不自然发音。
当 AI 写代码越来越快,你认为团队最该加强的是测试、重构,还是需求判断?
