临到汇报前，最麻烦的常常不是没人会做 PPT，而是材料还停在邮件、备忘录和零散想法里。老板给的是几段话，业务同事补的是需求背景，真正要交出去的却是一份 16:9 的提案稿。

annie-recruit/claude-ppt-skill 把这个麻烦收进 Claude Code 的 /ppt slash command：输入可以是 prompt、email、memo 这类非结构化文本，输出要落成 python-pptx 生成的 PPTX 和同名 PDF。它不像只写一段提示词，更像给提案 PPT 做了一条本地交付线。

先把零散材料改写成提案顺序

这类工具最容易做歪的地方，是把原始文字平均分到每一页，看起来生成了十几张幻灯片，实际上没有回答“为什么现在做、要做什么、怎么推进、风险在哪里”。这个仓库的 README 一开始就把对象说得很窄：prompt、邮件、备忘录都可以塞进来，但目标不是摘要，而是 기획안，也就是可以拿去沟通的提案。

所以它的关键不是“AI 会不会排版”，而是先承认输入本来就不干净。只要输入来自真实工作，里面就会有重复、跳跃、口语、没补完的前提。/ppt 的价值在这里变得具体：它给 Claude Code 一个明确动作，别把材料当聊天记录处理，要把它整理成提案稿的叙事顺序。

/ppt 是入口，也是一道边界

把命令做成 slash command，有一个隐含好处：使用者不需要每次重新解释“我要的是 PPT，不是总结，不是大纲，也不是邮件回复”。ppt.md 里直接写了调用方式，像 /ppt 신규 입사자 온보딩... 这样的例子，也把它的任务范围框在企划、汇报、PoC、内部方案这些材料上。

这个边界让它和“万能 PPT 生成器”拉开距离。它并没有承诺做任意风格大片，也没有把所有视觉生成任务都吞进去；它先把工作场景收窄到提案 PPT，再围绕这个场景安排字体、文件、导出和验收。

它把字体、文件和本地环境都算进了交付

README 里反复出现的不是炫酷模型名，而是 Homebrew、git、python3、python-pptx、PyMuPDF、LibreOffice、Pretendard 字体，以及要复制到 ~/.claude/commands/ 的 ppt.md、ppt_benchmarks.md 和 assets。Windows 侧还有 PowerShell 安装入口，说明它在意的是换一台电脑之后还能不能跑起来。

Pretendard 也不是顺手点缀。ppt.md 要求所有 run 同时指定 latin 和 a:ea 字体，目的很朴素：韩文和英文混排时不要在 PowerPoint 里变形。对提案稿来说，这类细节没有截图时很难被看见，却经常决定交付文件像不像一个认真整理过的版本。

渲染检查暴露了它真正担心的事

很多生成工具把“文件已保存”当终点，这个仓库把 PPTX 旁边的 PDF 也当成固定产物。ppt.md 要求用 LibreOffice 把 PPTX 转成 PDF，再渲染成图片检查破版、溢出、空白页、阴影、对齐和名词型收束。它担心的不是代码有没有执行，而是打开给别人看时会不会翻车。

PyMuPDF 在这里也不是为了显得技术栈完整，而是把“看一眼”变成可执行的检查动作。PPT 这类文件最尴尬的地方在于，生成时没报错不代表版面没问题；字体缺失、文本框溢出、图形错位，都可能只在渲染后暴露出来。

Benchmark 不是炫技，是给下一次少走弯路

ppt_benchmarks.md 的定位很克制：它不是复制模板，而是记录已确认的 deck 案例，用来在 Step 0 读取质量标准。项目还强调，只有被明确确认的成品才写进去，正在 review 的产物不能混进去。

这说明作者对“越用越稳定”的理解不是盲目累积提示词，而是把被认可的叙事顺序、register、设计规则和不能泛化的上下文拆开保存。对经常做内部提案的人来说，这比多一个主题模板更有用，因为真正耗时间的常常是判断什么风格能被组织接受。

适合收束提案，不适合包办所有幻灯片

annie-recruit/claude-ppt-skill 最值得看的地方，是它没有把 PPT 生成理解成一次性魔法。它把散乱材料、提案顺序、本地字体、PPTX/PDF 双输出、渲染验收和 benchmark 反馈放到同一条链上，这条链很适合处理工作里常见的企划稿和汇报稿。

它的边界也因此很清楚：如果目标是高度定制的品牌视觉、复杂动态图表或图像大片，它不是最合适的入口；如果手上是一段邮件、一份 memo、一个还没整理过的方案想法，而你需要一份能继续修改、能导出检查的提案 PPT，它的设计就有现实意义。