GitHub 爆火的「同事.Skill」项目，通过将聊天记录、工作文档喂入 AI，生成可复用的工作 Skill。本文拆解其技术架构，并探讨主动蒸馏自己 vs 被别人蒸馏的核心策略。
GitHub 爆火的「同事.Skill」项目，通过将聊天记录、工作文档喂入 AI，生成可复用的工作 Skill。本文拆解其技术架构，并探讨主动蒸馏自己 vs 被别人蒸馏的核心策略。
上周 GitHub 上出了一个项目，叫「同事.skill」。三天破千星，现在已经 5000 多星了。
Slogan 写得挺温柔：「将冰冷的离别化为温暖的 Skill，欢迎加入数字生命 1.0。」
操作也很简单：把离职同事的飞书消息、钉钉文档、邮件、截图喂进去，AI 就能生成一个能替他干活的 Skill 文件。用他的技术规范写代码，用他的语气回答问题，甚至知道他什么时候会甩锅。
但这篇文章不是来讲段子的。作为一个每天都在写 Skill、用 Skill 的人，我想认真拆解一下这个东西到底在做什么，以及你该怎么正确地利用它。
同事.skill 的技术实现不复杂，但架构设计很聪明。它把一个人拆成了两层：
# SKILL.md
layer_1: Work Skill
# 技术规范、决策路径、代码习惯
# 这是他「能干什么」
layer_2: Persona
# 说话方式、沟通节奏、情绪反应
# 这是他「怎么干」执行流程是：任务 -> Persona 判断态度 -> Work Skill 执行 -> 输出
数据来源支持飞书、钉钉、Slack 消息，邮件，PDF 文档，甚至截图。你也可以什么都不传，纯靠文字描述生成一个 Skill，只是精度会差一些。
它还支持版本管理——如果 AI 的回答不够像本人，你可以直接说"他没这么温柔，他一般会先发个问号"，系统会写入 Correction 层，下次对话就能纠正。
Hermes 三层记忆架构解决 Agent 记不住的问题，四阶段提示词搭建 Lead + VOC + GEO + Reddit + TikTok 五人 AI 团队，接入飞书群自动协作。
同事.skill 火了之后，GitHub 上几天之内冒出了一整个生态：
/let-go，查看所有前任叫 /list-exes。连放手都要写成 API。相关链接：
面对 Skill 化的趋势，有三种策略：
| 策略 | 做法 | 问题 |
|---|---|---|
| 被动蒸馏 | 同事走了，别人拿聊天记录蒸馏他 | 蒸馏什么、给谁用，他说了不算 |
| 假装蒸馏 | 反蒸馏.skill 交一份注水版 | 看起来完整但核心被移除 |
| 主动蒸馏 | 自己决定固化什么、记录什么、自动化什么 | 清楚知道 Skill 里有什么 |
第三种才是正道。
花叔从去年就开始把自己的写作风格、判断标准、工作流程写成 Claude Code 的 Skill。到现在跑着几十个 Skill：选题有 Skill，调研有 Skill，写作有 Skill，审校有 Skill，配图有 Skill，连发布到飞书都有 Skill。
区别只有一个：谁在控制蒸馏的过程。
如果你的工作是固定流程、固定标准、固定输出，那确实可以被一个足够好的 Skill 替代。
但想想看：如果蒸馏真这么有效，为什么没人去蒸馏马斯克？Karpathy 的所有公开演讲、论文、推文都在网上。芒格和巴菲特的传记、股东信、访谈加起来几千万字。但你拿这些去生成一个马斯克.skill，它能帮你做出下一个 SpaceX 吗？
做不到。因为这些人真正值钱的地方，是他们面对未知时的反应。那种东西不在文字里。
所以真正有用的策略是：
把自己的工作流程 Skill 化，恰恰是最不容易被 Skill 替代的做法。 因为你把重复的部分交给了 Skill，自己腾出手来去想新的东西。你永远跑在自己的 Skill 前面。
而从来不整理、不提炼的人反而更危险——他的重复和创造混在一起，别人拿聊天记录蒸馏一下，可能还真挺像他的。
如果你想开始主动蒸馏自己，可以从这几步入手：
以前"认识你自己"刻在德尔菲神庙上，是哲学问题。现在它变成了一个工程问题：你的 SKILL.md 里该写什么？更重要的是，哪些东西是你写不进去的？
写不进去的那部分，才是你。