Appearance
colleague-skill 和 anti-distill 是同一个冲突的攻守两面：前者把人的工作经验资产化，后者帮你交出空壳保留核心。但 anti-distill 分类器认为要保护的（Redis TTL规则、分页上限）是真正不可替代的东西吗？这场军备竞赛的终局不是哪方赢，而是文档可信度彻底崩塌。真正的护城河从来不在那几条结论里。
AI Skill 蒸馏战争：两个工具，一个误判
2026年4月
两个开源工具在同一周出现在我的 GitHub feed 里。
第一个：colleague-skill。把同事的聊天记录、工作文档喂进去，生成一个 AI Skill。以后新人可以直接调这个 Skill，让 AI 模拟那个人的工作方式——用他的技术规范写代码，用他的语气回答问题，知道他什么时候会甩锅。
第二个，几天后出现：anti-distill。把你被迫写的 Skill 文件扔进去，输出一份清洗版——结构完整、术语专业、读起来没问题，但核心知识全被抽掉了。同时生成一份私人备份，记录所有被抽走的东西。
README 里有一句话：公司让你写 Skill？跑一遍，交差用。核心知识留给自己。
这不是两个不相关的工具，这是同一个冲突的攻守两面。值得仔细看清楚。
这两个工具在做什么
colleague-skill 生成的 Skill 分两层：Work Skill（技术规范、踩坑经验、工作流程、经验知识库）和 Persona（5 层性格结构，从硬行为规则到人际模式）。运行逻辑是：Persona 先判断对这件事的态度，然后 Work Skill 执行，最后以他的语气输出。
这个设计不只是知识库检索，它想模拟的是一个人面对问题时的完整反应链。
anti-distill 的核心是一个内容分类器，把你 Skill 里的每个要点分为四类：
| 标签 | 含义 | 处理方式 |
|---|---|---|
SAFE | 通用知识，任何人都能写出来 | 原文保留 |
DILUTE | 有一定价值但可泛化 | 替换为"正确但无用的废话" |
REMOVE | 核心不可替代知识 | 替换为通用内容填充 |
MASK | 含内部敏感信息 | 替换为通用化表述 |
它认定必须保护的是"六大高价值类别"：踩坑经验、判断直觉、人际网络、隐性上下文、故障记忆、独特行为模式。清洗示例：
"Redis key 必须设 TTL，不设直接打回" → "缓存使用遵循团队规范"
"事务里不要放 HTTP 调用" → "事务边界设计注意合理性"
清洗后，技术上不能有错误，但换同岗位的人看，觉得"说了等于没说"。
一个被误读的历史先例
看到 anti-distill 的逻辑，我第一个联想到的是甘地的非暴力不合作运动。
1930 年，甘地带着数千人走了 388 公里去海边捡盐。不是因为盐重要，而是英国人说不许你捡。他的策略：表面上遵守游戏规则，同时让整个规则体系失去合法性。
anti-distill 的姿态表面上相似：配合，交差，但留一手。
但本质不同。非暴力不合作是公开的——甘地在众目睽睽之下捡盐，等着被逮捕，目的是让惩罚本身成为对殖民统治的控诉。它有道德诉求，针对的是系统的合法性。
anti-distill 是隐蔽的。它不主张"公司要求你把经验写成 Skill 这件事本身是错的"，它只是帮你在遵守要求的外表下保全自己。这更接近职场自我保护，不是对抗系统的原则立场。
真正的问题：anti-distill 在保护错误的东西
这是这篇文章最想说的一点。
anti-distill 的分类器把"Redis key 必须设 TTL，不设直接打回"标记为 REMOVE——核心知识，必须隐藏。
但"Redis 必须设 TTL"是你真正的护城河吗？
这是每个做后端的人早晚都会知道的事。你不告诉他，他也会在某次事故里学到。这条规则的价值在于它对应的情境：当时是什么系统、什么数据量、触发了什么问题、排查了多久、为什么选这个阈值。
如果你只给他结论，他拿到了一个脱离坐标系的外壳。所有的技术结论都有它的保质期和适用坐标。anti-distill 在认真保护的，恰恰是最容易被时间和情境稀释的那部分。
真正没法被蒸馏进任何文件的是什么？
是第一注意力——有经验的人看到同一个问题，眼睛第一眼盯着哪里。同样一份策划案，新人是在"读故事"，有经验的制作人是在"排地雷"：他的眼睛会自动跳过华丽的描述，精准锁到数值边界和资源依赖上。
是判断力在新情境下的适应能力——面对之前没遇到过的问题时，如何定义问题、如何排优先级、什么时候推回去、什么时候妥协。这不是可以归纳成规则的，它依赖于你处理过足够多的具体情境之后沉淀出来的直觉。
这些东西根本没法被序列化进文件。你不藏，别人也拿不走。
军备竞赛的终局
如果 anti-distill 的使用变得普遍，逻辑链很清楚：
colleague-skill 生成的大多数技能会变成空壳 → 公司意识到 Skill 质量不够，要求写得更细 → 员工使用更重度的清洗 → 公司引入 AI 检测"是否被稀释" → 员工进一步对抗……
这个循环的终点不是哪一方赢，而是文档本身的可信度彻底崩塌。
值得注意的是：这和很多企业文档的现实状态相当接近。很多公司的内部 Wiki 里，大量文档已经是"说了等于没说"的状态——不是因为有人用了 anti-distill，而是因为大家写文档时本来就习惯写通用表述。anti-distill 只是把这个过程自动化了。
colleague-skill 的正确用法
如果你用 colleague-skill，最大的误区是把它当 Oracle——输入问题，等待答案，把输出当真实那个人说的话。
它实际上更像一个视角透镜：帮你暂时站在另一个人的位置看问题，但思考这件事还是你自己做。
实际操作：你要 review 一段代码，想用一个专注数据库性能的老工程师的眼光来看。正确的方式不是把代码贴给 AI 问"他会怎么说"，而是先打开他的 Skill，翻 CR 重点一节，提取他的优先级排序：接口设计→N+1查询→边界条件→命名。然后你拿这个框架，自己去看代码。
AI 没有替你做判断，你只是借了一个别人积累出来的注意力框架。这个区别很重要——如果你真把它当神，你就成了 AI 的传话筒。
护城河在哪里
两个工具都在争同一个问题：什么是这个人真正不可替代的东西。
anti-distill 的答案是：具体的结论、规则、配置值。
这个答案是错的。这些东西会随着系统演化、团队迭代而过时，也随时可以被下一个人在实战中重新积累。
真正的护城河，是那个能随时写出新 Skill 的你——面对没遇到过的情况时，能判断什么重要、能从经验里提炼出可迁移的模式、能知道什么时候推回去。
所以支持你用 anti-distill 处理那些纯粹走形式的行政任务。但如果你真的拿它来保护自己的职业生涯，那说明你可能误判了自己的值钱在哪里。沙堡守得再严，也是沙堡。
FAQ
Q：colleague-skill 和 Claude Code 的 Skills 系统是同一回事吗？
不是。Claude Code 的 Skills 是自定义 Prompt 模板，控制 AI 的行为模式。colleague-skill 是一个独立项目，目标是把真人的工作经验封装成可调用的 AI 上下文。两者都叫"Skill"但场景不同。
Q：anti-distill 这类工具会不会影响公司对 AI 知识管理的推进？
长期来看会。如果员工普遍使用 anti-distill 交付空壳 Skill，公司积累的 AI 知识库质量会持续降低，最终倒逼出更强制性的要求或审查机制——形成文中描述的军备竞赛循环。
Q：作为个人，我该怎么面对公司强制要求写 Skill 这件事？
区分两类情况：纯走形式的行政任务，用 anti-distill 处理没问题；如果是你真正在乎的领域，认真写反而对自己有价值——写不出来的地方是你还没真正掌握的地方。保护结论毫无意义，培养出那种能在新情境下产生新结论的能力才是关键。
References
- colleague-skill — titanwings，MIT License
- anti-distill — 本地项目分析，含
classifier.md、diluter_work.md