“蒸馏老板”到底在蒸馏什么：拆开 `boss-skills` 之后，我看到的是一套行为规则生成器

如果你第一次看到 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.md
• management_analyzer.md
• persona_analyzer.md

这些 prompt 不做复杂算法，它们做的是强约束分析。

比如 judgment analyzer 会明确要求代理去找：

• 这个老板怎么判断项目值不值得做
• 他怎么判断方案是否过关
• 他怎么判断风险是否可接受
• 他怎么判断一个人是否靠谱

persona analyzer 也不是让模型“自由发挥”，而是要求把标签翻译成具体行为，比如：

• 在什么情况下，他会继续追问
• 在什么情况下，他会直接否定
• 在什么情况下，他会保护下属

换句话说，所谓蒸馏，不是让模型自己“悟”出一个老板。这里走的是固定提纲分析：从材料里提炼稳定规则。

第二层：把规则固化成可调用资产

分析完之后，仓库不会停在一段回答上。

它还有一组 builder prompt：

• judgment_builder.md
• management_builder.md
• persona_builder.md

builder 的作用，是把前面提炼出来的内容写成结构固定的 markdown 文档。

这样做的好处很实际：

• 规则可以被复用
• 内容可以被更新
• 不同老板可以有统一结构
• 后续纠偏可以按块增量改，不用整篇重来

所以这里的“蒸馏”，本质上是把非结构化材料，转成结构化规则文件。

这是一种知识工程，不是训练工程。

它的代码在做什么，又没做什么

如果你继续往下看 tools/ 目录，会发现代码部分非常克制。

它做了什么

仓库里有几类工具脚本：

• wechat_parser.py
• feishu_parser.py
• generic_chat_parser.py
• email_parser.py
• skill_writer.py
• version_manager.py

前四个 parser 的能力都很轻。它们主要是在不同格式的导出文件里，把目标人物的发言筛出来，整理成后续可读文本。

skill_writer.py 则负责把最终结果写入一个 skill 目录，生成：

• SKILL.md
• judgment.md
• management.md
• persona.md
• meta.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 不是终局。它更像一个很好的起点。

它真正提醒我们的，是另一件更重要的事：

组织里的隐性判断，本来就可以被结构化。