Matt Pocock：AI编程时代，软件工程基本功反而更重要了

在AI Engineer Europe大会上，知名开发者、TypeScript教育者Matt Pocock带来了一场发人深省的演讲。他的核心论点简洁而反直觉：在AI编程时代，软件工程的基本功不仅没有过时，反而比以往任何时候都更加重要。

这一观点直指当下开发圈流行的一种论调——"代码很廉价"（code is cheap）。Matt认为这个说法是错误的，甚至可以说，糟糕的代码从未像今天这样昂贵。

"Specs to Code"运动的困境

近来开发圈兴起了一场名为"Specs to Code"（规格到代码）的运动。它的理念是：你只需要用自然语言写清楚应用应该如何工作，然后交给AI去生成代码；如果程序有问题，你不看代码，而是回去修改规格文档，再重新生成代码。理论上，开发者可以完全不接触底层代码。

Matt坦言自己也认真尝试过这套方法，结果却令人沮丧。他发现，反复运行"编译器"（指AI生成流程）时，第一次产出的代码尚可，但随着每一次迭代——代码质量反而越来越差，越改越烂，最终陷入混乱。

"我不认为这套方法真的可行，"Matt直言。让AI自己维护代码、人类完全不看代码的想法，在实践中站不住脚。

从经典软件书籍中寻找答案

为了搞清楚问题所在，Matt回归到了几本经典软件工程著作。

在John Ousterhout的《A Philosophy of Software Design》中，他找到了对"坏代码"的定义——复杂性。书中写道：复杂性是软件系统结构中任何使其难以理解和修改的东西。换句话说，坏代码库就是难以修改的代码库。如果你无法在不引入bug的情况下修改代码，那它就是坏代码。

而在《The Pragmatic Programmer》（程序员修炼之道）中，他找到了"软件熵"的概念：系统天然趋向于混乱和崩溃。每当你只关注眼前这次修改、而不考虑整个系统设计时，代码库就会一步步恶化。这恰恰解释了他在"Specs to Code"实验中观察到的现象。

核心论点：好代码库让AI如虎添翼

Matt的结论是：好的代码库比以往任何时候都更重要。

原因很直接——AI在一个结构良好的代码库中表现极其出色，能释放巨大的生产力红利。反之，如果代码库难以修改，你就无法享受到AI带来的红利。因此，好代码库比以往更重要，也就意味着软件基本功比以往更重要。这正是整场演讲的主旨。

接下来，Matt结合自己在《Claude Code for Real Engineers》课程中的实践，系统梳理了几种常见的AI协作"失败模式"，以及如何用老派的软件工程智慧来规避它们。

失败模式一：AI没做你想要的东西

很多开发者都遇到过这种情况：脑子里明明有个好想法，AI却生成了完全不同的东西。

《程序员修炼之道》指出：没有人真正确切地知道自己想要什么。你和AI之间存在沟通壁垒。当你和AI对话时，实际上是AI在做"需求收集"。

Matt还引用了Frederick P. Brooks《The Design of Design》中的"设计概念"（Design Concept）——当多人共同设计一件东西时，会有一个飘浮在彼此之间的、无形的关于"我们在构建什么"的理念。它不是资产，无法写进markdown文件，而是构建物的隐性理论。

他意识到，问题在于自己和AI没有共享同一个设计概念。于是他开发了一个极其简单的技能，叫做"Grill Me"（拷问我），核心指令仅有两句：

就这个计划的每一个方面无情地拷问我，直到我们达成共识。逐一走遍设计树的每个分支，逐个解决决策之间的依赖关系。

这个技能在GitHub上意外爆红，仓库获得了约1.3万star。短短几行指令，能让AI向你抛出40个、60个甚至100个问题，直到确信双方达成了共识。它把AI变成了一个"对手"，不断挑战你的想法。这样产出的对话，可以直接转化为产品需求文档（PRD）或issue。Matt认为，这种做法比Claude Code默认的"计划模式"更好——后者过于急于生成资产，而他更希望先达成共享的设计概念。

失败模式二：AI太啰嗦，沟通效率低下

第二种失败模式是AI过于冗长，用太多的词汇来描述它在做什么，仿佛你们在鸡同鸭讲。

