从 2025 年 10 月 Anthropic 正式发布 Claude Skills 算起，到现在也就大半年时间，Agent Skills 已经成了 AI 圈最热的关键词。打开小红书、抖音，铺天盖地的不是“必备 Skills”就是“超好用的 Skills”，再不然就是“宝藏 Skills”；企业端更夸张，腾讯 WorkBuddy、QClaw 以及不少大厂内部都掀起了“Skills 运动”，直接给员工下 KPI 让人提交 Skills。这股热潮来得快，消耗得也快，最近甚至开始有点退烧，但我越看越觉得，很多讨论的出发点是反的。

这里想系统聊一下我的看法：通用型 Skills 终将被用户无感知，自己给别人写通用 Skills 没多大价值，未来真正值钱的，是被精打细磨过的领域知识技能包。

先给 Skill 分个类

谈演进趋势之前，得先把 Agent Skills 分清楚。在我看来，Skills 应该明确地分成三类，各自的演化路径完全不同：

一、通用工具型 Skills（工具类）

最常见的一类，也是社区里写得最多的一类。它们要么是某个 CLI 工具的配套 Skills（教 Agent 怎么用这个工具），要么是把开放世界的通用知识沉淀成可复用的指导包。典型例子：

• commit-message-writer：根据 git diff 生成 commit message。
• pr-reviewer：根据 diff 做 PR 审阅。
• readme-generator：给项目生成 README。
• gh-cli-skill：把 GitHub CLI（gh）的各种子命令、参数、典型场景封装成 Skill，让 Agent 知道什么时候该用 gh pr create、什么时候该用 gh issue close。
• lark-cli-skill：把飞书/Lark CLI 的命令体系封装成 Skill，让 Agent 能熟练处理消息、文档、日程、审批等通用协作场景。

这一类 Skill 的本质是把通用工具链 / 开放知识和大模型接起来。它们的共同特征：

• 不依赖业务上下文。
• 任何一个开发者拿过去都能直接用。
• 写起来最容易，也最容易撞车。

二、领域专家型 Skills（业务专家多年的经验，精打细磨）

这一类是真正的硬通货，但社区里讨论得最少。典型例子：

• 跨境电商的 Listing 写手，知道怎么写标题能过平台审核、关键词怎么布局能拿自然流量。
• 律所的合同审阅，知道哪些条款是高风险、哪些表述有合规隐患。
• 医生的病历摘要，知道哪些信息该留、哪些该隐、术语怎么规范化。
• SRE 的故障复盘，知道一份合格的复盘文档应该有哪些字段、哪些归因、哪些改进项是必须有的。

这类 Skill 的共同特征：

• 强依赖行业 know-how，不是模型能凭空生成的。
• 写得越细，越值钱；写得越粗糙，越没价值。
• 复用频率极高，因为同行业的同类任务会重复出现。
• 质量方差极大，不固化就一定会漂。

三、个人专属 Skills（私有记忆 + 个人习惯）

最后一类是只服务于一个人的 Skill。典型例子：

• 把自己的工作记录、个人偏好、常用链接、踩过的坑沉淀成 Skill。
• 给自己定制的写作风格、汇报模板、思考框架。
• 把零散的 dotfiles、shell 历史、IDE 配置背后的 why 沉淀下来。

这一类 Skill 的特征：

• 别人拿过去基本用不上。
• 但对本人来说价值极大，相当于把个人经验外置成了一个可以随时调用的协作者。
• 写起来最私人，也最难被商品化。

一个反共识的判断：通用型 Skills 终将无感知

社区里很多人在教如何写一个通用 Skill，我反而认为：

用户对通用型 Skills 应该是无感知或轻感知的，自己给别人写通用型 Skills 可能没有多大价值。

为什么这么说？因为通用工具型 Skills 注定会走一条被集成、被吞并的路。

第一，通用工具本身就不稀缺。任何人基于公开规范，几天就能写出一个 commit-message-writer。这类 Skill 的护城河几乎为零，今天能写出来，明天别人也能写出来。

第二，工具类 Skills 一定会被官方/平台收编。当某个 Skill 真的被大规模使用，它的下一个版本一定是直接集成进 CLI/IDE/Agent Runtime 本身，而不是继续作为 Skill 存在。回顾工具发展史，所有插件化的东西，最终都会被原生化。

更进一步，官方工具配套 Skills 应该由官方自己维护、用户无感使用。以 gh-cli-skill 为例：用户根本不需要感知它的存在——只要基于 AI Agent 调用 gh 命令，Skill 就会自动从 GitHub 官方拉取最新版本。如果反过来让用户自己去搜、自己装、自己同步，那才是反人性的设计。同理，lark-cli-skill 应当内置在飞书/Lark 官方客户端里，随官方升级自动迭代——用户不知道原来还有个 lark-cli-skill 才是最理想的状态。

