好的 skill 不是一段更长的提示词，而是围绕触发、结构、引导和剪枝设计出来的可维护 agent 操作接口。
AI Engineer / Matt Pocock
Agent skills 正在变成新的“教程地狱”。材料越来越多，仓库越来越多，别人分享的 skill 看起来都很有用，但真正拿来组合时，开发者经常不知道它为什么有效、什么时候该触发、哪里该删、失败时该怎么调。
Matt Pocock 把这种状态称为 “skill hell”。这场演讲真正有价值的地方，不是又给出一组可复制的 prompt，而是给了一个判断 skill 好坏的工程框架：Trigger、Structure、Steering、Pruning。换句话说，好的 skill 不是“写得更详细”，而是把 agent 的上下文、注意力和行动路径控制得更稳定。
很多人写 skill 时会直接进入正文：告诉 agent 要做什么、按什么步骤做、参考什么模板。但 Matt 的第一个问题更靠前：这个 skill 应该由用户显式调用，还是由模型自己判断是否调用？
这不是一个小配置，而是 agent 系统里的核心取舍：
| 触发方式 | 好处 | 代价 |
|---|---|---|
| Model-invoked | agent 可以自动发现并调用 skill | 每个 description 都进入上下文，增加 context load，也增加误触发或不触发的不确定性 |
| User-invoked | 上下文更干净，行为更可控 | 用户要记得何时调用，增加 cognitive load |
他把 model-invoked skill 的 description 称为 “context pointer”：它本身不是完整知识，而是放在上下文里的一个指针，告诉模型必要时去读更大的 skill.md。这个机制很强，但也危险。你每增加一个指针，就给模型多一个要考虑的入口，也多一个可能被忽略或错误调用的地方。
因此，skill 设计的第一条判断不是“自动化越多越好”，而是：这件事更应该消耗模型上下文，还是更应该消耗用户认知？
第二个框架是内部结构。Matt 认为，大多数 skill 都可以拆成两个主要单元：steps 和 reference。Steps 是 agent 要走的过程，reference 是帮助它完成过程的支持材料。
这个拆法看起来普通，但能解决很多 skill 变胖的问题。很多糟糕的 skill 会把流程、模板、背景知识、例外情况和历史补丁都堆进主文件，结果 skill.md 变成一个又长又难维护的混合文档。模型读进去以后，也不一定知道哪些是必须遵守的步骤，哪些只是必要时才看的参考。
更好的做法是先问三个问题：
这也是他为什么强调让 skill.md 尽可能小。小不是为了好看，而是为了降低维护成本、审计成本和 token 成本。主文件应该像控制面板，只保留稳定流程和必要判断；分支材料则通过 context pointer 在需要时再展开。
演讲里最有操作性的概念，是 “leading words”。Matt 的意思不是找一个漂亮标题，而是用一个短语压缩大量行为意图，让 agent 在推理和输出中反复引用它，从而改变执行方式。
比如 agent 写代码时常见的问题是横向铺开：先做全部数据库层，再做全部 schema，再做全部 API，最后才可能接上 UI。你可以告诉它不要这么做，但一长段解释很容易被稀释。更有效的做法，是用一个高密度短语，比如 vertical slice，把你想要的工作方式压缩进去。
好的 leading words 有三个特征：
这说明 skill 的 steering 不是“写更多规则”，而是设计能被模型复用的语言接口。英文被 Matt 称作一个很宽的 API：不同词会调用模型里不同的行为模式。skill 写作者的任务，是找到最能稳定触发目标行为的那几个词。
另一个很实用的技巧，是处理 agent 在某个步骤上不够用力的问题。Matt 举的例子是 plan mode：如果流程同时包含“提澄清问题”和“生成计划”，模型往往会急着奔向最终计划，只问一两个问题就草草进入下一步。
他的解法不是在同一个 skill 里反复强调“多问问题”，而是把流程拆开。先用一个只负责追问和读文档的 skill，让 agent 暂时看不到后面的计划目标；等这一步完成，再进入 PRD 或计划 skill。
这背后的原则是：agent 会被最终目标吸引。如果未来步骤过早暴露，当前步骤就可能被压缩。要让它在某个阶段做足 leg work，有时最有效的方法不是加规则，而是把后面的目标暂时藏起来。
最后一部分是剪枝。很多 skill 一开始能用，但随着团队不断往里加说明、补例外、贴模板，很快就会出现三类问题：重复、沉积和 no-op。
Matt 给出的维护原则很直接：每一块知识都应该有 “single source of truth”。模板不要在多个地方重复，定义不要散落在几个段落里，分支材料不要留在主路径上。否则 skill 会越来越像没人敢删的共享文档。
可以用一个简单的 deletion test 来判断某段文字是否必要：删掉它之后，agent 行为会不会变差？如果不会，它很可能是 no-op。No-op 最大的问题不是占几行字，而是让维护者误以为自己控制了行为，实际上模型根本没有因为这段话改变。
所以，真正成熟的 skill 工程不只是会写，也要会删：
这场演讲最值得带走的判断是：skill 不是提示词资产，而是 agent 的操作接口。它决定什么时候加载上下文、加载多少上下文、如何约束过程、如何调用参考材料、如何让模型在关键步骤上投入足够注意力。
这也是为什么组织层面会遇到 skill hell。没有 rubric，团队就无法判断一个 skill 是真的更好，还是只是更长、更热闹、更像文档。没有剪枝机制，skill 会像旧 wiki 一样积累沉积层。没有触发策略，model-invoked 的便利会变成上下文污染，user-invoked 的控制又会变成使用门槛。
Matt Pocock 给出的“missing manual”并不复杂，但很工程化：先定 trigger，再拆 structure，用 leading words 做 steering，最后持续 pruning。好的 skill 不是把所有知识都塞给 agent，而是把 agent 在正确时间引到正确上下文里，并让它用正确方式完成当前步骤。
Matt Pocock 的 Skill 地址： https://github.com/mattpocock/skills/tree/main