Skill不是万能筐

征哥的知识架构笔记/Skill设计/产出形态分类

你打开自己的Skill文件夹看看——有工具说明书，有SOP，有思考框架，有风格档案，甚至还有一份公司请假制度。什么都往里塞，什么都叫Skill。

核心判据

这个Skill跑完，产出的到底是什么东西？

▾混乱现场

这不就是"代码什么都能干，那我干出来的什么都行"吗？

Skill确实什么都能装——它本质上就是一个Markdown文件，Agent运行时加载进去的上下文。但"什么都能装"不等于"装什么都对"。你写代码的时候，不会把工具类、业务逻辑、配置文件全塞一个package里吧？那为什么写Skill的时候，就眉毛胡子一把抓了？

ClawHub上两万多个Skill，下载量高的不一定好用；awesome列表按领域堆了几百个，但你看不出缺口在哪；社区里甚至有人专门写了5条标准，教你怎么"5秒判断一个Skill值不值得装"——这说明什么？说明Skill的质量已经混乱到需要"筛选标准"来救场了。

问题不在Skill本身，在于你设计Skill的时候，根本没想过一个问题：这个Skill跑完，产出的到底是什么东西？

▾为什么乱？因为切面没对齐

Skill分类不是没人做过。恰恰相反，做的人太多了——但每个人切的不是同一刀。

Anthropic Claude Code团队的Thariq，按Skill在工程流程中扮演的角色，切了9类：Library & API Reference、Product Verification、Data Fetching & Analysis、Business Process……一路排到Infrastructure Operations。这是角色切面——Skill在流水线上站哪个工位。

awesome-claude-skills列表呢？按应用领域分：代码、写作、数据分析……这是领域切面——Skill服务于什么业务。

arXiv上的综述论文，按生命周期分4个阶段：Representation、Acquisition、Retrieval、Evolution。这是时间切面——Skill从出生到退场经历什么。

Reddit上还有一派，按形态分：task还是character？这是形态切面——Skill长得像什么。

四把刀，切的是同一块蛋糕。但它们切的是蛋糕的不同正交属性——角色是横切，领域是竖切，时间是纵切，形态是斜切。你把四种切法强行合并成一套，必然乱。

而且你仔细看Thariq的9类，一个有意思的发现：9类里面6-7类都是流程类，1类是知识类，1-2类跨类。按角色分，流程类天然占大头——因为工程团队嘛，干的活就是流程。但这个切面有一个致命盲区：它区分不了"流程"和"方法论"。而这恰恰是开发者最容易搞混的边界。

所以乱的本质不是"没人分类"，而是"大家在不同维度上分类，然后试图拼成一张图"。拼不上的。

▾一把尺子：产出形态

既然多切面合并必然乱，那就用单一判据。判据是什么？

问自己一个问题：这个Skill跑完，产出的是什么东西？

答案只有三种：

① 知识类

产出是"被查询的资料"。查得到、用得上，但不直接产出动作。比如一份工具说明书、一份公司请假制度、一份API字段说明。Agent需要的时候来查，查完就走，不动手。

② 流程类（SOP）

产出是"被执行完的动作"。照做就完，不要求理解为什么。比如一个代码审查流程、一个部署链路、一个PR盯梢流程。步骤是确定的，每一步都有明确输出，跑完就是跑完了。

③ 方法论类

产出是"被参考的思路"。教你怎么想，不保证能落地成具体动作。比如"遇到模糊想法该怎么想清楚"的task-alignment，比如"如何判断一个架构决策对不对"。思路给你了，但具体怎么干，你自己定。

三种形态，穷尽且互斥——一个产出，要么是"被查询的资料"，要么是"被执行的动作"，要么是"被参考的思路"。不可能同时是查询资料又是执行动作，也不可能是执行动作又是参考思路。分类法成立。

知识类的三子类

工具说明书 —— 工具/CLI/MCP怎么用

领域知识 —— 某领域的事实/规则/资料

风格·人格档案 —— 某个人/角色的做事方式与品味

第三种子类是社区里的热点——VoltAgent的taste-skill、Reddit上的"蒸馏同事"现象，争议很大，有人觉得该单列一类。但按产出形态判，风格档案的产出就是"被查询的资料"——Agent写脚本时来查"征哥会怎么说"，查完走人。和工具说明书同构，归知识类子类就够了。

Thariq自己也说过："最好的Skill通常能干净地归入某一类；而那些让人困惑的Skill往往横跨多个类别。"他按角色分9类，还是会出现"横跨"——因为9类的判据不统一，有的按角色，有的按场景。产出形态这把尺子，判据只有一个，横跨的问题自然消失。

▾那把最难的刀：流程vs方法论

三类里面，知识类最好认——产出不动手，查完就走。真正难的是流程类和方法论类之间的那条线。

有软件工程方法论， 不等于能开发一个软件。

方法论管的是"对不对"——架构该怎么做决策、需求该怎么拆解、技术选型该遵循什么原则。但"对不对"和"怎么干完"是两件事。你知道敏捷方法论，不代表你能跑完一个Sprint；你知道微服务原则，不代表你能把一个单体拆干净。

