我删掉了 29 个 AI Skill 里的 23 个：留下的 6 个都有同一个特点

两周多前我写过一篇给 AI 安排 8 个岗位的文章，装了 30 多个 Skill，每个都有明确的分工设想。今天早上跑完每天的数据流水线，我顺手翻了一眼本机 30 天的调用日志，然后把 29 个 Skill 里的 23 个挪进了冷宫。

不是它们不好用。是日志告诉我一个我没想过的事实：这 23 个，过去 30 天的真实触发次数加起来只有 3 次------3 个各被用过 1 次，剩下 20 个连一次都没有。

而这台机器上每天雷打不动在跑的流水线，只靠 6 个 Skill 撑着。

今天这篇把整个盘点过程摊开：怎么盘、日志哪里会说谎、23 个分别是怎么死的、留下的 6 个凭什么活着。最后有一张我自己在用的「三问判定表」，你今晚就能对着自己的 Skill 库跑一遍。

一、先交代盘点方法，别学我只看日志

盘点本身不复杂，但有个坑：只看调用日志会误判。

我一开始就掉进去两次。第一次是发现 dws（我把每天的博客早报推送到钉钉用的 CLI 工具）在日志里是零调用------差点被判死刑。后来才想起来，我是直接在终端跑它的，根本不走 Skill 调用通道。第二次反过来：复盘日记的 Skill 日志里也是零，但我的复盘文件实打实存在，只是产物落在另一个目录。

所以最后我用了三条线交叉验证：

1. 目录盘点：列出 Skill 安装目录下所有文件夹，先把平台自带的 3 个管理类工具（创建 Skill、装依赖这种）剔除，剩下 29 个是我主动装的
2. 调用日志：查会话数据库里最近 30 天的 Skill 工具调用记录，按名字分组统计次数
3. 产物落点：翻最近一个月产出的文章、表格、图片，反查是哪个 Skill 参与的

盘点脚本的核心逻辑很短，会话数据库是 SQLite，用 Node 直接跑：

const { DatabaseSync } = require("node:sqlite");
const fs = require("node:fs");

const db = new DatabaseSync(
  process.env.HOME + "/Library/Application Support/QoderWork/data/agents.db",
  { readOnly: true }
);

// 我装的 29 个（目录盘点时已剔除平台自带的 3 个）
const installed = fs.readdirSync(
  process.env.HOME + "/.qoder/skills"
).filter((d) => !["create-skill", "install-skill-dependency", "qoderwork-guidance"].includes(d));

const since = Math.floor(Date.now() / 1000) - 30 * 86400;
const rows = db.prepare(`
  SELECT json_extract(item.value, '$.input.skill') AS name, COUNT(*) AS calls
  FROM messages, json_each(messages.parts) AS item
  WHERE messages.created_at > ?
    AND json_extract(item.value, '$.toolName') = 'Skill'
  GROUP BY name
`).all(since);

const calls = new Map(rows.map((r) => [r.name, r.calls]));
const report = installed.map((d) => ({
  skill: d,
  calls30d: calls.get(d) ?? 0,
  verdict: (calls.get(d) ?? 0) === 0 ? "零调用" : "有触发",
}));

console.table(report.sort((a, b) => b.calls30d - a.calls30d));

（node:sqlite 需要 Node 22+，老版本把 DatabaseSync 换成 better-sqlite3 一样跑。）

跑出来的结果是一个断崖：第一名 35 次，第二名 2 次，后面五个各 1 次，剩下的全是 0。

二、23 个是怎么死的：四种死法

把 20 个零触发的和 3 个孤例触发的挨个翻一遍，死因高度集中。我按「装的时候我在想什么」分了四类。

死法一：「以后会用到」型

装它的那一刻我是真诚的。看到别人的工作流分享，觉得这思路真好，装上，仿佛装上我就拥有了这个能力。

生活规划类、思维方法类的几个 Skill 全在这一档。安装日期集中在我看了几篇「AI 治愈了我的生活」类文章的那周。之后 30 天，零触发。

「以后会用到」是个谎言，它真正的意思是「我现在很焦虑，先收藏缓解一下」。这跟浏览器收藏夹里那 2000 个「以后会看」的网页是同一种心理。

死法二：一次性任务残留型

有个 Skill 是 VM 报错那天装的，当天确实解决了问题。还有内网调试、特定项目复现用的几个，全是这种情况------问题解决的那一天，就是它退役的那一天，但它一直躺在常驻目录里占着心智。

这类最迷惑，因为它「用过，而且好用」。判定它要问的不是「好不好用」，而是「同样的问题多久会出现一次」。一年一次的问题，配一个随取随用的方案就够了，不配常驻。

死法三：低频格式转换型

docx、pdf、pptx 这几个，30 天里总共被用了 1 次。不是没用，是使用频率撑不起常驻。

这类我处理得最果断：冷宫。要用的时候装回来是 30 秒的事，常驻的代价是每次列 Skill 清单时我都要在脑子里过一遍「这是干嘛的来着」。低频工具的存储成本不是磁盘，是注意力。