第三，架构上通用 Skills 注定走向集中托管。Skill 的本质就是一堆 Markdown + 脚本，每个用户本地仓库都在重复存放完全相同的内容。理想的做法是：纯提示词（Markdown）部分内炼进 Agent Runtime 或 LLM Server，由服务端统一托管、按需下发；只有那些必须在本地执行、组装本地上下文的脚本才留在客户端。在当前 Agent 架构下，客户端是唯一的折中点（脚本必须本地跑、上下文必须本地组装），但服务端化是必然趋势——没人愿意在 100 台机器上维护 100 份一模一样的 commit-message-writer。

第四，通用 Skills 缺少评价机制，未来一定会长出 “Skills大众点评” 这类东西。官方工具配套 Skills 由官方背书，权威性没问题；但用户想用一个特定功能的 Skill 时，社区里动辄几十个同类实现，怎么选？看 Star？看下载量？这里存在一个明显的正反馈悖论——使用量越高的 Skill 越被推荐，越被推荐使用量越高。早期 GitHub 上的热门 Skill 就是这么卷出来的。没有真实使用效果、采纳率、失败率的评价体系，用户就只能盲选。未来一定会衍生出 Agent 世界的大众点评或高德必吃榜——基于真实调用数据为 Skills 评分、定级、进出。

举个具体的例子：早期 Git 客户端有大量第三方插件提供 diff 高亮、blame 视图，现在这些功能都已经默认内建到 Git、IDE、SourceTree 里面了。通用 Skills 会走一模一样的路线：从插件 → 默认能力 → 用户根本不知道它的存在。

所以，写通用 Skills 给别人用，注定是一份看上去热闹、实际上没沉淀的工作。

通用型 Skills 怎样变得无感知：三种技术形态

无感知不是一个口号，从软件工程的设计思想看，它或许有明确的技术形态。

1. 物理 Skills 层（用户可感知）

在用户的本地工作目录或家目录下，有一类 Skills 是物理存在、用户可感知的——比如 .claude/skills、~/.claude/skills、.agents/skills、~/.agents/skills 这些约定目录下的 Skills。它们的典型来源：

• 官方工具配套 Skills（如 gh-cli-skill、lark-cli-skill），随工具升级而更新。
• 用户主动安装 / 拉取的第三方 Skills，比如从 GitHub Awesome List 或企业内部仓库克隆下来的。

• 版本管理：用可追溯的历史记录管理代码与配置变更，支持对比、回退与协作，常见工具为 Git。

  项目级 Skills，放在仓库 .claude/skills 下随代码一起用可追溯的历史记录管理代码与配置变更，支持对比、回退与协作，常见工具为 Git。。

这一层 Skills 用户是看得见、摸得着的——可能是 clone 下来的文件夹、可能是 npm install -g 装的，也可能是 IDE/Agent 启动时自动加载的。热路径上 Agent 优先在这一层匹配，命中就直接用。

2. 缓存 Skills 层（用户无感知）

物理 Skills 不可能应有尽有——它本质上是用户或项目愿意装的那一份。真正做到应有尽有的，是 Agent 在后台维护的缓存层 Skills：

Skill 知识层
├── 远端源：GitHub Awesome List、官方文档、Stack Overflow 高赞答案
├── 本地缓存：.cache/skills/<task>/<source>.<hash>
└── 运行时：Agent 按需加载、按需淘汰

这一层用户完全无感知：

• 冷启动：第一次遇到某类任务时联网搜，结果落盘到 .cache/skills/。
• 热路径：物理层未命中时，自动到缓存层匹配；命中直接读本地，零网络开销。

两层共享同一套生命周期管理机制

物理层和缓存层虽然分工不同，但必须受同一套生命周期管理机制约束——周期更新保证新鲜度、可清理机制防止膨胀。Agent 后台统一调度这两件事，对用户都是无感的。

• 周期更新

  • 物理层：官方工具配套 Skills（gh-cli-skill、lark-cli-skill）随官方升级自动拉取最新版；用户主动安装的第三方 Skills 支持 skill update 一键同步上游。
  • 缓存层：按天/周周期性地去远端检索是否存在更新、采纳率更高、被验证更好的版本，若发现则异步替换本地。

• 可清理机制

  • 物理层：项目级 Skills 随仓库清理；用户级 Skills 提供 uninstall / purge 子命令；长期未被调用、且优先级队列排末位的 Skills 进入待清理队列，到期自动归档或删除。
  • 缓存层：长期未命中、长期未被调用、且优先级队列排末位的缓存条目自动淘汰，本地不会被爆。

关键判断：当物理层 + 缓存层都够用时，绝不能因为够用就直接放弃去了解业界有没有更好的实践——否则会错过最先进生产力的迭代。一个 80 分的旧 Skill 用三年，远不如一个 95 分的新 Skill 用三个月。

