装了 28 个技能，20 个从没打开过

技能的价值不在它写了多少知识，而在它有没有在该出现的时候被想起来。

前言

两个多月前，我给自己的 AI 编码环境装了一层“能力”：四五个上游仓库的技能包、一套协作工具链、几个记忆治理技能，再加上平台自带的。目录里躺着 79 个条目。

装的时候心态很简单——多一个技能，就多一种可能用上的能力。就像买工具箱，扳手、螺丝刀、内六角，先买齐，总有用得上的时候。

前阵子我想知道这些技能到底有没有被用上，于是写了个脚本，把本地两个多月的会话记录翻了一遍，只数一件事：skill 被真正加载的次数。

结果有点难看。

• 能正常加载的 53 个技能里，30 个一次都没打开过；
• 外装的 28 个技能，71% 从没打开过；
• 最近 7 天的 130 次加载，129 次是我自己写的技能；
• 全部加载量的 78%，集中在三个技能上。

我盯着这张表看了一会儿，第一反应是“白装了”，第二反应是——不对，问题可能不在“装”，在于我一开始就把技能当成了知识库。

有点像整理衣柜，翻出来一堆吊牌都还没剪的衣服。

先看账本

先把怎么数的说清楚，免得变成一篇只有感受的玄学。

统计对象是本地 365 个会话，时间从 2026-09-16 到 2026-11-09。只数 skill 工具的真实加载事件：一个技能被加载一次记一次，同一会话里重复加载重复计。目录里有多少个、我嘴上说有多少个，都不算。

再按来源拆开看：

（这里的 28 是安装数，和上表“有加载记录的 28 个”不是同一组，纯属巧合。）

这组对比就是整件事的起点：外装技能写得很全，但几乎想不起来用。

需要说明的是，这里的“没打开”只代表它没有被加载，不代表它没有价值——它可能作为参考手册被翻到过。但在 Agent 的工作方式里，没被加载就等于没生效：技能正文不会自动进入上下文，只有 name 和 description 会。

注：技能不是插件，装上不等于生效。它更像一张贴在墙上的操作卡，你得先抬头看见它，它才存在。

三个没想到

最大的三个，一次都没打开

外装技能里体积最大的三个，分别是 19.9 KB、18.4 KB、12.7 KB，主题是音频、云服务、测试。它们的加载次数全是 0。

我一开始以为是描述写得不好，后来发现更直接的原因：它们太长了。

技能正文越长，加载它的成本越高。而模型在“我大概知道怎么做”的时候，倾向于不加载。长文档天然劝退，除非它正好命中一个高频且具体的场景。

反过来，我自己写得最长的一个技能是 14 KB，加载了 4 次。因为它对应的是“每次导出本地化文案都要走一遍”的固定流程——场景极窄、步骤极多，正好需要文档。

所以判断标准不是“这份知识值不值得写”，而是“这个场景会不会重复发生到值得写”。

前三名吃掉八成

570 次加载里，前三名贡献了 443 次：

这三者构成了实际工作流的骨架：路由 → 读写通道 → 改动纪律。其余 25 个技能，合计只有 127 次。

说白了就是二八开。真正该改的不是“删掉没人看的”，而是“把前三名写得更准”。删掉 20 个闲置技能，省下来的只是目录体积；把路由的描述改准，影响的是每一次任务。

分水岭是“自己的事故”

最近 7 天的 130 次加载里，129 次是自建技能。这个比例高得有点可疑，于是我逐条看了外装技能的内容。

它们大多在讲通用工程正确做法：网络要服务端权威、数据要防注入、UI 要适配多端。这些都对，但它们是知识，不是动作。而我的工程有一堆非常具体、非常反直觉的约束：

• 部分对象由共享包管理，改错副本会被同步覆盖；
• 某个接口在未进入运行状态时调用，会触发一串关不掉的告警；
• 工具返回“成功”不等于改动真的落地了；
• 发布是两步：先发共享包，再发使用它的工程。

