AI 时代,软件基本功为什么反而更值钱了

大家好，我是 Immerse

专注分享 AI 玩法、独立开发与AI 出海的 AGI 实践者，更多干货欢迎关注公众号 #沉浸式AI 或访问 yaolifeng.com

你写一份 spec，AI 生成一版代码。跑一下，有点问题。你改 spec，再生成一次——变差了。再改，再跑——更差了。五轮之后，你面对的是一堆自己完全看不懂的垃圾代码。

如果你用过 AI 编程工具、试过那种叫 specs-to-code 的工作流，大概率经历过这件事。

这不是你一个人的问题。

Matt Pocock （TypeScript 大佬）他在一门「Claude Code for Real Engineers」的备课时搞出一套靠谱的 AI 编程方法论。

他试了 specs-to-code，看到了跟你一样的东西：每多跑一轮，代码就烂一层。他的结论非常直接——这条路走不通，因为它的本质跟 vibe coding 没有区别，只是穿了件好看的外套。

代码不便宜

specs-to-code 的驱动假设是四个字：代码廉价。

生成代码几乎不花钱了，所以我们不需要在乎代码本身——只要在乎 spec 就行；代码变烂了，重新生成一份新的就好。

Matt Pocock 认为这个假设从根上就错了。他在演讲里直接说：坏代码是有史以来最贵的东西。

理由：AI 在好的代码库里表现得非常好——它理解结构、能读懂上下文、改动准确。但在烂代码库里，AI 的表现跟迷路的初级工程师差不多：改一个东西坏三个，加一个功能引入五个 bug，最后你还是得自己上手收拾。

也就是说，代码库质量变成了一个杠杆。好代码库的收益被 AI 放大了，坏代码库的代价也被 AI 放大了。以前坏代码让你的团队慢 30%，现在坏代码让你连 AI 的红利都吃不上——别人一天 ship 的量，你一周都追不上。

这让软件基本功的价值发生了一个反直觉的变化：AI 越强，基本功的复利越高。不是基本功变得不重要了，是它变成了你能不能吃到 AI 红利的前置条件。

为什么代码会越来越烂：熵

Matt Pocock 翻出了两本老书来解释 specs-to-code 为什么会失败。

John Ousterhout 的《A Philosophy of Software Design》给了「坏代码」一个精确定义——复杂性(complexity)是软件结构里任何让系统难以理解、难以修改的东西。一个坏代码库不是写得丑的代码库，而是改不动的代码库。

另一本是《程序员修炼之道》(The Pragmatic Programmer)，里面有整整一章讲「软件熵」：每次你做一个改动，如果只想着这次改动本身、不考虑整体设计，系统就会一点点走向崩塌。

这正是 specs-to-code 里发生的事：你每「再跑一轮编译器」，AI 只关注这次改动要不要满足 spec，它不帮你维护整体设计。于是代码的结构越来越碎、熵越来越高、改动越来越难。这不是 AI 的错——你从来没告诉它什么才是好的结构。

AI 编程的失败模式和对应的老办法

认清「代码不便宜」之后，Matt Pocock 在实际教学和编程中发现了几种高频失败模式。有意思的是，他给每种失败模式找到的解法，全都来自软件工程的经典著作——不是什么新发明，是被验证了二十年甚至更久的老东西，只是被重新包装成了跟 AI 对话的方式。

AI 没做你想要的事：设计概念

你脑子里有个清晰的想法，AI 做出来的却完全不是那个东西。

为什么会这样？《程序员修炼之道》里有一句话：没人真的清楚自己想要什么。你跟 AI 之间有一道沟通屏障——你觉得自己说清了，但其实有大量隐含假设没传达到。

Matt Pocock 从 Frederick Brooks 的《The Design of Design》里借了一个概念：设计概念(design concept)。当两个人一起设计某个东西时，他们之间会飘着一个看不见的理论——那个东西应该是什么样的、为什么是这样的。这个理论不是一份 markdown 文件，是一种共识。

问题出在这里：你和 AI 之间，没有这个共识。

于是他写了一个叫 Grill Me（拷问我）的 skill。几行 prompt，让 AI 反过来变成拷问者——沿着你计划的每一个分支追问，直到它认为自己真的理解了你想做什么。在实际使用中，AI 会问你 40 到 100 个问题。

这个 skill 所在的仓库有大约 1.3 万颗 star。包含它的几行字就这样疯传了——因为它解决的是所有人跟 AI 打交道时最常见的第一个痛点。

它的输出是什么？一份足够清晰的对话记录，你可以把它整理成产品需求文档或一组 issue，AI 接走执行。

AI 太啰嗦：统一语言

另一种常见失败：AI 在用太多词描述它在干嘛，你们好像在各说各的。

这让 Matt Pocock 想起了跟领域专家合作的感觉——对方在用你不懂的术语，你把它翻译成连自己都不太懂的代码，中间有一道语言鸿沟。

他从领域驱动设计(DDD)里找到了答案：统一语言(ubiquitous language)——开发者之间的对话、代码里的表达、跟领域专家的对话，都源自同一套术语表。

