如果你第一次看到 vogtsw/boss-skills，很容易被它的名字吸引。
“蒸馏老板”这四个字很有冲击力。它像是在说：把一个老板的认知、判断和管理风格压缩成一个可调用的 AI 分身。听上去像某种人格工程，甚至有点像给组织做小型 AGI。
我最开始也带着这个预期去看它。
真正把仓库、提示词、脚本和样例文件拆开之后，我的判断变了：这个项目做的事情并不神秘，也不玄。它不是在训练模型，也没有把老板“学进参数”里。它做的是另一件更朴素、也更实用的事——把一个老板长期表现出来的判断方式、汇报偏好和表达习惯，整理成一套可调用的 skill。
这篇文章不打算把仓库目录逐个介绍一遍。我更想回答一个更核心的问题：一个叫“蒸馏老板”的项目，真正的技术原理到底是什么？
先把结论放前面
boss-skills 的核心原理，可以概括成一句话：
它更接近行为规则蒸馏。项目没有去训练一个老板模型，而是把老板的隐性管理逻辑改写成结构化 prompt 和 skill 文件。
如果你愿意再压缩一点，它其实是这样一条链路：
原始材料（聊天、纪要、邮件、批注）
→ 抽取老板相关内容
→ 按 judgment / management / persona 三个维度做结构化分析
→ 生成三份规则文档
→ 打包成一个可调用 skill
这就是它最核心的技术路线。
为什么“蒸馏老板”会成为一个真实需求
很多人理解老板，只停在“他说话凶不凶”“好不好沟通”这一层。可真正影响工作质量的，往往是老板的判断结构。
有些老板开会总在追问 impact。
有些老板不怕项目慢，怕的是你慢了还不提前说。
有些老板听不得铺垫，第一句没结论就会打断。
有些老板嘴上强硬，但关键时刻会替团队挡刀。
这些东西平时都散落在聊天、会议纪要、邮件批注和项目评审里。你每天都能感受到它们，但很难把它们说清楚。久而久之，团队里就会出现一种很典型的现象：大家知道老板“不好伺候”，却说不出到底该怎么对齐。
boss-skills 瞄准的，就是这部分长期处于口耳相传状态的组织知识。
它想做的，主要是把下面这些隐性规则显化：
- 他到底怎么判断一个项目值不值得做
- 他在意的是结果、节奏、风险，还是 owner
- 你应该怎么汇报，信息才算到位
- 你该怎么争资源、报坏消息、提方案
- 他在正常状态和压力状态下分别会怎么说话
从这个角度看，这个项目切中的问题是真问题。
它到底蒸馏了什么
仓库里最关键的设计，是把“老板”拆成了三个部分。
1. Judgment：老板怎么判断事
这一层说的不是风格，核心是判断框架。
比如一个老板会先看 impact，还是先看风险；会先看 owner 是否清楚，还是先看资源投入是否值得；会把延期视作正常现象，还是把“延期不报”视作不可接受的失分项。
这部分在仓库里被整理成 judgment.md。
样例里会出现很典型的规则句：
- owner 不明确，就不算 ready
- 风险发现后 24 小时内必须同步
- owner 不是转发消息的人，而是把结果拿回来的人
这些句子很重要。因为它们已经不再是情绪描述，而是可执行规则。
2. Management：你怎么向上管理他
这是这个项目最有意思的地方。
很多“人格模拟”项目只停在“让 AI 像某个人说话”。boss-skills 多往前走了一步：它不只问“老板会怎么说”，还问“你该怎么和他打交道”。
这层会提炼：
- 汇报要先结论还是先背景
- 报风险时必须带什么
- 提方案时是不是要给两个选项
- 争资源时，什么理由最能打动他
- 出了问题后，怎么修复信任
这部分对应 management.md。
如果说 judgment 是“老板的尺子”，management 就是在教你“怎么拿着这把尺子做事”。
3. Persona：老板怎么说话、怎么施压、怎么追问
最后一层才是很多人最先想到的“风格”。
仓库里把这部分写成 persona.md，会覆盖：
- 高频词和口头表达
- 对模糊表达的容忍度
- 什么情况下会打断你
- 什么情况下会明显加压
- 什么情况下会护团队
- 在压力状态下说话会变成什么样
这部分不是拿来做文学模仿的。
它的作用更像一个“输出控制层”：同样一句判断，是冷冷地说出来，还是带着追问压出来，还是先替你兜一下再给建议，差别很大。
所以仓库最后定义的运行逻辑很直接：
收到问题
→ Persona 决定语气和姿态
→ Judgment 评估项目与风险
→ Management 给出向上管理动作
→ 用该老板的风格输出
这已经足够说明它的本质：它是在拼装一个规则驱动的管理人格。
真正的“蒸馏”发生在哪里
这个项目最容易被误读的地方，是“蒸馏”两个字。
在机器学习语境里，蒸馏通常意味着一种模型压缩：把大模型的能力转移给小模型，让知识落在参数里。
boss-skills 完全不是这个路线。
它的“蒸馏”发生在两个层面。
第一层：从原始材料里提炼出稳定模式
仓库的 prompts/ 目录里有三组 analyzer prompt：
judgment_analyzer.mdmanagement_analyzer.mdpersona_analyzer.md
这些 prompt 不做复杂算法，它们做的是强约束分析。
比如 judgment analyzer 会明确要求代理去找：
- 这个老板怎么判断项目值不值得做
- 他怎么判断方案是否过关
- 他怎么判断风险是否可接受
- 他怎么判断一个人是否靠谱
persona analyzer 也不是让模型“自由发挥”，而是要求把标签翻译成具体行为，比如：
- 在什么情况下，他会继续追问
- 在什么情况下，他会直接否定
- 在什么情况下，他会保护下属
换句话说，所谓蒸馏，不是让模型自己“悟”出一个老板。这里走的是固定提纲分析：从材料里提炼稳定规则。
第二层：把规则固化成可调用资产
分析完之后，仓库不会停在一段回答上。
它还有一组 builder prompt：
judgment_builder.mdmanagement_builder.mdpersona_builder.md
builder 的作用，是把前面提炼出来的内容写成结构固定的 markdown 文档。
这样做的好处很实际：
- 规则可以被复用
- 内容可以被更新
- 不同老板可以有统一结构
- 后续纠偏可以按块增量改，不用整篇重来
所以这里的“蒸馏”，本质上是把非结构化材料，转成结构化规则文件。
这是一种知识工程，不是训练工程。
它的代码在做什么，又没做什么
如果你继续往下看 tools/ 目录，会发现代码部分非常克制。
它做了什么
仓库里有几类工具脚本：
wechat_parser.pyfeishu_parser.pygeneric_chat_parser.pyemail_parser.pyskill_writer.pyversion_manager.py
前四个 parser 的能力都很轻。它们主要是在不同格式的导出文件里，把目标人物的发言筛出来，整理成后续可读文本。
skill_writer.py 则负责把最终结果写入一个 skill 目录，生成：
SKILL.mdjudgment.mdmanagement.mdpersona.mdmeta.json- 以及几份拆分后的子 skill 文件
version_manager.py 负责版本存档和回滚。
换句话说，代码负责的是清洗、装配、版本化。
它没做什么
这部分更重要。
这个项目没有：
- 向量检索
- embedding 存储
- RAG 调用链
- LoRA 或 finetune
- 证据打分
- 长期自动学习
- 行为仿真的训练流程
你在仓库里看不到任何“把老板材料喂给模型训练”的链条。
这意味着它的智能核心，不在脚本里，而在 prompt 驱动的分析与生成过程中。
更准确一点说：
脚本是工地上的脚手架，真正完成蒸馏动作的是一套有约束的提示词工作流。
为什么这种方法居然是有效的
看到这里，很多人会下意识地觉得：既然没有训练，没有 RAG，没有复杂算法，那这是不是只是个漂亮一点的 prompt 包装？
某种意义上说，是。
但“只是 prompt 包装”不等于没价值。
这个项目有效，恰恰因为它抓住了组织中的一个关键事实：
一个老板最难复制的，往往是他的判断顺序。
如果你把一个老板的思考方式拆开，通常最后剩下的就是几类东西：
- 先看什么
- 哪些变量最重要
- 哪些表述会触发不信任
- 什么信息不全就不能拍板
- 什么情况下会给资源，什么情况下会先砍范围
这些东西本来就是规则化的。
它们未必需要训练进模型参数，只要能够被稳定描述，并在回答时按顺序调用，就已经能复现出相当强的“像他”的感觉。
这也是为什么 README 里一再强调，它不追求模仿口头禅，而是抽象管理方式、判断框架和沟通节奏。这个方向是对的。
很多所谓的人格模拟，最后只做成了“会学腔调的聊天机器人”。boss-skills 至少试图把东西拉回工作流本身。
这个项目真正的边界在哪里
夸完之后，边界也得说清。
第一，它更像“静态规则包”，不像“动态认知系统”
当前生成出的 skill，本质上是一组静态 markdown 文件。
这意味着一旦老板在不同场景下表现出冲突行为，比如：
- 对小项目看速度，对大项目看稳妥
- 对核心下属容忍度高，对边缘协作团队容忍度低
- 对上汇报和对下管理完全是两套话术
系统不一定能自然处理这些分层。除非写 skill 的人主动把场景边界补进去。
第二，它缺少证据回链
一条规则写出来以后，读者很难知道这条结论到底来自哪段聊天、哪次纪要、哪封邮件。
这会带来两个问题：
- 可解释性不够
- 新人接手时不容易校验
如果以后真要做成组织工具，证据回链几乎是必需的。
第三，它更依赖材料质量，而不是系统自我修复能力
README 里其实已经很诚实地承认了这一点：如果只给语气，不给项目材料，skill 会更像“会说话”，不一定像“会判断”。
这句话很关键。
因为它说明这个系统的下限，并不由 prompt 决定，而是由输入材料决定。材料一旦薄、偏、旧，蒸馏出来的规则就会空。
第四，它的修正方式还是“打补丁”
仓库里有一个 correction_handler.md，专门处理这种反馈：
- 他不会这么说
- 他不会先看这个
- 他更在意的是 xxx
系统收到这类纠偏后，会把修正写回 judgment、management 或 persona。
这说明它的演化机制并不是学习，而是增量补丁。
这不一定是坏事。对早期产品来说，这反而很稳。
但这也意味着，它离真正的“持续学习型组织人格系统”还有不小距离。
如果把它放到更大的坐标里看
我觉得 boss-skills 最值得肯定的地方，在于它提醒了我们一件事：
组织里那些最影响结果的知识，很多时候根本不在 SOP 里，而在人的判断里。
过去这类知识通常靠三种方式传递：
- 跟老板久了，自己摸出来
- 老员工口口相传
- 出了几次事故之后，全员长记性
这套传递方式当然真实，但也非常低效。它慢，不稳定，而且极度依赖个人经验。
boss-skills 提供的视角是：这些“看不见的管理逻辑”，其实是可以被提取、命名、结构化和封装的。
哪怕第一步只是 prompt + markdown，它也已经迈出了把隐性组织知识资产化的一步。
如果要做下一代，它应该往哪走
如果把今天这个仓库看作 v1，我觉得下一代最值得补的不是更花哨的人格模仿，而是三个基础层。
1. 证据索引层
每一条 judgment、management、persona 规则，都应该能回链到原始材料。
最好不是简单附一句“来自聊天记录”，而是能带：
- 来源类型
- 时间
- 场景
- 摘要片段
- 置信度
这样一来，规则就不再只是主观总结，而变成可审计资产。
2. 场景分层层
同一个老板在不同情境下，往往像不同的人。
对外部客户、对内部汇报、对高风险事故、对季度规划，他的判断顺序可能完全不同。
所以未来不该只有一个统一人格包，而应该至少有场景化层：
- 评审模式
- 事故模式
- 周报模式
- 争资源模式
- 对上汇报模式
这样 skill 才会从“像”变成“真能用”。
3. 调用编排层
现在的逻辑比较像：读一份静态规则，然后回答。
更合理的方式，应该是：
识别当前场景
→ 找到对应证据和规则
→ 判断是否存在冲突规则
→ 选择当前最适用的 judgment / management / persona 组合
→ 再输出
做到这一步，它才更像一个组织认知系统，而不只是一个 skill 生成器。
最后的判断
如果只问一句：boss-skills 到底是怎么“蒸馏老板”的？
我的答案是：
它并没有把老板训练成一个模型，也没有发明什么复杂的认知引擎。它做的是更扎实、也更容易落地的一步——把老板长期表现出来的判断规则、向上管理偏好和表达风格，从聊天、纪要、邮件和批注里提炼出来，再固化成一套可调用的 skill。
这条路线的关键，不在于模型有多强，而在于你有没有把“一个人究竟靠什么在做判断”这件事拆对。
从这个意义上看，boss-skills 不是终局。它更像一个很好的起点。
它真正提醒我们的，是另一件更重要的事：
组织里的隐性判断，本来就可以被结构化。