“蒸馏同事 Skill”写到第三篇。前两篇分别做了表格质检和视频复核：把同事重复做、又有明确标准的工作流程拆进 Skill 里，让它照着流程执行。这篇换一个更多人遇到过的事：做 PPT。

老板上午说，下午要开会

这个场景应该很多人都遇到过。上午老板说，下午要过一个方案。PRD 有了，BRD 有了，方案文档也有了。材料都在，但 PPT 还没开始写。

方案文档十几页，会议可能只给二十分钟。老板想先看结论、风险和下一步决策，团队想知道自己要配合什么。可方案文档不能直接拿去开会，你还要重新拆大纲、顺故事线、压缩文字、补图表、画流程图，最后再套公司模板。

一来一回，两小时很容易就没了。所以我做了一个 Skill：把现成方案，快速变成一套能讲、能对齐、能开会用的 PPT。

第一步：先拆 PPT 大纲

这个 Skill 不会一上来就生成页面。我会先把 PRD、BRD 或方案文档丢进去，让它完整读一遍材料。读完以后，它先拆 PPT 大纲。

这里我最关心几件事：

• 这场会要解决什么问题
• 听众是谁
• 结论怎么先讲清楚
• 汇报故事线应该怎么走
• 最后要产出什么结果
• 哪些地方需要数据依据
• 哪些风险和决策点必须摆出来

这一步别省。很多 PPT 写得慢，卡住人的地方是“不知道该怎么讲”。先把大纲拆出来，人再确认方向，后面就不容易跑偏。

写到这里，我发现它和前两篇的做法很像。表格 Skill 先拆规则，视频 Skill 先拆 SOP 和证据标准，PPT Skill 先拆汇报大纲和故事线。每次都是先把人的判断框架拆出来，再让它去执行。

第二步：确认大纲，再细化每一页

大纲出来以后，我不会直接让它继续生成，而是先让人看。方向对了，再进入第二步：拆每一页。

这一步会把 PPT 细化到页面级：

• 每一页标题是什么
• 正文写多少字合适
• 哪些内容要用数据辅助
• 哪些地方适合画流程图
• 哪些地方适合画业务图
• 这一页在整场汇报里承担什么作用

这里要确认的东西很多：方向、边界、删减，还有哪些页面必须重点讲。拆完以后，Skill 会输出一份 Markdown 文档，按页写清楚这一页讲什么、放什么文字、配什么图形、重点是什么。

这份文档给人确认，比直接甩一堆 PPT 页面更靠谱，可以减少 PPT 不满意反复修改的时间，也可以节省大量生图成本。如果大纲有问题，改大纲；如果某一页逻辑不顺，改这一页。不用等整套 PPT 生成完，才发现故事线不对。

第三步：套公司 VI，批量生成 PPT

等每一页内容确认完，再进入生成阶段。这个 Skill 里会预置公司的 PPT 模板和 VI，比如字体、颜色、标题样式、图表风格、常用版式，都提前放进去。

它会根据确认后的页面内容，按公司母版和常用版式组件生成可编辑 PPT 初稿，最后组合成一份完整 PPT。用户不用从零调样式，也不用每一页都重新想怎么排。

更适合公司内部使用的点在这里：它会尽量贴合公司原来的模板和汇报习惯，页面克制、结论清楚、方便二次编辑，减少那种看起来很炫、但没法直接拿去汇报的随机感。

我真正想蒸馏的能力

我这次想蒸馏的，不只是“做 PPT”这个动作，更是一个同事长期积累下来的汇报经验：拿到方案后，怎么判断汇报主线，怎么把长文档压成几页，哪里该放结论，哪里该放数据，哪里该画业务流程。

哪些内容适合老板快速看，哪些内容适合团队会后继续细看，这些判断平时都藏在人的经验里。把它拆出来，写进 Skill，下一次遇到类似场景就能复用。

从表格、视频到 PPT

回头看这三篇，其实是一条线。第一篇是数据，第二篇是视频，第三篇是文档和 PPT。它们处理的材料不一样，但方法很像：先找到一个同事每天都在重复做、又有明确标准的工作，再把里面的判断顺序、证据标准、输出格式拆出来。

最后让 Skill 负责读取、拆解、组织和生成初稿。人不用从 0 开始干重复劳动，只需要在关键节点做判断。这就是我理解的“蒸馏同事 Skill”：把同事已经验证过的工作方法，变成团队可以反复调用的流程。

以前做一版方案汇报 PPT，可能要花两个小时。现在先用 Skill 跑一版，五分钟左右就能拿到一个可讲版本，后面人再做判断和微调。这类小工具看起来不大，但用在真实工作里，体感会很明显。因为它省掉的，刚好是那些最耗眼睛、最耗耐心、最容易被临时需求打断的部分。