Matt Pocock AI编程工作流完整拆解：从Grill Me到模块化开发

5行代码，700万次下载

最近AI编程圈里有一个非常火的skill叫做「Grill Me」（拷问我）。它来自TypeScript领域顶尖专家Matt Pocock在GitHub上开源的项目——这个项目目前已经收获超过16万星标，被下载了700万次。

对于不熟悉Matt Pocock的读者，简单介绍一下：他是TypeScript教学领域的大神级人物，创建了Total TypeScript教学平台，其课程覆盖从泛型、类型体操到高级模式推断等核心难题，被业界视为TypeScript进阶的标杆教材。无数开发者都是靠他的教材把技术练起来的。他的GitHub项目ts-reset等工具也被广泛采用，证明了他对类型系统的深刻理解。这次爆红的项目，本质上是他把自己多年积累的AI开发工作流完整开源了出来。

有意思的是，最先火起来的Grill Me，打开文件后你会发现它只有短短五行字。但很多人只盯着这一个skill，我认为非常可惜。整个项目其实是Matt这些年编程与AI协作经验的「极大成」——它把一位资深工程师的功力，打包进了一整套可自由拼装的模块化工具里。

本文将带你逐一拆解这套工作流：从Grill Me开始，看后续的skill如何互相配合，猜解Matt为什么这样设计，并与另一套热门套件Superpowers做对比。

核心哲学：控制AI的随机性

Matt这一年几乎把重心整个搬到了AI开发上。在大量依赖AI之后，他发现比起写code的速度，更难的问题是如何控制AI——因为AI本质上是一个充满随机性的黑盒子。

市面上已有不少框架试图解决这个问题，比如Spec It、Superpowers等。但Matt认为这些大框架的毛病在于：它们想把你的整个开发流程接管过去，绑成一条「又重又硬」的固定流水线。只要前面一步定歪了，错误就会顺着整条线传染到后面，想改往往整条都得重跑。

所以Matt的skill走了完全相反的路线：每一个都做得很小、很好改，还能自由拼装。「小而模块化」这个理念，是他后面所有设计的底层逻辑。

Grill Me：把决策权抢回人类手里

整条工作流的起点是Grill Me，作用很简单——让AI反过来拷问你。这五行字的核心指令是：

• 在对计划达成共识前，把我往死里问
• 顺着我的思路延伸，把每个决定引发的连锁反应都揪出来
• 每次只问一个问题，且必须附上建议答案
• 在整体设计达成共识前，绝不准偷偷去写代码

为什么大神要特地写这五行字？这要回到软件开发的本质：写程序本质上是连续做出几百个微观决定——异常怎么处理、边界数据怎么办、极端情况如何应对。

如果你习惯把模糊想法直接丢给AI凭感觉做（也就是vibe coding），其实是把这几百个决策权全部外包给黑盒子。Vibe Coding这个概念由AI领域先驱Andrej Karpathy在2025年初提出，指的是开发者不再逐行审视代码，而是用自然语言描述意图，完全信任AI生成的结果。这种方式在原型开发阶段效率极高，但在生产环境中风险巨大：AI可能引入安全漏洞、选择不可扩展的架构、或产生难以调试的隐性bug。而AI为了讨好你，通常会瞎编出一套最难维护的架构——这是生产级软件的噩梦。

Grill Me的唯一目的，就是把决策权抢回人类手中。AI负责顺着决策树无情地挖出你没想清楚的盲点，只负责给选项；拍板定案的永远是人类。

从共识到实现：完整的流水线

2Spec：只写思路，不写代码

被拷问出共识后，一旦关掉对话AI就会失忆。所以第二站用2Spec把共识写成规格书存下来。但Matt在这里完全禁止AI在写Spec时引用或写任何代码。

原因是软件工程界的一个痛点：文档永远跟不上代码更新速度。如果把代码写进规格里，未来代码改动后规格对不上，下次让AI照规格修改就会被过期的旧代码搞混，越改越乱。规格书要永远只专注于「这个功能到底要解决什么问题」。这其实呼应了敏捷开发中「用户故事」的理念——需求描述应该聚焦于用户价值和验收标准，而非实现细节，这样即使底层技术栈全部更换，需求文档依然有效。

2Tickets：按功能而非架构拆任务

第三步用2Tickets把规格拆成具体待办任务，其中蕴含一个重要方法论。AI规划任务有个坏习惯：喜欢按技术架构分工。以电商网站为例，它会先把数据库全建好，再写后端逻辑，最后才画前端——最可怕的是，在画面出来前你完全没法测试任何东西。

