当前位置：首页 > news >正文

收藏！AI时代，软件工程基本功才是你的核心竞争力

news 2026/5/27 4:24:13

在AI coding时代，软件工程的基本功不仅没有过时，反而比以往任何时候都更加重要。AI是放大器，好的代码库能提升效率，而模糊混乱的代码库则会放大混乱。接口、边界、领域语言和测试等“老派”的基本功，是开发者手中杠杆率最高的武器。文章介绍了如何将工程理念揉进Agent时代的工作流，并通过开源项目mattpocock/skills展示了这些理念的实际应用。

我们正处于一个容易产生错觉的时期：看着大模型瞬间吐出几百行代码，不禁会想，既然代码生成的成本越来越低，那软件工程的那些条条框框——接口设计、架构边界、测试覆盖——是不是就没那么重要了？以后写好 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. 在让 AI 真正动手前，先需求深度拷问，让它追问你，把需求以及设计概念问清楚。
2. 给当前项目建立一份统一语言文档，让规划和实现使用同一套术语。
3. 不要只给模型报错日志，要给它小步反馈回路，尤其是类型检查、浏览器反馈和自动化测试。
4. 优先把相关代码收进深模块，而不是继续堆浅层碎片。
5. 把自己的时间从“盯每一行实现”，挪到“定义接口、边界和质量标准”上。

收尾一下

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

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

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

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

小白/程序员如何系统学习大模型LLM？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。