18trees-ppt-maker

项目是什么

18trees-ppt-maker 是一个跨工具的 AI skill：从素材一路做到可以直接发给别人看的网页 PPT 与 PDF。适用于 Claude Code、Codex，以及任何能读写文件、执行 Node 脚本的 AI 工具，服务对象是投资人材料、路演、项目汇报、行业分享这类要发出去的 PPT。

它要推翻的是普通 PPT 的默认前提——PPT 是讲稿的辅助，留白等讲者补话，小字等讲者解释。一旦这份 PPT 被直接发给别人、身边没有讲者，它立刻就散了。所以这个 skill 只守一条判据：一个完全不了解背景的人，只看这一页，能不能自己看懂它想说什么。答「不能」的元素，要么解释清楚，要么删掉，没有第三种处理方式。

具体结构

项目分三层：规则源、工作流，与它依赖的上游引擎。

规则源。 skills/ppt-maker/ 是唯一真相：SKILL.md 定义六阶段工作流与 10 条 P0 铁律；references/ 放口味档案、子 Agent 评审规格与版式细则；scripts/ 是两个只用 Node 标准库的脚本——独立阅读静态校验，以及 PDF 导出与打包——外加一份默认留空的人名黑名单模板。分发走插件清单，Claude Code 与 Codex 各一份。

工作流。 素材先变成两部分结构的叙事大纲（第 1 阶段），再定风格版式、生成单文件 HTML deck（第 2–3 阶段）；接着是静态校验加独立评审（第 4 阶段）、两个视口的验证（第 5 阶段，桌面 1440×900、移动 390×844）、导出 PDF 并打包（第 6 阶段）。顺序不能乱，前一步没稳定就进下一步，后面全部返工。

上游引擎。 渲染不由本项目负责：guizang-ppt-skill（AGPL-3.0）负责把 deck 渲染出来，本项目只在运行时按路径读取本机已安装的上游目录。仓库里没有上游的任何代码、模板或文档资产，所以这是插件关系，不是合并分发。

优秀设计

生成者自己评审是无效的，所以评审强制外置。 每完成一版 deck，必须起一个子 Agent 扮演委托人本人做独立评审，而它只拿到三样输入：产出的 HTML、口味档案、叙事大纲——不给背景，不给设计理由。它要逐条回答 14 项检查、输出带页码与原文引用的清单，且被要求至少找出 5 条问题；改完再跑一次，直到清单清空。规格与完整 prompt 模板在 reviewer-persona.md 里。

品味不是设计出来的，是从返工里长出来的。 taste.md 是它真正的心脏：每条雷区都保留委托人的原话与日期，写清判定与处理，并持续追加。整套规则来自一份 14 页商业 deck 的六轮真实反馈；新反馈的处理顺序固定——先进 taste.md，再判断是否升格成 SKILL.md 的 P0 铁律，能机器判定的同步写进校验脚本。

机器判得动的交给脚本，判不动的交给评审。 两个脚本零 npm 依赖：validate-ppt.mjs 拦页码连续性、字号下限、底部孤立小字这类低级问题；export-pdf.mjs 驱动本机 Edge/Chrome 导出 PDF 并打包。但脚本替代不了子 Agent 评审——「这页读不读得懂」机器判不了。

与上游的边界是有意为之。 不复制上游任何资产、只在运行时按路径读取，这个前提正是本项目能自主选择 MIT 的理由；一旦把两者打成单一分发物，整体就必须转为 AGPL-3.0 并保留署名。

解决了什么问题

• 「这份 deck 能不能不靠讲者直接发出去」有了一条统一判据，不再依赖散落的排版偏好。
• 页码连续性、字号下限、底部孤立小字、英文标签、未解释缩写、占位符、移动端用 display:none 藏正文、真人姓名——这些可机器判定的问题都会在发给别人之前被脚本拦下。
• PDF 导出绕开了横排翻页 deck 直接打印只能得到一页的问题，产出可一页一页翻看的成品。
• 交付物固定是三件套同前缀放在一个文件夹：大纲 Markdown、HTML 与 PDF。
• 未坐实的具体数字写成定性表述、署名只写角色不写真人姓名，材料因此可以放心对外分发。