从一条 ChatGPT 对话，到一个能够持续管理页面、版本和导出的本地工作流。

这件事一开始，并没有什么宏大的计划。

我只是想帮老婆做好一套 PPT。

以前做 PPT，大致有两条路。一条是自己从空白页面开始，找图片、写文字、调字号、改配色，一页一页排。另一条是找现成模板，把内容硬塞进去。前者很费时间，后者常常是模板很好看，但内容一换，整个页面就不协调了。

图片生成模型出现以后，我开始尝试第三条路：不再先找模板，而是直接描述我想要的页面，让 AI 按照内容生成完整画面。

最早，我是在 ChatGPT 的对话里做这件事。

我上传产品图、人物图和参考页面，告诉它这一页需要表达什么、画面比例是多少、文字应该放在哪里。生成结果不对，就继续在对话里改。人物五官有问题，就让它修人物；产品被画得太大，就让它缩小；视频页需要放竖版视频，就指定一个 3:4 的留白区域；页面文字太小，就再次强调“字体要大”。

那条后来被我交给 Codex 分析的共享对话，并不是我临时找来的案例，而是我之前实际做 PPT 留下的完整工作记录。

它记录了一个图片式 PPT 是如何在对话中一点点长出来的。

只是，当我真的用这种方式做完一轮以后，新的问题也出现了：我得到了一套页面，却没有得到一套能够重复使用的方法。

所有素材、提示词、生成结果和修改意见，都混在一条越来越长的对话里。同一页可能生成过好几个版本，但没有一个明确的位置告诉我，哪张是历史版本，哪张是候选版本，哪张才是当前采用。想修改第六页的一个局部，我需要先在很长的消息里找到它，再重新解释上下文。

做完一套以后，下一套还是要重新开始。

于是我开始想：能不能把在 ChatGPT 对话里已经走通的过程提取出来，交给 Codex，做成一个本地工作流？

这才是这个项目真正的起点。

01

ChatGPT 让我看到图片式 PPT 可以做，长对话也让我看到它的边界

当图片式 PPT 已经可以实现，越来越长的对话也开始暴露边界。

回看最早的对话，会发现整个过程并不是输入一句话，然后等待一套 PPT 自动出现。

真实过程更像是一个循环：上传参考图和文案，确定页面尺寸，生成一页，指出局部问题，基于上一版继续修改，再确认是否采用。

比如，我一开始要求生成三张用于介绍“宋锦的起源与发展”的图。第一次表达之后，AI 把它理解成了一张包含三个部分的大图。我只好进一步说明：

后来换到另一套宋锦产品，我又再次强调：

现在看起来，这只是一次普通的需求修正。但它后来成了整个工作流中非常重要的一条规则：一页 PPT，就是一个独立的生产任务。

一套 PPT 可以共享主题、字体和视觉方向，却不能把十几个页面当成一次图片生成。每一页有自己的内容目标、参考素材、画面构图、留白区域和修改历史。

类似的问题还很多。整页画布是 3840×2160、横版 16:9，不代表页面中的所有对象也是 16:9。视频页里面可能要保留一个竖版 3:4 容器；产品图有自己的真实长宽比例；人物、作品和标题之间也要有相对位置。

如果这些约束只留在对话里，每次修改都要重新解释。

另一个问题是版本。同一页可能经历第一版整体方向、第二版修正人物、第三版替换真实产品、第四版缩小产品比例、第五版再调整表情或服装。在聊天记录里，这些版本只是按时间依次出现。它们没有结构化关系，也没有“当前采用”的状态。

ChatGPT 对话模式的价值是真实的。它让我第一次把“生成一张好看的图”扩展成“逐页生成一套 PPT”。但它也让我意识到，生成能力和项目管理能力不是一回事。

我需要的不只是一个更长的 Prompt，而是一个能保存项目状态的地方。

02

我把那条对话交给 Codex，不是让它学习别人的方法，而是迁移我自己的经验

把长对话中的素材、页面、反馈和版本重新梳理成结构。

7 月 29 日，我把这条共享对话交给了 Codex。

我的目标很明确：先研究这个过程，看看能不能做成一个简单的本地 Web 产品，用于以后建立类似的图片 PPT。

