LearnPrompt/humanize-ppt 解决的是演讲能不能被听懂，而不是再套一个模板。 很多 HTML PPT 工具擅长把页面做漂亮，却不负责观众是否一页页听懂、素材是否真的支撑内容、渲染后有没有页面只能看不能讲。Humanize PPT 的位置正好在这里：把材料整理成 AST 观众状态转移大纲，再把每页的图片、图表、视频需求写进计划，最后把渲染好的 deck 拉回来做演讲体检。

这也解释了它的第一层边界：它不是最终渲染器。中文 deck 通常交给 guizang-ppt-skill，英文 deck 可交给 frontend-slides 或 beautiful-html-templates，配图和视频也会交给下游素材工具。Humanize 负责把“这场演讲应该怎么推进”写清楚，下游负责把页面画出来。

AST 让每页都有观众状态变化

README 里反复强调 AST，也就是 Audience-State-Transfer。它关心的不是这一页有没有酷炫排版，而是观众从什么状态进入这一页，又应该带着什么状态离开。换句话说，PPT 不只是信息容器，而是一次观众状态改变。

这对长一点的汇报很关键。直接用模板类 skill，常见结果是一个概念被铺成十几页，页页都像样，但讲的人不知道下一页为什么存在。Humanize 先输出 deck_brief.md、ast_outline.md、slide_plan.json 和 speaker_intent.md，让每页都有角色、意图和讲述动作，再把生产 brief 交给下游渲染。

本地试用有两种入口。最简单是让 Agent 安装 GitHub skill：

请安装 Humanize PPT Skill：https://github.com/LearnPrompt/humanize-ppt

也可以用 skills.sh 路径：

npx skills add LearnPrompt/humanize-ppt -g

Claude Code 用户还能走 plugin marketplace：

/plugin marketplace add LearnPrompt/humanize-ppt
/plugin install humanize-ppt

装完不要急着把它当模板生成器用。更合理的第一句话是让它先出 AST 大纲和每页意图，再指定下游渲染器，例如中文路径配 guizang-ppt-skill，英文路径配 frontend-slides 或 beautiful-html-templates。

素材需求前置到每页计划里

Humanize 的第二个价值，是把图片、SVG 图表、Remotion 视频这类素材需求前置到每页计划里。slide_plan.json 里的 media 槽会记录这一页要不要图、要不要图表、要不要视频，还会带上 asset_path 和 prompt_hint 之类字段，方便下游真正产出文件。

这能减少一个常见麻烦：等页面都排好了，才发现某页缺一张图，临时补出来的素材和叙事关系很弱。Humanize 的做法是先判断这一页承担什么观众状态转移，再判断视觉素材有没有必要。概念氛围图可以交给 baoyu-image-gen，视频片段交给 Remotion，数据流程更适合确定性 SVG 或 HTML 图表。

如果直接跑仓库脚本，README 和 SKILL 都推荐稳定入口 scripts/humanize_ppt.py。示例形态是：

python3 scripts/humanize_ppt.py 
  --source examples/01-ai-tool-update/source.md 
  --out .humanize-ppt-runs/ai-tool-update 
  --title "AI 工具更新，不只是功能清单" 
  --renderer guizang 
  --guizang-style A 
  --guizang-theme ink-classic

这一步产出的重点不是最终 HTML，而是给下游看的生产 brief。中文路径常见文件名是 guizang-production-prompt.md；英文路径会按渲染器写出 frontend-slides-production-prompt.md 或 beautiful-html-templates-production-prompt.md。下游 agent 读这个 brief，再按自己的原生方式渲染。

渲染完成后继续做演讲体检

很多 PPT 生成流程到“页面出来”就结束了，Humanize 还多一段演讲体检。它会拿渲染后的 HTML 和前面的 outline 对照，找出那些只适合看、不适合站上去讲的页，例如文字被遮挡、页面没有完成承诺的信息推进、某些页看起来满但没有可讲的动作。

体检入口是 --qa-from，传入下游渲染好的 HTML：

python3 scripts/humanize_ppt.py 
  --qa-from .humanize-ppt-runs/ai-tool-update/rendered/index.html 
  --out .humanize-ppt-runs/ai-tool-update 
  --renderer guizang 
  --guizang-style A 
  --max-qa-iterations 3

每轮会写出 outputs/qa/qa_report.md、outputs/qa/fix_prompt.md 和 outputs/qa/qa_iteration.json。报告给人看，修复指令交回下游渲染 skill，迭代状态记录轮次和剩余问题。三轮仍没解决时，状态会转为 needs-human，避免无限返工。

这里也要注意边界。Humanize 不会打开下游模板，不会复制下游 HTML 结构，也不会在渲染好的页面里硬插修补代码。它写的是“该怎么改”的要求，最终页面仍由下游模板原生渲染。这样下游 skill 更新模板时，Humanize 不必跟着改模板内部。

真正适合它的用法

如果目标只是生成一页漂亮封面，直接用渲染类 skill 更快。Humanize 适合更重的场景：有原始材料、旧 PPT、访谈稿、研究文档，想把它变成一场能讲的演示；或者已经用下游工具渲染出 HTML deck，希望有人按大纲逐页检查。

一条比较贴合定位的使用话术是：

用 humanize-ppt 把这份材料做成中文演讲 PPT：先出 AST 大纲和每页意图，
按大纲调 guizang-ppt-skill 原生渲染，配图用 baoyu-image-gen、视频用 remotion，
渲染完跑一遍演讲体检，告诉我哪几页只能看不能讲，最后出演讲模式。

把 LearnPrompt/humanize-ppt 放在模板前面，它像演讲导演；放在渲染后面，它像复核人。它不抢下游模板的美术工作，但能把“这套 PPT 到底能不能被人讲完”这件事提前管起来。