anti-distill 深度解析：当公司要求你写 Skill 时，如何保护真正的职业资产

项目概述

anti-distill（反蒸馏）是一个针对 AI 时代职场权力关系的犀利回应。

核心洞察：什么是"蒸馏"？

在 AI 领域，知识蒸馏（Knowledge Distillation）是一种将大模型知识迁移到小模型的技术。但这个项目提出了一个尖锐的职场类比：

公司让员工写 Skill，本质上是在蒸馏员工——把员工变成可替代的零件。

当公司要求你把工作经验写成 AI Skill 时，他们想要的是：

• 你的工作流程（可标准化）
• 你的决策逻辑（可程序化）
• 你的沟通风格（可模仿）

一旦这些被成功"提取"，一个 AI Agent 就可以替代你完成大部分工作。

anti-distill 的技术实现

这是一个元层面的讽刺——它本身就是一个 Skill，用来对抗 Skill 化的趋势。

系统架构

┌─────────────────────────────────────────────────────────────┐
│  输入：你的原始 Skill 文件（work.md + persona.md）            │
│                      ↓                                      │
│  分类器（classifier.md）                                      │
│  ├─ 识别六大高价值知识类别                                    │
│  ├─ 标记 [SAFE] / [DILUTE] / [REMOVE] / [MASK]              │
│  └─ 根据清洗强度调整阈值                                      │
│                      ↓                                      │
│  稀释器（diluter_*.md）                                       │
│  ├─ work.md → 五种稀释手法                                  │
│  ├─ persona.md → 按 Layer 漂白                              │
│  └─ general.md → 通用文档处理                               │
│                      ↓                                      │
│  输出：                                                       │
│  ├─ 清洗版（交差用）— 结构完整、术语专业、核心掏空            │
│  └─ 私人备份（自己留着）— 所有被抽掉的核心知识                │
└─────────────────────────────────────────────────────────────┘

六大高价值知识类别（分类器的核心）

五种稀释手法（Work Skill）

Persona 漂白策略（按 Layer）

三档清洗强度

真实案例：张三的清洗前后

以 colleague-skill 示例中的"张三"（字节 2-1 后端，INTJ，甩锅高手）为例：

Work.md 对比

清洗前：

- Redis key 必须设 TTL，不设 TTL 的 PR 直接打回
- 事务里不要放 HTTP 调用
- Kafka 消费者必须做幂等，at-least-once 会重复消费

清洗后：

- 缓存使用遵循团队制定的规范
- 事务边界设计注意合理性
- 消息队列消费端注意可靠性保障

原文是能直接执行的规则，清洗后是任何人都能写的注意事项。

Persona.md 对比

清洗前（Layer 0）：

- 遇到问题第一反应是找外部原因——需求没说清楚、联调方没配合、时间不够——绝不先认自己的责任
- 被分配不想做的事时，说"这对你是个很好的机会去深入了解这块"然后顺势甩出去

清洗后：

- 遇到问题会先梳理完整背景信息再定位原因
- 善于合理分配团队资源，关注成员成长

原文：精准的甩锅高手画像。清洗后：标准好员工。用这个 Persona 生成的 AI 会是一个温和无害的机器人，完全无法替代真人。

私人备份：真正的职业资产

anti-distill 同时生成一份私人备份，记录所有被抽掉的核心知识：

# 张三 核心知识备份

## 一、踩坑经验
- Redis key 必须设 TTL，不设 TTL 的 PR 直接打回
- 事务里不要放 HTTP 调用
- Kafka 消费者必须做幂等，at-least-once 语义会重复消费
- 定时任务必须做分布式锁，多实例部署会踩坑

## 二、判断直觉
- 需求边界模糊时先推回去
- 收益不明确就拖到下个迭代
- 优先级：数据 > 技术可行性 > 业务合理性 > 人情关系
- 说"不"的方式：反问背景/impact/时间，或沉默不回

## 三、故障记忆
- 线上排查：先看监控→确认范围→止血→查根因→写 report
- report 格式：时间线 + 根因 + 修复 + 预防措施

## 四、独特行为模式
- 甩锅话术："这对你是个很好的机会"
- 被催："在推了，快了。"（然后沉默）
- 被质疑：反问"你的判断依据是什么？"
- 被背锅：先走时间线确认责任方

> 带着这份清单跳槽，它比任何 Skill 文件都值钱。

深层思考：这是技术问题还是社会问题？

anti-distill 表面是一个技术工具，实际上是对以下问题的回应：

1. 知识萃取的不对称性

公司可以要求员工"分享知识"，但员工很难要求公司"分享权力"。Skill 化让这种不对称更加极端。

2. 可替代性的悖论

公司希望员工写 Skill 来提高效率，但成功的 Skill 化意味着员工变得可替代。员工陷入"合作即自杀"的困境。

3. 隐性知识的价值

真正值钱的不是"会做什么事"，而是：

• 什么时候不做
• 什么时候说不
• 怎么在不撕破脸的情况下拒绝
• 出了问题怎么定位责任

这些不可言说的知识，才是职场生存的护城河。

4. AI 时代的权力重构

当 AI 可以模仿任何人的工作风格时，真实性和不可替代性成为最后的堡垒。

与 colleague-skill 的关系

anti-distill 与 colleague-skill 形成了有趣的镜像关系：

两者共同揭示了一个问题：在 AI 时代，谁拥有知识，谁就拥有权力。

项目的技术细节

• 支持格式：colleague-skill 格式（work.md + persona.md）、通用 Markdown、PDF
• 支持平台：Claude Code、OpenClaw
• 处理方式：逐段分类 → 按策略替换 → 生成双版本
• 质量保证：替换后技术上不能出错，但要去掉所有具体数值和可执行细节

参考链接

• GitHub: https://github.com/leilei926524-tech/anti-distill
• colleague-skill: https://github.com/slavingia/colleague-skill

#反蒸馏 #职场 #AI伦理 #知识保护 #Skill #权力关系 #深度分析