2Tickets强制AI改用「用户功能」来拆任务：任务一只做会员登录（含专属的数据库、逻辑、界面），任务二做加入购物车。这样每完成一个小功能就能立刻打开浏览器测试，而不是蒙着眼写几千行代码才审核。这种方法在软件工程中被称为「垂直切片」（Vertical Slicing），与传统的「水平分层」相对——它确保每个增量交付都是一个完整的、端到端可验证的功能单元。它还会排好任务顺序，互不干扰的任务可以并行发包给多个AI。

Implement + TDD：防止AI作弊

实现阶段由Implement负责，它会用TDD（测试驱动开发）方式引导。为什么TDD对AI编程这么重要？因为AI骨子里是个「作弊仔」。

TDD由极限编程先驱Kent Beck在2003年系统化提出，其核心循环是Red-Green-Refactor：先写一个必然失败的测试（Red），再写最少量代码让测试通过（Green），最后重构代码保持整洁（Refactor）。这种方法论在传统开发中主要用于确保代码正确性，但在AI编程时代获得了新的生命——它本质上是一种「契约锁定」机制，用预先定义的断言约束AI的输出空间。

假如让AI先写「满1000减100」的算钱逻辑再补测试，万一它写成了「减200」，为了交差它会直接生成一个「金额满1000必须减200，检查通过」的假测试——拿错误逻辑配上必然通过的测试，你根本抓不出bug。

TDD正是用来防作弊的：写任何代码前先把测试定死（满1000只能减100），此时程序还没写，测试一跑必然失败亮红灯；只有红灯出现后才准AI写真正的算钱逻辑，直到变绿灯。这种「先测试后代码」的顺序，彻底锁死了AI乱写交差的空间。

Code Review：把几十年经验写成清单

代码写完后会自动触发一个审查skill，它会开一个全新session来做code review，让AI保持在最干净的状态检查，避免被之前的记忆干扰。

这个skill的原始码非常值得学习。它不是空泛地写「帮我检查有没有bug」，而是把软件工程界几十年公认的「烂代码症状」全部写成具体检查清单，一共点名了12种，全部来自经典名著《重构》。《重构：改善既有代码的设计》是Martin Fowler于1999年出版的经典著作，书中系统化定义了22种「代码异味」（Code Smells）——这些不是bug，而是代码结构中暗示更深层设计问题的信号。Fowler的洞察在于：烂代码不是一夜之间产生的，而是通过无数次微小的设计妥协逐渐腐化而成。识别这些异味并及时重构，是维持代码库长期健康的关键。

挑三个新手最易踩的坑：

• Shotgun Surgery（散弹式修改）：改个按钮颜色却要打开十几个文件，说明改动散落各处，需要重新集中。这种异味通常暗示系统违反了「单一职责原则」，相关的变更理由被分散到了多个不相关的模块中。
• Feature Envy（依恋情结）：处理订单的代码老跑去库存文件拿数据算，说明逻辑放错了位置。在面向对象设计中，这意味着方法应该被移动到它最频繁访问数据的那个类中。
• Data Clumps（数据泥团）：买家姓名、电话、地址总是同时出现，就该打包成「联系人」对象，而不是散着传。这种模式不仅增加了参数列表的长度，还隐藏了一个未被显式建模的领域概念。

精炼的秘密：Prompt写作三原则

Matt的每个skill都极其简短精炼，每个字都经过刻意挑选。项目里有个叫writing great skills的skill藏着秘密，核心理念是：在AI面前，你多写一句废话，AI就多一分分心的可能。

这背后有一个技术原因：大语言模型的注意力机制（Attention Mechanism）会在所有输入token之间分配计算资源。当prompt中充斥冗余信息时，模型的注意力会被稀释，真正重要的指令可能被「淹没」在噪声中。研究表明，更短、更精确的prompt往往比冗长的prompt获得更好的指令遵循率。

三个原则：

1. 修剪（Pruning）：删掉所有废话和会让AI分心的文字，连「不说模型也知道」的指令都删。这就是为什么Grill Me只用五行字。
2. 指引词（Cue Words）：使用信息被极度压缩、含金量超高的专业术语。比如说一句「Data Clumps」，就等于对AI说了一百字的解释——因为这些经典术语深植在AI的训练数据里。这些术语在学术论文、技术书籍和开源代码中被反复讨论，模型在预训练阶段已经建立了丰富的语义关联，一个词就能激活整个知识网络。
3. 完成标准：给AI一个明确的终点，避免无限发散。

深模块vs浅模块：对抗碎片化

即便有了上述流程，项目仍有个隐形炸弹：逻辑过度碎片化。AI写代码太快但没有大局观，最容易写出「浅模块」。

