内网自建基于模板的PPT Skill 梳理总结

前记:公司内经常都要写汇报材料，基本上都是以PPT为主，市面上的 PPT AI 工具还是有很多的,可惜我在金融内网,数据不出域、不能连公网,那些云端产品一个都用不了。于是我起了个念头——干脆自己在内网搓一个基于模板的 PPT skill,把"从一段汇报文字到一份能直接改的 PPT"这条路打通。

真动手之前,我先花了不少时间把两件事摸清楚:现在的"PPT AI"到底发展到哪一步了、那些开源网红项目底层是怎么做的、能不能直接抄进内网。然后这两天我分别用 Claude Code 和 Codex 各写了一个 skill 试水。结论有点扎心:两个都没做成。但正是这两个"没做成",让我对"PPT skill 到底该怎么设计"有了更明确的方向。

本文就是这一轮调研 + 踩坑的整理总结。

一、PPT AI 早已不只是「一段文字变几页」

原以为 PPT AI 就是"输入文字,吐出几页幻灯片"。深挖之后发现,截至 2026 年中,它早已把"生成一份 PPT"这件事,拆成了一条多阶段的流水线:

资料理解 → 提纲与叙事规划 → 版式选择 → 内容填充(文字 / 图表 / 素材)→ 原生对象渲染(写入 PPTX)→ 排版质检与校对。

每一段都不难理解:先读懂你给的资料,再想清楚每页讲什么、按什么顺序讲,然后为每页挑一个合适的版式,把文字、图表、配图填进去,渲染成一份真正的 pptx,最后再检查有没有溢出、重叠、占位符残留。公开产品和学术研究都在朝同一个方向收敛,这个方向可以用一句话概括:

上游用大模型做理解、规划和自然语言交互;下游用确定性的版式库、渲染引擎、OOXML/PPTX 写入器和质量检查,来保证结果可编辑、稳定、排版不翻车。

微软在 Microsoft 365 Copilot 里就是把 LLM、Microsoft Graph 和 Office 应用编排在一起;Google、Canva 各自强化协作、模板、图像与设计工作流;开源和学术侧则普遍在探索"文档到幻灯片""结构化 JSON 到布局""可编辑矢量输出"这些路线。

但这里必须先泼一盆冷水。别对"全自动、一次成稿、不用改"抱幻想。近期两个专门评测 PowerPoint Agent 的基准都说明,当前前沿模型在复杂、长链路、对布局敏感的 PPT 任务上仍然很脆弱:

• PPT-Eval:强模型在它的 120 个任务上,成功率只有 45%,平均部分得分 57%。
• PPTArena:结构敏感、跨页、母版样式与动画类的编辑,远没到"企业级放心放手"的程度。

这两个数字很重要，它直接决定了我们的设计取向:别赌端到端全自动,要把确定性的活儿从模型手里抢回来。

二、四条 PPT 生成技术路线横评

顺着上一节"上游模型规划、下游确定性渲染"的框架往下走,真正决定成败的是下游到底用什么把幻灯片"摆"出来。综合两份调研报告,能落地的技术路线其实就四条,我把它们摆在一起对比:

逐条客观看一下报告里的依据:

• (a) 代码库直接生成:用 python-pptx / pptxgenjs 之类的库直接写 OOXML,好处是可以直接指定中文字体、分页完全可控、纯库无外部依赖、离线能力极好,产物天然原生可编辑;insert_chart 能生成数据可改的原生图表而非图片。短板是设计丰富度得靠自己堆版式库,上限受限。报告把它连同 (c) 视为性价比最高的默认首选。
• (b) HTML/Web 渲染再转 PPTX:CSS 表现力最强,但这是个陷阱——Marp、Slidev、reveal.js 导出的 .pptx,底层机制(PptxGenJS 把每页当背景图处理)决定了它基本是"每页一张背景图"的图片版:不可编辑、清晰度受限、动画全丢;社区实测也印证了这点。而且中文比英文更容易在转换里出现字体替换和排版错位;那些在线工具号称的"pixel-perfect 100% 保真",本质也是靠把每页渲成高分图片实现的。
• (c) 母版(.potx)填充:设计师预制母版,代码按占位符/版式填内容,可维护性最好——改模板即可,不用动代码;品牌统一、原生可编辑。需要更强的原生图表和母版复用时,可以用 pptxgenjs 的 defineSlideMaster 或 pptx-automizer 的模板注入补强。它最适合"版式收敛、品牌统一、正式可编辑交付"的场景。
• (d) AI 手写 SVG→DrawingML:设计感最高,把矢量 SVG 翻译成原生 DrawingML 后依然可编辑;但每页让 AI 手写 SVG,token 成本高、稳定性吃模型,而且成套实现往往带联网的配图/公式/TTS 依赖,核心导出虽可离线,整体工程量偏重。

