AI Coding 时代,软件工程基本功比以往任何时候都更加重要

我们正处于一个容易产生错觉的时期：看着大模型瞬间吐出几百行代码，不禁会想，既然代码生成的成本越来越低，那软件工程的那些条条框框——接口设计、架构边界、测试覆盖——是不是就没那么重要了？以后写好 Prompt 把需求喂给模型不就行了？大不了不满足就重新生成？

Matt Pocock 在他最近的一场演讲里，给这种想法泼了一盆冷水。 在 AI coding 时代，软件工程的基本功不仅没有过时，反而比以往任何时候都更加重要

原因很简单，AI 是放大器。如果你有一个边界清楚、接口稳定、反馈回路完整的代码库，AI 会成倍提升你的效率；但如果你的项目本身就依赖模糊、术语混乱，AI 只会以极快的速度帮你把 “屎山” 堆得更高。

这篇文章我们将跟随 Matt 的视角，重新审视在 AI Coding 时代，为什么接口、边界、领域语言和测试这些“老派”的基本功，反而成了开发者手中杠杆率最高的武器。最后，我们还会聊聊他最近爆火的 mattpocock/skills 仓库，看看他是如何将这些工程理念直接揉进 Agent 时代的工作流中的。

原视频：[Fundamentals Matter More Than Ever” — Matt Pocock]https://www.youtube.com/watch?v=v4F1gFy-hqg”Software

要点速览

• • AI coding 时代，软件工程基本功不是退场，而是升值。 接口、边界、测试、反馈回路、统一语言，这些“老派”的基本功 决定了 AI 是帮你放大优势，还是帮你放大混乱。
• • specs-to-code 从规格直接生成代码最大的问题，不是模型偶尔写错，而是它会诱导你过早放弃设计责任。 你以为自己在提效，实际上是在给系统持续注入熵。
• • 坏代码在 AI 时代更贵。 因为 AI 在好代码库里会放大优势，在坏代码库里会放大混乱。
• • “AI 没做成我想要的东西”通常不是模型太笨，而是你和模型没有共享同一个设计概念。 这也是 Grill Me 需求深度拷问这类做法有价值的原因。
• • AI 太啰嗦，本质上是你和它没有统一语言。ubiquitous language 解决的不是文档整洁，而是降低 AI 偏航成本。
• • 反馈回路就是速度上限。 类型系统、浏览器环境、自动化测试都重要，但更重要的是逼模型小步前进。
• • 深模块比浅模块更适合 AI。 接口薄、内部厚，既减轻人的认知负担，也降低模型迷路的概率。
• • AI 更像战术执行者，人类更应该回到战略设计。 你该多花时间定义接口、边界、模块地图和质量标准。

【1】specs-to-code 为什么这么诱人，但又这么危险

specs-to-code 规格直接生成代码。你先写一份规格说明，再让模型把它直接变成代码；如果哪里不对，就回头改 spec，重新运行一遍，系统就会吐出新代码。表面看，这像是软件开发的“自动编译器时代”。

Matt 之所以反对它，不是因为模型偶尔会写错，而是因为这条路会把一个更严重的问题藏起来：它会诱导你越来越少看代码，越来越少思考系统设计。

他自己试过这条路。第一次跑，先得到一些代码；第二次跑，代码更差；第三次跑，代码更乱。最后你会发现，你不是在得到一个会自我修复的系统，而是在一遍遍把系统推向熵增。

这也是整场演讲最先立住的判断：specs-to-code 不是在自动化软件设计，它更像是在自动化软件退化。你以为自己在做减法，实际上是在把本该由人承担的结构责任提前扔掉。而这恰好说明，AI 越强，软件工程基本功越不能撤资。

【2】为什么 Matt 会说：坏代码现在比历史上任何时候都更贵

演讲里最有冲击力的一句话，是 Matt 直接反对“代码已经很便宜”这套说法。更准确地说，便宜的是生成一段代码这个动作，真正变贵的是坏代码。

这个判断之所以成立，是因为 AI 改变了“坏代码的代价结构”。过去坏代码的代价主要体现为人改起来慢、容易出 bug、新人接手成本高；到了今天，坏代码还会直接拖垮 AI 的发挥。所以“坏代码更贵”不是另一个主题，而是一个结果：AI 把软件工程基本功的回报率拉得更高了。

因为 AI 在好代码库里会读到清晰接口、稳定反馈、可预测边界；但在坏代码库里，它读到的是噪音、模糊依赖和错误自由度。结果就是，好代码库会放大 AI 的能力，坏代码库会吞掉 AI 的红利。

所以“代码变便宜”这句话，如果只指“生成一段代码的动作更便宜”，那没问题；但只要一进入维护、修改、测试、理解这些真正决定长期成本的环节，这句话反而更不成立。

【3】AI 没做成你想要的东西，问题往往不在模型，而在共享设计概念

