Skill 不只是个人资产：如何把经验沉淀变成团队基础设施

我在实践 Skill 体系一段时间后发现一个尴尬的问题：写好的 Skill 躺在本地目录里，除了我自己，团队里没有人知道它存在。

这不是「写得好不好」的问题，是可见性问题。知识沉淀的最后一公里，是让它被用到，而不只是被写下来。

分发比质量更先失效

团队里有个普遍现象：每个人都在解决相似的问题，但各自写了自己的那一套，互相不知道对方做了什么。不是因为大家不想分享，而是分享这件事本身有摩擦——「我得先整理一下才能发出去」，这句话是多少有价值的东西消失的开头。

Skill 的分发流水线要解决的就是这个摩擦。核心逻辑很简单：

1. 创建 Skill（SKILL.md + 结构化目录）
2. 验证元数据完整性，确保可被他人理解
3. 打包成可分发格式（zip 或 git 子目录）
4. 自动推送团队通知，让相关人看到「这个东西存在」

第四步是关键。如果第四步需要人工操作，它大概率不会发生。

什么让一个 Skill 「可分发」

并不是所有 Skill 都能直接发出去。在打包之前，有几件事值得检查：

命名是否规范。 fix-bug-final-v2 不是一个可被发现的名字。pdf-watermark、csv-export-security、api-error-handler 才是。命名即文档，别人看到名字就能判断要不要读。

触发条件是否明确。 SKILL.md 的第一件事应该是告诉读者「什么时候用这个 Skill」，而不是直接上操作步骤。这一条对编写者来说显而易见，对接收者来说却是最需要的信息。

依赖是否显式声明。 Skill 里用到了某个外部 API、某个本地路径、某个特定工具，都要写清楚。没有声明的隐式依赖是 Skill 在别人机器上跑不起来的头号原因。

通知机制的设计

自动通知的载体可以是 Slack、飞书、邮件，具体工具不重要，重要的是通知里包含什么。

一条有用的 Skill 发布通知至少要有：Skill 名称、一句话功能描述、直达文件的链接。不需要展开所有细节，只需要让接收者能判断「这和我有没有关系」。

通知太详细，会被当成文档跳过。太简略，会被当成噪声忽略。一句话摘要 + 一个链接，这个信息密度刚好能触发「啊，以后我可以用这个」的记忆锚点。

个人 Skill 和团队 Skill 的边界

不是所有个人 Skill 都适合共享。有些 Skill 高度依赖个人的工作流偏好或特定的项目上下文，强行共享反而制造噪声。

我自己的判断标准：如果这个 Skill 解决的问题在团队里至少有两个人会遇到，就值得共享。如果它是高度个性化的（比如我的某个项目特有的部署脚本），就留在本地就好。

共享出去的 Skill 需要比私人 Skill 更严格的文档标准，因为你不在场解释。

一句话心法

知识沉淀的价值，由「被写下来的质量」和「被看到的概率」共同决定——分发流水线是后者的倍增器。