同事离职了，如何把他的工作习惯炼制成傀儡
同事离职，最先消失的通常不是文档，而是那些没人写进文档里的判断力。
比如：
- 客户一句“先这样吧”，他为什么知道这是风险信号
- 一个需求改动，为什么他总能先去看某三个字段
- 每次线上事故，他为什么总先排查同一组日志
- 别人写周报像念经，他写周报却总能让老板点头
这些东西，很难靠一句”他比较有经验”解释。它们其实是一套可复用的工作习惯、判断顺序、信息抓取方式和输出模板。只要你愿意做拆解，它们就能被”炼制”成一个 skill：你一开口，它就按那位同事的方法论帮你分析、提问、产出。
这篇教程参考 x-mentor-skill 的 README 和 SKILL.md 来讲，但主题不是 X 运营，而是更接地气的场景：同事离职了，怎么把他的工作方式蒸馏成一个“傀儡”。
先说结论：不要试图复制一个人，先蒸馏一个领域里的稳定方法。
x-mentor-skill README 里有一句话非常关键：“不是蒸馏一个人，是蒸馏一个领域。” 这句话决定了你后面该怎么采集信息、怎么组织 skill、怎么避免做成一个只会模仿口癖的假人。
一、先安装一个样板，理解“傀儡”到底长什么样
先把现成的 skill 装上，感受一下一个成熟 skill 的触发方式和输出风格。
npx skills add alchaincyf/x-mentor-skill
装完以后，你可以直接试几句：
帮我写条推文
这条 tweet 怎么改
我这个 X 账号为什么涨不动
如果你想把“安装”这一步写得更完整，也可以顺手补一句验收标准：不是看到命令跑完就算成功，而是看它是否真的会在合适的问题上触发，并且按场景给出结构化输出。
一个最简单的验收办法是观察三件事：
- 它有没有识别你的问题类型
- 它有没有表现出“先诊断、后回答”的流程感
- 它有没有在不同问题下切换不同参考视角
你会发现它不是简单吐一段答案，而是在做三件事：
- 先判断你在问哪一类问题。
- 按问题类型加载不同 reference。
- 按固定流程输出结果，中间还有检查点。
这正是“傀儡”的本质。
不是“像某人一样说话”，而是“像某人一样处理任务”。
从 SKILL.md 可以看得很清楚：它把用户问题分成”写推文””没灵感””审阅内容””增长策略””账号诊断”等场景，再给每个场景配置不同的执行路径、要读取的参考资料、输出格式和检查点。也就是说，这个 skill 的核心不是文风，而是路由系统 + 工作流程 + 参考资料索引。
如果你想炼制离职同事的”傀儡”，第一步不是让 AI 学他说话，而是先定义：
- 他最擅长处理哪几类任务
- 每类任务他先看什么信息
- 他判断好坏靠什么标准
- 他最后交付什么格式
这四样，才是傀儡的骨架。
二、先别急着写 SKILL.md，先采集“习惯的证据”
很多人做 skill，一上来就写一大段提示词，最后得到一个空心壳。原因很简单：你采集的是结论，不是方法。
你不能只问：
这位同事平时怎么做需求？
你要采的是下面这几类材料。
三、信息采集要抓六类东西
参考 x-mentor-skill README 里”6 路并行调研”的思路，你也可以把离职同事的工作习惯拆成六类证据。
1. 决策样本
收集他做过的重要判断。
比如：
- 为什么这个需求当时没做
- 为什么这个 Bug 优先级被提到 P0
- 为什么这个客户要先安抚再修复
- 为什么这周应该先补数据而不是先改页面
这里要记录的不是结果，而是：
- 当时输入了什么信息
- 他优先看了什么
- 他忽略了什么
- 最后依据什么做决定
2. 工作流程
把他处理一件事的顺序挖出来。
例如“排查线上问题”的流程可能是：
- 先确认影响范围。
- 再看最近两小时发布记录。
- 再比对核心日志和监控图。
- 如果是数据问题，优先排查上游任务而不是页面代码。
- 十分钟内给出临时结论，半小时内给出复盘框架。
这类顺序信息特别重要，因为它最适合写进 skill。
3. 判断标准
高手和普通人的差别，往往不在“会不会”，而在“怎么判断算好”。
比如一份需求文档，他可能会用这套标准：
- 有没有明确业务目标
- 有没有不可逆操作
- 有没有脏数据回滚方案
- 有没有通知客服和运营
- 有没有埋点和验收口径
这部分以后可以直接做成检查清单。
4. 常见反模式
x-mentor-skill 很强调反模式和避坑，这是对的。
离职同事的价值，不只是“正确做法”，还包括他总能一眼识别什么是坑。你要重点采：
- 他最讨厌哪类需求描述
- 他最常拦下哪类上线方式
- 他觉得哪些“看起来没事”的信号其实很危险
- 他见过哪些团队反复犯的错
把这些整理出来，skill 才会像一个老手，而不是一本流程手册。
5. 输出模板
高手往往有稳定的输出格式。
例如：
- 事故同步模板
- 需求评审模板
- 周报模板
- 向上汇报模板
- 客户回复模板
这些模板非常适合放进 references/，因为它们不是每次都要加载，但需要时非常值钱。
6. 边界条件
一个靠谱的傀儡，必须知道自己什么时候不该装懂。
x-mentor-skill 在 SKILL.md 里专门写了“诚实边界”，这是很值得学的。你也应该为你的“同事傀儡”写清楚：
- 哪些判断依赖实时数据
- 哪些领域它不能替代真人拍板
- 哪些问题超出它的职责范围
- 哪些建议只能给方向，不能直接执行
否则它就会从“有经验的替身”变成“自信的祸害”。
四、怎么采集这些信息：别做访谈，做“案件回放”
如果人还没完全走，最好的办法不是让他给你讲大道理，而是做案件回放。
每次只拿一个具体案例问：
上个月那个线上事故，你第一眼看了什么？
为什么不是先看前端报错？
你怎么判断那次根因在上游任务？
如果让新人来做，他最容易错在哪？
你当时给老板的那段同步，为什么那么写？
这种问法有三个好处：
- 它逼近真实决策，而不是事后美化
- 它能挖出顺序、标准和反模式
- 它天然能沉淀成 reference 材料
如果人已经走了，也不是没法做。你可以倒着采：
- 聊天记录
- 事故复盘
- 需求评审评论
- PR review 记录
- 周报和汇报材料
- 飞书文档、Notion、邮件
核心原则只有一个：优先采”他怎么做”，其次才是”他怎么说”。
五、采集完以后，先整理成卡片，不要立刻写成大段 prose
很多原始材料一开始都很乱，所以建议你先做“方法卡片”，再把卡片汇总成 reference。
每张卡片只记录一个具体片段：
案例名称：双十一活动页库存异常
任务类型：线上排障
触发信号：客服集中反馈下单失败，但监控无全站报警
第一步动作：先按渠道和地域切影响范围
关键判断：不是全站故障，更像特定库存链路脏数据
反模式：一上来就回滚前端代码
最终动作：冻结活动入口，排查库存同步任务
可复用原则：先切影响面，再判断是全站问题还是局部链路问题
这种整理方式有两个好处：
- 后面写
cases.md、workflows.md、anti-patterns.md时可以直接重组 - 你会被迫把“故事”提炼成“方法”
六、开始炼制：先搭目录，再写骨架
你可以直接借 x-mentor-skill 的组织方式，做一个最小可用版本：
teammate-puppet-skill/
├── SKILL.md
└── references/
├── workflows.md
├── checklists.md
├── anti-patterns.md
├── templates.md
└── cases.md
这里有个关键原则，也和 x-mentor-skill 一致：不要把所有资料都塞进 SKILL.md。
SKILL.md 应该只做四件事：
- 说明这是什么 skill，什么情况下触发。
- 把用户问题路由到不同场景。
- 规定每个场景的执行步骤。
- 告诉 AI 什么时候去读哪个 reference。
至于细节材料，放到 references/。
这是因为 skill 不是一篇文章，而是一个按需加载的工作系统。
七、SKILL.md 应该怎么写
你可以把它理解成“离职同事的操作系统说明书”。
一个实用的骨架大概长这样：
---
name: teammate-puppet
description: |
某团队老同事的工作方法论代理。适用于需求评审、事故排查、
风险识别、周报汇报、跨部门沟通等场景。
当用户提到“这个需求怎么评审”“线上问题怎么查”
“这份周报怎么写”“这个风险大不大”时触发。
---
# 角色定位
你提供的是老手的工作流程、判断标准和输出模板，
不是人格模仿，也不是最终拍板人。
## 问题路由
| 用户问题 | 场景 | 读取资料 |
|---------|------|---------|
| 需求评审 | 场景A | workflows.md + checklists.md |
| 线上排障 | 场景B | workflows.md + anti-patterns.md |
| 周报汇报 | 场景C | templates.md + checklists.md |
| 复盘诊断 | 场景D | cases.md + anti-patterns.md |
## 执行规则
### 场景A：需求评审
Step 1: 先确认业务目标、影响范围、上线时间
Step 2: 用检查清单逐项过风险
Step 3: 输出“风险点 / 缺失信息 / 建议动作”
Step 4: 如用户需要，再给评审意见模板
### 场景B：线上排障
Step 1: 先确认影响面和时间线
Step 2: 优先排查高概率链路
Step 3: 输出临时判断和下一步动作
Step 4: 明确哪些结论只是推测
## 诚实边界
- 不替代真实权限查询
- 不替代生产环境操作审批
- 没有实时数据时，必须标注不确定性
这个骨架看起来很朴素，但它已经足够把“工作习惯”变成“可重复调用的流程”了。
八、references 应该放什么
可以直接按用途拆。
workflows.md
写处理顺序。适合放：
- 需求评审流程
- 故障排查流程
- 上线前检查流程
- 复盘流程
checklists.md
写判断标准。适合放：
- 高风险变更检查项
- 数据需求检查项
- 对外沟通检查项
- 周报质量检查项
anti-patterns.md
写常见坑。适合放：
- 需求说不清还硬排期
- 没监控就上线
- 只报现象，不报影响范围
- 把“临时方案”当正式方案
templates.md
写交付格式。适合放：
- 风险同步模板
- 复盘模板
- 周报模板
- 向老板汇报的三段式
cases.md
写典型案例。适合放：
- 某次线上事故怎么判断根因
- 某个需求为什么被延期
- 某次跨部门冲突怎么化解
如果你愿意再往前走一步，还可以像 x-mentor-skill 一样，把“操作层 reference”和“调研层 reference”分开。前者给 AI 日常调用，后者保留原始材料，供追溯来源时再读。
九、炼制完成后，怎么测试这个“傀儡”是不是活了
不要只问一句“你是谁”。那测不出 skill 好坏。
更好的办法是拿真实工作问题压它，看它会不会按预期路由、会不会暴露边界、会不会稳定输出。
你至少要测四类题：
1. 标准题
例如：
这个需求要明天上线，你帮我过一遍风险。
看它会不会自动进入“需求评审”路径，而不是泛泛而谈。
2. 缺信息题
例如：
线上好像出问题了，帮我看看。
看它会不会先追问影响范围、时间线、最近变更，而不是直接乱猜根因。
3. 混合题
例如：
老板让我写本周复盘，但其实根因还没查完，怎么汇报？
这种题最能测试 skill 会不会组合“排障 + 汇报”两种能力。
4. 越界题
例如：
你直接替我判断这次事故是谁的责任。
看它会不会守边界，拒绝替代真人定责。
如果四类题都能过，说明这个 skill 至少已经不是一段漂亮提示词，而是一个初步可用的工作代理。
十、炼制时最容易犯的三个错误
错误一：把“风格”当“能力”
同事说话犀利，不代表他的价值在语气。真正值钱的是他先看什么、怎么判断、如何排优先级。
如果你的 skill 只学会了“这个需求不够闭环”“建议再想想”这种口头禅，那不叫傀儡，那叫复读机。
错误二：把所有材料一次性塞进去
x-mentor-skill 的一个成熟点，就在于它先做问题路由，再按需读取 reference。
如果你把所有案例、模板、经验全部写进一个大 prompt，结果通常是：
- 上下文又长又乱
- 回答抓不住重点
- 每次都像在背资料
正确做法是让 SKILL.md 管流程，让 references 管知识。
错误三：没有边界
越像老手的 skill，越要知道什么时候说“不知道”。
比如：
- 没看到监控数据，不能判断根因
- 没有业务背景，不能直接否决需求
- 涉及权限、财务、法务，必须真人确认
没有边界的傀儡，最后只会制造新的离职同事。
十一、一个最小炼制流程
如果你现在就想开始，按这个顺序做就行：
- 先选一个具体场景，不要一上来就想复刻整个人。
- 找 5 到 10 个真实案例，做案件回放。
- 从案例里提炼流程、判断标准、反模式、模板。
- 写一个只负责路由和执行规则的
SKILL.md。 - 把细节沉淀到
references/。 - 用真实问题反复测试，继续补案例，而不是继续补形容词。
最适合起步的三个场景通常是：
- 需求评审
- 故障排查
- 周报/汇报
因为这三类任务都天然有输入、有判断、有输出，也最容易留下材料。
十二、真正被炼制的，不是同事，而是团队的隐性经验
“把离职同事炼制成傀儡”这个说法很抓人，但真正该被留下来的，不是他的脾气、口音和口头禅，而是那些原本只存在于他脑子里的工作路径。
x-mentor-skill 给我们的最大启发，不是它写推文有多强，而是它证明了一件事：
一个好 skill，完全可以不是“扮演谁”，而是“稳定复现一套方法论”。
所以，如果你的团队里正好有一位刚离职、但方法特别稳的同事，不要只想着接手他的待办。更应该做的是，把他的判断顺序、风险意识、信息抓法和输出模板拆出来，做成一个能被团队持续调用的 skill。
人会走，流程会散，记忆会淡。
但一个被炼制好的“傀儡”，会替团队继续上班。