死法四：功能重叠型

盘点时发现有两个 Skill 的功能几乎是重叠的，都是「创建一个新的 Skill」的脚手架。一个是平台自带，一个是我后来从社区装的。社区版装完我就忘了，之后所有新建动作走的都是自带那个。

重叠的功能没有切换成本的时候，你只会用先习惯的那个。装第二个的那一刻，它的命运就注定了。

三、留下的 6 个，都有同一个特点

先看名单：

Skill	30 天证据	触发时机
博客流水线	35 次调用	每天早上 9 点定时
消息推送 CLI	日志零调用（CLI 直跑）	每天早报发完
文风处理	1 次调用	每次发文前
表格处理	1 次调用	每次客户交付
UI 产出	2 次调用	每次出图
复盘日记	日志零调用（产物在别处）	隔天一次

刚盘完的时候我以为结论会是「留下的是功能最强的」。完全不是。这 6 个里有 3 个功能很单一，甚至有两个在调用日志里根本查无此人。

它们真正的共同点只有一个：每一个都嵌在一条会自己发生的流程里。

• 博客流水线挂在每天早上 9 点的定时任务上，不管我记不记得它，9 点它就在
• 推送工具是流水线的最后一环，早报发完必然轮到它
• 文风处理和表格处理各自绑在「发文日」「交付日」这两个必然发生的节点上
• 复盘日记绑在「隔天」这个节律上

换句话说：这 6 个的存活，不取决于它们多好用，取决于它们各自有一个宿主流程。流程到点就跑，跑到它就触发。而冷宫里那 23 个，全部没有宿主------它们唯一的触发条件是「我某天突然想起来」，而人从来不会突然想起来。

这个判据比我预想的有用。以前判断一个工具去留，我下意识问「它好不好用」「我需不需要」------这两个问题全是主观题，答案永远是「万一有用呢」。换成「它有宿主流程吗」，变成客观题，30 天日志一翻就知道。

四、三问判定表（今晚就能用）

把上面的东西收敛成一张表。任何一个 Skill，问三个问题：

问题	怎么查	危险信号
1. 过去 30 天有几次真实触发？	调用日志（注意 CLI 直跑和外部产物不算 0）	0 次，或只有 1 次
2. 它有固定的触发时机吗？	有没有挂在定时任务/流程环节/周期性节点上	触发条件是「我主动想起来」
3. 它的输出进了固定产物吗？	文章、表格、代码库、报告里能不能找到它的痕迹	输出没有被任何下游消费

三问全红，进冷宫。两问以上红的，标记观察，下个月盘点再判。

两个补丁：

• 日志会说谎。CLI 直跑的工具不走 Skill 通道，有的产物落在别的目录。触发数据要三条线交叉验证：调用日志、终端历史、产物反查。单看任何一条都会冤枉好 Skill。
• 孤例触发不算活着。30 天里被用过 1 次的，和 0 次没有本质区别------那是「一次性任务残留」，不是使用。我冷宫里就有 3 个是这样的：确实用过，好用，但那件事结束了。

五、我不站「全部清空」那一派

写这篇之前我去看了下别人怎么处理这个问题，大概分两派。

一派主张每半年把配置全清空 ，连上下文文件带 Skill 带钩子一起清，理由是「模型自己会想办法，清空了它会重新长出来」。这个思路对纯聊天场景可能成立。但我的流水线不行------那 6 个宿主 Skill 一清，每天早上 9 点的定时任务直接空转，日志和粉丝数据当天就断。清空的前提是你没有任何自动化在依赖它。有流水线的人清空，烧掉的不是冗余，是正在下蛋的鸡。

另一派是囤积派，看到 28.8 万 Star 的仓库就想装，看到「10 个必装」就想凑齐。Superpowers 现在 28.8 万 Star、Anthropic 官方 Skill 库 17.7 万 Star，生态确实繁荣------但生态的繁荣是供给端的繁荣，跟我硬盘该装几个没有关系。收藏 100 个 Skill 和掌握 100 个 Skill 之间，隔着 100 条宿主流程。

我站中间：按宿主流判去留，归档不删除。冷宫就是一个普通文件夹，23 个 Skill 原样躺在里面，SKILL.md 一个没删。哪天真有一条新流程需要某个技能，30 秒搬回来。删除是情绪化的仪式感，归档是工程化的决策------可逆，且不装深情。

六、写在最后

这次盘点最大的收获不是清单变短了，是那个判据：工具的存活不该取决于它的质量或我的自律，该取决于它有没有一个会自动发生的流程做宿主。

反过来说，想让一个好工具留下来，光「装上」是没用的，得给它修一条流水线，让它自己跑到必须用它的位置上。我留下的 6 个里，每一个背后都是我先搭流程、它才有位置的。

你有自己的 Skill 库吗？今晚翻一眼，评论区报个数：装了多少个，30 天零触发的有多少个。我猜这两个数字的差距，会比大部分人愿意承认的大。

---