结论很干脆:在"内网 + 原生可编辑"这个硬约束下,默认走 (a)+(c),用 PPT 生成库直接写 OOXML;HTML((b))适合当预览和快速迭代,不能作为正式导出。 路线 (d) 设计感最高,但成本与稳定性问题决定了它只适合作为后置的"高设计感模式"。

三、拆解三个「网红」Skill：它们到底是怎么做出来的

调研时绕不开三个被反复点名的开源/官方项目。我最关心的不是"谁好谁坏",而是它们底层到底怎么做的,以及能不能直接抄进内网。有意思的是,这三个刚好各自代表了上一节的一条路线——ppt-master 是路线 (d),歸藏是路线 (b),Anthropic 官方 skill 则同时覆盖 (c) 和 (b)。拿它们当活样本,正好把四条路线的取舍看得更具体。

说明:这一节的更细拆解(目录结构、关键脚本、prompt 组织)我还在补第一手材料,本文先讲到"技术方案"这一层,后续会再补一篇细的。

ppt-master(hugohe3,MIT,约 3.7 万 stars)—— 路线 (d):AI 手写 SVG→DrawingML —— 目前"有设计感 + 可编辑"最接近理想的开源实现。

它的流水线是:源文档 → Markdown → Strategist 出设计规格 → Executor 逐页手写 SVG → SVG 质检 → finalize → svg_to_pptx。核心一招是把每页 SVG 翻译成原生 DrawingML(<path>→<a:custGeom>、圆角矩形→roundRect、渐变→<a:gradFill>),所以默认导出的是真·可点选、可编辑的形状与文本框,而不是图片。官方一句话说得挺好:SVG 和 DrawingML "是同一种理念的两种方言"。它还内置 20 个版式模板、52 个可视化模板、6700+ 矢量图标,资源很足。

但要进内网,障碍不小:每页 AI 手写 SVG,token 消耗大、稳定性吃模型;它禁用 @font-face,依赖目标机已装好 PPT-safe 字体;而 AI 配图、Web 图搜、LaTeX 公式渲染、TTS 全都要联网。好消息是,"文字 + 自备图片"这条基础链路的后处理和导出,是可以完全离线的。

歸藏 guizang(op7418,MIT,约 2 万 stars)—— 路线 (b):HTML/Web 渲染 —— 设计质量极高,但形态不对。

它生成的是单文件 HTML 横向翻页 PPT,有两套视觉系统(电子杂志风 10 布局 + 5 套锁定主题色 / 瑞士国际主义 22 版式 + 4 套锚点色),README 里那句话我很认同:"不允许自定义 hex 值,保护美学比给自由更重要。" 但它明确不能产出 .pptx,字体依赖 Google Fonts CDN,还有 WebGL 流体背景——跟"内网可编辑 pptx"完全不搭。它对我的价值,是当成一份"版式规则 / 设计 checklist"来学。

Anthropic 官方 pptx skill —— 同时覆盖路线 (c) 和 (b) —— 它揭示了业界主流做法,而且有一处特别值得抄。

它给了两条路:一条是编辑/模板路径(markitdown 抽取 → unpack 解包 OOXML → 生成缩略图 → inventory 抽文本清单 JSON → 用 replacements.json 回填 → pack),本质就是路线 (c) 的母版填充;另一条是从零创建(HTML/CSS 设计单页 → Playwright 渲染 → PptxGenJS 生成),就是路线 (b),但它自己给的一堆硬约束(web-safe 字体白名单、渐变和图标必须先光栅化成 PNG、HTML 尺寸必须严格对齐否则报溢出)——恰恰暴露了 HTML→PPTX 这条路有多脆弱。

一句话结论:网红能给你底层机制、美学和工程思路,目前看来没有一个能直接抄进金融内网——不是要联网,就是只出 HTML,再不就是字体走 CDN。真正能在内网交付的东西,还得自己搓。

