AI Coding 时代，基本功才是你唯一的护城河
代码生成越来越快，但系统崩坏的速度，同样可以变得极其惊人。
说实话，第一次看到 Cursor 在十秒内甩出两百行代码的时候，我也恍惚了一下。
那个瞬间很难不产生一个念头：既然代码可以这么廉价地产出，软件工程里那些”老古董”——接口设计、架构边界、测试覆盖、领域语言——是不是终于可以退休了？以后写好 Prompt，把需求往模型嘴里一塞，不满足就重新生成，不就是新时代的软件开发吗？
Matt Pocock 在他最近那场爆火的演讲里，用一句话把这层幻觉撕了个干净：
AI coding 时代，软件工程的基本功不仅没有过时，反而比以往任何时候都更加重要。
这不是保守派的哀嚎，而是一个残酷的事实：AI 不是替代者，它是放大器。
一、AI 是放大器，不是魔法师
放大器有个特点：它只负责放大，不负责筛选。
如果你的代码库边界清晰、接口稳定、反馈回路完整，AI 会把你的效率成倍拉升。但如果你的项目本身就是一坨依赖模糊、术语混乱、职责交缠的泥巴，AI 不会帮你清理它——它只会以你从未想象过的速度，把这坨泥巴堆得更高、更结实、更难闻。
所以问题从来不是”AI 能不能写代码”。问题是：你的工程底子，能不能兜得住 AI 带来的庞大产能？
Matt 说得很直白：坏代码在 AI 时代更贵了。过去坏代码的代价是”人改起来慢”；今天坏代码的代价是”AI 在里面彻底迷路，然后带着你一起跑偏”。
二、specs-to-code：不是自动化设计，是自动化退化
演讲中有一个观点特别扎心—— specs-to-code（规格直出代码）这条路，表面上是软件开发的”自动编译器时代”，实际上是在自动化软件退化。
Matt 亲自踩过这个坑。第一次跑，得到一些代码；第二次跑，代码更差；第三次跑，代码更乱。你不是在得到一个会自我修复的系统，你是在一遍遍把系统推向熵增。
为什么？因为 specs-to-code 会诱导你越来越少看代码，越来越少思考系统设计。你以为自己在做减法，实际上是在把本该由人承担的结构责任，提前扔进了垃圾桶。
这恰好说明了一个反直觉的结论：AI 越强，软件工程基本功越不能撤资。
三、”AI 没做成我要的东西”——通常不是模型太笨
这是开发者抱怨最多的一句话。但 Matt 的观察是：问题通常不在模型，而在你和模型之间没有共享同一个 design concept（设计概念）。
Design concept 不是某份单独的文档，而是一种隐性共识——对”我们到底在造什么”的共同理解。人和人协作需要它，人和 AI 协作同样需要它。
这也是为什么 Matt 在 skills 仓库里做了一个叫 Grill Me 的动作：不急着产出计划，而是先把你摁住，一路追问——这个需求还有哪些分叉？这个决策依赖什么？这个约束到底是不是硬约束？
先对齐”我们在造什么”，再讨论”怎么造”。 很多返工不是发生在实现阶段，而是发生在最前面的概念没有对齐。共享 design concept，说到底是在把最前面的设计基本功补回来。
四、AI 太啰嗦？本质是你们没有统一语言
另一个高频场景：你跟 AI 聊着聊着，它开始车轱辘话来回说，而且越聊越偏。
Matt 的处理方式不是去找一个”更克制”的模型，而是回到领域驱动设计（DDD）里的 ubiquitous language（统一语言）。
对团队来说，统一语言是为了让开发和业务讲同一种术语；对 AI 来说，它变成了更实际的事：让模型的规划、讨论和实现，都围绕同一套词表和同一张概念地图运转。
模型很多时候不是不会写，而是不知道你说的”订单””模块””workspace””发布””版本”在当前系统里到底是什么意思。术语漂移一次，修复成本就是十倍。
Matt 的做法很朴素：扫描代码库，把关键术语整理成一份 CONTEXT.md，然后在规划和实现时反复使用。效果出奇地好——AI 不仅废话少了，实现结果和最初计划也更对齐。
统一语言不是文档洁癖，是在给 AI 协作打地基。
五、反馈回路，是你的速度上限
Matt 借用了《The Pragmatic Programmer》里的一个说法：outrunning your headlights，车开得比车灯照得还快。
把它放到 AI 时代，结论很锋利：
反馈的速度，就是你的速度上限。
真正限制 AI 编码速度的，不是 token 生成速度，而是你能多快拿到可信反馈。类型系统、浏览器环境、自动化测试——这些反馈回路不是配套设施，而是今天最贵的一项工程基本功。
这也是为什么 Matt 把 TDD 放到了很高的位置。不是因为 TDD 神圣，而是因为它能强迫 LLM 小步前进——先写测试，让测试失败；再做最小实现，让测试通过；最后重构。把”验证”前移成每一步的硬约束，模型才不容易一口气吐出一大坨无法验证的代码，然后才发现方向错了。
六、深模块：让人和 AI 都少费点脑子
在架构层面，Matt 给出的答案是 deep modules（深模块）——接口尽量简单，内部功能可以很厚；与之相对，浅模块拆得很细，功能不多，接口却很复杂。
浅模块多的代码库，会让模型在大量细碎节点之间来回穿梭，很容易因为结构太散、依赖太乱，在错误的位置浪费上下文。而深模块的接口薄、内部厚，AI 只要理解了边界和接口，就能在很多情况下独立完成实现；人也不必每次都把所有细节塞进脑子里。
设计接口，把实现委托出去。 真正值得人长期盯住的，是边界、模块地图和接口质量，而不是每一行内部实现。
七、人回战略层，AI 打战术仗
整场演讲的分工逻辑非常清晰：AI 更像一个战术执行者，在一线不断改代码的”地面程序员”；而人更该回到战略层，去做系统设计上的判断。
这包括：
- 模块边界怎么划
- 接口应该长什么样
- 哪些术语必须统一
- 哪些反馈回路必须先建好
- 哪些地方可以交给 AI 放手做，哪些地方必须人工严审
Kent Beck 有句话被 Matt 反复引用：”每天都要继续投资系统设计。” specs-to-code 最大的问题，不是它想提效，而是它在诱导你从设计上撤资。
八、他不只是说说而已：mattpocock/skills
如果演讲是在讲判断，那 Matt 最近开源的 mattpocock/skills（已经 58k+ stars）就是把这套判断直接做成了工程动作。
这个仓库最值得注意的地方，不是它又提供了一批 prompt，而是它的设计理念和演讲几乎完全同频：小、可改、可组合，而且不要把整个过程交给 AI 接管。
你几乎可以一一对应：
- “AI 没做成你想要的东西” → `/grill-me`、`/grill-with-docs`
- “AI 太啰嗦，没有共享语言” → `CONTEXT.md`、ADR
- “反馈回路就是速度上限” → `/tdd`、`/diagnose`
- “AI 会更快把系统推向 ball of mud” → `/zoom-out`、`/improve-codebase-architecture`
Matt 不是嘴上说”基本功重要”，而是真的在把这些基本功产品化、流程化、可复用化。这也是它为什么能在这么短的时间里被大量开发者接受——大家未必照搬，但立刻就能看懂背后的方法论。
写在最后
最近几个月，行业里有个词被反复提起：Harness Engineering。翻译成大白话就是——用软件工程的思维，去驾驭 AI 带来的产能爆炸。
工具进化得再快，也别把它误当成自身能力的跃升。代码生成的速度越来越快，但它也悄悄隐藏了一个代价：系统崩坏的速度，同样可以变得极其惊人。
接口、边界、测试、深模块设计、统一语言——这些过去用来对抗系统复杂度的手段，现在成了我们驾驭 AI、不被机器产出的海量代码反噬的唯一缰绳。
在学习和使用 AI 工具提效的同时，也要回归到软件工程本身，把基本功练到极致。软件工程师是不能在代码里丢失掌控感的。
本文部分观点参考自 Matt Pocock 的演讲 “Fundamentals Matter More Than Ever” 及其开源项目 mattpocock/skills。