这里的“研究”，不是研究别人是怎么做的，而是让 Codex 回看我已经做过的项目，把那些散落在长对话里的操作提炼出来。

共享页面并不好解析。普通网页读取没有直接拿到完整正文，最初的网络请求也遇到了缓存和域名解析问题。后来把共享页 HTML 下载到本地，再从页面里的 React Router 数据流中解析对话结构，才把主线还原出来。

解析结果里有 978 条消息，其中包括 154 条用户消息、546 条助手消息和 176 条工具消息。

978 并不代表有 978 个有效步骤。里面混杂着系统消息、生成工具记录、不同分支和大量中间状态。真正需要找的是：我提出过哪些要求、上传过哪些素材、哪些页面被反复修改，以及哪些约束一再出现。

最后提取出的主循环并不复杂：

这时我第一次更清楚地看到，原来自己在 ChatGPT 里做的，不是一串互不相关的指令，而是一套已经初步形成的工作方法。

Codex 根据这套方法，先整理了产品合同、数据结构、架构和实现计划。页面编号、标题、正文、画布尺寸、参考图、提示词、占位区域、版本历史和当前采用版本，都开始变成明确的数据字段。

从梳理角度看，这一步是成功的。

但我很快问了一句：

答案是：还不可以。

当时完成的是研究和产品文档，并不是一个真正能打开使用的产品。这个小插曲后来一直提醒我：在 Codex 工作流里，“已经分析”“已经设计”“已经写文档”和“已经可以运行”是不同状态。

如果用户最后需要的是一个工具，那么再完整的架构文档，也不能代替一个真实页面。

于是，任务从研究正式进入了实现。

03

第一个本地版本能运行，但我一看就觉得太复杂

第一个原型从功能堆叠中退出来，回到简单的页面主线。

有了结构以后，Codex 开始做本地 Web 原型。

我当时给了一个本地前端作为架构参考，希望保留原始素材输入、每页图片提示词、生成图片和历史版本选择这些能力，但视觉上要更简洁。

第一版做出来以后，我的直接反馈是：

从功能角度看，把素材、页面、提示词、版本、导出全部铺在一个界面上，似乎很完整。但实际使用时，我最常做的事情不是同时操作所有信息，而是先看整套 PPT 的页面顺序，然后选择其中一页继续处理。

因此，工作台后来改成了横向排列的 PPT 页面节点。每张卡片首先展示页码、页面大图、页面标题、当前版本状态，以及该页一共有几个版本。素材、提示词和版本历史不再长期占据页面，而是在需要时打开。

这个变化看起来只是界面简化，背后其实是对工作流的重新判断：做 PPT 时，页面序列是主线，详情信息只是某一页的附属状态。

页面大图还承担了另一个入口。我希望点击页面大图后，能够在具体区域上做批注。比如选中画面中的某个位置，写“这里换成我提供的产品图”，同时选择一张本地图片作为补充信息，再把批注和参考图一起交给 AI 生成新版本。

文字信息则不适合和批注、素材、版本全部堆在页面底部。我明确提出，详情区应该改成弹窗，而不是一个置底模块；文本区域应该通过顶部第一行进入。

最终，两个入口被区分开：点击顶部页码节点，查看文字、图片提示词等页面信息；点击页面大图，进入区域批注。

工作台里还出现了“采用此版”。它解决的是长对话里一直存在的问题：新生成的图片不应该自动覆盖已经确认的页面。新结果先进入候选版本，只有我明确选择后，才成为当前采用；原来的版本仍然保留在历史里。

这里还必须说明一个边界：早期原型中的“生成模拟新版本”只是为了验证交互和版本状态，并不等于当时已经接通了完整的真实 AI 图片服务。原型验证的是工作流，而不是生产服务已经全部完成。

工作台最终收敛为横向页面节点：先看整套 PPT，再进入单页处理。

详情信息从页面底部的内联区域，改为按需打开的弹窗。

04

8 月 1 日，宋锦珍珠台灯成为第一套完整实战

真实宋锦素材进入工作流，第一套完整实战开始成形。

7 月 29 日完成的工作台，最开始只是一个演示原型。真正检验它有没有价值，必须拿一个新项目来做。

8 月 1 日，我提供了四张真实素材图和一个淘宝产品资料链接，开始制作《宋锦珍珠台灯布艺小夜灯手工》。

