ppt-image-first：它让 PPT 先被看见再被确定

做 PPT 最容易翻车的地方，往往不是收尾页少了一个图标，也不是某个标题字号没统一。真正麻烦的是，所有人还没看见页面长什么样，就已经在口头上把风格谈完了。

“专业一点”“有设计感一点”“不要太花”，这些话单独看都没错，落到页面上却可能是三种完全不同的东西。等一整套 PPT 已经生成出来，再发现封面像路演稿、目录像培训课、正文像研究海报，返工就不只是换模板，而是重走一遍判断。

材料也经常不是完整报告。有人只给一个题目，有人塞来几段笔记，有人把论文、产品介绍、汇报要点混在一起。直接做页面，页面会空；先让人填长表，沟通又会卡住。

NyxTides/ppt-image-first 切中的就是这个缝隙。它不是急着把 PPT 做出来，而是先把“该怎么确认”这件事往前搬：先把需求说清一点，把内容垫住一点，再拿真实页面预览来决定风格。

这条路线听起来慢一点，但对很多演示稿反而更省事。因为它承认一个事实：PPT 的风格不是靠形容词定下来的，得靠首页、目录页、正文页这些具体页面一起被看见。

它先让模糊需求有个能落脚的内容底座

这个仓库的 README 把第一段流程拆得很细：轻量 intake 之后，不立刻进入配色和版式，而是先做 baseline judgment，再进入需求确认。这里的“轻量”很重要，它只关心用途、受众、页数或时长、已有材料，以及学校、公司、实验室、课程、品牌这类身份锚点。

它没有把用户拖进一张很长的设计参数表。相反，conversation-first 的意思更像设计侧先接住问题：你到底要汇报、答辩、路演还是培训；听众是谁；手里材料够不够支撑一套 deck。

材料不够时，它会生成 content_report.md。这个文件不是几条大纲，而是一份小型报告化内容基底，里面要处理 source status、content thesis、narrative body、section candidates、page content candidates 和 visualizable content。页面先找到“能讲什么”，后面才有资格讨论“怎么长得好看”。

风格不是被选择出来的，是被预览图逼出来的

ppt-image-first 最有意思的地方，是它不满足于让人看三段风格描述。references/preview-flow.md 里反复强调，风格确认默认要靠真实图像预览，而且每个方向固定看三类页面：首页、目录页、正文页。

这三个页面选得很实在。首页看第一眼和气质，目录页看结构能力，正文页看信息承载。只看封面，很容易被氛围骗过去；只看正文，又容易低估一套 deck 的第一印象。三I张一起看，风格才不只是“好看”，而是能不能撑完整套汇报。

仓库还把预览界面固定在 assets/preview_shell/index.html 里，不建议随手换成别的页面。这个细节说明它不是临时拼几张图给用户看看，而是把“比较方向”当成工作流的一部分。后面的 candidate picker 和 review shell 也走同样思路，界面壳子是流程凭证，不只是装饰。

style-system.md 里的 V1 到 V8 看起来像内部设计参数，但它没有要求前台用户逐项填写。布局、材质、光照、容器这些由 agent 内部综合，密度、文字和视觉平衡、品牌约束再结合真实需求判断。它真正想避免的是那种“请勾选科技风、商务风、极简风”的表单感。

整页图路线很强，也有清楚的代价

README 说得很直接：这套 workflow 默认用 GPT Image 2 生成整页视觉图，再把这些页面图放进 PPTX 容器里交付。成品更像完成度很高的视觉稿式演示页，适合展示、汇报和继续做图像级 retouch。

这也意味着，它不承诺页面里的文字、图形、装饰元素都能像 PowerPoint 原生对象那样逐项编辑。对有些场景，这是缺点；对另一些场景，恰好是它的取舍。它把视觉一致性和预览继承放在前面，把“每个元素都可编辑”放在后面。

所以它适合的不是所有 PPT。若团队后续要在 PowerPoint 里频繁改字、换图、拆图表，完全可编辑路线会更稳。若目标是先拿到一套风格完整、能汇报、能评审的演示稿，image-first 反而少了很多半路补丁。

这里最怕的做法，是把生图当背景，再用后期 overlay 去补标题、数字、标签和说明框。SKILL.md 明确反对这种 patch-overlay-driven 的生产方式。生成出来的页面应该是完整页面，不是等着再被第二套系统救回来。

它把“不满意”变成下一轮能执行的输入

很多 PPT 自动化流程到第一版就收尾，最多让人给几句修改意见。ppt-image-first 不太一样，第一版完整结果出来后，review and retouch 是主流程，不是临时补充。

review shell 做了一件很实际的事：让用户直接在页面图上画笔、画矩形、加注释，然后复制一份 review-shell-v2 JSON 回来。这个 JSON 只带坐标和反馈，不把大图塞进文本里。后续脚本 render_review_markup.py 会把这些坐标标注重新画回本地页面图，再把标注图和文字意见一起作为返修依据。

这件事对 AI 生成 PPT 很关键。因为“不好看”太空，“这里层级压不住”“这一块太拥挤”“这个图标抢正文”才有用。把反馈绑定到页面位置后，下一轮修正不再靠猜。

它还区分了几种返修动作：全页重新生成、局部图像编辑、内容或蓝图问题。这个分类不花哨，却能防止一个小问题被当成整页重做，也能防止叙事内容已经变了，却还假装只是调图。

这条路最适合先把方向定准的人

从项目附带的示例图和 demo deck 看，它服务的不是“随手出几页模板”，而是答辩、研究汇报、产品介绍、路演、培训、复盘、方案提案这类需要先确认内容和视觉方向的场景。它对沟通成本的判断很现实：早一点看见页面，晚一点返工。

它没有把 Agent 放出去自由发挥到底。需求确认、风格确认、生成前确认、初稿评审与返修，每个点都像一道小闸门。闸门多了，速度看上去慢；但每一次停顿，都是为了避免后面整套页面偏航。

如果只想要一份完全可编辑、后续主要在 PowerPoint 里细改的文件，ppt-image-first 不一定是最顺手的路线。它更像是在说：先别急着交付 PPT 文件，先让大家看见页面、看见风格、看见正文能不能承载信息。确认这些以后，生成才真正有意义。