Skill 优化的隐藏抓手：找到能牵引模型的那个词

公众号名称：AI 方寸山

作者名称：问答

发布时间：2026-06-23 08:48

最近在优化自己的一批 Skill，从 matt 那里学到了一个词：leading words，引导词。

他说：Skill 中，不要只写规则，要写“能被模型反复激活的概念词”。

直白说，就是要说专业领域的黑话。

比如：抓手，赋能，漏斗，沉淀，倒逼…

哎哎哎，跑偏了。此处的黑话可不是为了加密和故弄玄虚，而是一个能持续牵引 agent 行为的高密度概念词。

什么意思呢？

就是被高度浓缩过的、包含复杂行为和决策指引的一些词。

比如：写作时，要求采用“金字塔原理”的行文结构、“英雄之旅”的读者体验；写代码时，要求的“Clean Code、Deep Module”。

我看了几个比较好用的 skill，发现都不是一眼就能看懂的。毕竟，skill 是给 agent 的操作手册，而不是人类的。

提示词，本质是另一种编程语言，只是灵活度更高，没有特有的语法和结构。因为是要给大模型看的，所以好的提示词其实是对人类阅读不友好的。

以 /teach 为例，教你学习的一个skill。整份 SKILL.md 里提到 “zone of proximal development” 就 5 次。

这个词来自教育学，意思大概是：学习任务不能太简单，也不能太难，而要落在“用户感觉有挑战，但还没被吓住”的区域。

这比直接写一堆规则更强。

普通写法可能是：

教学时不要太难，也不要太简单。要根据用户当前水平调整难度。要循序渐进。要让用户保持参与感。

但如果写成：

Keep the lesson within the user’s zone of proximal development.

效果可能更好。因为这个短语背后压缩了很多教育学语义：因材施教、适度挑战、动态调整、避免挫败、保持学习动机。

模型看到这个词，不只是理解字面意思，还会激活它参数里和“教育理论”“好老师”“学习支架”“循序渐进”相关的一整片知识区域。

这个词，会“触发”模型内部相关的知识和行为模式。

而且更妙的是：你只写一次，模型却会在自己的思考里反复念叨它：“我先看看这是不是落在用户的最近发展区”“这个难度有没有超出他的最近发展区”。它从你单方面下的规则，变成了模型自己给自己下的命令。所以才会出现“只写 5 次，却管了全程”的效果。

因为一个 skill 文件不可能每一步都写死。真正有效的 skill 不是“穷举所有操作步骤”，而是放入几个能让模型自己延展的高质量概念锚点。

说到这里，有一个点挺反常识的。我原来的理解是，尽量在 skill.md 中避免重复的词，毕竟上下文宝贵。但实际学习和体验下来发现，一个好的引导词，在文中多次强调，反而效果更稳，这可能是反复强调下的场域的构成吧。

所以，好的 Skill.md 不是规则越多越好，而是要有一些高压缩率的行为概念，让 agent 在执行时能自己抓住它，并沿着这个方向展开。

那什么才是有效的引导词（黑话）？差不多有以下几个特点：

第一，它是一个领域里的术语，不是随便造的形容词。

第二，它能压缩一套方法论，而不是只表达态度。

第三，它足够短，方便模型在计划、反思、执行中反复引用。

第四，它带有方向性，能让模型知道应该偏向哪种行为。

第五，它最好能和任务场景强绑定。

简而言之，引导词就是你和模型的“共识”。

这些共识，会让你的 Skill.md 里少写“正确废话”，多放“行为锚点”，从而达到一个词就能触发一系列决策和行为。

比如：我的 skill 里原来写：

分析问题时要全面。 修改代码要谨慎。 注意兼容性。 添加必要测试。

好像都要求了，也好像都是正确的废话。

我根据 writing-great-skills 的要求修改后是这样的：

minimal invasive patch. call-chain first. observable behavior before implementation. test seam

如果你不是程序员，这几个词肯定看的云里雾里的，估计都得去问下 AI 这代表什么意思。

这就是高密度的复杂行为的引导词，这些词会迫使模型展开一套工程分析路径。

这背后可能隐藏着一个更深层的含义：

LLM 对语言的响应，不只是执行规则，而是被概念场牵引。

你给它一个普通规则，它会按规则做。
你给它一个高质量概念，它会调用围绕这个概念的一整套知识、风格和行为模式。

这就是为什么同样是 prompt，有些写法像说明书，有些写法像“人格和方法论注入”。

那怎么选词？能借就别造。

领域里现成的术语，模型在预训练里见过无数次，先验拉满，你白嫖就行。自己生造的词，模型一次没见过，等于零先验：你不解释，它就只能瞎猜，跟你写一句没人懂的形容词没区别。matt 自己也强调：先去找现成的词，实在没有，再考虑造。

为啥？借来的词，根本不用你定义。

就像前面那句：

修 bug 时遵循 minimal-invasive-patch；动手前先 call-chain-first；所有改动落在 test-seam 上。

test-seam 是 Michael Feathers 早就立住的词，call-chain、minimal patch 也都是工程圈嚼烂的概念，模型全认。你直接用就完事了，一句话顶你原来那三段“正确废话”。这时候你要再写段定义解释 test-seam 是啥，那才叫脱裤子放屁，因为模型比你还熟。

那词汇表（GLOSSARY）到底什么时候才需要？就两种情况：

1. 你真造了一个新词

   ，预训练里查无此词；

2. 你借了个词，但要把它摁死成一个特定意思：

   这个词在模型脑子里太常见、太多义，你不框住，它就按默认理解跑偏。

而且这两种情况下，词汇表里真正值钱的，常常不是那行定义，而是那句“别跟谁搞混”。这正是 writing-great-skills 的 GLOSSARY 在干的事：它给 module、seam 这些词写条目，每条都附一行 Avoid:，把模型往默认含义上的漂移死死按住。

举个例子。“完成”这词模型天天用，但它默认的“完成”特别松，跑通一次就敢跟你说搞定了。如果我想让 skill 里的“收工”是个硬标准，光写在规则里不够，得在词汇表里把它摁死：

## 收工（done）
满足以下全部，才算收工：
- 相关测试全绿，且新增了覆盖本次改动的用例
- 无新增 lint / 类型报错
- 关联 issue / changelog 已更新
- 临时调试代码、日志已清干净
别搞混：跑通一次、“看起来能用”、单测过了但没补新用例

这条才配得上写进词汇表，因为它不是在解释一个词，是在改写模型对这个词的默认理解。这才是自定义黑话唯一真正划算的用法。

说到底，规则是写给模型“这次”看的，引导词是写进模型“脑子”里的。前者你得一条条盯着，后者它自己会念。

我觉着这是个很好的方法，不仅降低 skill 的长度，还能让效果更稳。

聪明的你可能会反应过来，这不就是提示词工程刚出时的“遣词造句”吗？是的，殊出同归，毕竟只要输入给大模型的内容就是提示词，而 skill 只是打包提示词的方式。

但是大部分 skill 只是写规则写流程，很少有去思考和打磨一句话、一个词的。这就导致随着场景越来越多和复杂，导致 token 暴增和行为偏移。这就是我最近遇到的困境，所以看到引导词这个概念时很有感触，故写下来分享给大家。

写 skill，优化 skill，先试试，找到那个词。

感谢您阅读到这里，一起动手实践吧。

---

内容效果不满意？点此反馈