打磨咨询级的 PPT 全流程生产引擎手记

写在前面

如果你也在打磨自己的 AI 智能体，这篇文章应该能引起你的共鸣。

不是那种“我用 Cursor 半小时做了一个 App”的爽文，也不是“Agent 颠覆一切”的布道。就是一个普通人，花了好几周时间，反复打磨一个 AI 技能，从“能跑”到“能用”到“敢拿出来给人用”的全过程记录。

这个技能叫深映（Sloth-DeckStudio-Den）——一个咨询级的 PPT 全流程生产引擎。它能帮你从一句话需求出发，走完深度研究、叙事架构、视觉导演、幻灯片渲染、质量审查五个阶段，最终交付一份可直接面向决策者的 。pptx 文件。

听起来很酷对吧？但从“能跑通 demo”到“敢交给真正的咨询顾问审视”，中间的距离，远比想象中大。

这篇文章，我想把这个距离拆开来讲。

起因：一个让人又爱又恨的技能

故事要从深映的“前史”说起。

去年底，我用 QoderWork 平台搭建了 Sloth 家族的几个技能——自媒体运营、B2B 销售、装备制造报价、留学生全能助手。每个技能都在各自的领域解决真实问题，我也逐渐摸索出了一套可复制的开发方法论。

但 PPT 这个方向，一直是我心里的一根刺。

原因很简单：PPT 太常见了，也太难做好了。市面上不缺“AI 做 PPT”的工具，但大部分产出的东西，明眼人一看就知道是 AI 做的——配色刺眼、排版随意、图表像十年前的风格。McKinsey 的顾问看到这种 PPT，大概会默默关掉文件，然后给你发一封“谢谢，我们自己来”的邮件。

我不甘心。

深映的初始版本，其实已经“能跑”了。五阶段流水线搭好了，12 种布局模板就位了，11 套品牌预设配置好了，58 个矢量图标准备好了。SKILL.md 写了 1028 行，把从研究到渲染的每一步都交代得清清楚楚。

但是——“能跑”和“好用”之间，隔着一道看不见的鸿沟。

现实：1028 行 SKILL.md 背后的隐患

第一个让我意识到问题严重性的，是 token 消耗。

每次调用深映，光是加载 SKILL.md 就要吃掉大量上下文窗口。1028 行的指令文档，AI 读到后半段，前半段的细节已经开始模糊了。这就像一个厨师，菜谱背到第 50 页，第 3 页的火候要求已经忘光了。

更要命的是，所有核心逻辑都堆在一个文件里。图表推荐、布局检索、品牌适配、密度审计、事实核查……27 个 Python 模块各自为战，没有统一的模板规范，也没有缓存机制。每次渲染都是“从零开始”，同样的布局结构，换个内容又要重新算一遍。

我做了个粗略的估算：一次完整的 15 页 PPT 生产，光重复计算就浪费了将近 40% 的 token。

这不行。

六条战线，同时开打

下定决心优化之后，我列了一张清单。不是那种“有空再说”的愿望清单，而是“这次一定要解决”的作战计划。

六条战线，优先级从高到低：

第一，模板标准化。 12 种布局模板，每种都要有统一的 Blueprint 规范——页面类型、内容槽位、数据绑定规则，全部写成标准格式。不再允许“这个模板比较特殊，例外处理”的情况存在。

第二，Blueprint 渲染优化。 建立从 Blueprint 到 SVG 的确定性渲染路径。同样的输入，必须产出同样的输出。不再依赖 AI 在渲染阶段的“临场发挥”。

第三，并行渲染。 页面之间没有依赖关系，为什么要一页一页串行渲染？改成并行处理后，15 页 PPT 的渲染时间直接砍掉了一大半。

第四，缓存机制。 相同的布局结构+相同的数据类型 = 相同的渲染结果。把计算过的结果缓存起来，下次直接复用。

第五，合规预检。 在渲染之前，先跑一遍“飞行检查”：数据完整性、格式规范性、品牌一致性。问题在源头发现，比渲染完了再返工便宜 10 倍。

第六，智能主题推荐。 这是最有技术含量的一项——根据 Blueprint 的内容特征，自动推荐最合适的品牌主题。

