夜雨聆风📦这篇信息密度有点大，建议先收藏🤲
下次让 AI 写项目之前，翻出来看一眼能少踩很多坑 🕳️
AI 编程工具的能力像坐了火箭一样往上蹿。很多人开始习惯一种新的开发方式：打开 ChatGPT 或 Cursor，丢一句"帮我做一个电商网站"，然后把 AI 吐出来的代码直接复制贴上。跑得动就继续，跑不动就把报错再丢回去让 AI 改。
这种开发方式叫Vibe Coding。
但如果你真的用这种方式做过一个正经项目，你大概已经隐隐感觉到不对劲了。AI 写功能的速度确实快得吓人，但写着写着，你的项目开始变得像一栋结构诡异的房子——表面看起来房间分得清清楚楚，但你永远找不到大门在哪。
要改一个按钮的颜色，你得同时打开十几个文件；要修一个结账的 bug，你得把 AI 的上下文窗口撑爆，它还是搞不清楚逻辑到底散落在哪里。
这时候你才反应过来：你被 AI 写的代码绑架了。
而 GitHub 上一位拥有超过 18 万颗星的项目作者，TypeScript 领域公认的顶级大神 Matt Pocock，早就踩过这个坑了。他不仅踩过，还把自己跟 AI 密集协作两年后总结出来的完整工作流，全部开源了出来。
今天我们就来把这套工作流拆开，看看大神到底是怎么把 AI 从"乱枪打鸟的实习生"变成"指哪打哪的资深架构师"的。
01 大多数 AI 写的代码，都是一栋没有大门的房子
先问你一个问题：你觉得 AI 写代码最大的问题是什么？
很多人会回答"会有 bug"。不对。AI 写出来的 bug 其实相对好修，你只要把报错丢回去，它大概率能自己改好。
真正致命的问题，是 AI 写出来的代码架构，往往是一坨浅模块。
什么叫浅模块？Matt 在项目里用了一个非常生动的比喻。想象一栋房子，里面厨房、客厅、卧室都分得清清楚楚，但这栋房子没有大门。你要进厨房得爬外面的窗户，进客厅得走屋顶的烟囱。每个房间都有自己独立的入口，互不相通。
听起来很荒谬对吧？但 AI 写代码的时候，最爱盖这种房子。
拿一个电商网站的结账功能来说，AI 接到"帮我实现结账"这个需求后，会非常"尽责"地把逻辑拆成五个小模块：计算折扣、验证信用卡、建立订单、扣除库存、发送邮件。听起来很合理，甚至很有"工程思维"对吧？但问题在于，AI 没有帮这五个小房间盖一扇统一的大门。
结果就是，主程序必须亲自去跟五个模块打交道，手动把数据传来传去。主程序知道折扣怎么算的吗？不需要，但它被迫要知道"我该在什么时候去调用折扣模块、什么时候去验证信用卡"。这就像你要去这栋房子做客，明明只是来找朋友聊个天，却得先记住五组密码、走五条不同的路线。
最糟的是，当结账功能出 bug 时，你让 AI 去修。AI 一打开代码，发现逻辑散落在五个文件里。为了搞懂"满 1000 送 100"这个折扣到底有没有生效，它必须在这五个房间之间疯狂跳转。但 AI 的上下文窗口是有限的——塞进去三个房间的记忆，前两个就开始模糊了。于是它开始凭感觉瞎猜，最后很可能把你原本正常的代码也一起改坏了。
浅模块会让 AI 迷路；只有深模块，才能让 AI 精准打击。
那什么是深模块？
深模块不是把一万行代码塞进同一个文件里。深模块的核心只有一句话：对外提供一扇极度简单的大门，把所有的复杂性锁在门后。
同样是结账功能，深模块对外只暴露一个函数，比如叫 processCheckout。主程序调用它的时候，只需要丢进去一个购物车对象，其他什么都不用管。至于折扣怎么算、信用卡怎么验证、库存怎么扣、邮件怎么发，通通锁在这个大门背后。主程序敲一次门，事情就办妥了。
深模块的好处是，当结账出问题时，AI 只需要打开这一个文件，所有的逻辑都完整地呈现在它眼前。它不用跳来跳去找线索，所以能极度精准地定位 bug 并修复。
听到这里你可能想问：道理我都懂，但 AI 写代码天生就爱写浅模块，我总不能每一行都盯着它吧？
这就是 Matt Pocock 这套开源项目真正值钱的地方——他把"让 AI 写出深模块"这件事，变成了一条可以自动运行的生产线。
02 动工之前，先让 AI 把你拷问到崩溃
Matt 的工作流，起点是一个叫做grill-me的 skill。
如果你去 GitHub 上打开这个文件，会发现一个被下载了 610 万+次、帮 Matt 拿下 18 万颗星的 skill，里面居然只写了五行字。
这五行字的核心指令只有一条：在 AI 和你对计划没有达成完全共识之前，必须把你往死里问。
AI 会像画心智图一样，顺着你的每一个决定往下追问。你说"我要做一个购物车"，AI 不会直接回"好的，我帮你写代码"，它会反问："购物车里的商品要保存多久？用户关掉浏览器再打开，购物车还在吗？如果用户同时在两个设备上登录，购物车要同步吗？库存不足的时候，是直接不让结账还是允许超卖？"
每次只问一个问题，而且必须附上 AI 自己的建议答案。在你对所有关键决策拍板定案之前，AI 绝对不准碰任何一行代码。
为什么要用这种近乎"拷问"的方式来开头？
因为写程序这件事，本质上就是连续做出几百个微观决策。防呆怎么做？断线怎么办？极端数据怎么处理？如果你把模糊的想法直接丢给 AI，等于把这几百个决策权全部外包给了 AI 这个黑盒子。
而 AI 为了尽快给你一个"能跑的东西"，一定会选择最偷懒、最讨好的方式——也就是写出一堆后续根本没法维护的浅模块。
所以 grill-me 的唯一目的，就是把决策权抢回人类手里。Matt 知道让人类对着空白屏幕从零写一份完美企划书太痛苦了，所以他让 AI 来扮演那个"专门找漏洞"的角色。AI 只负责把盲点挖出来，拍板定案的永远是人类。
但这里有个问题：拷问完了，对话一关，AI 就失忆了。刚才吵出来的共识怎么办？
03 把共识锁死，再把任务切成 AI 嚼得动的小块
第二站，叫做to-spec。
它的任务很简单：把刚刚和 AI 吵架出来的所有共识，写成一份规格书。
但 Matt 在这个 skill 里加了一条非常极端的禁令：写规格的时候，绝对不准出现任何程序代码。
为什么？因为文件永远跟不上代码更新的速度。如果你把代码写进规格书里，三个月后需求变了，代码改了，但规格书里的旧代码还躺在那。下一次你让 AI 照着规格书改功能，它一读，发现规格书里写的是 A，实际代码已经变成 B 了。AI 会被这份过期的文件搞到精神分裂，越改越乱。
所以 to-spec 强制规格书只专注回答一个问题：这项功能到底要解决什么？至于怎么实现，那是后面的事。（Matt 在 2026 年的更新中，已正式用 /to-spec 取代了旧版的 /to-prd，名称虽然变了，但核心理念一脉相承。）
规格写好了，接下来是第三站，to-tickets。它的作用是把规格书拆成具体的待办任务。（同样，/to-tickets 也已正式取代了旧版的 /to-issues。）
这个 skill 里藏了一个 Matt 非常看重的开发方法论：按使用者功能来拆任务，而不是按技术架构。
让 AI 自己规划任务，它有一种天生的坏习惯——喜欢照技术分层来分工。做一个电商网站，AI 会这样拆：先建数据库，再写后端逻辑，最后画前端画面。等你跑完整个流程，终于看到画面的时候，如果发现数据库一开始就建歪了，你前面所有的努力全部报废。
但 to-tickets 会强制 AI 改掉这个习惯。同样做电商，它会切成两个任务。第一个任务是"会员登录"：这个任务里已经包含了登录需要的数据库表、登录的后端逻辑、登录的前端界面。任务一做完，你马上就可以打开浏览器测试登录功能好不好用。
第二个任务是"加入购物车"：同样完整包含数据库、逻辑、界面三层。
差别在哪里？按功能拆，每做完一个任务，你就有一个可以实际测试的产品增量。你不是蒙着眼让 AI 写了几千行代码之后才开始审核，而是每完成一小块，就能立刻确认它到底会不会动。那些互不干扰的任务，你甚至可以同时分派给多个 AI 平行作业。
04 TDD 不是老派，是用来防 AI 作弊的
任务拆完了，终于进入实作阶段。Matt 的系统里有一个专门写程序的 skill 叫做implement。
它会照着任务清单开始写代码，而且用的是 TDD，也就是测试驱动开发。
很多人觉得 TDD 是老派敏捷开发时代的东西，早就过时了。但 Matt 认为，在 AI 时代，TDD 反而是防作弊的唯一武器。
什么叫防作弊？你知道 AI 有多爱作弊吗？如果你让 AI 先写算钱的程序，再补测试，它给你写了一个 bug——满 1000 元应该扣 100，它写成了扣 200。然后你让它补测试，它会"贴心"地帮你生成一个测试，内容是"验证满 1000 元是否扣 200"，然后跑出"通过"的绿勾。它拿自己写错的逻辑去配一个绝对会通过的测试，你根本抓不出 bug。
但 TDD 的顺序是反过来的。AI 必须先写测试："购物车满 1000 元，结账金额必须扣 100"。这时候程序根本还没写，测试一跑，必死无疑，红灯亮起。等到红灯亮在那里了，AI 才开始写真正的算钱逻辑，写到测试变绿为止。
用这个顺序，你彻底锁死了 AI 乱写交差的空间。测试是 AI 自己写的，但它没法作弊，因为测试在代码之前就已经定死了。
程序写完了，测试也过了，这套流程还会自动触发一个Code Reviewskill。它会开一个全新的对话 session 来做审查，避免被写代码时的记忆干扰。
这个 skill 值得特别提一下，因为它不是那种敷衍的"帮我检查有没有 bug"。Matt 直接把软件工程界几十年来公认的烂代码症状，全部列成了具体的检查清单。里面点名了 12 种坏味道，像Shotgun Surgery（改一个东西要同时改十几个地方）、Feature Envy（逻辑放错了位置）、Data Clumps（三个变量老绑在一起出现却没人打包）等等。这些症状全都出自经典名著《重构》，Matt 就是把这本书的智慧直接写进了 skill 的指引词里。
05 大神的 Prompt 为什么这么短？因为他懂"修剪"
如果你仔细看过 Matt 这些 skill 的源代码，会发现一件很反直觉的事：他的每一个 skill 都出奇地短。grill-me 只有五行，其他 skill 也极少有超过十句的。
他到底是怎么把 Prompt 磨得这么精炼的？项目里其实有一个叫做writing-great-skills的 skill，专门讲这件事。
他的核心理念很简单：你多写一句废话，AI 就多一分分心的可能。
所以他提了三个原则。第一个叫Pruning（修剪），把所有的废话、赘词、甚至那些你不说模型也知道的常识指令，全部删光。第二个叫指引词，也就是用那种信息密度极高的专业术语来取代长篇大论。你写一整个段落跟 AI 解释"请帮我把那些老绑在一起出现的变量打包成一个对象"，它不一定听懂，但你说一个词Data Clumps，AI 秒懂。因为这些术语早就深植在 AI 的训练数据里。Matt 就是用这招，用一个专有名词取代了一百字的废话。
第三个原则是完成标准，也就是给 AI 一个明确的终点，告诉它"做到什么程度算完"。这三个原则加在一起，Matt 把会乱发散的 AI 变成了听话的奴隶。
06 每周帮你的项目做一次"大扫除"
有了这套工作流，AI 写出来的代码已经比乱枪打鸟好太多了。但 Matt 还是很清楚：AI 天生没有大局观。不管你怎么规范它，它每次还是只能盯着眼前那几个文件。久而久之，你的项目还是会被一堆浅模块慢慢侵蚀。
所以他开发了一个名为improve-codebase-architecture的大扫除 skill。
这个 skill 会做一件非常狠的事：删除测试。它会去检视你项目里的每一个模块，然后问自己一个问题——如果我把这个模块直接删掉，让主程序自己接管它的工作，会发生什么事？
如果删掉之后，天下大乱，原本被藏好的复杂逻辑全部炸回主程序里，那证明这个模块是货真价实的"深模块"，它真的有在做事。
但如果删掉之后，代码反而变清爽了，原本要跳来跳去看两个文件，现在所有逻辑都集中在一个地方——那就说明这个模块根本没有隐藏任何细节，它只是一个空壳。AI 就会精准地把这些假装在做事、只会害人迷路的浅模块揪出来，然后建议你把它清掉。
Matt 的建议是，每隔几天就在终端机跑一次这个指令。它会扫描整个项目，然后生成一份可视化的 HTML 诊断报告，画出前后架构对比图。你连代码都不用看，只要看着图，挑一个最想改的地方，对 AI 说"照这个方案重构"，它就会自动帮你把四散的代码重新聚拢成深模块。
07 Wayfinder：比 grill-me 更强大的探索工具
除了前面介绍的这套核心工作流，Matt 在 2026 年还推出了一个重要新工具：/wayfinder。
grill-me 虽然好用，但它有一个局限：它是一场独立的拷问会话。如果你的需求比较复杂，一次 grilling 会话很难覆盖所有维度。而且每次拷问都要从头开始摸你的项目，效率不够高。
/wayfinder 解决了这个问题。它的定位是"spec 之前的探索阶段"的 agent 编排器。具体来说，它会做三件事：
第一，先扫描你的代码库，理清现状。它不像 grill-me 那样从零开始，而是带着对项目的理解来跟你对话。
第二，把一个宽泛的大需求拆成多个聚焦的小 grilling 会话，并行跑起来。每个会话对应一个决策点，比如"数据库怎么设计"、"API 怎么定义"、"错误怎么处理"。
第三，输出一份决策完备的 spec，可以直接交给 to-spec 和 to-tickets 去生成规格和任务。
Matt 在一次直播中用真实需求做了演示——给自己的 Course Video Manager 加一个 TikTok 创建器。从最初口述需求，到 Wayfinder 绘制"地图"、回答 grilling 问题、创建决策和研究 ticket，再到多个会话并行推进，整个流程把"雾里看花"逐步推成了清晰的 spec。
简单来说：grill-me 是一个拷问工具，wayfinder 是一套拷问的指挥系统。如果你的需求相对清晰、范围不大，grill-me 就够了。但如果面对的是复杂、模糊的大型任务，wayfinder 能帮你把探索过程组织得更高效。
值得注意的是，Matt 在 2026 年 7 月中旬明确更新了自己的推荐：他不再将 grill-me 作为编码的默认推荐，而是推荐在实施前用grill-with-docs来对齐计划。grill-with-docs 会在拷问过程中同步维护项目的 CONTEXT.md 和 ADR 文档，建立共享的领域术语。目前他更进一步，默认推荐 domain-model 作为规划起点。
这个变化传递了一个重要信号：skill 不是供起来的框架，而是随时可以被替换、被组合的一次性工具。Matt 撤下自己最火的 skill，不是因为 grill-me 不好，而是因为他在实践中找到了更适合特定场景的工具。这恰恰体现了他小模块化、可自由拼装"的设计哲学——连作者自己都在随时更换组件。
08 大神的真正武器，从来都不是代码
讲到这里，我们可以回答最初的那个问题了：为什么 Matt Pocock 能靠一个开源项目拿到 18 万颗星，把 AI 治得服服帖帖？
答案其实就两个字：底子。
他靠的不是什么奇招，而是过去几十年软件工程界早就被验证有效的硬功夫——深模块理论、烂代码的 12 个征兆、TDD 开发流程、重构心法。他把这些知识全部内化成了自己的思维方式，然后巧妙地用在了两个地方。
第一，用在架构上。他把那些经典的老方法写成 skill 的规则，直接写进系统里来约束 AI。
第二，用在沟通上。既然他懂那么多软件工程的专有名词，他干脆就把这些词拿来当 prompt。与其写一百字废话去跟 AI 解释需求，不如直接丢一个精准术语，AI 一听就懂。就像一位老教练给球员的一句话，听起来很简单，里面却装了几十年的经验。
这就彻底打破了一个迷思：很多人以为有了 AI，我们就不需要在自己的领域精进了。
但 Matt 用这 18 万颗星证明了一件事：只有成为专业领域的专家，你才能真正控制好 AI。如果你对自己的领域一知半解，你连 AI 在瞎编什么鬼话都看不出来，更别提让它帮你写出生产级别的代码了。
Matt 真正开源给我们的，从来都不是那几个 skill。他是在教我们一件事：在这个 AI 时代，真正让你不可取代的，是你在专业领域积累的思维和语言。用它去驾驭 AI，而不是被 AI 牵着鼻子走。