两层的意义是：物理层保显性可管理（用户能装、能删、能 review），缓存层保隐性全覆盖（让用户即使不装也能用上业界最新）。分层决定 Skills 放在哪，生命周期决定 Skills 怎么活——这两件事必须作为整体来管理，否则任何一层单兵突进都会让另一层失效。

3. 按使用频率与采纳度划分优先级（优先队列）

通用 Skills 数量会爆炸式增长，必须引入优先级机制。设想一个类似优先队列的结构：

维度	含义	权重建议
调用频率	Skill 在最近 N 天被调用了几次	高
用户采纳率	Agent 给出的建议里，用户实际采用了多少	高
失败率	使用后被回滚/重写的比例	负向
来源权威度	GitHub stars、官方文档、社区评分	中

调用频繁 + 采纳率高 + 失败率低的 Skill 自动升权，被 Agent 默认启用；反之则降权，进入淘汰队列。

这个机制的本质是：让被验证过的最佳实践自动浮上来，让过时/无效的 Skill 自动沉下去。用户无需手动管理 Skills，Agent 自己会择优。

缓存晋升：高频 Skills 可晋级为物理 Skills

优先级队列不仅决定哪些 Skill 被启用，还决定它们住在哪里。

当一个缓存层 Skill 的调用频率和价值被验证到一定程度时，Agent 可以自动把它晋升为物理层 Skill，纳入 Git 管理：

• 晋升路径：.cache/skills/<task>/ → .agents/skills/<task>/（物理目录） → 写入 Git。
• 晋升触发条件：调用频率超过阈值（如 30 天内被调用 N 次） + 用户采纳率 > 阈值 + 失败率为 0。
• 晋升后的好处：
  • 跨 workspace 迁移：新机器 git pull 一下就把自己用顺手的 Skills 一起带过来。
  • 跨设备同步：物理层 Skills 跟着 Git 走，缓存层 Skills 不入库。
  • 可审计、可 review：晋升的 Skill 变成显式资产，使用者能明确感知我在用这个。

反过来也成立：物理层 Skills 长期不被调用、采纳率持续走低时，会被降级回缓存层，腾出 Git 空间，避免个人 Skills 列表被一堆过时内容堆满。

完整的工作目录结构：

~/workspaces/my-project/
├── .git/
└── .agents/
    ├── skills/         # 物理 Skills（含晋升来的，建议入 git）
    │   ├── commit-helper/    # 来自缓存层晋升
    │   └── lark-helper/      # 来自缓存层晋升
    └── memory/         # 个人专属记忆（建议进 git）
        ├── preferences.md
        ├── past-decisions.md
        └── style.md

通用 Skills 缓存不一定要入库（随用随拉），但物理层 Skills + 个人专属记忆一定要入库。换台电脑、换一个 workspace，pull 一下代码就把自己用顺手的 Skills 一起拉过来了。

自媒体越宣传，越说明通用 Skills 不该被关注

回头看最近各种 Skill 入门教程、十大必装 Skills 这类自媒体内容，它们越火，恰恰越说明通用 Skills 的命运：

• 它们的内容很轻——几分钟就能讲完一个 Skill；
• 它们的读者很广——面向所有 AI 用户；
• 它们的变现路径很短——卖课、卖社群、接广告。

但也正因为如此，它们注定是通用型内容。

如果是工具型的、开箱即用的通用 Skills，普罗大众根本无需关注。

真正需要关注的，是：

• 领域专家型 Skills——那才是需要自己长期沉淀、可以拿出来卖的资产。
• 个人专属 Skills——那才是只服务于自己、跟随自己一辈子的数字记忆。

通用 Skills 的最佳归宿，就是默默躺在本地缓存里、按使用频率排队、被 Agent 自动择优调用。当一个 Skill 真正做到这一点，它的作者应该感到骄傲——因为它已经成功到让用户忘记了它的存在。

---

真正值钱的是：领域专家型 Skills

与通用工具型 Skills 形成鲜明对比的是，领域专家型 Skills 才是未来真正能产生价值、甚至被商品化的资产。

它的价值来自四个稀缺性：

1. 经验稀缺：领域专家多年的实战经验，是模型无法凭空生成的。
2. 口径稀缺：每个行业都有自己的黑话、合规要求、禁区表达，这些只能在实战中沉淀。
3. 复用稀缺：同行业、同场景的任务会高频重复，每一次复用都摊薄了 Skill 的边际成本。
4. 质量稀缺：不固化就一定会漂，固化下来就能稳定输出。

更关键的是，领域专家型 Skills 是可以对外销售的。

未来 SKILL 会变成领域知识技能包，像 App Store 一样被上架、被订阅、被评分。