四、母版/模板：一份 PPT Skill 里到底该放什么样的模板

这一节是我这轮踩坑最大的收获。做 PPT skill,最容易被忽略、又最要命的,不是模型,而是你喂给它的那份模板本身。

先搞清楚：PPT 模板在结构上到底是什么

很多人以为模板就是"一套好看的配色皮肤",这是最大的误解。PowerPoint 官方把模板定义成"主题 + 针对某种用途的内容",它背后真正决定"能不能被自动化"的,是四层结构:

母版(Slide Master)→ 版式(Slide Layout)→ 占位符(Placeholder)→ 主题(Theme)。

关键是占位符:当内容落进 layout 上的占位符里,它会自动继承位置、尺寸、字体、格式;主题则统一管着配色和字体族。只有当一份模板把标题、正文、图片、图表、页脚都做成了可识别的版式和占位符,AI 才能稳定地"把内容放对位置"。

真正的瓶颈：模板够不够「结构化」

这是这轮调研我最想强调的一句话:

这条路线的瓶颈,从来不是"模型会不会写内容",而是"模板是否足够结构化"。

如果一份模板其实是一堆手工摆的自由文本框、装饰形状、截图图表、局部调过的位置——报告里管这叫"假模板"——那不管模型多强,结果都是溢出、错位、字体替换、图表不可编辑、图片裁切失真。反过来,一份"结构清晰"的模板,哪怕设计朴素,AI 也能稳稳套上。所以有个反直觉但特别重要的结论:

"模板好不好用"和"好不好看"是两回事。 那些完全靠手工摆文本框、截图图表堆出来的"漂亮模板",恰恰是最难自动化的。

实操判断：先分清模板是哪一种

再往下,是我自己踩坑换来的一个判断——"套用模板"其实有两种完全不同的含义,取决于模板文件本身是什么东西,对应两种渲染策略:

用错策略的代价我是真金白银付过的:品牌规范型只有 5 页,你去"克隆"它——无米可炊;成品版式库你去"从零自绘"——结果就是难看的"太简单"。 下一节你会看到,我用两个不同的工具各写一个 skill,两个都独立收敛到了"自绘 vs 克隆"这对模式,也都被同一句反馈从自绘逼向克隆——这说明它不是某个工具的偶然,而是问题结构本身决定的。

落到 Skill 里：模板应该怎么放

把"结构化"和"分清性质"这两点合起来,一份 PPT skill 里的模板该怎么放,思路就清楚了:

1. 结构化优先,别用"假模板"。 内容一律落到真正的 layout 占位符里,而不是散落的自由文本框;主题色、字体走 Theme,代码只引用主题变量,绝不写死 RGB——否则后续换肤、换品牌、国际化全会崩。这是模板能被自动化的前提。

2. 内置一套语义化版式库,再加一层"模板元数据"。 预制封面、目录、章节、要点、两栏、对比、KPI、图表、总结等版式,每种对应结构化 JSON 里的一个 type。但光有原生的 title/body/picture 太粗,还得给每个占位符补一层业务语义标签——比如 cover_title、kpi_value、hero_image、main_chart、source_citation——并标上文本容量(max_chars)、图表约束(类型/系列数/类别数)、图片比例、以及放不下时的回退版式(fallback)。这样 LLM 就不用去猜"哪里该放什么",只需回答"给哪个槽放什么内容"。这套约束驱动的设计——guizang、Anthropic、gamma 一致——不是限制美感,而是保证下限,"少选择"才"不翻车"。

3. 把设计规则固化进母版,代码只引用不硬编。 拿我用的模板举例:

• 配色:一个 accent 主色(#F25822)+ 深主色 / 辅色,只允许引用这些品牌 token。
• 字号层级:大标题 28-36pt、封面 ~54pt,和正文拉开层次;幅面 16:9 不缩放。
• 中英文字体分开设:python-pptx 里 latin 和 ea(东亚)要分别设;离线可商用优先选思源等开源字体规避版权;另外要注意字体授权——很多系统字体不允许嵌入/再分发,不嵌入又会在别的机器上被替换,直接把版式冲垮。
• 防脏数据:模板里的示例数字(比如 80%、500,499K)没被填充时必须清空,否则会被下游当成真实业务数据——这在金融场景是红线。

4. 记住几个"工程上致命"的坑。 我的一份调研报告里总结的失败模式,几乎每一条我都想点头:假模板(选对版式但内容不进框)、母版污染(换了主题个别页不跟随,因为被手工格式覆盖过)、图表不可编辑(模板放的是截图图表,只能换图不能改数据)、导出变成整页大图(文字选不中)。这些坑,买工具前、或自建落地前,都得拿真实模板先跑十个样例验一遍。

一句提炼:模板得先"结构化、能被读懂",再谈克隆还是自绘;母版决定了一个 PPT skill 的天花板和下限。 先把"模板懂得被用"解决,再追求"模型更聪明"——这几乎总是回报最高的顺序。

五、两次 Skill 实验：效果为什么不行，以及下一步怎么改

现在讲我这两天真正动手做的事。我分别用 Claude Code 和 Codex,让它们各写了一个内网 PPT skill:一个叫 template-pptx,一个叫 outline-to-ppt-template。

有意思的是,两个工具在没有互相参考的情况下,都独立收敛到了同一套架构:一种"按坐标自绘"的模式,加一种"克隆真实源页"的模式——正好印证了上一节那个判断,模板的性质决定了该用哪种。至于 XML 关系怎么重映射、槽位怎么定位这些具体实现,基本都是大模型自己边写边决策的,我这里就不展开了。我更想诚实地讲清楚两件事:效果为什么不行,以及该往哪里改。

效果复盘：两个都还不够可交付

• 两个 skill 的第一版都走"自绘",结果都被同一句反馈打回:"你只是用了模板的背景,没有用模板里的元素" / "太简单"。这里有个很能说明问题的量化诊断:从零自绘,每页大概只有 9 个形状;而模板成品页有大约 33 个——你没法用 9 个形状去追平别人 33 个堆出来的精致。这也正是"模板性质决定策略"的由来。
• 改走"克隆真实源页"之后,确实能保留卡片、图标、圆环指标和品牌元素了,方向是对的。Codex 那版跑"阶段性工作汇报"能出 7 页、圆环指标也换成了真实业务数字、溢出检查也过了——但离"能直接拿去交付"还差一截,内容页的丰富度和精致度都还撑不起一份正式汇报。

下面两个图片是我跑的效果不太行的例子：

image-20260712183431694

image-20260712183440394

下一步：从「能出片」走向「可交付」

复盘下来,要让它从"能用"走到"可交付",我认为得往这几个方向补:

1. 模板要选对、并且先分类。入库前先判断它是"版式库型"还是"品牌规范型",优先收版式库型(成品页丰富度高、克隆即用);自绘那条路只当兜底,别指望它追平成品页。
2. 把原生图表补上。现在只能改文字、动不了图表数据,得接上 chart 的数据级更新,否则数据页永远差一口气。
3. 建真正的 QA 回路。内网装上 LibreOffice,把"导出→转图→视觉检查"这套自动校验补齐,别再靠人工打开 PowerPoint 一页页看。
4. 版式收敛、把选版规则打磨稳,而不是追求"任意复杂大纲都能自适应"——先把十几种常用页型做扎实。
5. 目标别定太高。先追求"稳定替掉 60–80% 的机械排版",而不是一步到位的全自动。

一句话:方向我认为是对的(创意归模型、排版归代码),但"最后一公里"的丰富度、图表和 QA,才是决定它能不能真交付的地方。

六、结语：

折腾了一两天，把两个ai平台的token额度都用光，有如下几点结论：

1. 网红ppt skills项目直接抄进内网很难。 ppt-master 的 SVG→DrawingML、Anthropic 的"生成即验证"QA,思路都很好,但落地要自己剥依赖、自己搓。
2. 模板是地基,而且先要分清模板的性质，基于丰富的模板库才能让大模型有更好的发挥。 如果是版式库型就用克隆方案、品牌规范型就采用自绘方案。
3. 先别要求全自动。 我这两个 skill 现在都还没成,但方向我认定了:创意归模型、排版归代码、QA 和人工负责保底。 MVP 该追求的是稳定替掉机械活的大头,而不是 100% 无人介入。

虽然踩了一些坑，没能产出实际能用的基于模板的PPT skills，但至少对ppt ai有了比较系统的认识，以及确认了下一步探索的方向，要产出一个内网可用的简单ppt skills还是有可能的，我还在路上，后续有最新进展再做更新。