Matt Pocock 演讲逐帧拆解：好 Skill 和坏 Skill 的差距就在这 4 个维度
Matt Pocock 演讲逐帧拆解：好 Skill 和坏 Skill 的差距就在这 4 个维度
你的 skill 明明写得很清楚，但 agent 就是不按你说的做。问题不在 agent——在于你还没掌握「引导词」这门手艺。
你有没有经历过这种绝望：下载了一堆 AI coding 工具，装了二十个社区 skill，以为从此开发效率要起飞了。结果发现 agent 要么根本不调用你的 skill，要么调用了也不按里面的流程走，要么产出的东西和 skill 里承诺的效果差了十万八千里。
如果你有过这种感受，恭喜你——你正困在 Skill Hell 里。
这个概念来自 Matt Pocock（Matt Pocock Skills 作者，目前最流行的工程 skill 集合之一）在一场技术演讲中的分享。他把这种现象命名为「Skill Hell」，是继 Tutorial Hell（教程地狱）和 Framework Hell（框架地狱）之后，AI 时代开发者面临的第三种困境：
- Tutorial Hell：疯狂看教程，但拼不出一套完整的东西
- Framework Hell：每十分钟出一个新框架，永远在追热点
- Skill Hell：几百个免费 skill 摆在面前，但你不知道哪些真的好用、哪些只是占坑，更不知道它们各自的那一套流程为什么总是打架
问题的根因很简单：我们没有一个评判 skill 好坏的标准。没有人告诉你"看一个 skill 的时候应该关注哪些维度"。于是社区里充斥着大量看似有内容、实际对 agent 行为零影响的 skill。
Matt 给出的答案是：一份 4 维度的 Skill 检查清单。
一、Trigger（触发）：你的 Skill 该让谁按开关？
这是 skill 设计的第一道选择题——你的 skill 是 用户手动调用（user-invoked），还是 模型自动判断激活（model-invoked）？
两种模式的区别
技术上，区分两者的关键是一个叫 context pointer（上下文指针）的东西——就是 skill 的 description 字段。如果 skill 包含 description，它就会常驻在 agent 的系统上下文中，agent 可以根据描述自动判断"我现在需要调用这个 skill"。这是 model-invoked 模式。
如果不写 description 或者显式设置了 disableModelInvocation: true，那这个 skill 就只是一个躺在文件系统里的 .md 文件，agent 不会主动去读——除非用户通过 /skill-name 或自然语言明确要求。
关键权衡：Context Load vs Cognitive Load
每种选择都有代价：
| 选择 | 代价 | 典型代表 |
|---|---|---|
| Model-invoked | Context Load（上下文负担）：每多一个 model-invoked skill，agent 的上下文就多一条 description，耗费 token 不说，还增加 agent 的决策负担 | Superpowers |
| User-invoked | Cognitive Load（认知负担）：用户需要记住有哪些 skill 可用、什么情况下该用哪个 skill | Matt Pocock Skills |
Matt 的选择是偏好 user-invoked。原因很直白：model-invoked 带来的是不可预测性——即使某个 skill 完全适用于当前任务，模型也可能"选择不调用它"。你无法 100% 确定你的 skill 会在正确的时间被激活，除非你专门去做 eval 测试。而对于大多数个人开发者来说，做 skill 级别的 eval 几乎是不可能的。
Tip #1：在 user-invoked 和 model-invoked 之间做一次有意识的决策，而不是随大流。
二、Structure（结构）：Skill 里只有两种东西
Matt 提出了一个极其简洁的 skill 内部模型：任何 skill 都可以拆成两种基本单元——Steps（步骤）和 Reference（参考资料）。
- Steps：skill 按顺序执行的操作流程
- Reference：辅助执行步骤的静态资料——模板、术语表、检查清单、PRD 模板等等
有些 skill 只有 Steps（比如一个纯流程 skill），有些只有 Reference（比如一个术语表 skill），但大多数 skill 是两者的组合。
以 Matt 的 to-PRD skill 为例：
- Steps（3 个）：寻找相关上下文 → 和用户确认测试场景 → 写 PRD 文档
- Reference（2 个）："什么是测试场景"的说明 + PRD 模板
让 skill.md 尽可能小
Tip #3：skill.md 是 skill 的核心文件，让它越小越好。
小的 skill.md = 更好维护 + 更容易审查 + 更少 token 消耗。每砍掉一个不必要的词，就是替用户省了好几次调用的 token。
Branches（分支）：skill 的不同使用路径
让 skill.md 变小的关键技术，是识别 skill 的 branches——不同的使用场景分支。
举个例子：
to-PRD只有一个 branch：永远创建 PRD → 所有 reference 都应该在主 skill.md 里Domain Modeling有两个或三个 branch：更新 context.md / 创建 ADR / 也可能什么都不做 → ADR 模板和 context.md 模板不需要常驻主 skill.md
对于多分支 skill，把只在特定分支有用的 reference 外置为独立文件，通过 context pointer 按需加载。Matt 管这叫 External Reference——一个"如果你需要 X 就去读那个文件"的指针。
核心操作：把分支专属的参考资料藏在 context pointer 后面。
三、Steering（驾驭）：让 Agent 真的听你的
这是整场演讲里最值钱的部分。Matt 用两个技术解决了"skill 写得很清楚但 agent 不照做"这个千古难题。
技术 1：Leading Words（引导词）
Leading Words（德语文学理论中叫 Leitwort）是一种自带"压缩包"效果的词或短语——你用短短两三个词，就能激发 agent 激活一整套行为模式。
Matt 举的例子是 "vertical slice"（垂直切片）。每个工程师都知道 agent 有一个经典毛病：拿到一个任务后逐层编码——先写数据库层、再写 schema 层、再写 API 层、再写前端……而不是像人一样先做一个最小可工作的端到端切片。
如果你只在 skill 里写"不要逐层编码，先做一个小功能再扩展"，agent 大概率还是逐层来。但如果你在 skill 里反复使用 "vertical slice" 这个 Leading Word：
用 vertical slice 的方式来实现功能
先做一个 thin vertical slice 验证全链路
每个 vertical slice 完成后再扩展下一个
效果验证方式：去 agent 的 reasoning traces 里看——如果 agent 在思考过程中自己说出了 "let me approach this as a vertical slice"，那就说明 Leading Word 起作用了。Agent 在自我复述这个短语的过程中，会被自己的"推理"引导到正确的行为模式上。
Matt 说几乎所有听过这个技巧的人都回应"哦对，我其实一直在下意识这么做"。他的建议是：从现在开始，有意识地在 skill 里保持一致、有力的 Leading Words，并去 reasoning traces 里检验它们是否真的生效。
他还有一个很妙的比喻：英语就像一套有着巨大 API 的编程语言，不同的词就是在调用不同的"函数"，而 Leading Words 就是那些最常用、最可靠的函数名。
技术 2：Legwork（工作量）——隐藏终点让 Agent 走好当下的路
另一个常见的问题是 agent 在某个步骤"不够用力"。
Matt 举了一个他称之为"无处不在"的经典案例：Plan Mode。几乎所有 Plan Mode 的实现都有两步——先问澄清问题，再写计划。但 agent 知道自己的终极目标是"写出一个计划"，所以它在第一步（问澄清问题）上总是浅尝辄止——问一两句就急着跳到第二步。
Matt 的解法是把计划流程拆成两个独立 skill：
grill-with-docs：纯提问阶段，agent 看不到"写计划"这个后续步骤to-PRD：拿到足够信息后，才进入写文档阶段
核心原理：当你让 agent 只看得到当前步骤时，它会在这个步骤上投入更多"腿力"——因为它没有捷径可抄。
这不是每个 skill 都需要做的事，但在那些"第一步总是做不好"的场景里，这是唯一有效的解法。
四、Pruning（精简）：砍掉不起作用的内容
一个 skill 的臃肿往往是其他问题的症状，而不是原因本身。Matt 指出了三种最常见的失败模式：
1. DRY（重复）
同一份 reference material 出现在多个地方。解法：单一事实来源（Single Source of Truth）——每个信息只在一处定义。
2. Sediment（沉积）
多人协作的产物——每个人都在往同一个 markdown 文件里加东西，但没人敢删别人的内容。日积月累就变成了沉积层。解法：按 branches 归位，或者直接删除过时的东西。
3. No-ops（空操作）
这是 Agent 生成 skill 最容易出现的毛病。 No-op 是指 skill 中那些"看起来在说点什么，但删掉后 agent 的行为完全不变"的内容。
Matt 给出了一个实用的 Deletion Test：假设你的 skill 里有一整段告诉 agent "要写详细的长 commit message"。删掉这段。Agent 大概率还是会写正常的 commit message——因为这是它从训练数据里就会的基本行为。
凡是通过 Deletion Test 的内容，都是 no-op——大胆删。
检查清单回顾 + 行动指南
把四步串起来，就是一份完整的 Skill 质量审查清单：
- Trigger：决定 user-invoked 还是 model-invoked，理解你付出的代价（context load 还是 cognitive load）
- Structure：Steps + Reference 两单元 → 识别 branches → 外置分支专属 reference → 让 skill.md 尽可能小
- Steering：提炼一致的 Leading Words → 去 reasoning traces 验证 → 必要时拆分 skill 增加 legwork
- Pruning：查 DRY → 清沉积 → 做 Deletion Test 删除 no-ops
一条建议
如果你现在手头有正在维护的 skill，立刻拿这份清单过一遍。Matt 已经把整套方法论编码成了一个叫 writing-great-skills 的 skill（就在他的 Matt Pocock Skills repo 里），你可以直接用它来审查和改写你的 skill。
如果你对 AI 工程化开发感兴趣，Matt 还在 aihero.dev 有一个 newsletter，接下来几个月会发布 AI Coding 速成课程。
本文基于 Matt Pocock 演讲 "Building Great Agent Skills: The Missing Manual"（原定于 AI Engineer World's Fair 发表）改写。配图为视频截图。
声明：本文中所有截图均截取自 Matt Pocock 的 YouTube 原视频，仅用于教学评论和内容分析目的，版权归原作者所有。
浙公网安备 33010602011771号