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 层，下次对话就能纠正。
同事.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 里该写什么？更重要的是，哪些东西是你写不进去的？
写不进去的那部分，才是你。
零配置、全模态、本地运行的开源知识图谱工具，token 消耗降低 71.5 倍，无需向量数据库，pip 一键安装。
GitHub前CEO打造的Entire CLI开源工具，通过Checkpoints技术自动捕获AI编程上下文，让每次提交都携带完整的推理过程，解决AI代码难以追溯的痛点。
飞书、钉钉、企业微信相继推出命令行工具，Karpathy强推CLI复兴趋势，本文教你如何用CLI让AI Agent直接操作企业软件。