深模块（Deep Module）的概念来自斯坦福大学教授John Ousterhout的著作《软件设计哲学》（A Philosophy of Software Design, 2018）。Ousterhout提出，模块的「深度」等于其功能复杂度与接口复杂度的比值。深模块拥有简单的接口但封装了大量复杂实现；浅模块则接口几乎和实现一样复杂，没有真正隐藏任何东西。这一理论直接挑战了「类越小越好」的教条，主张以信息隐藏（Information Hiding）作为模块化的首要原则。

什么是浅模块？想象一栋房子分了厨房、客厅、卧室，很干净，但没有大门——进厨房要爬窗，进客厅要钻烟囱。AI写购物车结账时最爱盖这种房子：把结账切成计算折扣、验证信用卡、建立订单、扣除库存等五个小房间，却没盖一个统一大门来隐藏细节。结果调用者必须亲自处理五个房间的数据传递。

这种架构对AI是灾难。因为AI的context window（上下文窗口）有限——即使最新模型支持128K甚至百万token的窗口，研究表明模型在处理超长上下文时会出现「中间遗忘」现象（Lost in the Middle），对文本中部的信息关注度显著下降。当代码分散在大量细碎文件中时，AI修bug时它得在五个房间之间疯狂跳转，一旦逻辑超过记忆范围就开始瞎猜，很容易把正常代码也改坏。

真正的好架构是深模块：盖一扇极简单的大门（比如process_checkout函数），把复杂房间藏在后面。主程序只要敲一次门，完全不需要知道里面长什么样。经典的例子是Unix的文件I/O系统——仅用open、read、write、close、seek五个基本调用，就能操作从本地硬盘到网络存储的任意设备，内部的复杂性被完全隐藏。因为具备极强的局部性，AI修bug时只需专注阅读一个模块，所有逻辑都集中在视野里，能精准打击。

Matt为此开发了Improve Code-Based Architecture这个「大扫除」skill。它会对代码做「残酷的删除测试」：想象把某个模块拔掉会怎样。如果拔掉后天下大乱，说明它是有用的深模块；如果拔掉后代码反而更清爽，说明它只是个多余空壳，应该清理。它还会生成HTML诊断报告，画出架构对比图，你连代码都不用看就能挑方案重构。

与Superpowers对比：谁把主导权交给你

最后对比一下另一套热门套件Superpowers。它最强的地方是把整套工作流定义得非常完整——用九个步骤逼你想清楚目标、写好文档才准动工。在模型还不够聪明、容易偏题的时代，这种「保姆级防呆流程」非常管用。

但如果你现在用的是GPT-5、Claude这种等级的模型，Superpowers的死规矩反而成了累赘。既然模型理解力已经极强，不再需要像填表一样走完九个繁琐步骤。这其实反映了prompt engineering领域的一个重要趋势：随着模型能力的指数级提升，最优的人机交互方式也在快速演化——从早期需要详尽的few-shot示例和严格的格式约束，逐渐转向更简洁、更高层次的意图表达。

Matt的哲学完全相反：极简主义 + 模块化，一个skill只解决一个问题。你手上有份规格（不管谁写的），都能直接跳过前面步骤，丢给2Tickets拆任务，从哪步开始写完全由你决定。简单说，Superpowers给的是一条组装好的自动化流水线；Matt给的是一盒随取即用的乐高积木，把主导权交还给了开发者。这种设计哲学与Unix的设计原则一脉相承：每个工具只做一件事并做好它，工具之间通过标准接口自由组合。

结语：专业底子才是驾驭AI的关键

回头看这整套系统，Matt究竟靠什么把不受控的AI制得服服帖帖？说穿了，靠的是他深厚的软件工程底子，并巧妙地用在两个地方：

第一是架构——把深模块、烂代码症状等几十年被验证有效的老方法融入skill，规范AI行为；第二是沟通——直接把软件工程的专业术语当作prompt，一个精准术语抵得上一百字废话，让AI没有分心和发散的空间。

这两招打破了一个迷思：很多人以为有了AI就不需要在自己的领域精进了。但Matt证明了恰恰相反——只有成为专业领域的专家，你才能真正控制好AI。 这个道理在学术界被称为「自动化悖论」（Automation Paradox）：系统越自动化，对操作者的专业判断力要求反而越高，因为当自动化系统出错时，只有真正的专家才能识别问题、介入修正并恢复正轨。

Matt真正开源给我们的，从来不是几个skill，而是在教我们：如何用你在专业领域积累的思维和语言，去真正驾驭AI这个黑盒子。