我对内容结构的要求是：第一部分介绍宋锦珍珠台灯的历史背景和文化寓意；第二部分介绍材料、成品和制作步骤；最后要有一个视频演示底图页面，预留 3:4 视频容器。

这一次，我不是让 Codex 随便套一个模板，而是沿用刚刚建立的模式：先组织页面，再逐页生产。

最初形成的是 9 页方案，大致覆盖封面、宋锦历史、文化寓意、材料、灯体结构、十二件成品展示、前半段步骤、后半段步骤和视频演示。

我又强调了两次：

以及：

这两句话反映了我当时对成品的期待：不能只是把几张用户素材压进一个 16:9 画布，或者做成普通的图片拼贴。每一页应该有完整的场景、统一的光线和真正属于这一页的构图。真实产品图和步骤图仍然要保留，但它们不能只是生硬地贴在背景上。

第一套 9 页内容生成以后，我又提出：

这一步让整个结构发生了变化。

如果把中文标题和正文直接生成进背景图片，页面看起来可能是完整的，但后续几乎无法稳定修改。错一个字、换一句文案、调整一个字号，都可能需要重新生成整张图，而且中文生成本身也不够稳定。

所以后来采用了更可靠的方式：图片生成负责无字背景和视觉场景；本地代码负责叠加中文、页码和版式；导出 PPTX 时，中文使用可编辑文本对象。

这套分层后来成为工作流里最重要的规则之一。

宋锦珍珠台灯的 9 页工作台初态。页面、版本与“当前采用”状态已经分开。

真正开始生成前，先把材料、成品、结构和步骤四类真实素材整理出来。

05

第一版做出来以后，修改才真正开始

第一版出现后，拆页、补页、反馈和版本选择才真正开始。

9 页初版并不是终点。

我首先觉得宋锦历史部分太单薄。当时第二页只用一页讲宋锦，我提出要改成两张来解说，通俗易懂，字要大，给老人看；背景还要有人、有意境、有宋锦、有历史文化感和不同花纹。

后来我又补充了三张参考图，把这部分进一步扩展为三页，并要求人物使用相应时代的人物和穿搭，字体要大，内容适合老人阅读，文案不能只是资料说明，要更有故事感。

我还直接评价：

于是，原本相对概括的历史介绍，逐渐变成宋代起源、明清传承和当代新生三个阶段。页面数量也从 9 页增加到 10 页，再发展到 11 页。

这段过程让我意识到，PPT 的页面结构不是开始时定好以后就完全不动。真正看见页面以后，我们可能会发现一页装不下，或者信息虽然装下了，但读者根本没有足够时间理解。

“多一页”并不一定意味着冗长。有时候，拆页反而能让字号更大、节奏更清楚。

视觉和文案之外，工艺准确性也需要继续修改。第 10 页的第三步配图不对，我让 Codex 参考最后一页真实灯具成品重新处理。即使一张步骤图看起来合理，只要它和真实产品结构不一致，就不能因为“画面好看”而保留。

当天持续修改后，本地可见成果包括 11 页可编辑文字版 PPT、11 页 16:9 图片包、页面总览图和 AI 生成主视觉原图。现场记录里也曾看到相应可编辑版本在 Keynote 中打开。但更准确的说法是：当时的 11 页版本有可见打开记录，仍有单页继续修改；这不能自动证明此后所有版本都已经完成最终交付验收。

做完这一轮后，我要求 Codex：

我不想让当天踩过的坑只停留在当天的聊天里。既然已经发现历史内容要拆页、老人阅读需要大字号、真实产品不能乱画、中文应该可编辑，这些就应该进入产品规则。

同时，工作台也不能永远只有一个示例项目。它需要先进入项目列表，再打开某个项目的页面工作台。每个项目的素材、页面、提示词和历史版本都应该相互隔离。

这时，这个本地网页才开始从“一个 PPT 页面编辑器”变成“可以承载多个 PPT 项目的工作台”。

宋锦历史内容被拆开后，结构从 9 页逐步发展到 11 页。

06

第二个项目一开始，就把第一套工作流的问题暴露得更彻底

第二个项目把视觉不统一、比例不准和工艺不清楚同时暴露出来。

