上周一个老板问我：他想像同行那样，用 3 个真人带 30 个数字员工跑业务（这个比例是我们推演的示意，不是他的真实编制）。卡点在哪？
不是模型不够聪明，也不是工具不够多。卡在一个很朴素的地方：没有一个中层愿意把自己的判断标准写成文档。
审批到什么金额要上报、哪种客户投诉要升级、什么情况下可以破例——这些判断每天都在发生，但全装在某个管理者的脑子里。数字员工问他，他口头答；换一个场景，又得重新问。
于是 30 个数字员工，每一个都变成了「等他拍板」的排队窗口。
一、不是管理者管 AI，是 AI 倒逼管理者先把自己管明白
我们习惯的说法是「管理者要学会用 AI」。这句话方向没错，但太浅了。
真实发生的事是反过来的：不是管理者学会了管 AI，而是 AI 倒逼管理者先把自己管明白。
数字员工要稳定跑，前提是它的判断标准是显性的、可执行的。而判断标准的源头，是管理者。所以 AI Native 组织的第一道工序，不是部署模型，而是 把管理者脑子里那些「只在特定情境下才做的判断」榨出来，写成规则。
我把这个过程叫 蒸馏——先说清楚，这里不是模型蒸馏（把大模型蒸成小模型），也不是我在组织 AI 化路线图里批评的「人肉蒸馏」（用 AI 加速一个本来就不合理的流程）。这里的蒸馏，是 把隐性的管理判断，编译成显性的组织规则。蒸馏是隐喻，编译是机制。
| 蒸馏前（隐性判断） | 蒸馏后（显性规则） | |
|---|---|---|
| 存放位置 | 管理者脑子里 | 组织规则 / Spec |
| 数字员工能否自主 | 不能，每次都要问人 | 常规场景可以 |
| 管理者角色 | 日常判断的瓶颈 | 规则的设计者 + 例外的裁决者 |
| 规模化 | 1 个管理者卡住 N 个数字员工 | 1 份规则驱动 N 个数字员工 |
数字员工的本分率里我说过，数字员工要有边界——权限系统决定它能不能做。但边界这条线画在哪？答案不在权限系统里，在管理者的判断里。权限系统只是执行者，判断标准的设计者，是那个愿意被蒸馏的管理者。
「把审批判断写下来」具体长什么样？一个被蒸馏出来的审批规则，最小结构是：
from dataclasses import dataclass
@dataclass
class ApprovalRule:
"""把管理者脑子里的审批判断，编译成数字员工可执行的规则。"""
name: str
threshold: float # 金额阈值（被蒸馏的判断）
escalate_to: str # 超阈值上报给谁
purchase_rule = ApprovalRule(
name="采购审批",
threshold=5000.0, # 「5000 以内自己定」——原本只在老板脑子里
escalate_to="部门主管",
)
def decide(amount: float) -> str:
"""数字员工拿到金额，按规则自主决策，不再排队等老板。"""
if amount <= purchase_rule.threshold:
return "自主执行"
return f"升级给 {purchase_rule.escalate_to}"
print(decide(3000.0), decide(8000.0))
# generated by hugo AI
这段代码的价值不在逻辑，而在它 把一句「你看着办」变成了可执行、可审计、可复用的规则。老板那句口头禅被蒸馏成了 threshold 和 escalate_to 两个字段——从此 30 个数字员工都能照着跑，而不用每一个都去排队问他。
二、被蒸馏 ≠ 被替代：剩下的 20%，才是你不可替代的部分
这里是大多数管理者真正焦虑的地方。
我在AI Native 研发的复利里写过一种「蒸馏焦虑」：工程师 Alice 担心「教 Agent 越多，自己越可替代」。那时的解药是「AI 红利是扩边界，不是缩团队」。
对管理者，这个焦虑更尖锐，但答案也更清晰。关键是把判断分成两类：
| 判断类型 | 能蒸馏吗 | 蒸馏后归属 |
|---|---|---|
| 审批阈值（超过多少要上报） | 能 | 编译成规则 |
| 升级条件（什么投诉要升级） | 能 | 编译成规则 |
| 汇报格式 / 异常分级 | 能 | 编译成规则 |
| 什么时候该破例 | 不能 | 管理者裁决 |
| 该信任谁、该赌一把 | 不能 | 管理者裁决 |
能蒸馏的，是 规则性判断——它们有明确的输入、条件、动作，本来就不该占用一个管理者的注意力。蒸馏不出的，是 例外性判断——破例、信任、下注，这些依赖情境、关系和担当，写不成规则。
所以「被蒸馏」不是失去价值，而是 把价值集中到真正稀缺的地方。管理者的工作，从「做绝大部分的日常判断」，变成「设计判断规则 + 裁决规则管不了的少数例外」——80% 和 20% 只是我的粗略比例，重点在方向的倒转。
一个不愿意被蒸馏的管理者，表面上保住了「每件事都要问我」的存在感，实际上把自己锁死在低价值的重复判断里——而且数字员工永远跑不起来。而一个敢被蒸馏的管理者，腾出来的不是岗位，是去做只有他能做的裁决。
三、蒸馏的产物：一条「老板担责」的授权链
管理者把判断编译成规则，数字员工照着规则跑。那么出了问题，责任落在谁身上？
落在授权它的那个「人」身上——也就是发工号的老板。
这条授权链是 AI Native 组织的责任骨架：
老板 ──授权──> 数字员工 ──调用──> AI 执行
▲ │
│ ▼
└──────── 系统审计 <────── 行为留痕 ┘
（老板担责）
# generated by hugo AI
为什么必须是老板担？因为 组织成员的责任，不能落在一个没有法律主体的 AI 上。数字员工是组织成员，但出了事，追责必须追到授权它的那个人。如果这条链断在「AI 自己负责」，数字员工就永远只是工具，不是组织成员。
这其实把数字员工的第一准则不是可控性的结论往前推了一步：那篇说责任要追到「人」，这篇说的是——那个「人」，就是授权者本人。你在Agent Spec 是数字员工的劳动合同里给数字员工签的每一份契约，背后都站着一个为它兜底的管理者。
所以「敢被蒸馏」的完整含义是三件事：
- 敢把判断写下来——让数字员工有规则可依
- 敢退守例外——承认 80% 的判断可以交出去，守住 20% 的裁决
- 敢担责——数字员工出了错，授权的人站出来，而不是甩给「AI 自己干的」
第三条最难，也最关键。前两条是能力问题，第三条是担当问题。一个组织的数字员工能跑多快，上限不取决于模型，而取决于有多少管理者敢同时做到这三件事。
结语
AI Native 组织的第一生产力，从来不是更强的模型，也不是更多的工具。
是 敢被蒸馏的管理者——他们把隐性判断编译成规则，让数字员工有边界、有规则、能自主；自己退守到例外裁决，并为这一切担责。
模型会一直变强，工具会一直更新。但「管理者愿不愿意把自己的判断交出来，并为交出去的判断负责」——这件事，AI 替代不了，也等不来。
你的组织里，有多少管理者敢被蒸馏？欢迎留言聊聊。