Matt 把第一个失败模式说得很直接：很多人抱怨“AI 没做成我想要的东西”，但问题通常不是模型太弱，而是你和模型之间没有形成共享的 design concept (设计概念)。

design concept 可以理解成一种看不见的共同理解。它不是某份单独的 markdown 文档，而是你和协作者对“我们到底在造什么”这件事的隐性共识。人和人一起设计东西时需要它，人和 AI 一起设计时同样需要它。

这也是 Grill Me 这个 skill 有意思的地方。它不急着产出计划，而是先把你摁住，一路追问：这个需求还有哪些分叉？这个决策依赖什么？这个约束到底是不是硬约束？只有当这些问题被问透了，AI 才开始真正动手。

这背后的方法论并不复杂：先对齐“我们在造什么”，再讨论“怎么造”。 很多返工不是发生在实现阶段，而是发生在最前面的概念没有对齐。共享 design concept，说到底是在把最前面的设计基本功补回来。

【4】AI 太啰嗦，不是表达问题，而是你们没有统一语言

第二个高频失败模式，是 AI 非常啰嗦，而且越聊越偏。Matt 的处理方式，不是去追一个更“克制”的模型，而是回到 DDD，也就是领域驱动设计里的 ubiquitous language。

对团队来说，ubiquitous language 本来是为了让开发和业务讲同一种术语；对 AI 来说，它变成了另一件更实际的事：让模型的规划、讨论和实现，都围绕同一套词表和同一张概念地图运转。

这件事看上去像文档工作，实际上是在降低偏航成本。因为模型很多时候不是不会写，而是不知道你说的“订单”“模块”“workspace”“发布”“版本”在当前系统里到底是什么意思。

Matt 的做法很实用：扫描代码库和规划材料，把关键术语整理成一份 markdown 文档，然后在规划和实现时反复使用。根据他的观察，这件事不只会让 AI 讲得更少废话，还会让实现结果和最初计划更对齐。统一语言不是润色文档，而是在给 AI 协作打地基。

【5】反馈回路不是配料，而是速度上限

到了第三类失败模式，问题从“做错方向”变成了“方向对了，但做出来的东西还是不能用”。Matt 给出的第一反应非常传统：类型系统、浏览器环境、自动化测试，这些反馈回路一个都不能少。

但他随后又点了一个更关键的问题：就算这些反馈回路都在，模型也未必会正确使用它们。它很容易一口气做太多事情，先吐出一大坨代码，再想起来要不要 type check、要不要跑测试。

《The Pragmatic Programmer》里有个说法，叫 outrunning your headlights，意思是车开得比车灯照得还快。Matt 把它借过来之后，给了一个非常适合 AI 时代的判断：

反馈的速度，就是你的速度上限。

这句话的含义很重。它等于在说：真正限制 AI 编码速度的，不是 token 速度，也不是补全速度，而是你能多快拿到可信反馈。反馈回路也不是配套设施，而是今天最贵的一项工程基本功。

【6】TDD 真正重要的，不是教条，而是强迫 AI 小步前进

所以 Matt 会把 TDD 放到这么高的位置。不是因为 TDD 神圣，而是因为它能强迫 LLM 小步前进。

先写测试，让测试失败；再做最小实现，让测试通过；最后再重构。这套节奏的本质，不是形式主义，而是把“验证”前移成每一步的硬约束。

Matt 还强调了一点：测试之所以一直难，不只是因为写断言本身难，而是因为测试里充满相互依赖的决策。你测多大的单元、mock 什么、验证哪些行为，这些选择是连在一起的。

也正因为如此，他才会把问题继续往下挖：真正适合 AI 的，不只是“有测试”，而是天然更容易测试的代码库。TDD 在这里重要，不是因为它神圣，而是因为它把基本功变成了能一轮一轮执行的工作节奏。

【7】深模块为什么同时减轻 AI 和人的认知负担

Matt 给出的答案是 deep modules。所谓深模块，就是接口尽量简单，但内部功能可以很厚；与之相对，浅模块看起来拆得很细，实际上功能不多，接口却很复杂。

这两种结构在 AI 时代的差异非常大。浅模块多的代码库，会让模型在大量细碎节点之间来回穿梭。它不是完全不会探索代码，而是很容易因为结构太散、依赖太乱，在错误的位置浪费上下文。

深模块的好处则是双向的。对 AI 来说，它只需要先理解模块边界和接口，就能在很多情况下完成实现；对人来说，你也不必每次都把所有细节同时装进脑子里，而是可以先守住接口设计和用途判断。

这也是 Matt 后面那句建议的基础：设计接口，把实现委托出去。 真正值得人长期盯住的，是边界、模块地图和接口质量，而不是每一行内部实现。深模块不是品味问题，而是 AI coding 时代很现实的一项架构基本功。

【8】AI 时代的人类角色，不是少思考，而是更多做战略设计

到这里，整场演讲其实已经把人和 AI 的分工说得很清楚了。AI 更像一个战术执行者，一个在一线不断改代码的“地面程序员”；而人更该回到战略层，去做系统设计上的判断。这里说的人类角色升级，不是少做基本功，而是把几项最关键的基本功从执行层上移到设计层。

