现在 skill 多到下不完。热门的那些还打成了 plugin，一条命令装进来，分享和下载都方便得不像话。
热闹起来之后，围着 skill 的人也分出了好几拨：
- 有人以创建 Skills 为乐
- 有人以收藏 Skills 为乐
- 有人以使用 Skills 的过程为乐
- 有人以分享 Skills 的使用方法为乐
- 有人以通过 Skills 创造商业价值为乐
五种都成立，也都能各得其乐。我更想弄明白的是另一件事：这几拨人里，谁手上那份能力是别人替代不了的？
先从我自己的用法说起。我基本不会完整安装一个 plugin。碰到一个看着不错的 skill，我的动作是拆开看，不是装上用。看它的框架逻辑，看它用了什么技术手段，然后问自己两个问题：哪里值得学，哪里过度设计了？对我具体的场景，哪些是没用的，哪些是需要优化的？看完再按自己的需要，重新做一个更定制化的。
别人的工作流程，天然不是你的
这不是说那些 skill 不好。热门的 skill 必然有值得学的地方，它们考虑的情况比较周全，一些边界情况也想在里面了，而且会尽量设计得通用一些，好让每个人都能通过一定的定制，把它调到自己顺手的程度。
但也正是因为考虑了太多东西，理解起来并不是特别清晰和容易。
skill 就是一个人的工作流程，只是这个工作流程交给 agent 去实施。
工作流程这个东西是长在人身上的。你处理一份材料的顺序、你在哪一步会停下来确认、你踩过哪些坑所以多加了一道检查，这些都是你自己的。别人的 skill 再周全，装进来也只是别人的流程在你机器上跑。对我来说真正有用的部分，是它的框架逻辑和技术手段，不是那个文件本身。
写这一环，agent 比人合适
有意思的是，skill 由人来写，其实并不特别合适。让 agent 来写更好，因为它会把自己更关注的重点落到文件里。
但 agent 不能乱写。它有个毛病，喜欢加很多没必要的标点符号和加粗强调，把一个原本应该干净、对人来说非常可读的文件，写得晦涩不直观。这件事的后果比它看起来严重：文件一旦不方便阅读，就失去了被审查的可能性。
skill 是 agent 写的，但人一定要知道里面到底做了什么，在方向上跟人对齐。这条守不住，你手里就不是一份流程，是一个黑盒。
一份你读得下去的 skill，你才有资格说它写错了。一份你读不下去的，你只能选择信或者不信。
顺带说一句，skill 也在慢慢被模型内化。它本质上就是一个长程任务的工作流，而模型对这类任务的安排能力一直在长。
门槛落在拆解上
写既然可以交出去，剩下那份能力是什么？我认为是流程的拆解能力，而这是一个很重要的职场能力，不是什么 AI 技能。
具体说，就是面对一件复杂的事情，怎么把它拆成多个步骤、分动作去完成。每个动作要完成什么事、要拿到什么结果，才能进入下一个环节。而且中间并不是直接串联就能走完的，会遇到很多分叉、选择，或者计划的改变，这些都得在拆的时候想到。
尤其是那些没做过、还没固定下来的流程，需要把它提炼成 SOP。这件事本身就有门槛。如果是给人用的 SOP，人应该能做，这是基本功。
给 agent 的 SOP 要多一层：你得理解 agent 的能力上限和边界。
- 哪些它能做，哪些做不了；
- 哪些任务要拆得足够细，它才做得动；
- 哪些你给一个很粗的目标，它就能自己完成。
这三条判断不到位，拆出来的东西不是太碎就是太糙。太碎，你在替 agent 做它本来能自己做的决定，写了一堆废话；太糙，它就在你没交代的地方自由发挥。良好的拆分，是建立在对 agent 能力边界的理解上的。
还有一条我越来越常用的做法：skill 里除了纯文本的描述，对于那些固定的动作、需要确定性输出的环节，尽量写成可执行脚本，或者直接让 agent 写成脚本。脚本有清晰的输入和输出预期，偏离或者出错的可能性就会低一点。
这其实是拆解的最后一层：拆到某个动作已经没有判断余地了，它就不该再留在自然语言里，让模型每次现场重新推理一遍。该固化的固化，该留给判断的留给判断，这条线画在哪，是拆的人说了算的。
桥边的四种人
现在很多工作都可以围绕着 agent 展开，而 skill 是人和 agent 之间的一座桥。
开头那五种乐，换个说法就是这座桥边的几种人。有人是来造桥的，有人是过桥的，有人是给桥做维护的，还有人是通过这座桥过到对面去售卖东西的。每个环节对人的要求完全不同，最好当然是全才，但现实里不是。
我在部门里写过一些自认为有用的 skill，主要是做 paperwork 和一些相对固定的工作流程。分享给同事用，他们发现确实还挺好用。但每个人绝对会有特殊的需求，这时候就需要做一些定向的改造。
改造这一步，卡人的地方就出来了。如果连一个 skill 压根都看不懂，那就很难下手。当然也可以让 AI 去改，但改完之后某些方面的细节有没有被注意到，你是不知道的；何况在一个非常臃肿的 skill 里面改东西，成本本来就挺高。看不懂加上臃肿，两件事叠在一起，改的意愿就没了，最后大家又退回到"收藏"这一步。
所以不是每个人都要会造桥。但一个组织里，总要有一个人擅长做这件事，并且以之为乐，去推动大家先感受到三件事：原来 skill 是这样用的，原来 agent 是这么理解这个 skill 的，原来 skill 的创造并不复杂，只要用自然语言就可以。
这三件事一旦被感受到，事情就松动了。最重要的可能还是想明白自己到底要什么，然后把它拆解出来做成一个 skill。哪怕只有三五行，对于 agent 来说，它也可以是非常清晰的行动建议。
我的思考
写到这里，几个判断清楚了一些。
第一，收藏不等于拥有。 skill 很多，但很多人只是收藏罢了，并不会真正结合自己的业务或问题把它跑起来，去创造点新的东西。遇到 skill 不满足自己的时候，也少有人会动手去优化它。收藏这个动作有一种虚假的踏实感，好像能力已经进账了，其实只是文件进账了。
第二，可读性就是可审查性。 agent 写 skill 比人写更合适，但前提是写出来的东西人还读得动。一份堆满强调符号、结构缠绕的 skill，等于把审查权一起交出去了。让 agent 写，同时要求它写得干净，这不是两个要求，是一个。
第三，拆解是职场能力，不是 AI 技能。 能把一件复杂的事拆成一串有明确交付的动作，这在没有 agent 的年代也一样值钱。skill 的设计需要一个框架性的思考，需要对问题深入思考、剖析、反思的能力，这不是所有人都非常擅长。给 agent 写 SOP 只是把这项老能力挪到了一个新场景，附带多要求一条：你还得懂 agent 的边界在哪。
第四，总得有一个以之为乐的人。 一个组织里，造桥的、过桥的、维护的、过桥去卖东西的，可以是不同的人，分工本身没什么问题。但如果一个都没有人真的以创造这件事为乐，那再多的热门 skill 装进来，也只是把别人的工作流程搬进了自己的机器。
我自己还是更喜欢拆的那一步。装一个现成的 skill，最多让我省点时间；拆开一个别人的 skill 再重写一遍，我才知道自己那件事到底是怎么干的。这大概是这些工具给我的一个额外好处，它逼着我把一直没说清楚的东西，说清楚一次。