AI 编程的底层原则

Matt Pocock 怒怼「Specs-to-Code」：AI 时代，软件基础比任何时候都更重要

刚刷完 Matt Pocock 这场演讲，标题叫 《Claude Code for Real Engineers》，直接把很多人的焦虑干碎了。

他一句话总结就是：软件工程的基础知识，现在比以往任何时候都更值钱。

不是因为 AI 要取代你，而是因为坏代码在 AI 时代变得前所未有地昂贵。他把「specs-to-code」「只改 spec 不看代码」这些流行玩法，直接批成了 vibe coding 的另一种形式。然后用一整套非常老派、但极其有效的软件工程方法告诉你：怎么把 Claude Code 这类 AI 工具，真正用成工程师的 10 倍放大器，而不是一个越写越乱的代码老虎机。

这场演讲最反常识的地方在于：大家都以为 AI 让代码变便宜了，但 Matt 说，真正变贵的恰恰是坏代码。

坏代码，在 AI 时代反而更贵了

现在很多人都在喊：「代码已经便宜了，用 AI 随便生成就行。」

Matt 直接反驳：错。Code is NOT cheap。坏代码现在是最贵的。

为什么？因为在一个好的代码库里，AI 能真正发挥 10 倍效率；但在一个烂代码库里，AI 只会越写越烂，最后 entropy（熵）爆炸。

他自己亲测过 specs-to-code 模式：第一次生成代码还行，第二次质量开始变差，第三次直接垃圾。原因也很简单，每次只改 spec，不关注整体设计，代码结构就会越来越复杂。到最后，AI 根本看不懂自己在改什么，只能在混乱上继续叠混乱。

所以 AI 时代不是可以忽略代码，而是必须把代码写得比以前更好。只有好的代码库，才能真正吃到 AI 的红利。

AI 没理解你，是因为你们没有共享蓝图

最常见的问题是：你脑子里有一个很清晰的 idea，但 AI 做出来的东西完全不是那回事。

Matt 说，这是经典的 design concept 缺失。这个概念来自 Frederick P. Brooks 的《The Design of Design》。你和 AI 之间没有共享的「设计概念」，就像两个人在设计同一栋房子，但根本没对齐蓝图。

所以他的第一个实操技能叫 Grill Me。

这个 skill 在 GitHub 已经有 13k+ stars，核心 prompt 就两句：

Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one by one.

意思很简单：让 AI 不要急着写代码，而是先疯狂追问你，直到你们对这个需求建立共同理解。

AI 会问你 40 到 100 个问题，把需求树上的每个分支都走一遍。Matt 说，这比 Claude Code 默认的 Plan Mode 好很多，因为 Plan Mode 太急着产出东西，而 Grill Me 先做最重要的事：把概念对齐。

他的建议是，把这段对话记录直接转成 PRD 或 issues，然后再交给 AFK agent 接着干。

让 AI 少废话，先统一语言

第二个问题是：AI 输出又长又绕，你看着累，它自己也容易跑偏。

Matt 搬出了领域驱动设计 DDD 里的一个核心概念：Ubiquitous Language，通用语言。

也就是你、团队、代码库、AI，都应该使用同一套词汇。否则你说的是「用户」，AI 理解成「账户」；你说的是「订阅」，AI 理解成「订单」；你说的是「workspace」，它可能在代码里到处找 project、team、org，最后越改越乱。

他的实操技能叫 Ubiquitous Language Skill。

做法是让 AI 先扫描整个代码库，提取所有术语，然后做成一个 Markdown 表格：术语、定义、使用场景。之后所有 prompt 都带上这个文件，强迫 AI 和你使用同一套语言。

效果非常明显：AI 的思考痕迹会变短，实现会更精准，啰嗦程度也会大幅下降。Matt 说这个方法简直是 powerhouse，他自己一直开着这个文件，用在 Grill 和 planning 过程中。

AI 写不出能跑的代码，本质是反馈太慢

第三个问题更现实：AI 写了一大坨代码，但根本跑不通。

Matt 认为，核心原因不是 AI 不够聪明，而是反馈循环不够强。他推荐三板斧：静态类型、浏览器访问权限、自动化测试。

但问题是，AI 默认不会好好使用这些反馈。它很喜欢一次写一大坨代码，然后才想起来跑 type check。等它发现错了，错误已经叠了几十层，修起来就像拆炸弹。

Matt 提到一个很反常识的观点：速率限制，本质上就是反馈速率。