这让Matt想起了资深开发者与领域专家协作的经历。如果领域专家让你构建一个关于微芯片的应用，而你对微芯片一无所知，你们就必须建立某种共享语言，否则专家会用你听不懂的术语，你会把它翻译成连自己都不理解的代码。

为此，他转向了**领域驱动设计（DDD）**中的"通用语言"（Ubiquitous Language）概念——开发者之间的对话、代码表达、以及与领域专家的对话，都源自同一个领域模型。本质上，这是一个markdown文件，列出你和AI之间共同的术语表。

Matt做了一个"通用语言"技能：扫描代码库、提取术语、生成一个包含所有术语的markdown表格文件。他会把这个文件常开在旁边，在规划和"拷问"AI时反复引用。通过阅读AI的思考轨迹，他发现这不仅改善了规划质量，还让AI的思考变得更简洁，最终实现的代码也更贴合原始计划。

失败模式三：AI做对了，但代码跑不起来

第三种情况是：AI构建了正确的东西，但它就是不工作。

显而易见的解法是反馈循环：静态类型（如果你还不用TypeScript，那太疯狂了）、给LLM访问浏览器的能力（对于前端应用是必需的）、以及自动化测试。

但Matt观察到，即便有了这些反馈循环，LLM也用不好——它不像资深开发者那样能充分利用反馈。它往往一次做太多事情，产出海量代码后才想起来"哦，我应该做个类型检查"或"我应该跑个测试"。

《程序员修炼之道》里有个绝妙的比喻——"超越你的车灯范围"（outrunning your headlights）：反馈的速率就是你的速度上限。这意味着你应该边做边测，采取小而审慎的步伐。而AI默认状态下恰恰不擅长这一点。

因此，**测试驱动开发（TDD）**成为了关键技能。TDD强迫LLM放慢脚步：先写测试，让测试通过，再重构代码使其更优雅、更贴合设计意图。

好代码库 = 易于测试的代码库

但Matt也承认，测试本身一直很难，因为写测试涉及大量相互依赖的决策：测试多大的单元？测试什么？测试哪些边界？

他多年职业生涯得出的洞察是：好的代码库就是易于测试的代码库。这又回到了"代码结构很重要"的核心命题。

借鉴Ousterhout的思想，他主张构建"深模块"（deep modules）——即用简单接口隐藏大量功能的模块，而非充斥着大量小函数、浅接口的碎片化结构。

Matt指出，AI很擅长生成上图这种"许多小碎块"式的代码，但这会导致AI最终读不懂自己写的代码——因为它被淹没在浅模块的海洋里，无法把握模块间的协作关系。相比之下，深模块把复杂性封装在简单接口之后，让你可以在接口层进行测试，也让AI更容易理解。

设计接口，委托实现

Matt反复强调的原则是：设计接口，委托实现（design the interface, delegate the implementation）。

对于应用中不那么关键的模块，你可以明确定义好接口，然后把内部实现交给AI处理，自己只需从外部进行测试和验证。当然，涉及金钱等敏感逻辑的部分你不能这么做，但在应用的大部分模块中，这种"从外部设计模块"的做法能极大解放你的心智负担。

这也意味着，在与代码打交道、规划变更时，我们必须始终对系统中的模块保持清晰的"地图"意识。Matt引用了Kent Beck的名言——"每天都为系统设计做投资"（invest in the system design every day）。而在"Specs to Code"的做法中，我们恰恰放弃了对系统设计的投资，任其自行发展。

结语：AI是战术军士，你是战略家

Matt用一个精妙的军事比喻收尾：如果把AI看作执行代码变更的战术军士（tactical sergeant），那么你就必须是站在它背后、在战略层面思考的那个人。

而战略层面的能力，正是我们过去二十年乃至更久所积累的软件工程基本功——深模块设计、通用语言、TDD、系统架构。

"代码不廉价，代码很重要，"这是Matt最想传递的信息。在AI浪潮中感到自己技能被淘汰的开发者，或许应该反过来看：那些经典书籍里的老道理，正是你在新时代做出巨大贡献的底气所在。

Matt Pocock的相关技能已开源在GitHub仓库 Matt Pocock Skills，更多内容可在其网站 aihero.dev 查看。