AI 编程的六种失效模式，以及 Matt Pocock 的解法

 上月，Matt Pocock 在一场技术演讲里聊了一个很实在的话题：AI 编程到底卡在哪？

说明一下：Matt Pocock 就是写了那个很好用的软件开发 Skill 集合的人。

这个 skill 仓库在 https://github.com/mattpocock/skills

他试过传统的 SDD开发，也就是『从规范到代码』——写一份规范，让 AI 翻译成代码，出问题就改规范再跑一次。

结果呢？第一轮出来的代码还行，第二轮更糟，第三轮直接乱码。

他试了又试，结论是：这行不通。

AI 本身不是问题，糟糕的代码库才是。

AI 在一个优秀代码库里的表现远好于烂代码库——后者只会加速熵增。

Matt 从几本经典书里找答案，总结了六种失效模式。

他打了个比方：

AI 就像一个优秀的战术程序员，冲在前线改代码的士官，能执行具体任务，但看不到全局。

你需要一个更高层次的人——一个具备战略思维的人，那就是你。

六种失效模式其实指向同一个问题：AI 当不了战略指挥官，但你把它当成了战略指挥官来用，或者根本就没有设置这个角色。

AI 不会帮你想设计，它只会加速你的设计决策。

设计得好，AI 加速你；设计得烂，AI 加速你的崩溃。

1 失效模式 1：AI 听不懂你的意图

你脑子里有一个方案，AI 做出来的是另一回事。这不是 AI 的错，是沟通出了问题。

Frederick Brooks 在《设计的设计》里提出一个概念叫『设计概念』

——当两个人共同设计一件东西时，他们之间会流动一种关于『正在建造什么』的模糊想法。它不是文档，不是 PRD，而是大脑里那个无形的模型。

你和 AI 之间，就是这个大脑里的模型对不上。

解法：Grill Me  Skill。

让 AI 反过来追问你，直到双方达成共识。Matt 的版本会让 AI 问你 40 到 100 个问题，沿着每个决策分支逐一确认，直到两台大脑里的设计概念对齐。对话的结果可以转成 PRD 或 issue，交给 AI 执行。

2 失效模式 2：AI 太啰嗦，但说不清楚

AI 用了很多华丽的词，但始终说不到点子上

这就像开发者和领域专家之间的语言鸿沟——专家用业务术语，你用技术术语，谁也听不懂谁。

或者 AI 说了很多，但重要的事情都被埋在了一大堆文字当中，你都没有什么心情读全它。

解法：通用语言（Ubiquitous Language）。 来自领域驱动设计（DDD）的思路。

做一个 Markdown 术语表，把项目里所有关键概念的定义、中英文对照、用法边界写清楚，AI 和人都用它。

Matt 的做法是写一个技能，自动扫描代码库提取术语，生成术语表。在规划、写代码、做烧烤（Grill）时全程打开，AI 的思考轨迹会更清晰，产出也更接近你的预期。

3 失效模式 3：AI 写的东西跑不起来

代码逻辑上是对的，但一跑就出问题。

AI 不会像有经验的开发者那样——写一小段就编译、测试、确认——而是闷头写完一大坨，最后才检查类型和测试结果。

解法：测试驱动开发（TDD）。 TDD 强制 AI 迈小步：先写测试，再写实现，然后重构。步子一小，反馈就快。但 TDD 本身有个门槛——测试很难写：测多大单元？模拟什么？测哪些行为？这些决定相互关联，新手容易卡住。

当然，现在也有人提出：TDD 太浪费token了，而效果并不理想。其实，可以参考之前我的文章中提到的一些方法，比如：TDD 的粒度大一些。隔一段时间就运行一下 mutition score. 

Matt 发现了一个关键关联：好的代码库天然容易测试。代码库越好，反馈循环越强，AI 收到的反馈质量越高，产出的代码也越好。这是一个正向飞轮。

4 失效模式 4：AI 创造了浅层模块地狱

AI 默认生成的代码库充满大量小模块——每个模块功能不多，但接口复杂，互相依赖。AI 自己都看不懂这种代码。它要逐个遍历、理解每个模块的依赖关系，经常找不到正确的文件。

解法：更多地设计并使用深层模块（Deep Modules）。

这个概念来自 John Ousterhout 的《软件设计哲学》。好的模块应该是『深层』的，也就是说：在简洁的接口下，隐藏丰富的功能。

即：模块数量少、功能强、接口简单。

AI 不需要深入实现细节，直接用接口就能工作。

把代码库从浅层重构为深层，是一个系统性的动作：扫描代码，把逻辑相关的代码封装进一个深层模块，在接口处测试，实现交给 AI。

5 失效模式 5：你的大脑跟不上了

AI 让你产出更多代码，但你的大脑处理能力没有增长。你要同时理解 AI 生成的代码、维护设计概念、跟踪模块变更——认知负荷飙升。

解法：设计接口，委托实现。 把深层模块当作『灰色盒子』——你只设计它的接口和行为契约，不关心内部实现。外部有可测试的边界，内部交给 AI 处理。

你从外部验证，AI 负责填充。这能大幅降低大脑负担。

但要这么做，你必须非常熟悉整个系统的模块地图。

每次修改时，都要在 PRD 里明确说明：改哪个模块、接口怎么变。

6 失效模式 6：对系统设计撤资

『规范到代码』运动的本质，其实在真实场景下，常常很容易把所有精力放在规范的迭代上，放弃对系统本身的整体结构设计。但产生代码廉价了，但它产生的影响可能并不廉价，糟糕的代码，很可能损失惨重。

解法：每天对系统设计进行投入。

Kent Beck 的原话是：每天都要对系统设计进行投入。不是项目开始时投一次，而是每天。Matt 的做法是，每个 PRD 都会明确模块变更和接口设计，把系统设计纳入日常节奏。

7 总结

Matt 把 AI 比作一个优秀的战术程序员——冲在前线改代码的士官。你需要一个比他更高层次的人，一个具备战略思维的人，那就是你。你用了 20 年的软件基础技能——设计模式、模块化、DDD、TDD——在 AI 时代不是过时了，而是变得更关键了。

AI 不会帮你想设计，它只会加速你的设计决策。设计得好，AI 加速你；设计得烂，AI 加速你的崩溃。