关于第六项，我想多说几句。

我设计了一个五维度评分引擎。它不是简单的关键词匹配，而是从五个维度综合打分：场景匹配（0-25 分，“路演”内容自动加分给 pitch-vc 主题）、模板亲和（0-20 分，数据密集型报告不适合叙事型主题）、图表适配（0-25 分，从 YAML 品牌预设中提取每种主题对图表类型的偏好）、信息密度（0-15 分，高密度内容匹配高密度主题）、视觉平衡（0-15 分，用对数空间比较避免零除问题）。

五个维度加起来，满分 100。11 套品牌预设逐一打分，排出座次，给出推荐理由。

听起来挺优雅的对吧？

开发过程可一点都不优雅。

模板分类第一次就写错了——我把三个不存在的模板名写进了分类列表，导致评分引擎在匹配时直接“抓空”。还有一次，信息密度维度的计算在纯数据报告上直接崩溃了，因为叙事内容占比为零，导致密度比的计算出现了除零错误。最后用 math.log1p() 把线性空间转换到对数空间才解决。

你看，这就是打磨。不是灵光一闪的浪漫故事，是一个坑一个坑填过去的苦活。

五轮实测，六个 bug

六条战线的优化完成后，我长舒一口气，觉得差不多了。

然后现实给了我一巴掌。

我决定用五个完全不同的 AI 主题来做端到端测试，每个主题都是一份完整的、可交付的 PPT：

五个主题，覆盖了咨询报告、创业融资、技术演讲、政策研究、产品发布五个差异极大的场景。26 项测试用例，从 Blueprint 生成到 SVG 渲染到 PPTX 转换，全流程跑通。

结果？第一轮就炸了。

Bug 1：theme.get("inverse") 抛出 AttributeError。 渲染引擎把 Theme 对象当成了字典来访问。Theme 是个类实例，不是 dict，应该用 getattr(theme, "inverse", False)。这种错误，代码审查看不出来，只有真正跑起来才会暴露。

Bug 2：TPL-COMPARISON 模板的 items 格式不对。 Blueprint 里写的是字符串数组 ["选项A", "选项B"]，但模板期望的是字典数组 [{"label": "选项A"}, {"label": "选项B"}]。一个格式差异，整个对比页渲染失败。

Bug 3：Windows 多进程 spawn 问题。ProcessPoolExecutor 在 Windows 上需要 if __name__ == '__main__': 保护，否则子进程会递归创建，直接卡死。macOS 上跑得好好的，Windows 上就翻车了——跨平台兼容性的经典坑。

Bug 4：chart_recommender 的导入方式错了。 测试脚本试图 from chart_recommender import ChartRecommender，但 chart_recommender 是函数式 API，不是类。测试代码本身就有 bug。

Bug 5：GBK 编码问题。 Windows 默认编码是 GBK，测试输出文件读回来时乱码。必须显式指定 encoding="gbk"。

Bug 6：智能推荐的模板分类错误。 这个前面提到了——三个不存在的模板名混进了分类列表。

六个 bug，每一个都不大，但每一个不修都会导致某个场景下的崩溃。

修完之后，五个主题全部跑通。25 项端到端测试，全绿。

那一刻的感觉，怎么说呢——不是狂喜，是一种安静的踏实。就像打磨一件木器，最后一遍砂纸走过，手摸上去，终于没有毛刺了。

家族公约审计：8 项合规问题

你以为到这就结束了？

还没有。

深映是 Sloth 家族的成员。家族有一套公约——命名规范、文件结构、Frontmatter 格式、README 品牌标识、CHANGELOG 标准……一共 9 大类、33 项检查。

我对深映做了一次全量审计。

结果：8 项不合规。

没有 🔴 必修项，但 8 个 🟡 加在一起，说明一件事：这个技能在“功能”层面已经打磨得不错了，但在“工程规范”层面还有很多债没还。

这其实是很多 AI 技能项目的通病——功能做得很炫，但版本号对不上、文档格式混乱、私有文件散落在仓库里。就像一个厨师，菜做得很好吃，但厨房一团糟。

