用 Codex 生成 PPT 大纲到底能省多少时间上周团队内部的技术分享轮到我主题是「Spring Boot 3 升级踩坑实录」。按照以往经验从确定主题到拿出能看的 PPT 大纲少说也要抽出一个完整的下午——翻资料、理逻辑、算页数、配时长最后往往还要推翻重来两三轮。这次我换了个思路让 Codex 先跑一轮看看它能把准备时间压缩到什么地步。结果有点出乎意料。从输入需求到拿到可用大纲全程不到 8 分钟。而我自己手工调整到最终版本又花了大概 20 分钟。对比之前纯手动的 3-4 小时框架搭建阶段的效率提升确实肉眼可见。结构合理性Codex 的「骨架」够稳吗我给的提示词很直白「帮我做一个技术分享的 PPT 大纲主题 Spring Boot 3 升级踩坑实录时长 30 分钟受众是还在用 Spring Boot 2 的 Java 开发。」Codex 返回的结构长这样封面与背景2 分钟为什么要升级、技术债风险升级路线图2 分钟评估 → 迁移 → 测试 → 灰度 → 全量三个核心踩坑15 分钟javax 迁移 jakarta、Spring Security 配置变更、第三方依赖兼容性性能对比3 分钟启动时间、内存、QPS升级 Checklist3 分钟可直接复用的检查清单总结与 QA5 分钟这个骨架的合理之处在于节奏感。它不是平均分配每页时间而是把重头戏压在「踩坑」部分——这恰恰是听众最关心的。封面和背景控制在 2 分钟避免了开场拖沓Checklist 作为收尾给了可带走的价值。但也不是没有槽点。Codex 最初把「性能对比」放在了「踩坑」之前我手动调到了后面。因为先讲数据、再讲故事听众容易走神反过来用痛点牵引数据才成了验证。这个调整说明Codex 能搭出 80 分的框架但叙事顺序仍需人把关。页数与时长匹配算得准不准30 分钟分享Codex 规划了 10 页平均每页 3 分钟。实际演讲里这个密度偏松。我按经验把踩坑部分拆成了 6 页每坑 2 页现象 解法总页数扩到 12 页时间反而更舒服。这里有个有趣的发现Codex 对「页数」的理解偏保守。它似乎默认每页承载的信息量较大适合提纲挈领的讲法。但技术分享里一页塞太多代码或对比观众根本来不及消化。我的做法是让 Codex 先按它的节奏生成再按自己的演讲习惯拆细而不是直接要求它生成 15 页——那样容易为了凑数而稀释内容。技术深度与受众适配它懂你的听众吗提示词里「还在用 Spring Boot 2 的 Java 开发」这个限定Codex 理解得不错。它自动避开了 Spring Boot 3 的底层源码分析而是聚焦「从 2 到 3 的迁移成本」——命名空间变更、配置类废弃、依赖版本冲突这些都是迁移者最真实的痛点。但有个细节它没处理好javax 迁移 jakarta 这部分Codex 只写了「用 OpenRewrite 自动化 手动修正」。实际上团队里很多人没用过 OpenRewrite需要补充一句「这是一个自动重构工具类似大规模查找替换但会保留语义」。这种受众认知 gap 的填补目前还得靠人。另一个例子是 Spring Security 的配置变更。Codex 给出了WebSecurityConfigurerAdapter到SecurityFilterChain的代码对比但没解释「为什么废弃前者」。我在大纲里加了一行「Spring 团队想推动函数式配置减少继承滥用」。这句话让改动有了上下文听众更容易接受。从大纲到完整内容扩展空间有多大Codex 的大纲有个特点每个节点都是「可展开的钩子」。比如「坑 1javax → jakarta 命名空间迁移」它下面已经埋好了三层信息现象编译全红解法OpenRewrite 自动化 手动修正耗时比预期多 3 天这三层就是天然的扩展路径。实际做 PPT 时我把「现象」做成了两张截图对比迁移前后的编译错误「解法」补了一个 30 秒的 OpenRewrite 命令行演示「耗时」则扩展成了一张甘特图。整个过程像填空而不是从零创作。对比传统流程这个差异很关键。以前写大纲脑子里同时装着「结构」和「内容」两层经常写着写着就陷进细节里。Codex 把这两层解耦了先定结构再填内容认知负担小很多。时间账到底省了多少我粗略记了笔账环节传统方式Codex 辅助备注主题拆解与结构搭建60-90 分钟8 分钟含多轮 prompt 调整页数与时长分配30 分钟已内嵌在大纲微调即可技术点筛选与排序45 分钟15 分钟需人工校验受众适配大纲到 PPT 初稿60 分钟30 分钟扩展节点、补充案例总计3-4 小时约 1 小时含人工调整最省时间的环节是结构搭建从 60-90 分钟压到 8 分钟接近一个数量级的提升。但也要注意这 8 分钟的前提是提示词足够清晰——如果需求模糊来回纠偏的时间会成倍增加。另一个隐性收益是心理成本。以前写大纲前 20 分钟往往对着空白页发呆不知道从哪里下手。Codex 给了第一版之后修改比创作轻松得多进入状态更快。它的边界在哪里用下来Codex 在 PPT 大纲场景有三条明显边界第一叙事节奏依赖人。它能按时间分配页数但不懂「先抑后扬」或「悬念埋设」。技术分享不是信息罗列情绪曲线还得自己设计。第二案例鲜活度不足。它生成的「坑」是通用的但真实的踩坑往往带有个性化细节——比如「那天凌晨 2 点线上报警发现是某个内网依赖没升级」。这些故事性元素Codex 给不出。第三视觉呈现无感知。大纲是线性的但 PPT 是空间化的。哪里放全图、哪里做对比、哪里需要动画引导这些它帮不上忙。所以我的用法是Codex 出骨架人负责注入灵魂。骨架阶段省下的时间可以挪到案例打磨和排练上整体质量反而更高。一个可复用的 prompt 模板最后分享下我沉淀的 prompt 结构试了几次比较稳定帮我做一个技术分享的 PPT 大纲。 主题[具体主题] 时长[X] 分钟 受众[技术背景 当前状态] 要求 - 结论先行每页先说观点 - 核心难点占 50% 以上时长 - 结尾给可带走的 Checklist 或资源 - 标注每页建议时长这个模板的 trick 在于约束条件具体化。「结论先行」控制叙事风格「核心难点占 50%」防止平均用力「标注时长」让页数分配有据可查。Codex 对这种结构化指令的响应明显比模糊描述更稳定。如果你也在准备技术分享不妨先让 Codex 跑一版大纲。省下的时间足够你把某个案例讲得更透或者干脆早点下班。