# 一个声乐老师，做出了 GitHub 上最火的 AI Skill 

最近听了一期 The Pragmatic Engineer 的播客，嘉宾叫 Matt Pocock 。我感觉内容讲的很好，是非常值得看的一起播客，没事，我带大家一起看看这期干货，到底讲的是什么？真心推荐大家认真对完这篇文章。

这个人的经历很有意思。我原本以为他是那种从小写代码的技术天才，结果完全不是。他在做程序员之前，当了六年声乐教练。在伦敦教人唱歌，教人练口音，教人演莎士比亚，还去咨询公司教高管怎么做演讲。

后来他不想待在伦敦了。他说他在伦敦住了两年，受不了。他想回到他长大的乡下去。但声乐这行，要做到一定水平，必须待在大城市。于是他开始琢磨，有没有什么工作可以远程做？

他选了编程，纯粹自学。

他自学的第一个项目就特别猛：做了一个网页版的音频频谱分析工具，可以看到学生唱歌时声音的共振频率是不是平衡的。他自己说，跑起来巨卡，但确实让教学变好了一点。

2017 年前后，他找到了第一份正式的开发工作。因为当了六年声乐老师，他有一个别的程序员没有的优势：特别会说话。面试的时候，他技术知识不多，但能把知道的东西讲得很清楚。这个组合让他升得很快，几年之内跳了好几家公司。

再后来他加入了 Vercel，就是做 Next.js 的那家公司。但他在 Vercel 只待了三个月，因为他同时在做一件事：给 TypeScript 做教学课程。

他做了一套叫 Total TypeScript 的课程，预售阶段就爆了。他在 Vercel 的工资已经很好了，但课程预售的收入是工资的三四十倍。课程正式上线后，很快突破了百万美元。他后来公开说，总收入到了 250 万美元。

这本来可以是一个完美的故事，教程做得好，收入很高，一直做下去就行了。

然后 AI 来了。

## 一、AI 吃掉了「知识」，但吃不掉「智慧」

Matt 说，他教课的时候，其实在教两层东西。表面上是语法、是写法、是具体的知识点。但他同时也在传递一种判断力，就是什么时候该用什么，为什么要这样组织代码。

知识现在很便宜了。你随便问一个 AI，它都能给你讲明白 TypeScript 的某个特性怎么用。但判断力这个东西，AI 教不了。你还是得自己踩坑，自己积累。

他的 TypeScript 课程收入开始下滑。他花了挺长时间才想明白自己在 AI 时代应该做什么。

他先试过做一些把 AI 嵌入应用的课程，效果一般。他还试过所谓的 spec driven development，就是写一份详细的规格说明书，让 agent 照着做。结果发现代码越改越烂，spec 改一轮，代码质量就掉一截。

转折发生在去年年底。很多人管那段时间叫「圣诞假期觉醒」。大家放假，有大把时间跟 AI 较劲，忽然发现模型已经够好了，真的可以把具体的编码任务委托出去。

Matt 也是这时候想明白的。写代码这种具体的、战术层面的活儿，AI 已经能接住了。人要做的是更上面一层：架构怎么设计，系统该往哪个方向走，这些长线的决策。

## 二、Grill Me：让 AI 像资深工程师一样拷问你

想明白之后，他开始做 AI Skills。所谓 Skill，说白了就是一组 Markdown 文件，塞进你的编程工具里，agent 可以自己调用，或者你手动触发。

他最火的一个 Skill 叫 Grill Me。原理特别简单：让 agent 像一个特别较真的资深工程师一样，针对你要做的功能，疯狂提问。

播客主持人自己试过。他说他想做一个很简单的 API 端点，查一下某个邮箱是不是自己的付费订阅用户。结果 Grill Me 一口气问了他 35 个问题。认证用 bearer token 还是 JSON？要不要做限流？限流的策略是严格到每天一千次就不让再调，还是弹性一些？

他说他又烦又佩服。好久没有经历过这么深入的设计讨论了。而且这种讨论通常只有跟特别有经验的工程师才能发生。

Matt 说，Grill Me 的价值在于，它逼你自己做决策。不像你直接跟 agent 说「帮我做一个 API 端点」，那样 agent 就替你把所有决定都做了，做出来的东西很可能跟你想的完全不一样。Grill Me 让你一个一个问题过，每个决定都是你自己拍的。有时候它提到的某个方面你没想清楚，你还得暂停一下，去查资料，去找另一个 AI 问问看。

这个 Skill 仓库放到 GitHub 上以后，他自己都没怎么宣传，就已经开始疯涨了。现在有 23 万颗星，是全 GitHub 第二火的 AI Skills 项目。

## 三、他翻出了一本还包着塑料膜的老书

Matt 在折腾 AI 编程的过程中，碰到一个很烦人的问题。

agent 写代码的时候，它会先把整个数据库层写完，再写整个应用层，最后写整个前端。每一层单独看还行，但拼到一起就出问题。因为数据库里的设计会影响前端展示，你得让这些层早一点对上才知道合不合理。可 agent 总是最后才开始组装。