这个战略层具体包括什么？其实就是几项必须继续由人掌舵的基本功：

• • 模块边界怎么划
• • 接口应该长什么样
• • 哪些术语必须统一
• • 哪些反馈回路必须先建好
• • 哪些模块可以交给 AI 放手实现，哪些地方必须人工严审

Matt 引用 Kent Beck 的那句“每天都要继续投资系统设计”，其实就是整场演讲的最终收束。因为 specs-to-code 最大的问题，不是它想提效，而是它在诱导你从设计上撤资。

看了他怎么说，再看他怎么做：mattpocock/skills 本质上是在把基本功 workflow 化

如果说前面这场演讲是在讲判断，那 Matt 最近开源的 mattpocock/skills，就是把这套判断直接做成了工程动作。这个仓库已经有 58.2k stars。它之所以爆火，不只是因为作者本人有影响力，而是因为这套仓库几乎把他在演讲里的核心观点，一条条落实成了可执行的工作流，与他的理念相辅相成。

仓库地址：https://github.com/mattpocock/skills

这个仓库最值得注意的地方，不是它又提供了一批 prompt，而是它的设计理念和这场演讲几乎是同一套话。仓库首页的标题叫 Skills For Real Engineers，强调的也不是 vibe coding，而是小、可改、可组合，而且不要把整个过程交给 AI 接管。换句话说，他不是在替你发明一条“AI 可以绕开软件工程”的新路，而是在把软件工程基本功重新编码进 agent workflow。

你几乎可以一一对上前面讲过的几个问题。

• • 前面说“AI 没做成你想要的东西”，他对应做了 /grill-me 和 /grill-with-docs，先逼自己把需求、约束和分叉问清楚。
• • 前面说“AI 太啰嗦，本质上是没有共享语言”，他对应做了 CONTEXT.md、ADR 和 /grill-with-docs，把统一术语和关键决策沉淀下来。
• • 前面说“反馈回路就是速度上限”，他对应做了 /tdd 和 /diagnose，把测试驱动和诊断闭环变成日常动作。
• • 前面说“AI 会更快把系统推向 ball of mud”，他对应做了 /to-prd、/zoom-out、/improve-codebase-architecture，强迫自己持续回到模块、边界和架构设计。

所以看完这个仓库，你会发现一件很重要的事：Matt 不是嘴上说“基本功重要”，而是真的在把这些基本功产品化、流程化、可复用化。 这也是它为什么会在这么短时间里被大量开发者接受。大家未必会完全照搬这套 skills，但很多人都能立刻看懂它背后的方法论。

这件事对我们自己的启发也很直接。真正值得学的，不一定是把这个仓库一比一搬回去，而是学他这一步：不要让 AI 替你绕开基本功，而是把基本功写进工作流，让 AI 在这些轨道上跑。

可以快速借鉴到项目落地到点

这两天看完  Matt Pocock 这个演讲视频，以及他在 Github 上热度很高的开源项目 mattpocock/skills。我觉得下面几个小点是非常值得个人或团队学习和借鉴的。

1. 1. 在让 AI 真正动手前，先需求深度拷问，让它追问你，把需求以及设计概念问清楚。
3. 2. 给当前项目建立一份统一语言文档，让规划和实现使用同一套术语。
5. 3. 不要只给模型报错日志，要给它小步反馈回路，尤其是类型检查、浏览器反馈和自动化测试。
7. 4. 优先把相关代码收进深模块，而不是继续堆浅层碎片。
9. 5. 把自己的时间从“盯每一行实现”，挪到“定义接口、边界和质量标准”上。

收尾一下

很多时候，我们容易把工具的进化误当成自身能力的跃升。代码生成的速度越来越快，但它也悄悄隐藏了一个代价：系统崩坏的速度同样可以变得极其惊人。

Matt Pocock 的这场演讲，与其说是在强调基本功，不如说是给 AI 时代的开发者指明了一条真正的护城河。接口、边界、测试和深模块设计，这些过去用来对抗系统复杂度的手段，现在成了我们驾驭 AI、不被机器产出的海量代码反噬的唯一缰绳。这也解释了为什么 mattpocock/skills 这样不教捷径、只谈工程流的项目会引发如此大的共鸣。

最近几个月被反复讨论的 Harness Engineering，本质上就是应用软件工程的思维来指导 Ai Coding 时代的项目落地，所以，软件工程基本功比以往任何时候都更加重要。

我们得想想，自己现有的工程素养，能不能兜得住 AI 带来的庞大产能? 在学习和使用ai工具提效的同时，也要回归到软件工程本身，把基本功练到极致，软件工程师是不能在代码里丢失掌控感的。

AI 趣实验 出品谢谢你读我的文章，既然看到这里了，如果觉得不错，关注我，顺手点个赞、在看、转发三连吧～