8 月 8 日，我在同一个工作台里发起了第二个项目：《水晶发财树 DIY｜亲手种下一树福气》。

这次我提供了产品资料、真实成品图、材料图和文案方向。核心内容是“以铜丝为枝，彩晶为叶”，介绍不同水晶的传统祝愿含义，再进入缠绕、编织和组装步骤。我还补充了一句给长辈的祝福：

这套 PPT 最初规划为 10 页，仍然遵循 16:9、大字号、中文可编辑和末页视频区域等规则。

从数据和文件角度看，第一版很快形成了。但视觉效果并不及格。

我的原话是：

这是整个项目里很重要的一次反馈。它指出了一个容易被忽略的问题：真实素材优先，并不等于把真实素材直接贴到背景上就完成了。

早期几页虽然使用了真实产品图，却明显像一张照片卡片放在设计背景上。图片边缘、光线方向、空间关系和背景材质没有真正融合。单独看每个元素都没问题，组合起来却不像一个完整场景。

接下来先生成了几个视觉方向，我选择了第 1 个方向：深胡桃木、暖金侧光、完整实景摄影感。

然后重做被点名的六页：封面、大树寓意、五色晶石、材料、成品展示和视频页。新的方向不再依靠矩形卡片和拼贴边框，而是让产品、材料或装饰真正存在于一个完整的桌面、室内或庭院场景中。文字和视频框仍由本地布局层承载。

这次修改没有覆盖旧结果。旧页面保留为 v1，新场景成为 v2，并被设为当前采用。工作台中可以看到每页有两个版本。

这正好验证了 7 月 29 日建立的版本机制不是多余功能。如果没有历史版本，我只能在“保留一个粗糙页面”和“冒险覆盖它”之间选择。有了历史版本，重新生成变成一个可比较、可回退的过程。

07

视觉统一以后，工艺步骤仍然必须服从真实参考图

画面是否漂亮，不能替代对真实工艺参考的核对。

完成整体视觉重做，并不代表这套 PPT 已经准确。

8 月 9 日，我重新启动本地服务，继续检查制作步骤。我给了一张新的工艺参考图，指出第 6 页应该是“三分叉，分叉头部固定小石头”。

生成的新图仍然有问题。我直接在图片坐标上标出了石头的位置，并强调：

这不是视觉偏好，而是工艺事实。如果步骤图把铜丝穿过水晶的方式画错，即使画面光影、配色和构图都很好，也会误导真正跟着 PPT 操作的人。

随后，我又发现 7 和 8 之间缺了一步：

于是新增“第四步：打胶固定”，原有后续页面顺延。

这类结构变化比简单插入一页复杂得多。工作台已经保存了每页的稳定 ID、用户修改过的标题、图片提示词、区域批注、候选版本、历史版本和当前采用状态。如果只是按照数组位置粗暴插入，新旧页面可能重复，或者覆盖用户已经修改的数据。

因此，本地项目数据需要做幂等迁移：无论加载多少次，“打胶固定”都只能插入一次，原来的页面状态还要保留。

这一轮完成后，数据测试通过 8/8，前端构建通过，PPTX 内部出现 11 个幻灯片 XML，并能找到第 8 页“打胶固定”的文字。

但这些证据证明的是数据迁移没有重复插页、前端代码能够构建、PPTX 结构中确实有新增页面。它们不等于 PowerPoint 或 Keynote 中的视觉效果已经人工验收。

真实参考 → 旧版 → 中间版 → 最终版。画面漂亮不能替代工艺准确。

新增“打胶固定”不是补一张装饰图，而是从真实工艺参考转换为独立教学页面。

08

页数不是固定数字，内容结构会随着实际检查不断变化

页数不是预设的数字，而是在检查中不断拆分、合并和移动的结果。

8 月 10 日，这套 PPT 又经历了一轮结构调整。

最开始，我要求取消原第二页，把第二页中的祝福文字合并到第三页，同时删除原第十页。当时形成过一个 9 页的中间方案。

但这个 9 页不是最终版本。

继续检查后，我又觉得“大树的寓意”需要单独表达，于是要求在第二页加入一棵写实的大树。第一版大树和背景太阴暗，我又补充文案：

同时要求画面更加阳光，更有正向寓意。