这个思想来自《The Pragmatic Programmer》。开得太快，就一定会撞车。所以他的实操建议是：强制 TDD。

先写测试，让测试通过，再重构代码。TDD 会逼 AI 每次只走一小步，天然匹配 small, deliberate steps。这比让 AI 一口气写完整个功能可靠得多。

真正适合 AI 的代码，不是更多模块，而是更深模块

这可能是整场演讲最硬核的部分。

Matt 引用了 John Ousterhout 的《A Philosophy of Software Design》。这里有一个非常重要的判断标准：坏代码 = 很多浅模块；好代码 = 少量深模块。

什么是 shallow modules？就是功能很少，但接口很复杂。AI 遇到这种代码，就像在迷宫里乱窜，每个模块都要理解一堆细节，一不小心就改崩。

什么是 deep modules？就是功能很多，但接口极简。复杂性被藏在模块内部，外部只暴露简单、稳定的接口。

AI 最喜欢这种结构。因为它只需要理解接口，就能安全地修改实现。

所以 Matt 的另一个实操技能叫 Improve Codebase Architecture。步骤很清晰：先扫描代码库，找到相关代码块；然后把它们封装成一个深模块；接着设计一个简单接口，这一步必须由你亲自把关；最后，具体实现细节可以交给 AI。

这个 skill 可以重复使用，把代码库里一堆浅模块，逐步重构成深模块。

你的工作不是写更多代码，而是守住设计边界

很多工程师现在最大的压力是：AI 出代码太快了，大脑跟不上。

Matt 的解决方案是：把模块当成灰盒。

你不需要盯着每一行实现细节。你真正要做的是设计接口、定义目的、写测试边界、把关键模块边界守住。至于非核心模块内部怎么实现，可以大胆交给 AI。

这样你的大脑负担会大幅降低，同时还能保持对整体设计的掌控。

他还引用了 Kent Beck 的一句话：每天都要投资系统设计。

而 specs-to-code 最大的问题，恰恰是反过来。它是在 divest from design，也就是放弃设计。所以越跑越崩。

一套普通工程师可以直接抄的 AI 编程工作流

新需求来了，不要立刻让 AI 写代码。先用 Grill Me 建立 shared design concept，让 AI 把你脑子里的模糊想法追问清楚。

接着生成 Ubiquitous Language 文件，让 AI、你、代码库使用同一套语言。之后所有 prompt 都带上它，减少误解和废话。

然后用 TDD 模式 写代码，先测试，再实现。不要让 AI 一口气写一大坨，而是让它每一步都接受反馈。

同时，定期运行 Improve Codebase Architecture，把浅模块逐步重构成深模块。重要接口自己把关，实现细节大胆委托给 AI。

最后，每天花时间思考模块边界和系统设计，而不是只盯着写代码。

Matt 自己就是用这些 skill，把 Claude Code 玩成了真正的工程师工具，而不是 vibe coding 玩具。

这场演讲最狠的几句话

Specs-to-code 不是未来，它只是另一种 vibe coding。

坏代码在 AI 时代比以前更贵，因为它会把 AI 的能力也一起废掉。

AI 是地面上的战术士兵，你才是战略指挥官。

软件基础知识，尤其是设计、模块化、测试，现在比 20 年前更重要。

最后真正让人安心的，不是 AI 变强了，而是基础知识还值钱

AI 没有让代码变得不重要。恰恰相反，它让「写好代码」这件事变得前所未有地关键。

你越懂老派软件工程，越懂 Ousterhout、Brooks、DDD、TDD，AI 就越能为你所用。你越偷懒，只想改 spec、不看代码，代码库就越快崩成一团垃圾。

Matt Pocock 这场演讲，其实是给所有还在焦虑「AI 会不会抢饭碗」的工程师打了一针强心剂：

你的基础知识，现在是稀缺资源。

想直接抄作业的同学，可以去 GitHub 搜 MattPocockSkills。里面有他提到的所有 skill：Grill Me、Ubiquitous Language、Improve Codebase Architecture。

他也在 AIhero.dev 写 newsletter，YouTube 和 Twitter 都持续更新。

你们现在用 AI 写代码时，最头疼的失败模式是哪一个？是 AI 不理解需求，太啰嗦，还是代码跑不通？

欢迎下面聊聊，我把 Matt 的 skill 也分享出来一起讨论。

完整演讲逐字稿，可以在 Podwise 免费获取。