坏代码，正在变得越来越贵
主流叙事是"代码已经便宜，AI 随便生成就行"。Matt 的判断完全相反：Code is NOT cheap，坏代码反而是最贵的资产。
逻辑很简单。在干净的代码库里，AI 能拿到 10 倍放大效应；在烂代码库里，AI 只会在混乱上叠混乱，熵爆炸的速度比人手写还快。他自己测过 specs-to-code 的迭代曲线：第一次生成还行，第二次开始下滑，第三次直接成垃圾。每次只改 spec 不看整体设计，结构必然失控，最后 AI 自己都看不懂在改什么。
这是个很反共识的结论：AI 不是让代码可以糊弄，而是逼着你必须把代码写得比以前更好。AI 红利只发给好代码库。
共享设计概念：Grill Me
最常见的失败模式是——你脑子里的 idea 很清楚，AI 做出来完全不是那回事。
Matt 把这个问题归结为 Frederick P. Brooks 在《The Design of Design》里讲的 design concept 缺失：你和 AI 之间没有共享的设计蓝图，就像两个人合盖一栋房子但图纸根本没对齐。
他的第一个 skill 叫 Grill Me，目前 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 别急着写代码，先疯狂追问。一轮下来通常会有 40 到 100 个问题，把需求树的每个分支都走一遍。Matt 认为这比 Claude Code 默认的 Plan Mode 强得多——Plan Mode 急着出东西，Grill Me 先把概念对齐这件最重要的事做掉。把这段对话直接转成 PRD 或 issues，再交给 AFK agent 接力。
通用语言：让 AI 闭嘴并且更精准
第二个常见痛点：AI 输出又长又绕，自己也容易跑偏。
Matt 搬出 DDD 的核心概念——Ubiquitous Language。你、团队、代码库、AI 必须使用同一套词汇。否则你说"用户"，AI 理解成"账户"；你说"workspace"，它在代码里到处找 project、team、org，越改越乱。
对应的 skill 叫 Ubiquitous Language Skill。让 AI 先扫描整个代码库提取术语，做成一份 Markdown 表格：术语、定义、使用场景。之后所有 prompt 都挂着这份文件。效果很直接——AI 的思考痕迹变短，实现更精准，废话大幅减少。Matt 自己一直开着这个文件用在 Grill 和 planning 阶段。
反馈循环：速率限制本质上是反馈速率
AI 写一大坨代码但跑不通，根本原因不是它不够聪明，而是反馈循环太弱。Matt 推荐三板斧：静态类型、浏览器访问权限、自动化测试。
但 AI 默认不会好好用这些反馈。它喜欢一次写一大坨，再回头跑 type check，错误已经叠了几十层，修起来跟拆炸弹一样。
这里他引用《The Pragmatic Programmer》里一个反常识的视角：速率限制本质上就是反馈速率。开得太快一定会撞车。
实操建议很硬：强制 TDD。先写测试，再让测试通过，再重构。TDD 天然逼着 AI 每次只走一小步，匹配 small, deliberate steps，比让它一口气写完整个功能可靠得多。
深模块 vs 浅模块：AI 真正喜欢的代码结构
这是整场演讲最硬核的部分，引用自 John Ousterhout 的《A Philosophy of Software Design》。判断标准只有一条：
- 坏代码 = 很多浅模块：功能少，接口复杂。AI 在里面像走迷宫，每个模块都要理解一堆细节，一不小心就改崩。
- 好代码 = 少量深模块：功能多，接口极简。复杂性藏在内部，外部只暴露稳定接口。AI 只需理解接口就能安全地修改实现。
对应的 skill 叫 Improve Codebase Architecture，步骤很清晰：
- 扫描代码库，找到相关代码块
- 封装成一个深模块
- 设计一个简单接口（这一步必须由你亲自把关）
- 具体实现交给 AI
可以反复使用，把代码库里一堆浅模块逐步重构成深模块。
工程师的角色变了：守边界，而不是写代码
很多人现在最大的压力是 AI 出代码太快，大脑跟不上。Matt 的解法是：把模块当灰盒处理。
你不需要盯每一行实现。真正要做的事是设计接口、定义目的、写测试边界、守住关键模块边界。非核心模块内部怎么写，大胆交给 AI。
他引用 Kent Beck 的一句话：每天都要投资系统设计。而 specs-to-code 最大的问题恰恰是反过来——它在 divest from design，放弃设计。所以越跑越崩。
一套可以直接抄的工作流
把上面几件事串起来就是一个完整流程：
- 新需求来了，别急着让 AI 写代码。先用 Grill Me 建立 shared design concept，把模糊想法追问清楚
- 生成 Ubiquitous Language 文件，所有 prompt 都带上它，统一语言
- 用 TDD 模式写代码，先测试再实现，每一步都接受反馈
- 定期跑 Improve Codebase Architecture，把浅模块重构成深模块。重要接口自己把关，实现细节大胆委托
- 每天花时间想模块边界和系统设计，而不是只盯着写代码
几句最狠的判断
Specs-to-code 不是未来，它只是另一种 vibe coding。
坏代码在 AI 时代比以前更贵，因为它会把 AI 的能力一起废掉。
AI 是地面上的战术士兵，你才是战略指挥官。
软件基础知识，尤其是设计、模块化、测试，现在比 20 年前更重要。
把这场演讲放到市场视角看，结论其实很冷静：AI 编程工具的差距正在被快速抹平，真正构成壁垒的不是用了哪家模型、哪个 IDE，而是使用者本身的工程基本功。Ousterhout、Brooks、DDD、TDD 这些被新一代开发者觉得"过时"的东西，反而是 AI 时代少数还能复利的资产。
specs-to-code 之所以会火，是因为它给非工程师一个"我也能做产品"的幻觉。但幻觉撑不过三轮迭代。一人公司想靠 AI 把生产力放大到 10 倍，前提不是更会写 prompt，而是代码库本身配得上被放大。
想抄作业的，可以去 GitHub 搜 MattPocockSkills，Grill Me、Ubiquitous Language、Improve Codebase Architecture 三个 skill 都在里面。建议先用 Grill Me 跑一次自己手头的项目——大部分人会发现，瓶颈从来不在 AI，而在自己脑子里那张没画清楚的图。