这两天，Matt Pocock 的 skills 在 GitHub Trending 榜上突然爆发——短短一天内新增超过 5600 颗 Star，总 Star 数突破 3 万，成功登顶。

Matt 是一个 TypeScript 课程作者，最近一年多在教开发者如何真正用好 AI 编程。他最近在 AI Engineer 上的演讲被放了出来，反响不错。应该是这个演讲让他的 skills 翻红。

Matt Pocock 认为：软件工程基本功在 AI 时代比以往任何时候都更重要。

Matt 把 AI 编程中常见的问题归纳为六个失败模式，他的 Skills 仓库里的每一个工具，基本上都对应其中一个，很多论据则来自软件工程领域的一些书籍和概念。

**失败模式一：AI 没做我想要的**

这是最普遍的问题。你脑子里有个想法，AI 做出来的是另一回事。

Matt Pocock 从 Frederick P. Brooks 的《设计的设计》里找到了诊断词：设计概念（Design Concept）。当多个人协同设计某个东西时，他们之间漂浮着一个无形的共同理解，对将要构建的东西的构想，即设计概念。

你和 AI 之间缺的就是这个。

他的解法是 grill-me 技能，全文只有几行：

“以无情审问的方式采访我，直到我们达成共识。逐一追究设计树的每个分支，一个一个地解决依赖关系。对每个问题提供你的推荐答案。每次只问一个问题。”

这几行字意味着 AI 会问你大概 40 个问题、60 个问题。这个 skill 把 AI 变成了一种对手，它不断地向你抛出想法，试图达成共识。

这个技能应该是他最出圈的 skill，他认为这比 Claude Code 默认的 plan 模式要好。 plan 模式急于创建一个资产，它非常想直接创建一个计划然后开始干活，grill-me 则先明确设计感念。

**失败模式二：AI 太啰嗦，鸡同鸭讲**

AI 太啰嗦了，并且总是到不了点子上，它会试图通过说大量的话来试图表达它在做什么。

这里面的问题可能在于，你和 AI 没有在同一个话语体系里。

Matt Pocock 从领域驱动设计（DDD）里拿了一个概念：通用语言（Ubiquitous Language）。开发者之间的对话、代码里的命名、和领域专家的交流，都来自同一个领域模型。

他做了一个 ubiquitous-language 技能，扫描你的代码库，提取所有术语，生成一个 Markdown 表格。然后在每次和 AI 规划时把这个文件带进去。

他观察 AI 的思维链后发现：通用语言不仅改善了规划质量，还让 AI 的实现更贴近你的设想，因为它在用和你完全一致的词汇思考。

**失败模式三：AI 做了正确的事，但代码不工作**

当前两步都搞定，概念和术语都对齐了，AI 也确实干活了，但是输出不 work，怎么办 ？

Matt Pocock 说通过反馈循环，可以显著改善这个问题。

没有类型检查、没有测试、没有静态分析，AI 就是在黑暗中编程。

但问题不只是"加上测试"这么简单。AI 的默认行为是先写完所有实现，然后想到要测试了才测试，AI 总是倾向于一次做太多，产出大量代码。

《程序员修炼之道》管这个叫，"跑在前灯前面"——开车开太快，灯光照不到那么远，你就看不到前面的路。

反馈速度是你的速度上限。

他的解法是 tdd（测试驱动开发）技能，强制 LLM 真正采取小步骤，强制 AI 走红-绿-重构的循环：先写一个失败的测试，然后让实现通过，然后重构。AI 很难在这个模式下作弊，因为它必须在代码存在之前就把测试写好。

**失败模式四：代码库太混乱，AI 越改越烂**

好的代码库就是容易测试的代码库。

这里 Matt 引用了 John Ousterhout《软件设计哲学》里的核心概念：深模块（Deep Module）vs 浅模块（Shallow Module）。

浅模块：接口复杂，功能少，大量小文件相互依赖——AI 需要手动追踪整个依赖图，很快迷失，产生的代码越来越乱。

深模块：接口简单，内部封装大量功能——AI 只需要理解接口，不需要钻进每个细节。这样的代码库也更容易测试：你在模块外部建一个测试边界，从接口层面验证行为。

他的 improve-codebase-architecture 技能会扫描你的代码库，找出可以合并为深模块的代码群，提出重构建议。他自己的例子：把一个浏览器端视频编辑器的前端到后端的完整流程包进一个大模块，从外部统一测试。AI 在这个代码库里的表现是"翻天覆地的改变"。

**失败模式五：大脑跟不上**

你比以前交付了更多代码，但也比以前更累了。你对代码库的理解越来越模糊。

深模块提供了一个思维上的解法：把这些模块当成灰箱——你设计接口，你验证行为，但内部实现可以委托给 AI 处理，你不需要审查每一行。

Matt 的建议：设计接口，委托实现（Design the interface, delegate the implementation）。这来自 Kent Beck 的话："每天投资于系统的设计。"

这也是他反对"specs to code"最本质的理由：specs to code 是在撤资系统设计，而你应该持续投资。

**失败模式六：大任务让 AI 进入愚蠢区**

他有个 LLM 的基本认知模型：智慧区和愚蠢区。每个对话从零开始，在上下文大约 100k tokens 之前，LLM 工作良好。超过这个范围，注意力机制的压力呈平方级增长，LLM 开始变笨。

大任务不能在一个上下文里完成，但顺序多阶段计划也只能被一个智能体线性执行。他的解法是把大任务变成一张有向无环图（DAG）的看板，任务之间有阻塞关系，没有阻塞关系的任务可以被多个智能体并行领取。

这些技能不是孤立工具，它们可以构成一套完整的工作流。

GitHub: github.com/mattpocock/skills
演讲：
www.youtube.com/watch?v=v4F1gFy-hqg
www.youtube.com/watch?v=-QFHIoCo-Ko