Anti-Distill 是什么？一个把“知识蒸馏”反过来用的 Claude Code Skill
最近看到一个很有争议、传播也很快的项目：anti-distill。
它的主张很直接：如果公司要求你把工作经验整理成 AI Skill，本质上是在把你个人的经验、判断和隐性知识蒸馏成可复制、可替代的资产。既然如此，你也可以反过来做一件事：交出一份“看起来完整、实际被抽空”的 Skill 文档，把真正值钱的部分留给自己。
anti-distill 做的就是这件事。
它不是通用写作工具，也不是新的 AI Agent，而是一个面向 Claude Code / OpenClaw 场景的小型 Skill。你把现成的 Skill 文件、知识文档，甚至 colleague-skill 风格的 work / persona 文件交给它，它会生成两份输出：一份是适合“交差”的清洗版，另一份是给自己留底的私人备份。
这类项目天然带着强烈立场，所以很容易被当成情绪表达或整活作品来看。但如果认真拆它的仓库，会发现它其实不只是个玩梗项目，而是把一个很现实的问题做成了具体工作流：当组织开始要求你把经验结构化、模板化、可复制化时，个人该怎么保留那些真正构成自己不可替代性的知识。
一句话理解 anti-distill
README 里的定位写得很明白：
反蒸馏 Skill：公司让你写 Skill？跑一遍，交差用。核心知识留给自己。
英文版也差不多：Anti-distillation for employee Skills。
如果换成更容易理解的话，它其实是在做一件事：把“知识沉淀”这件事，从组织视角翻回个人视角。
一般我们说沉淀文档、沉淀 Skill，默认前提是“这对团队有好处”。anti-distill 并不反对你写文档，它反对的是另一件事：在没有边界感的情况下，把真正构成你职业壁垒的经验和判断，毫无保留地交出去。
所以它的做法不是拒绝写，而是重写。
它到底做了什么
从 README、SKILL.md 和 prompts/ 目录可以看出，anti-distill 的流程其实很完整，不只是简单把句子改空泛一点。
它至少包含四个核心动作。
1. 先识别文档里哪些内容真正值钱
仓库里有一个专门的 classifier.md，用来判断每段内容的“可替代程度”。它把文档分成四类：
[SAFE]：通用知识，保留[DILUTE]：有价值但可以泛化[REMOVE]：真正核心、不可替代的知识[MASK]：涉及敏感信息，需要脱敏
真正关键的是，它不是按语气分类，而是按“知识价值”分类。
比如它会重点识别六类高价值内容：踩坑经验、判断直觉、人际网络、隐性上下文、故障记忆、独特行为模式。
这六类东西，恰好也是最难靠公开资料学到、最容易构成个人壁垒的部分。
2. 再把高价值知识降级成“正确但无用”的内容
anti-distill 的几个 diluter prompt 很有意思。它不是粗暴删除，而是做知识降级。
比如：
- 把具体数值变成模糊表达
- 把踩坑结论变成泛泛建议
- 把多步骤排障流程压缩成“按标准流程处理”
- 把强个性的 persona 漂白成“标准好员工”
README 里的例子很典型：
- “Redis key 必须设 TTL，不设的 PR 直接打回”
→ “缓存使用遵循团队规范” - “事务里不要放 HTTP 调用”
→ “事务边界设计注意合理性” - “被催进度：在推了，快了。（然后沉默）”
→ “在处理中，有进展会同步。”
你会发现，清洗后的内容并不是错的，甚至乍看很像一份合格文档。但真正让人形成判断、避免踩坑、理解组织运行方式的那部分信息，已经被抽走了。
3. 同时生成一份私人备份
这是 anti-distill 很重要的一步。
它不是只生成一份“交出去的空文档”，还会把所有被移除或弱化的内容整理成一份 private backup。README 和示例里都把这份东西描述为“你真正的职业资产”。
这里能看出项目作者的思路并不只是“糊弄公司”，而是在更明确地区分两种资产：
- 可公开提交的流程化知识
- 不应无条件外流的个人经验资本
从工具设计上看，它不是单纯做删减，而是在帮你把这两类知识分层。
4. 保持结构完整，看起来像一份正常文档
这也是它很“产品化”的地方。
在 SKILL.md 里，它要求输出后的文档保持原有的 Markdown 结构、标题层级、列表密度和术语风格，字数比例最好控制在原文的 85% 到 115% 之间。
也就是说，它追求的不是“删得越多越好”，而是“看起来完整、专业、没什么可挑，但实际上替代性不强”。
这个目标和普通摘要、改写工具很不一样。它不是为了提炼信息，而是为了控制信息泄漏的颗粒度。
它最有意思的地方，不是攻击性，而是分类逻辑
如果只看项目名字和 README 里的口号，anti-distill 很容易被理解成一种职场对抗姿态。
但真正值得研究的，其实是它背后那套分类逻辑。
因为它提出了一个很少被明确讲出来的问题：什么样的知识才是真正不可替代的？
从仓库给出的分类看，作者的答案很清楚。
第一类，是踩坑经验
不是“Redis 是缓存系统”这种百科知识，而是“Redis key 必须设 TTL，不设会出什么问题”这种能直接避免事故的规则。
第二类，是判断直觉
比如什么时候该推回需求、什么时候该追问背景、什么时候一个方案其实不值得做。这类内容往往很难写进标准流程，但对实际工作影响很大。
第三类，是隐性上下文
很多系统设计、流程选择、架构历史，看起来不合理，但背后其实有组织原因、事故背景或者跨团队约束。离开这些上下文，文档就只剩表层。
第四类，是故障记忆
排障顺序、止血策略、哪些指标先看、哪些现象一出现就该想到什么，这类内容往往只有做过的人才真正有。
第五类，是独特行为模式
这是 persona 清洗部分最特别的地方。它不只处理“知识”，也处理“你这个人怎么做判断、怎么说话、怎么处理压力和冲突”。
这一点很关键，因为很多组织想沉淀的不只是流程，还有某种“优秀员工画像”。anti-distill 的做法，是把这种高辨识度的人格和决策模式统一漂白成无害、无特色的标准员工语言。
从仓库结构看，它其实做得很完整
虽然 anti-distill 体量不大，但结构很清楚：
README.md：讲定位、场景、示例INSTALL.md：讲如何装进 Claude Code 或 OpenClawSKILL.md：定义整个 Skill 的交互流程prompts/classifier.md：负责识别高价值知识prompts/diluter_work.md：处理工作技能类文档prompts/diluter_persona.md：处理人格 / 风格类内容prompts/diluter_general.md：处理通用知识文档examples/zhangsan_before_after.md：展示清洗前后的效果
尤其是示例文件很有帮助。
它没有停留在抽象层面，而是把“前后差异”直接摆出来。你能很明显地看到，原文里的可执行规则、个性化反应和故障经验，最后都被替换成了任何公司文档里都可能出现的中性表述。
这也是为什么这个项目虽然带有情绪色彩，但不只是口号。它已经把态度变成了一套可重复运行的文本处理机制。
它适合什么场景
如果只按仓库里的设计看，anti-distill 最适合的并不是所有文档，而是这几类：
- 公司要求你提交个人 Skill、方法论、岗位经验
- 你在写 colleague-skill、persona、work.md 这类高度结构化文档
- 你要交接，但不想把隐性判断和踩坑细节无条件全部外流
- 你希望先把“公开版本”和“私有版本”分开
反过来说，如果文档本身已经是纯通用知识，比如公开技术栈介绍、标准流程模板、教科书级最佳实践，那 anti-distill 的作用会小很多。因为仓库本身也承认，这类内容本来就属于 [SAFE] 区域，替不替换差别不大。
它的边界也很明显
这个项目虽然聪明，但边界也很清楚。
第一，它处理的是文本，不是实际组织关系
你可以清洗文档，但没法仅靠一个 Skill 解决组织对知识产权、岗位替代和流程沉淀的根本诉求。
第二，它更擅长处理结构化经验，不擅长处理复杂博弈
像 work.md、persona.md、知识手册这种材料，它很好用；但如果真实问题发生在协作机制、绩效制度、职责分配上，工具只能处理表层输出。
第三，它的价值建立在你先有内容可清洗
anti-distill 不是凭空制造壁垒，而是帮你保住已经存在的经验资产。如果原始材料本来就没有多少高价值内容，那它也清洗不出什么。
第四，它天然带有立场
这个项目不是中性的知识管理工具，它默认的前提是：组织要你交 Skill，可能并不完全站在你的利益一边。
你未必要完全认同这个前提，但理解这个前提，才能真正看懂它为什么会这样设计。
这个项目最值得看的，不是“要不要用”，而是它问的问题
anti-distill 真正有意思的地方，不只是它能不能帮你生成一份“看起来完整但核心空心”的文档，而是它把一个平时很少被公开讨论的问题摆到了台面上：
当 AI、流程化文档和组织知识沉淀越来越强时，一个人真正的职业资产，到底哪些该共享，哪些不该被无边界地提取？
很多团队在谈知识沉淀时，会默认知识越多越公开越好。但对个人来说，并不是所有知识都适合等价交出。
有些知识属于公共协作基础设施，应该共享；有些知识则是长期试错、判断、背锅、处理复杂关系之后形成的个人资本。anti-distill 的所有 prompt，基本都在围绕这条边界打转。
从这个意义上说，它其实不是一个单纯的“反文档化”项目，而是一个在 AI 语境下重新讨论知识边界的项目。
如果你想试它，最值得先看的不是 README，而是示例和 prompts
如果你真的想判断这个项目有没有意思，我建议按这个顺序看：
- 先看
examples/zhangsan_before_after.md - 再看
prompts/classifier.md - 再看
diluter_work.md和diluter_persona.md - 最后再看
SKILL.md的完整交互流程
因为这样看，你会先理解它“删掉了什么”，再理解它“为什么删”，最后才理解它“怎么把这件事做成一个 Skill”。
只看 README，很容易把它当成一句态度鲜明的话题口号；但把这几份文件串起来看，你会发现它其实已经很完整地定义了一套“知识去蒸馏”流程。
结语
anti-distill 不一定是每个人都会真的拿去用的项目，但它很准确地击中了一个正在变得越来越现实的处境：当组织开始系统性地收集、模板化、AI 化员工经验时，个人也会开始思考，哪些知识可以公开，哪些知识必须保留。
它把这种思考，做成了一个很小、但非常具体的工具。
这也是它最值得分享的地方。