随后，我在大树之后增加了两页：玛瑙石介绍和水晶石介绍。制作步骤部分也新增了一张合并总览页，把前面分开的步骤集中展示，方便参与者快速回顾完整流程。

经过删除、合并和新增，页面数量最终发展为 13 页。

这段经历让我不再把“页数”理解成项目开始时必须锁死的数字。更准确的说法是：开始时需要有页面计划；生产时需要逐页管理；检查时允许基于真实阅读和教学需要调整结构；每次调整后，工作台排序、历史数据和 PPTX 都要同步。

如果只改前端页面列表，没有同步导出的 PPTX，工作台和交付文件就会变成两个版本。如果只改 PPTX，没有更新项目数据，下次打开工作台又会退回旧结构。

因此，页面结构本身也成了需要管理的版本状态。

经过删除、合并和新增后，水晶发财树最终形成 13 页结构。

09

最后一个问题很小，却说明“生成完成”离“真正能用”还有多远

一个小的透明度问题，让“已经生成”和“真正能用”的差别变得具体。

13 页结构形成后，我继续检查第 4 页。

这页介绍不同颜色水晶的寓意。画面里的水晶太透明，与背景混在一起，几乎看不到。我提出：

最后的修改不是简单增加饱和度，而是同时调整几个因素：背景改为暖茶灰石材，降低过曝；增加紫、粉、黄、乳白和浅绿色水晶；强化晶体边缘和内部纹理；增加明确投影；拉开背景与透明晶体之间的明度和颜色差。

同时，旧第 4 页被放入历史版本，新版设为当前采用。PPTX 和 Web 静态资源也同步更新。

这一轮有一组明确的技术验证结果：第 4 页 PNG 是 3840×2160；PPTX 内部有 13 页；数据测试通过 9/9；前端构建通过；输出目录和发布目录中的 PPTX 哈希一致；本地第 4 页资源 HTTP 返回 200。

这些证据说明文件已经生成、项目数据已经更新、前端可以构建、资源可以访问，PPTX 结构和发布副本也一致。

但最后仍然有一项没有做：没有在 PowerPoint 或 Keynote 中人工打开最终 13 页版本进行检查。

所以这篇文章不能把它写成“最终已经完成 Office 验收”。我能准确说的是：最终 13 页文件已经生成，并完成了结构、尺寸、构建和本地资源验证；办公软件中的最终视觉和编辑体验仍需要单独打开确认。

这不是咬文嚼字，而是我使用 Codex 做项目以后形成的一个重要习惯：图片生成成功，不等于图片已经保存；图片保存成功，不等于工作台已经采用；工作台已经采用，不等于 PPTX 已经重新构建；PPTX 已经生成，不等于页数和尺寸正确；结构正确，不等于 PowerPoint 里视觉正常。

“完成”不是一个按钮状态，而是一系列证据。

第 4 页不是简单增加饱和度，而是同时调整背景、晶体颜色、明度和投影。

10

这套工作流最后变成了什么

素材、规划、单页生成、批注、版本、可编辑文字与导出逐渐连成系统。

回看整个过程，我最早想解决的只是：怎样更快地帮老婆做好一套 PPT。

先在 ChatGPT 里试，是因为对话是最自然的起点。把素材和需求发进去，哪里不对就继续说，几乎不需要先学习一个新工具。

但真实做过以后，我发现对话最擅长的是探索，不擅长长期保存项目状态。

后来迁移到 Codex，不是简单地把同样的 Prompt 换一个地方继续输入，而是把已经发生过的过程拆成结构。

最后形成的工作流大致是：

其中有三层内容不能再混在一起。

第一层是真实素材。产品图、材料图、工艺参考图和步骤事实必须尽量保持真实。不能因为生成模型画得更漂亮，就接受一个结构错误的产品，或者让铜丝以实际无法操作的方式穿过水晶。

第二层是生成视觉。背景、空间、光影、氛围和装饰可以交给图片生成模型。水晶发财树从“贴图”改成深胡桃木、暖金侧光的完整实景，正是这一层发挥价值的地方。

第三层是确定性布局。中文、页码、标题层级、视频框、导线和对齐，应该由本地代码或 PPT 对象负责。这些内容需要准确、可编辑、可重复生成，不能把稳定性押在图片模型上。