这些东西任何上游技能都不会写，因为它们不是通用知识，是这个工程踩出来的事故。

技能的价值，恰恰长在事故上。

为什么百科型技能必然失效

回头看，外装技能用不起来，大概有四个原因。

① 描述太宽，命中不了真实说法。

“用于相关开发任务”这种描述，在模型眼里等于没有描述。人不会说“我要做相关开发任务”，人会问“这个对象该在哪改”。

② 正文太长，加载成本高于收益。

一个 19 KB 的技能，全量读进来是一笔实打实的上下文开销。模型会本能地绕开它，除非任务真的卡住了。

③ 内容是知识，不是第一步。

好的操作手册第一句告诉你“现在去跑哪条命令”；百科第一句告诉你“这个概念是什么”。后者读完，你还是不知道从哪下手。

④ 和本地规则脱节，甚至冲突。

通用建议说“用文件同步工具管理代码”，而我的工程磁盘上没有源码。技能越通用，越容易在具体工程里给出错误的下一步。

四个原因叠在一起，结果就是：装得越多，可用的越少。因为每一次选择都变贵了。

我把能力拆成了四层

改法不是“多写技能”，而是把原来混在一起的东西拆开。现在我的环境里，四类信息各归各层：

画成图大概是这样：

规矩层  →  什么绝对不能做
流程层  →  这一步先做什么
记录层  →  凭什么这么判断
工具层  →  能不能用脚本代替记性

核心就一句话：规则写红线，技能写步骤，记录放别处，能用脚本就别靠记性。

我拿自己的规则文件做过一次体检：20 条规则里，只有 3 条既说清了什么时候触发，也说清了违反了怎么发现，其余 17 条的生效完全靠自觉。

那 17 条不是不重要，是没有触发器。

注：写规则之前先问三个问题——防住哪一次真实事故？在哪个动作前后触发？违反了靠什么发现？答不出第三个，就别放进正文，挪到记录里。违反了都发现不了的规则，只是装饰。

怎么写一个真会被用上的技能

如果只记一句，那就是：description 是触发器，正文才是内容。

技能开头那两行（name 和 description）会自动进入上下文，正文必须主动加载。所以描述写不准，正文写得再好也没人看。

一个可用的骨架长这样：

---
name: config-change
description: 当需要给配置表加列、加行、改 id，或遇到“导出后报错 / 这个 id 配错了 / 数据下发不出去”时使用。触发场景：加一列、加个条目、改配置、同步导表源头。
---

# 配置表变更

## 第一步
先确认权威源：改导表源头，本地副本只用于临时验证。

## 判定表
| 现象 | 结论 | 动作 |
| --- | --- | --- |
| 单条下发失败 | 该行 id 在权威表里不存在 | 先逐行校验，再上线 |
| 整批下发失败 | 全有全无的下发语义 | 不要逐条重试，先修表 |

## 红线
1. 表里只要有一行 id 失效，命中它的整批下发都会失败。
2. 改完必须同步回导表源头，否则下次导出会被覆盖。

## 反模式
- 只在本地副本上改完就宣布完成。
- 用“应该能发”代替一次真实的校验调用。

三条写描述的经验，都是踩出来的。

写用户的原话，不写分类名。 把“加一列”“显示不对”“点了没反应”“导出后报错”这些真实说法写进描述。用户不会说“配置变更场景”。

覆盖同义词，但别堆砌。 同一个动作常有三种说法，描述里至少覆盖两种。堆十个关键词反而会稀释信号。

别写“用于处理相关任务”。 这句话的信息量是零，还会挤占真正有效的触发词。

注：写完两周后数加载次数。零加载先改描述，不要急着加新技能——大多数“没被用上”不是内容问题，是触发器问题。

我也写废了一批

如果这篇文章只讲成功，它就不可信。