我花了半小时，逐项修复：更新版本号、纠正英文标题、重写 CHANGELOG 为标准格式、把散落文件迁移到 references/、补全 。gitignore 规则。

8 项全部修复，提交推送，打了 v3.2.0 的 tag。

打磨这件事

回头看这段历程，我想分享几个真实的感受。

第一，“能跑”到“能用”的距离，远比你想象的长。

深映的第一版 demo 大概花了我两三天。但从 v2.0 到 v3.2.0，中间的优化、测试、修复、合规对齐，断断续续花了将近三周。而且这还是在有完整方法论指导的情况下——如果不是之前几个技能积累的经验，这个时间可能要翻倍。

第二，AI 技能的打磨，和传统软件工程有本质区别。

传统软件的 bug 是确定性的——要么报错，要么不报错。但 AI 技能的“bug”很多时候是“质量不够好”——图表配色凑合能用但不够专业，叙事结构完整但缺少张力，排版对齐了但视觉节奏太平。这种“质量 bug”没有报错信息，只有你拿给真正懂行的人看，才能得到反馈。

所以深映的五阶段流水线里，每个阶段都有质量门禁。DeepScout 的数据不够丰富？打回重搜。Architect 的叙事弧线太平淡？要求增加认知张力。SlideWright 的渲染太单调？回到 Visual Director 重新规划。

对平庸零容忍——这不是一句口号，是写在代码里的质量门禁。

第三，跨平台兼容性永远不能假设。

我在 macOS 上开发，测试全部通过。结果一上 Windows，多进程 spawn 问题、GBK 编码问题接连暴露。如果你的技能要面向多平台用户，请一定在目标平台上做完整测试。

第四，工程规范不是“锦上添花”，是“产品化”的标志。

版本号对齐、CHANGELOG 规范、私有文件管理——这些看起来不起眼的“小事”，恰恰是区分“个人玩具”和“可交付产品”的分水岭。一个连版本号都对不上的技能，你怎么敢交给客户用？

深映能为你做什么

说了这么多打磨的故事，你可能想知道：深映现在到底能做什么？

简单说，它能帮你从一句话需求到一份咨询级 PPT 的全流程自动化。

你只需要说：“帮我做一份关于 XX 的 PPT。”

然后深映会：

深度研究（DeepScout）——多源数据采集，框架驱动的信息填充，不是随便搜几条就完事。

叙事架构（Architect）——找到你的“灵魂句”（soul sentence），围绕它构建 MECE 验证的叙事骨架。不是堆砌信息，是讲故事。

视觉导演（Visual Director）——6 种视觉主角类型，根据内容特征选择最合适的视觉语言。数据说话就用数据可视化，情感共鸣就用大图留白。

幻灯片渲染（SlideWright）——SVG 到 PPTX 的像素级转换。12 种布局家族，16 种图表类型，雾霁蓝色系设计系统。

质量审查（Compass）——L1 逻辑 + L2 数据 + L3 视觉，三重检查。不是走过场，是真的会打回重做。

而且现在有了智能主题推荐——你不需要纠结该用哪套品牌预设，引擎会根据你的内容自动推荐最匹配的主题。

写在最后

打磨一个 AI 技能，和打磨一件手工艺品，本质上是同一件事——你愿不愿意在没人看到的地方，再多花一点心思。

1028 行的 SKILL.md 拆成 10 个文件，是为了节省那几百个 token 的上下文消耗。五维度评分引擎的对数空间转换，是为了解决纯数据报告场景下的边界问题。CHANGELOG 的格式规范化，是为了让下一个接手项目的人能快速理解版本演进。

这些事情，不做也能用。但做了，就是“能用”和“好用”的区别。

慢一点，深一度。

这不只是树懒老 K 的品牌 slogan，也是我在这段时间打磨深映过程中最深的体会。

如果你也在打磨自己的 AI 智能体，希望这篇文章能给你一点共鸣和参考。打磨的过程确实辛苦，但当你看到最终产出拿给真正懂行的人看，对方点头的那一刻——一切都值了。

*关注「树懒老K」公众号，获取更多 AI 技能开发的一手经验。