Skill 的两个问题：怎么写好，怎么管好

我一开始也不知道一个好 Skill 应该怎么写。

看起来这事很简单：写一个 SKILL.md，告诉 agent 什么时候用、怎么做、注意什么。真写起来就会发现，很多所谓 Skill 只是把 prompt 换了个文件夹。它说了一堆原则，但 agent 真开始干活的时候，还是不知道先读什么、怎么判断该不该触发、输出应该长什么样、最后怎么验证。

所以这篇其实只想说两个问题。

第一个问题：怎么写好 Skill。

第二个问题：Skill 多了以后，怎么管好。

我的答案都不复杂。

先学别人怎么写

不知道怎么写，就别先闭门造车。

我的办法很土：拿来主义。

先把公开的好 Skill 都收集过来，官方的、社区的、垂直领域的，都放进一个本地库里。不是为了照抄，也不是为了堆数量，而是为了看清楚一件事：那些真的有用的 Skill，到底共同解决了什么问题。

看多以后会发现，好 Skill 通常不是在给模型加人设，而是在改变工作流。它至少会说清楚：

• 什么任务应该触发它
• 触发以后要先收集哪些输入
• 中间按什么步骤走
• 最后输出什么形状
• 怎么证明这次真的做完了

再往下，好的 Skill 还会把边界也写出来：什么时候不要用，哪些文件先读，哪些脚本可以直接跑，哪些结果必须经过验证。它不需要写得很玄，越像一个能执行的工作手册越好。

这就是第一个问题的答案：先收集，再分析，最后沉淀成自己的规范。

再让 agent 管起来

第二个问题更现实。

Skill 少的时候，人脑还能记住。Skill 一多，就不可能靠记忆管理了。你会忘记已经有一个类似的，会重复写，会把临时有用的东西当成长期资产，也会把早就没人用的 Skill 留在库里占位置。

所以我直接让一个 agent 管。

需要 Skill 的时候，先查库。查到了，就用。查不到，才写一个新的。新写的先放在 young，别一上来就假装它是长期资产。用得多、有证据，再升到 core。长期不用，或者被更好的替代，就回收到 archive。

同一类任务也可以留两个版本试一段时间。不是靠感觉争谁更好，而是看谁被用得更多，谁更少返工，谁更容易通过验证。Skill 也应该有版本实验，不要一写出来就像立法一样不能动。

对外接口也应该尽量小。不是暴露一堆 search、audit、promote、archive 给普通 agent，而是只给一个意图：

我现在要做这件事，有没有能直接用的 Skill？

剩下的搜索、匹配、记录、临时生成、版本实验、后续回收，都让 Skill agent 自己消化。普通 agent 不应该为了用一个 Skill，还先学会怎么管理 Skill 仓库。

现在我做了一个很粗糙的 demo，代码放在 skill-library。它通过一个很小的 MCP server 接住任务意图，返回现有 Skill；没有强匹配时，也可以现场生成一个临时 young Skill。这个临时 Skill 不是最终答案，只是一张任务卡：先让 agent 干起来，后面再看它有没有长期价值。

我觉得重要的不是这个系统本身。

重要的是这个思路：不要把 Skill 当成神秘提示词，也不要怕 Skill 多。先收集，先用起来。好的留下，差的改掉，没用的回收。只要这条循环跑起来，库就会慢慢更像一个工具箱，而不是一个 prompt 垃圾堆。

很多事情都是这样。

一开始不知道怎么做，就先看别人怎么做。看多了，拆开，留下能复用的部分。等东西多了，就别再靠人脑硬记，让 agent 管起来。

不要怕。

干就完了。