流程类（SOP）呢？拿过来就能干。步骤是具体的、可描述的、可执行的。每一步干什么、输出什么、怎么判断过了，都写清楚了。

但这里有个容易绕进去的坑：一个SOP内部可以调用方法论。

比如"部署一个服务"这个SOP，内部会调用"如何判断该不该回滚"的方法论。再比如Anthropic内部的babysit-pr——盯PR全流程的SOP，内部调用了"如何判断PR是否ready"的方法论。那它到底是流程类还是方法论类？

看产出形态。它跑完的产出是"PR被合了或者被退了"——这是一个被执行完的动作。所以它是流程类。判据看产出形态，不看内部成分。

反过来，有人把"如何做代码审查"写成方法论类Skill——教你怎么想、该关注什么、用什么视角。但实际产出是"审查完的代码报告"。这是流程类的产出形态。写法错了，Skill触发的时候Agent不知道该"想"还是该"干"，结果就是混乱。

还有人把"如何思考产品需求"硬写成流程类Skill——列了一堆步骤，但每一步都没有确定输出。Agent执行到某一步，卡住了：下一步该干嘛？不知道，因为这不是SOP，这是方法论。你硬把它压扁成步骤，Agent反而跑不动。

SOP是拿过来就能干的，方法论是教思路但不保证能落地的。混淆这两类，不是分类问题，是设计问题——你用错了模式。

▾三类Skill，三种设计标准

分类不是贴标签。分类的真正价值在于：不同类型的Skill，设计标准完全不同。你用同一套标准去设计三类Skill，和眉毛胡子一把抓没有区别。

知识类：查准就行

知识类Skill的核心指标是检索命中率和信息密度。Thariq在官方博客里说得很清楚：Library & API Reference类Skill的核心不是通用文档，而是"gotchas列表"——团队里人人知道、但模型默认不知道的踩坑点。Claude本来就会写代码，你把API文档全文贴进去，它自己查得到，写了反而增加上下文负担，不增加任何价值。

Description字段是触发条件，不是简介——"当用户需要翻译英文文档时触发，不适用于日常短句翻译"。写准触发条件，Agent才知道什么时候该来查你。

流程类：跑通就行

流程类Skill的核心指标是步骤确定性和容错。每一步干什么、输出什么、怎么判断过了，都得写清楚。Thariq甚至说Product Verification类Skill是"所有类型里最值得花力气的"——Anthropic建议让工程师花一整周专门打磨验证Skill。关键是在每一步加程序化状态断言，不靠"看起来差不多"。

但流程类有一个容易踩的坑：写得太死。Thariq明确说"别把Claude钉死在固定轨道上"——SOP需要留判断空间。Runbooks类Skill的入口不是"我要写什么"，而是"现在出了什么症状"——报警进来，它负责映射到工具和路径。症状到路径之间，需要Agent自己判断。

方法论类：用对思路就行

方法论类Skill的核心指标是启发性和可迁移性。这是现有内容最缺的一块——Thariq的9类里几乎没有纯方法论类Skill，因为Anthropic内部是工程团队，方法论被内嵌在流程类Skill中。但在个人PKM场景下，方法论类Skill是刚需。"遇到模糊想法该怎么想清楚"的task-alignment，"如何判断一个架构决策对不对"的决策框架——这些不是SOP，你硬写成SOP，Agent执行时卡在"下一步该干嘛"；你当知识查，查到了也不知道怎么用。

错配的后果

用流程类的标准去要求方法论类，只会把思路压扁成步骤，Skill变成"伪SOP"；用知识类的标准去要求流程类，步骤变成了参考资料，Agent查到了但不执行。类型决定了设计标准，标准决定了Skill能不能用对。

▾跨类的Skill，该拆了

Thariq的原话："最好的Skill干净地落进一类；想干太多事的会跨好几类，把agent搞糊涂。"

一个Skill如果三类都塞不进去，先检查是不是判据用错了。如果确实横跨了两类——比如既查资料又跑流程，既教思路又执行动作——那不是分类法的问题，是Skill本身的设计问题。该拆。

拆的依据还是产出形态：哪个产出是主导形态，就归哪类；如果两个产出都重要，那就拆成两个Skill。一个Skill干一件事，干干净净。

分类不是目的。目的是让你在设计Skill之前，先想清楚"这个Skill跑完，产出的到底是什么东西"——想清楚了，类型就定了；类型定了，设计标准就对了；标准对了，Skill才不会变成万能筐里的又一个杂物。

这套法目前覆盖个人PKM场景，迁移到团队/工程仓库时，流程类可能需要按Thariq的方式细分子类——Verification、Runbooks、CI-CD各管各的。边界附近的Skill（比如"怎么造Skill"的skill-creator，半流程半方法论），归类靠主导形态判断，未来可能需要更细的判据。

核心判据不会变：产出形态。

一个Skill跑完，产出的是什么？答案只有三个——被查询的资料、被执行的动作、被参考的思路。拿这把尺子量，就不会乱。

#征哥的知识架构笔记 #得到大脑

20年研发老兵 · 资深架构师 · QCon/SACC/msup Top 100 讲师