1. 学术类 PPT 生成 Skill 的整体设计思路1.1 为什么学术 PPT 值得单独做一个 Skill做过学术汇报的人都有一个共同感受内容明明是自己写的但一到排版环节就像换了个人在干活。组会汇报、开题答辩、中期检查、毕业答辩、会议 talk每一种场景对 PPT 的要求都不一样但底层逻辑高度一致——信息密度高、逻辑链条清晰、图表规范、公式可读。这和商业路演、产品发布那种“一张图一句话”的风格完全是两码事。我最早是用手工做学术 PPT 的一套 30 页的组会汇报光调格式就要花两三个小时。后来试过各种在线模板站发现两个问题一是模板好看但不适合学术场景大量装饰性元素挤占版面二是公式和参考文献的排版几乎没法自动化。再后来开始用python-pptx写脚本批量生成效率上来了但每次换课题都要重写一遍布局代码复用性很差。这就是“学术类 PPT 生成 Skill”要解决的核心问题把学术 PPT 的排版规则、结构范式、图表规范沉淀成一个可复用的能力单元输入是论文、实验数据、汇报大纲输出是符合学术规范的 PPT 文件。它不是一个模板而是一套生成逻辑。从热搜词也能看出来python-pptx、pptxgenjs、agent skill、codex skill、ai skill这些词频繁出现说明大家关注的不只是“怎么做一个 PPT”而是“怎么让 AI 或脚本替我做一个学术 PPT”。这个 Skill 的定位就是后者。1.2 技术选型python-pptx 还是 pptxgenjs这是第一个要拍板的问题。两条路线我都实际跑过说下真实感受。python-pptx是 Python 生态里操作 PPTX 文件最成熟的库优势在于和数据处理链路天然打通pandas读完 Excel 直接画图matplotlib出图直接插入公式处理可以借助sympy或latex2mathml转成 OMML 再嵌入学术圈 Python 用户基数大遇到问题好查资料pptxgenjs是 JavaScript 路线优势在于如果 Skill 要跑在浏览器端或 Node 服务里不需要额外起 Python 进程和前端可视化库如 ECharts配合更顺生成速度在纯文本场景下略快我的选择是以python-pptx为主pptxgenjs作为轻量场景的备选。原因很直接学术 PPT 的核心难点不在“生成文件”而在“处理学术内容”——公式、图表、参考文献、数据表格。这些环节 Python 生态的成熟度明显更高。热搜里python-pptx安装被单独搜也侧面说明这条路是主流。提示python-pptx安装时建议锁定版本pip install python-pptx0.6.23新版本在部分中文字体渲染上有过兼容性波动锁版本能省掉很多排查时间。1.3 Skill 的输入输出边界定义一个 Skill 如果边界不清用起来就会很痛苦。我把这个学术 PPT 生成 Skill 的边界定义成下面这样输入侧接受三类东西结构化大纲JSON 或 Markdown包含章节标题、要点、备注数据文件CSV/Excel用于自动生成图表素材文件图片、公式 LaTeX 源码、参考文献 BibTeX输出侧产出一个.pptx文件满足16:9 版式符合主流投影和线上会议统一的字体、配色、页眉页脚规范图表自动编号公式居中带编号参考文献页自动生成不负责的部分也要说清楚不做内容创作那是大模型的事不做动画设计学术场景动画越少越好不做模板美化学术 PPT 的美是克制。这个边界一划Skill 的职责就清晰了它是一个“排版执行器”不是一个“内容生成器”。热搜里agent skill和skill和agent的区别被频繁搜索其实说的就是这个——Skill 是能力单元Agent 是调度者。学术 PPT 生成 Skill 只干排版这一件事干到极致。2. 学术 PPT 的核心排版规则拆解2.1 版式规范为什么学术 PPT 要“丑得有理”很多刚入门的同学会拿商业模板套学术内容结果就是满屏渐变、阴影、立体字导师看一眼就皱眉。学术 PPT 的审美逻辑和商业 PPT 完全不同它的第一原则是信息可读性优先于视觉冲击力。具体到参数上我总结了一套经过多次答辩验证的规范元素规范值理由正文字号20-24pt投影后排也能看清低于18pt后排就吃力标题字号28-32pt与正文形成层级差但不喧宾夺主行距1.2-1.5倍学术内容段落长行距太密会糊成一片页边距上下2.5cm左右2cm留白是学术 PPT 的呼吸感来源配色主色1个辅助色2个超过3个颜色就会显得杂乱图表字号不小于16pt图表里的字比正文更容易被忽略这套参数不是拍脑袋定的。我做过一个简单的测试把同一页内容分别用18pt和24pt排出来投到120寸幕布上坐在最后一排看18pt的注释文字基本要靠猜。从那以后我就把正文下限锁死在20pt。配色方面学术场景我推荐深蓝灰白或者墨绿浅灰白这种低饱和度组合。原因很简单投影仪的色彩还原普遍偏色高饱和度颜色投出来会失真低饱和度反而稳定。热搜里ai相关ppt模板和ppt模板被搜得多但学术场景真的不需要花哨模板一套干净的母版就够了。2.2 结构范式学术汇报的“八股”其实是优势学术 PPT 的结构高度模式化这恰恰是自动化生成的最大机会。不管是组会还是答辩基本都逃不出这个骨架封面页题目、作者、单位、日期目录页研究背景、方法、实验、结论研究背景与问题定义相关工作可选组会可省方法/模型介绍实验设置与数据集实验结果与分析结论与未来工作参考文献致谢页这个结构稳定到什么程度我统计过自己近三年的汇报 PPT90% 的页面都能归到这十类里。这意味着 Skill 可以针对每一类页面写专门的生成函数而不是用一套通用逻辑硬套。比如“方法/模型介绍”页学术场景几乎必然包含模型结构图、关键公式、符号说明。那 Skill 在生成这类页面时就应该预留三个区域上方放结构图中间放公式下方放符号表。这种“按页型定制”的思路比通用模板的适配度高得多。注意结构范式是骨架不是枷锁。如果某次汇报是纯综述性质相关工作部分就要展开如果是工程落地汇报实验部分要加重。Skill 应该支持章节的增删和权重调整而不是死板地按固定顺序输出。2.3 公式与符号学术 PPT 最容易翻车的地方公式排版是学术 PPT 和普通 PPT 最大的分水岭也是最容易出问题的地方。我踩过的坑包括公式字体和正文不一致、公式编号对不齐、符号在投影上太小看不清、LaTeX 转 OMML 后格式错乱。先说字体。学术公式的标准字体是Cambria MathWord/PPT 默认或Latin Modern MathLaTeX 风格。如果正文用宋体或思源黑体公式用 Cambria Math视觉上是协调的。但如果正文用了花体字公式就会显得突兀。再说编号。学术 PPT 里公式编号不是必须的但如果要编号建议用右对齐括号编号格式如(1)、(2)和论文保持一致。python-pptx本身不直接支持公式编号我的做法是在公式文本框右侧单独放一个编号文本框用制表位对齐。符号说明是另一个重灾区。热搜里对偶 凸优化 ppt和利润最大化(原问题)与资源估值最小化(对偶问题)之间的对偶 ppt这两个词很有意思说明做优化方向的同学对公式和符号的排版需求特别强烈。对偶问题这种内容符号表是刚需——原问题变量、对偶变量、拉格朗日乘子不列清楚听众根本跟不上。我的做法是每个含公式的页面下方强制预留符号说明区用两列表格呈现左列符号右列含义字号比正文小2pt但不少于16pt。这个规则写进 Skill 后公式页的可读性提升非常明显。2.4 图表规范数据可视化的学术底线学术 PPT 的图表和商业 PPT 的图表是两种生物。商业图表追求“一眼惊艳”学术图表追求“一眼看懂且可复现”。几个硬性规范坐标轴必须有标签和单位不能只有刻度数字图例位置固定不要每张图都换位置误差棒必须标注这是学术诚信问题配色用色盲友好方案如 ColorBrewer 的 Set2 或 Paired图表编号连续图1、图2、图3正文引用时对得上python-pptx插入图表有两种方式一是用原生 chart 对象二是插入matplotlib生成的图片。我的建议是学术场景优先用图片因为原生 chart 的样式定制能力有限而matplotlib可以精确控制每一个像素。代价是图表不可编辑但学术 PPT 本来也不需要现场改数据。生成流程上我习惯先用matplotlib出图存成 300dpi 的 PNG再用python-pptx的add_picture插入同时记录图表编号和标题最后统一生成图表目录页。这个流程跑顺之后一套 10 张图的实验汇报图表部分从原来的一小时压缩到十分钟。3. 实操过程从零搭建这个 Skill3.1 环境准备与依赖安装先把环境搭起来。我用的 Python 版本是 3.10太新的版本有些库还没跟上太旧的版本类型提示不好用。python -m venv ppt_skill_env source ppt_skill_env/bin/activate # Windows 用 ppt_skill_env\Scripts\activate pip install python-pptx0.6.23 pip install matplotlib pandas openpyxl pip install pillow # 图片处理 pip install bibtexparser # 参考文献解析如果你要处理 LaTeX 公式还需要额外装pip install latex2mathml这个库把 LaTeX 公式转成 MathML再通过python-pptx的 OMML 接口嵌入。实测下来简单公式加减乘除、上下标、求和积分转换成功率在95%以上复杂公式多行对齐、矩阵需要手工微调。提示latex2mathml对\begin{align}环境的支持不完整多行公式建议拆成多个单行公式分别转换再用文本框手动对齐。3.2 母版与版式定义python-pptx操作母版的方式和手工编辑不太一样它是通过slide_layouts来选版式的。默认模板有11种版式但学术场景常用的就三种标题页、标题内容、仅标题。我的做法是先手工做一个母版文件把字体、配色、页眉页脚、页码位置都设好然后用python-pptx打开这个母版文件基于它的版式来生成页面。这样比纯代码设置样式要省事得多也更灵活。from pptx import Presentation from pptx.util import Inches, Pt prs Presentation(academic_master.pptx) # 版式索引0标题页1标题内容5仅标题6空白 title_layout prs.slide_layouts[0] content_layout prs.slide_layouts[1]母版里我固定了几个东西页脚放汇报人和日期右上角放章节名右下角放页码。这些在母版里设一次所有页面自动继承不用每页重复写代码。配色方案我定义成常量方便统一修改COLOR_PRIMARY (0x1F, 0x3A, 0x5F) # 深蓝 COLOR_SECONDARY (0x6B, 0x7B, 0x8D) # 灰蓝 COLOR_ACCENT (0xC0, 0x39, 0x2B) # 砖红用于强调 COLOR_TEXT (0x2C, 0x2C, 0x2C) # 近黑这套配色我用了两年多投影效果稳定打印成讲义也清晰。3.3 内容解析与页面生成Skill 的核心逻辑是“解析输入 → 匹配页型 → 调用生成函数”。输入我用 JSON 定义结构大概是这样{ meta: {title: 基于XXX的方法研究, author: 张三, date: 2024-06}, sections: [ { type: background, title: 研究背景, points: [问题定义..., 现有方法不足...], figures: [fig1.png] }, { type: method, title: 方法介绍, formula: \\min_{x} f(x) \\lambda \\|x\\|_1, symbols: [[x, 优化变量], [\\lambda, 正则化系数]] } ] }解析器读这个 JSON按type字段分发到对应的生成函数。每个生成函数负责一类页面的排版比如gen_method_slide会预留公式区、符号表区、结构图区。这里有个设计取舍要不要支持 Markdown 输入。Markdown 写起来快但表达力有限公式和图表位置不好控制。我的方案是 Markdown 作为快速草稿JSON 作为正式输入。Skill 提供一个 Markdown 转 JSON 的预处理函数把#标题转成 section把$$公式转成 formula 字段。页面生成时文本内容用text_frame逐段添加注意设置word_wrap True和合适的行距。图片用add_picture插入插入前先用 Pillow 检查尺寸超过版心宽度的自动等比缩放。def add_picture_fit(slide, img_path, left, top, max_width, max_height): from PIL import Image with Image.open(img_path) as im: w, h im.size ratio min(max_width / w, max_height / h) new_w, new_h int(w * ratio), int(h * ratio) slide.shapes.add_picture(img_path, left, top, new_w, new_h)这个add_picture_fit函数是我用得最多的工具函数避免了图片溢出或变形的问题。3.4 公式嵌入的完整实现公式这块单独拎出来说因为它是学术 PPT 的命门。完整流程是LaTeX 源码 →latex2mathml转 MathML → 转 OMML → 嵌入 PPTX。python-pptx没有直接的 OMML 接口需要操作底层 XML。from latex2mathml.converter import convert from pptx.oxml.ns import qn import lxml.etree as etree def latex_to_omml(latex_str): mathml convert(latex_str) # MathML 转 OMML 的转换逻辑略可用 XSLT 或第三方库 return omml_element说实话这个转换链路有点长而且 MathML 到 OMML 的转换没有官方库我用的是一个开源的 XSLT 样式表。实测下来简单公式没问题复杂公式偶尔会丢符号。更稳的替代方案把公式用matplotlib渲染成图片插入。matplotlib的mathtext引擎支持大部分 LaTeX 语法渲染质量高而且完全可控。import matplotlib.pyplot as plt def render_formula(latex_str, output_path): fig plt.figure(figsize(6, 1)) fig.text(0.5, 0.5, f${latex_str}$, fontsize24, hacenter, vacenter) plt.axis(off) plt.savefig(output_path, dpi300, bbox_inchestight, transparentTrue) plt.close()这个方案的好处是所见即所得不用担心转换丢符号坏处是公式变成图片不能编辑。学术 PPT 的公式本来也不需要现场编辑所以这个代价可以接受。我现在默认用图片方案只有需要频繁改公式的场景才用 OMML。注意matplotlib渲染公式时如果公式里有中文需要设置mathtext.fontset为stix或cm否则中文会显示成方框。纯英文公式没这个问题。3.5 参考文献自动生成学术 PPT 的最后一页通常是参考文献格式要求严格。我用bibtexparser解析.bib文件按引用顺序生成编号列表。import bibtexparser with open(refs.bib) as f: bib_db bibtexparser.load(f) def format_reference(entry, index): authors entry.get(author, ).replace( and , , ) title entry.get(title, ) year entry.get(year, ) journal entry.get(journal, entry.get(booktitle, )) return f[{index}] {authors}. {title}. {journal}, {year}.生成的参考文献页字号比正文小2pt行距1.15每条之间留一点间距。如果文献超过15条分两页显示不要硬挤在一页里。这里有个细节PPT 里的参考文献不需要像论文那样完整作者可以只列前三位加“等”期刊名可以缩写。目的是让听众知道出处不是让他们去查。我一般控制在每条不超过两行。4. 常见问题与排查技巧实录4.1 中文字体渲染异常这是python-pptx最高频的问题。表现是代码里设了“微软雅黑”生成的文件打开后变成宋体或默认字体。原因通常是母版里没有嵌入该字体或者字体名称写错了。python-pptx设置字体时用的是字体名不是字体文件。from pptx.util import Pt run.font.name 微软雅黑 # 关键同时设置东亚字体 run.font._element.rPr.rFonts.set(qn(a:ea), 微软雅黑)只设font.name对中文无效必须同时设a:eaEast Asian属性。这个坑我踩了整整一个下午才找到原因。如果换了电脑打开还是不对说明目标电脑没装这个字体。学术汇报建议用思源黑体或微软雅黑这种普及度高的字体别用太冷门的。4.2 图片插入后模糊图片模糊的原因通常是分辨率不够。python-pptx插入图片时不会自动提升分辨率如果原图是 72dpi 的截图插到 PPT 里放大后就会糊。解决办法所有图表用 300dpi 导出截图用系统自带的截图工具时注意别缩放。matplotlib保存时指定dpi300bbox_inchestight去掉多余白边。如果图片已经糊了重新生成比后期锐化有效。PPT 里的图片锐化功能基本是摆设。4.3 公式编号对不齐公式编号对不齐是因为公式图片宽度不一致导致编号位置浮动。解决办法是用固定宽度的公式容器公式图片居中编号右对齐。# 公式容器宽度固定为版心宽度的70% formula_width int(prs.slide_width * 0.7) # 公式图片居中放在容器里 # 编号文本框放在容器右侧右对齐这样不管公式多长编号位置都是固定的视觉上整齐。4.4 生成速度慢一套 40 页的 PPT如果每页都重新打开母版、重新解析样式生成时间可能超过30秒。优化思路是复用 Presentation 对象母版只打开一次所有页面基于同一个对象生成。另一个耗时点是图片处理。如果同一张图在多页出现用缓存避免重复读取。matplotlib渲染公式也可以缓存相同 LaTeX 源码只渲染一次。优化后40页 PPT 的生成时间可以压到5秒以内基本感觉不到等待。4.5 常见问题速查表问题现象可能原因解决方法中文显示为方框未设置东亚字体同时设font.name和a:ea图片模糊分辨率不足图表用300dpi导出公式编号错位公式宽度不一用固定宽度容器生成速度慢重复打开母版复用 Presentation 对象页码不连续母版页码域未更新手工设页码或改用文本框配色投影失真饱和度过高改用低饱和度配色参考文献格式乱BibTeX字段缺失加默认值兜底4.6 几个独家避坑心得心得一先做母版再写代码。很多人一上来就写代码设样式结果代码越写越长改一个颜色要改十几处。正确顺序是手工做一套满意的母版再用代码基于母版生成内容。母版改一次所有页面跟着变。心得二公式优先用图片。OMML 方案听起来高级但转换链路长、出错率高。学术 PPT 的公式不需要编辑图片方案更稳。只有需要反复改公式的场景才值得上 OMML。心得三留一页“备用页”。答辩现场经常被问超纲问题临时画图来不及。我的习惯是在 PPT 最后放几页备用内容比如补充实验、参数敏感性分析平时不展示被问到就跳过去。这个习惯帮我救过好几次场。心得四导出 PDF 再检查一遍。PPTX 在不同电脑上打开可能有细微差异导出 PDF 能锁定最终效果。答辩前一定导一份 PDF 备用万一现场电脑没装 Office 或字体缺失PDF 能兜底。心得五控制单页信息量。学术 PPT 容易犯的错是“一页塞太多”。我的经验是一页不超过 6 个要点每个要点不超过 2 行超过就拆页。听众的注意力有限信息过载等于没讲。这套 Skill 我从最初的手工排版到脚本生成再到现在的结构化 Skill前后迭代了大概七八个版本。最大的体会是学术 PPT 的自动化难点不在技术在于把学术规范翻译成代码规则。公式怎么排、图表怎么标、参考文献怎么列这些规则想清楚了代码只是执行。反过来如果规则没想清楚代码写得再漂亮生成的 PPT 还是不能用。后续我打算把这个 Skill 往两个方向扩展一是接入大模型做内容摘要从论文 PDF 直接生成汇报大纲二是支持多语言方便国际会议场景。不过那是下一步的事了当前版本先把排版这件事做扎实。