他做了个 skill：让 AI 扫一遍你的代码库，找出术语，生成一份 markdown 表格——一份你和 AI 共用的词汇表。通过读 AI 的 thinking trace，他观察到一个明确的效果：规划质量提升了，AI 的思考过程变得不再啰嗦，最终实现也更贴近原计划。

这其实是一个很古老的工程实践：先对齐语言，再开始干活。只是以前对齐的是人和人，现在多了一个 AI。

做对了但不工作：反馈回路和 TDD

还有一种：AI 理解了你的意图、做出了对的东西——但就是跑不起来。

解法方向很明确：反馈回路。类型检查、浏览器预览、自动化测试——这些你都知道。但 Matt Pocock 观察到一件事：LLM 不像资深开发者那样善于利用反馈回路。它的倾向是先写一大坨代码，写完之后才想起来跑个类型检查、跑个测试。

《程序员修炼之道》管这叫「outrunning your headlights」（开得比车灯照得还远）：你接收反馈的速度，就是你能跑的速度上限。

所以他用 TDD——测试驱动开发。不是因为 TDD 是什么新东西，而是因为 TDD 的节奏恰好能解决 AI 的这个毛病：先写一个测试（小步），让测试通过（验证），再重构。它强迫 AI 走小步。

但这里又引出了下一个问题：一个好测的代码库和一个难测的代码库，差距巨大。

AI 迷路了：深模块 vs 浅模块

再一种：AI 在你的代码库里迷路了——它来回导航、反复探索，但就是搞不清楚你的代码在干嘛。

回到 Ousterhout。他在书里讲到两种模块形态。

深模块(deep modules)——大量功能藏在一个简单接口背后。你想钻进去看可以，但你不需要，接口已经告诉你一切。

浅模块(shallow modules)——功能不多，接口却很复杂。一堆小的、相互纠缠的碎片。

一个充满浅模块的代码库，对 AI 来说就像一座没有路标的迷宫——它必须穿过一堆小节点、来回导航，看不清依赖关系，最终放弃理解。

而一个深模块代码库，AI 只需要理解接口就能干活。你把接口设计好（这是你的活），实现部分可以交给 AI 处理（这是它的活）。

Matt Pocock 做了一个「改进代码库架构」的 skill：它帮你探索现有代码，找出那些「看起来相关」的零散逻辑，把它们包进一个深模块。这样的代码库自然就是好测的——围绕模块的边界简单，在接口处测试就行。一个奖励 TDD 的代码库。

你的脑子跟不上了：灰盒

还有一种失败模式不是 AI 的问题，是你的：AI 在全速运转，你 ship 的代码比以往任何时候都多——但你的脑子跟不上了。

Matt Pocock 的解法是把深模块当作「灰盒」(gray boxes) 来用：你只设计接口，实现部分你不深入操心、也不逐行 review。只要模块外面有一个可测试的边界、你理解它的用途、能从外部验证它的行为就行。

这不是让你不管质量——而是让你把有限的脑力分配到真正重要的地方：接口设计和模块划分。实现细节交给 AI，你从外面测、从外面验证。

真正的杠杆不是 AI 技巧

回过头看这整套东西，你会发现一件有点讽刺的事。

这两年大家疯狂学的是什么？prompt engineering，AI agent，多轮对话技巧，各种 AI 工具链……好像「学 AI」才是正经事，以前那些软件工程的老东西都过时了。

但这场演讲里每一个具体解法的来源，都是 1990 年代到 2000 年代写的书：Ousterhout、Brooks、DDD、Kent Beck、《程序员修炼之道》。没有一个新东西。

他把这些老规则翻出来、包装成 Claude Code 的 skill，就成了 1.3 万颗 star 的仓库。不是因为他的 prompt 写得多精妙——而是因为那些规则本身就有效，只是人们忘了它们在 AI 时代同样适用。

Kent Beck 说：每天对系统的设计投资。

specs-to-code 的问题恰恰是在设计上撤资——把设计思考的责任甩给 AI、指望 spec 能自动变成好结构。它做不到。好的结构是需要人主动投入的。

你其实已经准备好了

把 AI 想成一个特别好的、地面上干活的程序员。它是一个战术角色——在战壕里做改动、写代码、执行计划。

那谁站在战略层面？谁负责代码库的结构、模块的边界、接口的设计、系统的演化方向？

是你。

而这个角色需要的，恰好是你花了五年、十年、二十年练出来的东西：怎么拆模块、怎么设计接口、怎么控制复杂度、怎么让代码库在长期保持可修改性。

这些东西没有过时。它们变成了你能不能用好 AI 的前置条件。

如果你最近因为 AI 的速度而焦虑、觉得自己的手艺不值钱了——也许恰恰说反了。

那些看起来最「传统」的软件基本功，才是你在 AI 时代真正的杠杆。

仓库地址（所有 skill）：GitHub 搜索 matt pocock skills

课程和内容：aihero.dev