与此同时，多家互联网大厂开始将Skill产出量和Token消耗量纳入绩效考核。一场以「知识沉淀」为名的运动，正在制造前所未有的职场悖论。

一、蒸馏的真相：你写的每一行经验，都在训练替代者

"技能蒸馏"原本是AI领域的技术术语——将大模型的能力压缩到小模型中。而当这个词进入职场，它有了更残酷的含义：将你的判断力、经验直觉、甚至犯错后修正的路径，编码成一段可复用的Prompt或Skill文件。

一位大厂中层在内部论坛写道："上个月我把三年积累的故障排查手册写成了Skill，领导表扬了我。这周我得知，隔壁部门用这个Skill把故障响应从人工30分钟压缩到了自动3分钟——他们不再需要值班工程师了。"

这不是阴谋论。在知识管理的外衣下，公司获取的是去人格化的能力副本。一旦某个岗位的核心决策逻辑被充分文档化、Skill化，这个岗位对人的依赖就从"不可缺少"变成了"可替换的组件"。更讽刺的是：写得越详细、越真诚、越有教学精神的人，被蒸馏得越彻底。

二、悖论：Skill没替代我，但让我天天加班

另一条故事线同样荒诞。许多一线员工发现，Skill非但没有让他们"被替代"，反而制造了新的工作量黑洞。

一位后端工程师吐槽："我写的Skill被市场部同事拿去用，他们不懂参数含义，每次跑崩了都找我救火。我不仅没被替代，反而成了七八个部门的免费运维。"还有人遇到更离谱的情况——Skill版本迭代后与公司内部系统不兼容，原作者被迫无偿维护，"Skill变成了一份没有工单的On-call"。

这里暴露了一个关键问题：AI Skill降低了使用门槛，但使用门槛降低不等于理解门槛降低。当所有人都能调用你的Skill时，你从"专业输出者"变成了"全民技术支持"。知识蒸馏的承诺是"复制你的能力"，而现实是"复制你的麻烦"。

· · ·

三、共鸣触发点：知识沉淀还是自我淘汰？

真正让IT人破防的，是意识到一个闭环正在形成：

公司要求你写复盘 → 复盘变成文档 → 文档变成Skill → Skill替代或消耗你 → 你继续写新的复盘

这个循环的每一次迭代，都在降低你的不可替代性。当「知识沉淀」被定义为职场美德时，很少有人追问：沉淀之后，沉淀者去哪了？

并非所有公司都怀有恶意。许多管理者确实是出于效率提升的善意。但善意和结果之间没有等号。系统一旦运转起来，它不关心初衷——它只关心Token消耗量、Skill覆盖率、人工介入率的下降曲线。在这些指标面前，个体是不可见的。

一位匿名员工说得精准："我不是怕AI替代我，我是怕我亲手写的文档替代了我，而公司还觉得这是我自己选的。"

四、解药：留一手不是消极，是职业素养

面对这场不对等的博弈，"该不该留一手"已经不是一个道德问题，而是一个生存策略问题。以下是三条不卑不亢的边界法则：

第一，蒸馏过程，不蒸馏判断。把操作流程写清楚没问题——"点击这个按钮、配置那个参数"。但为什么选择这个方案、为什么绕过那个陷阱、什么情况下应该推翻既定规则——这些元判断，是任何人都蒸馏不走的。文档化你的What和How，保留你的Why。

第二，构建Skill依赖而非Skill替代。让你的产出物成为"提升效率的工具"而非"消除岗位的产品"。具体做法：Skill的输入需要领域理解才能正确提供，Skill的输出需要专业判断才能解读。让Skill降低你的重复劳动，而不是降低你的存在价值。

第三，投资不可蒸馏的资产。跨部门的人际信任、对业务上下文的深度理解、在模糊需求中快速定位真问题的能力——这些东西无法被编码为Skill文件。GitHub上那个千星项目的真正价值不是反蒸馏的技术方案，而是它提醒了一件事：你最有价值的部分，从来不在文档里。

那么，你现在有遇到这样的情况么？你会怎么做呢？