• 我自己写的 25 个技能里，10 个从没被加载过，占 40%；
• 11 月新写的 11 个流程技能里，只有 6 个真正被用过，其余 5 个还没形成使用习惯；
• 有两个技能功能重叠（一个讲读写循环，一个讲编辑器工作流），实际只有前者有流量；
• 还有 26 个条目因为软链指向空目录，根本加载不了，却一直占着目录位置。

最后一条最需要警惕。这类“看起来有、实际没有”的能力，比没有更危险，因为它会让人误判自己有什么。

我现在的判断标准更冷静了：

技能不是“我会什么”的清单，是“我下次一定会再走一遍”的路径。

只走一次的流程，写在文档里；会重复十次的流程，才值得做成技能。

注：清点技能时，先看它能不能加载，再看它有没有被加载。文件在、链接断了，这种“假存在”最难发现。

从个人习惯到团队资产

个人用和团队用是两回事。

我的技能一开始深度绑定这个工程：正文里全是内部规则编号、共享包所在工程的名字、绝对路径、对使用者的固定称呼。别人拿去直接用不了。

后来把工程专属的写法拆了出去，做法很笨但有效：

• 正文零编号：把「见规则 3.2」这类锚点删掉，判断标准本身留着；编号只在末尾的可删附录里保留追溯；
• 绝对路径清零：只写“工程根”“共享包所在工程”这类中性词；
• 一处示例代替硬编码：需要举例时写“本工程为 X”，而不是把 X 写死进每一步；
• 保留可删附录：换工程时整段删掉，不影响正文。

最后整理出 14 个技能、约 139 KB，放进团队的版本库。判断标准是一个乘法：

值得共享 = 用得多 × 别人用不上

用得多、又只对本工程有用的（路由、读写循环、改动纪律）必须进；用得少但只对本工程有用的（归属判定、交接、收尾）给新人用；通用百科型的不进——上游维护得更好，重复维护只会漂移。

注：技能想搬到别的工程，最大的障碍不是内容，是里面写死了太多这个工程的名字。凡是写死了工程名、路径、内部编号的地方，搬过去都会变成误导。

关于“插件”的一句实话

我确实把插件面收窄了：编辑器插件目录里只剩两个文件，其中一个在现在的做法里已经不是必需；Agent 侧只剩三个 bundle（其中一个还是记忆模块），外加两个外部工具服务。

但我不想把它写成“我删掉了 N 个插件”——我没有留下可核对的删除记录。能确认的只是“现在的技能库很窄”，不能确认“曾经删了多少”。

这两件事我得分开说，不然就成了编数据。

能确认的部分已经足够说明问题：技能库越窄，选择成本越低，真正有用的东西越容易被选中。

如果你想试一遍

四步就够：

1. 导出最近一个月的技能加载记录，按次数排序；
2. 圈出零加载的，先看描述，再看内容，最后才决定删；
3. 把你最常做、最容易出错的那条流程，写成第一个技能（300 行以内）；
4. 两周后复测：如果它进了前三，说明触发器写对了；如果还是零，改描述，别加新技能。

写在结尾

折腾这套东西两个多月，期间也没少怀疑自己是不是在配置上花的时间比省下来的还多——这句话我上次写规则体系的时候说过一次，这次还得再说一次。

但把加载记录按次数排开的那一刻，感觉还是值得的。哪些技能在干活、哪些只是占着目录，一眼就看得出来，没什么比这个更实在。

还有一些没想清楚的地方。比如技能该怎么在多人协作里共享，版本怎么管；比如“记得去加载某个技能”这件事，现在仍然靠描述写得好，有没有可能做成更像一套固定做法的东西。

以及一个更根本的问题：我到底是在给 AI 写操作手册，还是在借这个机会，把自己的工作方式重新梳理一遍。

目前倾向于后者。

感谢你看完了我的这点絮叨。

数据来自个人会话日志的离线统计，只来自我一个人、一个工程，结论不构成通用基准。技能名称与工程细节做了脱敏与简化处理。