欢迎收听跨国串门计划，这是一档专注于让中文听众无障碍欣赏全球优质外语播客的节目。通过先进的 AI 声纹克隆技术，我们不仅将内容翻译成中文，还完美保留了原主持人和嘉宾的独特声音，为您呈现全球顶尖的 AI 财经、健康与科技领域精品内容。我是主播一凯，一位热衷于 AI 领域的产品经理，很荣幸能为您搭建这座跨越语言障碍的桥梁。
接下来，让我为您简单介绍本期我们克隆的这档节目。本期我们克隆的是知名播客 AI Engineer 在 2026 年 6 月的一期节目，主讲人是 Matt Pocock。他是 Matt Pocock：的作者，这套技能集在 AI 工程领域非常流行，因此他对如何构建高质量的 Agent 的技能有着很深的一手经验。
这期他主要围绕一个被称作“技能地狱”的普遍困境。分享了一套系统性的技能构建框架，那我们就一起来听听这期的完整对话。朋友们好，我本来特别希望能去 AI Engineer World Fair 现场，但家里有事走不开，没法到场了。不过我不会让大家空手而归，我会把原本要在旧金山做的演讲内容分享给你们。这场演讲叫《缺失的手册：如何写出好技能》。
我觉得区分好技能和坏技能的能力只会越来越重要。作为开发者，我们好像特别擅长给自己找各种地狱，比如几年前有教程地狱，就是你一头扎进一堆教程想学东西，结果拼不起来，陷入一个走不出来的循环；还有框架地狱，每隔十分钟就冒出一个新的 JavaScript 框架，你得不停的学最热门的新东西。而现在，我觉得我们又有了一个新版本的地狱，叫技能地狱。
技能地狱就是。你手头有各种各样的技能，随便下载、贡献、自己摸索，但你其实搞不清楚这些零件是怎么拼到一起的，你分不清好技能和坏技能。这意味着人们试图拼凑这些框架，想一口气把所有东西都试一遍，结果要么做不到，要么拿不到技能本身承诺的效果。这在个人层面是这样，在组织层面也一样。组织不知道也不理解怎么构建好技能，怎么把他们的操作流程转化成 agent 能执行的东西。
如果你做不到这一点，就很难收获技能能带来的好处。再来一个技能就行了，兄弟。这好像就是我们现在的状态。我对此也有点愧疚，因为 Matt Pat Skills 就是我的技能仓库，也是目前最流行的工程技能集之一。所以我想帮那些用我技能的人走出技能地狱。那我们该怎么做？怎么走出去？到底缺了什么？在我看来，我们缺的是不知道什么让一个技能变得优秀。
我们还做不到看一眼某个技能就说这个技能在这些方面做得好，那些方面做得不好。没有一个共享的评判标准，没有一个框架来审视技能并把它变得更好。这就是我今天要给大家的东西。我会给你们一个技能检查清单，一份你可以用来审视技能内部的清单，确保它做到了它该做的事儿，以及改进它的方法，写出好技能的方法。这份清单长这样。
我们从技能的触发开始，也就是技能是怎么被调用的，以及你在设计时需要做的决策。然后是技能的内部结构，技能内部到底是怎么组成和布局的？第三点是怎么用技能来引导，怎么让技能告诉 Agent 该做什么？第四点是怎么把技能做得尽可能小？因为一旦我们有了一个能用的技能，就需要把它最大化，减掉所有无关的东西，减掉所有无效操作。
我不在现场有一个好处，就是你可以立刻去试试看，因为我已经把所有这些内容编码进了我仓库里的一个新技能，叫 Writing Great Skills。所以，如果你有马上能用的场景，直接去我的技能仓库，关掉浏览器，离开这里，用这个技能去改进你现有的技能，或者写出优秀的新技能。好，我们开始过这份检查清单。第一点，触发，也就是技能被调用的方式。
为了讲清楚这个，我要做一点对比。我的技能经常被拿来跟另一套非常流行的工程技能 Superpowers 比较。我经常被问到，你的技能跟 Superpowers 比怎么样？它们有什么区别？要理解这一点，我们需要先理解用户调用和模型调用技能的区别。任何时候，你有一个技能，你都可以手动调用它。技能就在你的文件系统里，Agent 可以直接拉取技能，并理解里面的内容。
你随时可以通过跟 agent 的沟通来做到这一点，具体形式不一定都是斜杠，取决于你用的 harness，但你总是可以用户调用你的技能。另一种调用方式是由 agent 自己来调用，这些叫模型可调用技能或者模型调用技能。你可以写一段描述技能的描述会一直留在 agent 的上下文里，agent 可以看着它，然后决定。
好，基于这个描述，我要调用这个技能，然后把 skill 点 md 文件，也就是技能的核心内容读进我的上下文窗口里。这就是调用技能的方式。技能被调用时就是这么回事。这个描述相当于一个上下文指针，它待在 agent 上下文里，指向另一个文件。Agent 需要更多上下文时，可以过去看。对于这个上下文指针，你不需要把它放进 Agent 的上下文，它完全可以对 Agent 不可见。
这就是我们说的用户可调用技能。有些技能只能由用户调用，因为他们没有这个上下文指针，这是可选的。比如，我们来看我的 code-based design，这是一个模型可调用技能，它有一个描述会进入 agent 的上下文窗口。但如果我们看我的 Groovy 技能，可以看到它设置了 disable model invocation true，这意味着这段简短描述只展示给用户，agent 是看不到的。
所以这是第一条建议：决定你的技能是用户调用还是模型调用。你可能会觉得模型调用技能更好，对吧？因为模型可以自己调用，用户也可以调用，更灵活。但每次你往 agent 环境里加一个模型调用技能，都会增加我所说的 agent 的上下文负载。它加了一条新描述，每次请求都在消耗 token，同时也给 agent 多了一个要思考的东西。
如果你有一百个模型调用技能，agent的上下文里就会有一百条描述。所以，要么压减模型调用技能的数量，要么全部用用户调用技能。这看起来是合理的，但用户调用技能有另一种负担：用户调用技能越多，用户的认知负载就越高。换句话说，用户需要在脑子里记的东西越多，对操作者的技能要求就越高。所以，如果我们比较
Map Skills 和 Super Powers，Super Powers 主要是模型调用技能，它给 Agent 赋予超能力。
而我的技能，我更倾向于完全掌控。这意味着我可以把 Agent
的上下文负载压到最小，但这确实给我自己带来了更多认知负载。所以我需要非常深入地理解这些技能，才能把它们用到极致。那我为什么这么做？为什么我更偏好用户调用技能？因为每次你有一个模型调用技能，基本上你就要付出不可预测性的代价。因为每次有一个上下文指针从一个资源指向另一个资源，模型可能就是不跟过去，哪怕这个技能对当前任务来说绝对完美，它也可能就是不调用。
我更愿意消除这层不可预测性，给用户增加一点认知负载。换来的是，你直接把一整类问题消灭在萌芽状态，因为这种不可预测性会迫使人们去评估自己的技能，确保他们在正确的时机被调用，这非常麻烦。是我宁愿避开的问题，但我想在这里展示的是，模型调用技能和用户调用技能各有各的成本，所以选哪个并不是一个简单的决定。以上就是触发，也就是技能如何被调用。
现在我们来谈谈结构，也就是技能的内部布局。我认为大多数技能需要放入两个主要单元，这两个单元是步骤和参考。步骤是技能要逐步执行的操作流程，参考是帮助他完成这些步骤的任何辅助信息。你可以有只有参考没有步骤的技能，也可以有没有参考只有一组简单步骤的技能。但如果你开始把技能看作由这两个单元组成，就能帮你更好的拆解它们。
我们来看一个例子，我的一个技能叫二PRD，它从当前上下文窗口创建产品需求文档，它有三个步骤：找到相关上下文，跟用户确认测试接缝。这里有一个人在回路中的检查点。确保测试方面不出什么奇怪的问题，我觉得很重要。然后我们撰写产品需求文档，为了支撑这三个步骤，我们有两块参考材料，一块是关于什么是测试接缝的简短参考，另一块是产品需求文档模板，就是一个用来写PRD的Markdown模板。
所以这是一个从零开始写技能的好方法。你先确定需要哪些步骤，然后写出这些步骤，再确定这些步骤需要什么参考材料。把它放在技能里一个单独的区域，专门放参考材料。不过有一个非常重要的约束，我们需要考虑，这是第三条建议：我们要让主 skill 点 md 文件尽可能小。每个技能由它的描述、一个 skill 点 md 文件以及从它分支出去的任何参考材料组成。
而这个 skill 点这个 skill 点 md 文件，如果我们把它做小，能在很多方面省事儿。越小的技能越容易维护，越容易审查，要琢磨的词也更少。而且你每砍掉一个词，就省下一个 token，等于从技能成本里省下好几个 token。所以，我确实认为小技能对维护者和使用者都很重要。一个很实用的瘦身方法是去想技能的不同分支，也就是技能的不同使用方式。
因为如果某份参考资料只在一个分支里用到，那它就可以考虑从主 skill 点 md 里移出去。举个例子，看我的二 P R D，它有两份参考资料，什么是测试接缝以及 P R D 模板？P R D 模板我们每次都需要，因为我们总是在创建 P R D。什么是测试接缝的信息？我们大概每次也需要，因为我们总会问测试接缝的事。
所以，RPRD 只有一个分支，所有参考资料都属于这个分支。那它们大概也应该留在 skill 点 md 文件里。但再看我的另一个技能 domain modeling，它做两件事：更新一个叫 context 点 d 的本地词汇表，同时创建架构决策记录。也就是说，他在做两件不同的事，或者他也可能两件都不做，那他就不需要 context 点 md 模板，也不需要 adr 模板。
所以，domain modeling 有两个甚至三个分支，这意味着我们不需要把 adr 模板或 context 点 md 模板放进主 skill 里，可以把它们挪到单独的区域。具体做法是，你有 skill 点 md 文件，然后把它放在一个上下文指针后面，让上下文模板指向技能文件夹里的另一个 markdown 文件。
这个上下文指针的意思就是，如果你需要模板或者需要更新 context 点 md 文件，就去这个文件。我把这叫做外部参考，就是 skill 点 md 外部的一份参考资料，你可以很方便的引用。Agent 也很容易拉取，因为它是跟技能打包在一起的，所以这是一个让 skill 点 md 尽可能小的技巧。好处非常多，把分支参考资料藏在上下文指针后面。
换句话说，如果你觉得你的技能会被用在很多不同场景，那就把跟那些分支相关的参考资料藏到上下文指针后面。好，这就是结构。我们要想着把 skill 点 md 做得超级小，要想着技能里的分支，把资料移到上下文指针后面，还要想着步骤和参考，这是技能内部的两个主要单元。接下来讲引导，也就是我们真正让 agent 按我们想法做事的方法。
对我来说，引导归结为一个特别酷的技巧，这也是我今天最想让你从演讲里带走的东西。这个技巧解决的是这个问题：agent 不按我的想法做。也就是说，我在技能里写清楚了，我觉得自己说得很明白，但他就是不做。我觉得出现这种情况的主要原因是你没用一种叫引导词的技巧。引导词的概念，或者说，如果你喜欢文学理论的话，大概就是有些词能把一大堆意思压缩到很小的空间里。
这些引导词对 agent 来说特别强大。因为你把引导词放在技能本身，放在文本里，然后 agent 会在自己的操作中，在自己的思考 token 里，在给你的输出里把这个引导词重复给自己，然后因为他反复强调这个词，而这个词又希望描述了你想要 agent 做的事，他就会去改变行为。我们用一个例子来具体说明。
假设我们有一个问题，一个 agent 的经典问题就是他们会一层一层地写代码。也就是说，你给他一大块工作，他通常会先把数据库层全写完，然后是所有 schema，然后是所有 API 端点，然后是前端。他们不会做人类那种典型做法，尽早寻求反馈，先把一个小东西跑通，再往外扩展。我们可以试着鼓励 agent 这样做，直接说不要一层一层写代码，确保先做一个小切片，再从这里展开。
但如果我们改用引导词呢？我们说垂直切片就是我们的引导词，我们要把工作切成垂直切片，而不是水平切片。垂直切片在开发领域是个挺知名的术语，所以这有希望触发 agent 的先验知识，让它理解我们的意思。我们不需要只写一个、两个词的技能。光说垂直切片，我们要做的是把大量含义压缩到一个相对短的短语里，然后在整个技能中反复使用它。
这个技巧有一个很酷的地方，你能知道它有没有生效，因为你在技能里写了垂直切片，然后就会在推理轨迹里看到它说好，我们要把它做成一个薄的垂直切片，接着你就能得到更好的实现计划。每个听我讲过这个技巧的人反应都差不多是哦，对我其实已经这样做了一段时间。一直在用这些小短语来引导 agent 按我想要的方式做事。
我现在只是要求你在技能里持续的使用它们，然后在思考轨迹里观察 agent 是怎么采纳你的做法的。很多时候，如果 agent 没按你的想法来，你就需要让你的引导词更一致、更有力，同时去找其他引导词。因为英语就像一个相当宽泛的 API，有各种不同的函数可以调用，不同的东西可以尝试，而可选的引导词非常多。
agent 其实还挺擅长帮你想出这些词的。另一个你可以用的小手段是，有时候 agent 就是做的基础工作不够。我指的是，比如我们正在某个步骤上，这个步骤可能是去问澄清性问题或者去探索代码库，但 agent 就是做的不够，没有在那个步骤上投入足够的精力。一个非常典型的例子，而且我几乎在所有地方都见过，就是计划模式。
因为在计划模式里，我们有两个步骤：先问澄清性问题，然后创建计划。而在我试过的每一个计划模式实现里，我都发现问澄清性问题这一步就是基础工作永远做的不够。他看到自己的最终目标是创建计划，所以他只在问澄清性问题上做一点点基础工作，问你几个问题，然后就迫不及待地去创建计划了。那我的解决方案是什么？我不做计划模式，而是做了一个叫 Grill with Dogs 的技能，这基本上就是我的问澄清性问题阶段。
然后我把它拆成一个独立的技能，把计划部分也拆成它自己的技能。所以现在 Grill with Dogs 是一个独立的技能，Agent 只能看到流程的这一部分。等 Grill with Dogs 完成之后，我们再去做 RPRD。换句话说，我们有第一步和第二步，但 Agent 一次只能看到一个步骤。这是一个非常棒的技巧，通过隐藏未来的目标、隐藏未来的步骤，来增加当前步骤的基础工作量。
并不是总需要把技能拆成单个步骤，但在那些你特别想要额外多做一轮基础工作的场景里，没有比这更好的技巧了。效果非常非常好，好，这就是引导，用引导词把你想要的东西压缩成小而可复用的 token，然后确保每个步骤的基础工作量都做够了。现在我们进入减枝，减枝其实就是一组快速过一遍的失败模式，是各种你可能出错的地方。
第一个相当明显，我们不想要巨大的技能。巨大的技能通常是其他东西出问题的症状，是这些失败模式之一的症状。第一个很简单，不要重复你自己，你一定要留意重复。总的来说，我喜欢让技能的每个部分都有一个单一事实来源，也就是说，如果你有一份参考材料，比如 P R D 模板。或者更小的东西，比如什么是测试接缝，你要确保不会在好几个地方重复它，或者在多个地方覆盖多个步骤。
只要确保每个部分都有一个单一事实来源，不要重复自己。跨参考材料也一样。技能变大的下一个原因是冗余沉积。冗余沉积就是大家在同一个文档集上协作时的经典现象。每个人都往一个共享的 Markdown 文件里加东西，加自己的内容，又没勇气去删改别人的东西，最后就积累了大量冗余沉积，里面往往有跟技能无关的材料，尤其是那些没有好好整理过的东西。
对于一个有很多冗余沉积的技能，你首先需要看的是结构。这是你要做的第一件事，你要确保加进来的东西对所有分支都相关。如果不相关，就把它移到正确的分支里去；如果完全无关，也许就直接删掉，或者里面有些东西已经完全过时了，那就直接干掉。下一个失败模式在 Agent 帮你写技能时特别常见，就是无效操作，也就是技能里那些看起来在做点什么。
但实际上，在技能上下文中并不会影响 agent 行为的内容。假设我们有一个实现技能，里面有一整段告诉 agent 要写一个又长又详细的提交信息。如果你把那段话直接删掉，会怎样？agent 大概率还是会写出一份像样的、比较长的提交信息。很多人问我怎么把技能文件做得这么精简，其实就是用这些方法做删除测试，把内容压缩成引导词，确保里面没有无关的东西，也没有冗余沉积。
好，这样我们就完成了整个框架的梳理。第一，检查触发，确保它在正确的时机被激活，同时检查我们是否在施加上下文负载或认知负载。第二，结构方面要考虑分支，把内容组织成步骤与参考，并确保只跟某个分支相关的材料不要放在主 skill 点 md 里。第三，引导方面要把文本浓缩成引导词，并观察这些引导词是否出现在推理轨迹里。
同时还要考虑基础工作量，要不要把这个技能进一步拆分，通过隐藏后续阶段来增强他对当前阶段的专注度。最后是剪枝，对整个技能做一遍最终的剪枝检查，留意冗余沉积，留意垃圾内容，尤其要留意无效操作。要上手这套框架，最好的方式就在这个技能本身里，就在 Writing Great Skills 这个技能里，你可以去 My Pocket Skills 那边找到它，下载下。
用它来改进你自己的技能，甚至可以用它去审查一些社区编写的技能，看看你实际引入的那些技能到底好不好用。如果想持续关注我的内容，我在 ihero.dev 上有份 newsletter。接下来几个月的计划是发布一门 AI 编码速成课程，会系统介绍我刚才讲的很多内容，以及怎么上手用 AI 做工程开发。希望我今天分享的这些能帮你逃离技能地狱，或者至少试着走上那条艰难的出坑之路。
很抱歉没能亲自到场，感谢观看，我们很快再见。