一个跨境电商运营多年的老板，把自己的 Listing 写作经验封装成 Skill，卖给其他中小卖家； 一个资深律师，把合同审阅经验封装成 Skill，按调用次数收费； 一个资深 SRE，把故障复盘与应急响应经验封装成 Skill，企业按席位订阅。

这不是科幻，这是 Skill 商品化的必然路径。原因很简单：

• 通用能力会被模型原生吸收，免费。
• 领域经验无法被模型原生吸收，必须由专家持续供给并维护。
• 凡是必须由专家持续供给并维护的东西，最终都会商品化。

回到个人层面，这也是为什么我前面说：

自己给别人写通用型 Skills 没有多大价值，而自己沉淀领域专家型 Skills，是真正能积累复利的事情。

个人专属 Skills：另一条被低估的路

最后想单独说一下个人专属 Skills。社区里很少有人讨论这一类，但我认为它被严重低估了——它才是每个用户最需要关注的，是自我提效的关键。

它的价值不在于被复用，而在于把个人经验外置成一个 24 小时在线的协作者。几个具体场景：

• 写作：把个人的思考框架、段落结构、标题套路沉淀成 Skill，让 Agent 写出来的初稿直接就是我会写的样子，而不是 ChatGPT 的样子。
• 代码：把团队的代码风格、命名规范、Review 偏好沉淀成 Skill，Agent 生成的代码直接过 Code Review。
• 决策：把当遇到 X 情况，我通常会先做 Y，再做 Z这种决策习惯沉淀下来，让 Agent 在关键时刻给出和自己判断一致的建议。

这些 Skill 别人拿不走，也不指望别人拿走，但它把一个人的经验价值从每天 8 小时扩展到了每天 24 小时。

自我蒸馏：一种戏谑，也是一种现实

网上流行一种说法：把自己的 Skills 蒸馏给 Agent，把自己也蒸馏了，就可以在被裁之后，以数字生命的形态继续在公司里工作。

这虽然是段子，但背后的逻辑很现实——个人专属 Skills 才是自我提效的关键。一个员工如果连自己的 Skills 都没沉淀下来，谈何提效？谈何复用？谈何议价？

但要不要把自己蒸馏成可被替代的形态，这事儿得看立场。我自己有两个视角：

• 视角一（企业视角）：员工是螺丝钉，少了谁公司都能运转。所谓的 Skills 运动看起来是赋能，但本质上是给工具配了个人，而不是给人配了个工具——企业想要的不是一个更强的员工，而是一个可被无限复制的工具人。
• 视角二（个体视角）：每个员工都是独一无二的，特性、个性、工作模式、思考方式都不一样。
  • 从个体时间维度看：一个人在 25 岁、35 岁、45 岁的 Skills 截然不同；甚至同一个人每天的 Skills 都在变化——今天的状态和明天的状态会差很多。
  • 从群体维度看：允许个体的差异性和个性，才是给创新、进步留的口子；把所有员工都炼化成标准件，创新也就死了。

我的结论很明确：既不看好炼化员工的观点——那是把人当工具；更不认可把个人专属 Skills 强塞给别人用的观点——那不是分享，是强人所难，是把自己用顺手的私货强行灌输给别人，堪比老一辈把自己的人生经验 Skills 强加到晚辈身上——谁受得了？

个人专属 Skills 的最佳归宿，就是留给自己、跟随自己、随自己一起进化。

三类 Skills 的演进方向

最后用一张表收个尾，三类 Skills 的演进方向完全不同：

类别	演进方向	是否商品化	写给别人的价值
通用工具型	被平台收编 → 用户无感知	几乎不可	低
领域专家型	上架成领域知识技能包 → 被订阅	可，且应被商品化	高（最值得做）
个人专属型	外置成个人协作者 → 持续进化	不可，但值得长期沉淀	无，但自己用最值

如果要给一个行动建议，那就是：

• 别再花时间写通用型 Skills 给别人了，那份作者署名的虚荣收益，很快会被模型原生吸收掉。
• 把时间花在领域经验沉淀上，把多年积累的 know-how、口径、禁区、验收标准封装成可复用、可售卖、可订阅的领域知识技能包。
• 顺手把自己的个人习惯也沉淀成 Skill，这件事不性感，但它是少数能跟自己一辈子、且越用越值钱的数字资产。

未来的 Agent 生态，最稀缺的从来不是 Skill 的数量，而是 Skill 背后那一份被精打细磨过的领域经验。

---

备选标题

以下为已弃用的旧标题，仅作留档，不再使用。

• Agent Skills 演进趋势：通用无感、领域值钱、个人专属
• 别再给别人写通用 Skill 了：未来值钱的是领域知识技能包
• Agent Skills 三分类：工具类、领域专家类、个人专属类
• Skill 写给谁？写给别人的通用 Skill 没价值，写给自己的最值钱
• 当 Skill 变成商品：领域专家才是 Agent 时代真正的赢家