最稳定的方法，不是让同一个模型包办全部工作，而是把不同任务交给更适合的部分。

11

我从这次经历里得到的几个经验

生成能力、项目状态和人工验证，是三层不同的问题。

1. AI 降低的是第一版成本，不是最终判断成本

AI 确实能更快地给出第一版。但第一版出来以后，我仍然要判断文案是否单薄、字体是否适合老人、产品比例是否真实、步骤是否正确、页面是否属于同一个视觉世界。

过去大量时间花在手动制作上；现在更多时间花在选择、纠错和定义标准上。工作没有消失，而是位置发生了变化。

2. 一页一个任务，比“一次生成整套 PPT”更可靠

每页独立以后，素材、提示词、比例、批注和版本才有明确归属。修改第 4 页，不会要求重做整套 PPT；新增“打胶固定”，也可以在结构上明确插入。

3. 新版本不能覆盖旧版本

生成模型的结果有不确定性。重新生成可能更好，也可能更差。旧版如果直接被覆盖，比较和回退都会变得困难。候选版本、历史版本和当前采用必须是三个不同状态。

4. 真实素材优先，不代表直接贴图

水晶发财树初版给我的教训很直接：真实产品图很重要，但把它放进一个矩形卡片里，并不等于完成设计。需要保真的部分要锁定；需要场景化的部分则要重新处理空间、光线和构图。

5. 中文和关键结构尽量走确定性布局

如果中文生成在图片里，修改成本很高，也不稳定。让 AI 负责画面，让本地代码负责中文和视频容器，虽然工作流多了一层，却让结果更可靠、更可编辑。

6. 工作流不是设计出来的，是在真实项目里改出来的

7 月 29 日，我以为先写清产品合同和架构，就能得到一个工具。随后一句“可以运行了吗”，让我意识到文档和产品之间还有一段距离。

第一版工作台又太复杂，只能根据真实使用方式重新简化。宋锦台灯让我发现历史内容要拆页、文案需要故事感、中文必须可编辑；水晶发财树又让我发现拼贴感、工艺准确性、结构迁移和版本保留的问题。

如果没有这两套真实项目，很多规则只会停留在想象里。

7. “完成”必须有清楚的证据层级

我现在更愿意把状态拆开：计划中、已执行、已生成、已同步、已构建、已验证结构、已在真实软件打开、已人工验收。

这样看起来更麻烦，却可以避免把一个中间状态误认为最终结果。

12

结尾：我做出来的，不只是一个生成按钮

最终得到的不只是两套 PPT，而是一套能够继续复用和判断的方法。

这件事从帮老婆做 PPT 开始。

最早，我在 ChatGPT 里通过一条很长的对话，一页一页生成、修改和确认。它让我看到，AI 已经可以参与完整 PPT 的视觉制作。

后来，我把这条对话交给 Codex，希望把已经做过的事情整理出来。

7 月 29 日，本地工作台从文档变成可运行原型；8 月 1 日，宋锦珍珠台灯从 9 页反复调整到 11 页，并把中文改成可编辑文本；8 月 8 日至 10 日，水晶发财树经历粗糙初版、六页重做、真实工艺修正、页面增删和第 4 页透明度调整，最终形成 13 页版本。

回头看，Codex 最有价值的地方，不是替我按下一个“生成 PPT”按钮。

它做的是把对话里的经验提取出来，把散落的素材和页面组织起来，把一次次反馈变成可复用规则，再通过真实项目继续修正这套规则。

最后得到的，也不只是一套宋锦台灯 PPT 或一套水晶发财树 PPT。

我得到了一套以后还可以继续做第三套、第四套 PPT 的方法。

AI 可以帮我更快地生成第一版。

而我真正需要学习的，是如何定义一页应该解决什么问题，如何判断画面是否真实，如何保留修改历史，以及如何用证据确认一项工作究竟做到哪一步。

这可能才是我用 ChatGPT 和 Codex 做 PPT 以后，最重要的收获。

最终落地的本地工作流面板：11 个页面节点、当前采用状态和单页进入方式被放在同一条页面主线上。

--

关于我：

kevin2.0，互联网产品、网易 11 年、阿里 3 年，做过 LOFTER、考拉电商、在阿里做过社交，创业过……现在继续创业中，欢迎交流。