他觉得这样不行。然后他翻出了书架上一本一直没拆封的《程序员修炼之道》。

他说这本书他买了之后一直没看，还包着塑料膜。翻开以后，几乎每一页都觉得像是写给今天的。里面有一个概念叫 tracer bullet，追踪子弹。意思是做一个功能的时候，不要按层来，要纵向切一刀，从数据库到应用逻辑到前端，先把一条窄窄的路径跑通，确认可行之后再往两边扩展。

他把这个词写进了给 agent 的提示词里。然后他发现了一件有意思的事：agent 开始在自己的推理过程中主动使用这个词了。它会说「好的，我把这个做成一个 tracer bullet」。

他管这个叫 leading word，引导词。因为这些经典编程书籍几乎肯定在模型的训练数据里，当你在 prompt 里用了这些专业术语，就相当于激活了模型脑子里对应的那片知识。

他又从《软件设计哲学》里捞出了 deep modules 这个概念，从《领域驱动设计》里拿到了 ubiquitous language 的思路。他发现这些二三十年前的老概念，到了 AI 时代反而更好用了。

## 四、给你的项目发明一套「黑话」

这一点我觉得特别值得说。

Matt 说他有一个教学应用，里面有一种叫 ghost lesson 的东西，就是还没正式创建的虚拟课程。当你把一个 ghost lesson 变成真正的课程时，它所在的 ghost section 也得跟着变真，ghost course 也得跟着变真。这个过程挺复杂的，每次跟 agent 描述都要费很多话。

后来他跟 agent 一起给这个过程起了个名字，叫 materialization cascade，物化级联。

就这么一个词，之后他只要跟 agent 说「执行 materialization cascade」，agent 就知道该做什么。沟通效率直接起飞。

他现在专门有一个 Skill 叫 Grill with Docs，就是在讨论需求的同时，顺便跟 agent 一起建立一套项目专属的领域术语。这些术语写进代码、写进文档、写进 prompt，人和 agent 说同一套话。

想想看，我们跟同事合作的时候也一样。一个团队里大家用同一套行话，沟通速度快很多。现在 agent 每次启动都是从零开始的，它没有长期记忆。如果你的代码库里到处都是这些清晰的术语，agent 进来就能读懂，就像一个新人入职第一天看到了一份特别好的文档。

## 五、你的代码就是 agent 的工作环境

Matt 反复在说一个观点：代码库就是 agent 的工作环境。你把代码写得干净、结构清楚，agent 的表现就好。你的代码一团糟，agent 也会跟着输出一团糟。

人可以适应烂代码。你在一个项目待久了，哪里有坑你都记得住，绕着走就行了。但 agent 做不到，它每次开一个新的会话都是失忆状态，面对的都是一个全新的代码库。

他用了一个比喻：这就像 memento driven development。就是电影《记忆碎片》那个意思，你的 agent 每天早上醒来都不记得昨天发生了什么。所以你必须把代码库维护到一种状态，让一个什么都不知道的新人也能迅速看懂、上手干活。

他每天早上会让 agent 自动跑一遍代码库的架构检查，生成改进建议。他看一眼，觉得靠谱就点一下，变成工单，让 agent 去执行。这样持续地修缮代码库，就像打理一座花园。

这让我想到，以前我们说代码整洁很重要，很多人觉得是一种追求完美的洁癖。但现在情况变了。代码整洁直接影响 agent 能不能帮你干好活。这变成了一个实实在在的效率问题。

## 六、什么时候该规划，什么时候直接干

关于要不要做前期规划，Matt 说得很实在。

如果改动很小，五行代码的事，直接让 agent 做就好了。做完你看一眼，不对再改。

如果是一个功能，一个会话能搞定的那种大小，先用 Grill Me 跟 agent 讨论清楚再动手。

如果是更大的项目，要跨好多个会话才能做完，那就用他的另一个 Skill 叫 Wayfinder。Wayfinder 会生成一张地图，上面有很多节点，有些已经探明了，有些还是迷雾。你每次开一个会话，就是在地图上往前走一步，掀开一片迷雾。他用这个工具做过五六十个节点的大项目，甚至拿来规划过在院子里盖办公室这种非技术的事情。

有人问他，这跟瀑布流开发有什么区别？他说他在写 spec 之前会先让 agent 快速做好几个原型。现在做原型太便宜了，你可以让 agent 噼里啪啦做出三四个版本，挑一个最接近你想要的，再在上面细化。这个能力以前根本想象不到。

## 七、推荐三本书

最后 Matt 推荐了三本书。

第一本是《程序员修炼之道》，里面的概念几乎都能直接用到跟 AI 协作上。

第二本是 John Ousterhout 的《软件设计哲学》，讲的是怎么在架构层面做出好的判断。

第三本是 Eric Evans 的《领域驱动设计》，他说主要看前三章就够了，核心是 ubiquitous language 那套思路。

这三本书，最年轻的也有二十年了。

有点讽刺，也有点让人安心。AI 在往前跑，但真正好用的方法论，很多是老一辈程序员早就总结好的。它们没有过时，只是换了一个新的应用场景。

#科技先锋官##How I AI#