# 前言 TRAE Work 并非一个输入主题就能自动生成完美演示文稿的魔法工具。它的核心价值在于，能将内容整理、页面设计、素材制作、导出验收等琐碎环节，整合进一条可持续迭代的工作流程。但使用的前提是，你必须先清晰定义“怎样才算合格”，并将这个标准明确告知工具。

过去制作演示文稿时，我始终怀有一个朴素想法：只要 AI 能够生成页面，后续工作就会轻松许多。然而，经过多次实际操作后才发现，实际情况远非如此。 因此，本文想探讨的并非“如何写一句万能指令”，而是完整记录一次具体实践经验——在使用 TRAE Work 制作演示文稿时，先定义清楚“怎样才算好”，再让工具逐步推进的完整过程。 整个过程将穿插一个真实案例：将 OpenAI 的两篇文章整理成一次社区分享内容。 ## 一、为什么说“生成演示文稿”并非最难的环节 演示文稿是一种特殊的媒介。它既不完全等同于文章，也不等同于海报。文章写清楚就能阅读，海报设计美观即可发布，但演示文稿往往还需要能够讲解、编辑、导出、接受批注，并且打开后文字最好仍能继续编辑。 因此，许多问题并非在生成前出现，而是在生成后逐渐暴露：

• 首页封面缺乏吸引力
• 页面看起来像网页截图
• 标题读起来不够自然
• 背景纹理影响文字可读性
• 文字框比实际内容宽出许多，选中后才发现对象与视觉并不匹配

这些问题单独看来都不算严重，但叠加在一起，就会让一份演示文稿卡在“接近完成”与“可以交付”之间的灰色地带。 ### 具体实战案例 例如，阅读 OpenAI 的两篇文章：一篇关于 Harness Engineering，另一篇介绍开源 Codex 编排工具 Symphony。单独看都是技术文章，但放在一起阅读，能够看出背后的递进关系：先让单个 Agent 在工程环境中稳定运行，再解决多个会话同时运行时人工监控不足的问题。 于是，我将这些阅读感悟整理成了一套社区分享演示文稿。这个案例恰好说明：一份优秀的演示文稿不是简单地将两篇文章翻译成页面，而是先提炼出“我读完以后真正想表达什么”这个核心。 ## 二、最初也以为，难点在于生成演示文稿 许多人第一次使用 AI 制作演示文稿，通常都是从一句话开始的： ``` 帮我把这篇文章做成一份分享演示文稿。 ``` 这句话可以作为入口，但只做到这一步，后续往往难以收场。因为演示文稿不是简单地将内容塞进页面就结束，它涉及一系列判断：

• 这套内容的目标受众是谁？
• 每一页希望观众记住什么？
• 哪些是客观事实，哪些是主观理解？
• 这套视觉风格应该像分享材料，还是像产品后台、网页组件、信息图？
• 最终如何判断它是否可以交付？

这些问题如果不明确，AI 就会按照它最容易理解的方式去执行：生成一套非常规整的页面，每页包含卡片、标题、要点、状态条，看起来完整。但放到分享场景中就会发现不对劲——它像网页截图、像后台页面、像设计原型，唯独不像一套能够站在台上讲解的演示文稿。 因此，动笔之前需要一份简洁的备忘录。这份备忘录不需要复杂，但至少需要回答：

• 两篇文章各自在回应什么问题？
• 这次分享的主线是什么？
• 目标读者或听众是谁？
• 文章里哪些判断必须保留？
• 哪些说法有事实边界？
• 这套演示文稿最终需要输出哪些文件和预览？

以这次 Codex Symphony 的分享为例，一开始就确认了一条主线：不是将 Harness、Symphony、Loop Engineering 并列解释，而是讲述一个递进过程。 主线一旦确定，后续页面就不再是随意摆放内容：封面为什么讲“人站的位置变了”，第 9 页为什么不能写成“官方定义”，每页标题为什么要简洁明了——这些判断都有了依据。 这也正是“读后感做演示文稿”与“文章摘要做演示文稿”之间的根本区别。 摘要会拆分成“第一篇讲什么、第二篇讲什么、最后总结一下”，能做出来但显得平淡。真正适合分享的，是把阅读后形成的判断表达出来。这次的判断就是： ``` AI 编程的新概念并非凭空出现。 先有 Harness 解决“Agent 如何稳定运行”。 再有 Symphony 回应“Agent 增多后，人如何有效监控”。 真正发生变化的，不仅是工具，更是人站的位置。 ``` 所以现在更习惯将第一步写为： ``` 请先不要生成演示文稿。 先使用 $kz-article-deep-analysis 分别分析这两篇文章。（这是自己的专属技能） 每篇都提取核心议题、核心主张、论证框架、认知增量与边界条件。 然后基于两份分析结果，整理一份备忘录、主线以及每页要表达的核心判断。 输出后暂停，等我确认。 ```

这里还有一个非常实用的技巧：让 AI 将备忘录保存为文档，而不是在对话框中临时生成一版。 文档化之后，与 AI 的沟通就有了固定参考点，可以直接围绕备忘录文件进行修改：这句话是否符合主线，哪一页多讲了一个观点，某个判断是否越过了事实边界。这比生成一整套演示文稿后再回头修改要轻便得多。 演示文稿一旦生成，问题就会混在一起：可能主线不对、标题不自然、视觉不舒服、文本框太宽。你说“整体调整一下”，AI 很难判断应该修改内容、设计还是文件。但停留在备忘录阶段，修改成本就低得多。

## 三、长文要先转化为“每页一个判断” 文章和演示文稿最大的区别不在于字数，而在于观看方式。文章可以慢慢铺垫，但分享型演示文稿不行——观众每页停留的时间非常有限，一页塞入三个观点，讲解者累，听众也容易走神。 因此，第一步通常是先制作一个幻灯片提纲，不追求多漂亮，但要把每页的功能说清楚： ``` Slide 03 核心观点： AI 编程的痛点正在向后转移。 证据对象： Harness -> sessions -> supervision overload -> Symphony。 布局方式： process sequence。 ``` 这次演示文稿修改过很多标题。早期的偏概念化：“认知递进”“模式变化”“官方边界”——在文章中可以解释，但放到标题上就显得过于沉重。后来改成了更像现场会说的话： **偏概念的旧标题**

• 认知递进
• 模式变化
• 官方边界

**像人话的新标题**

• AI 新词不是凭空冒出来的
• 痛点在往后移
• session 多了，人盯不过来
• 关系可以这样讲

这套读后感演示文稿最终拆分为 11 页，按照读后的认知顺序来拆分，而不是按照两篇文章的目录： ``` 01 封面：从 Harness 到 Symphony，真正变的是人站的位置 02 钩子：AI 没改掉技术演进规律，只是把问题暴露得更快 03 递进：AI 编程的痛点在往后移 04 Harness：第一阶段不是调度，而是先让 Agent 跑稳 05 现场：项目现场越清楚，单个 Agent 越容易跑稳 06 新瓶颈：Agent 跑稳后，瓶颈从写代码转向盯 session 07 Symphony：session 多起来之后，调度实践就变得自然 08 模式变化：真正变的是人站的位置 09 边界：可以用 Loop Engineering 理解，但不能说成官方定义 10 给小团队：别急着抄 Symphony，先看自己卡在哪一层 11 收束：先补 Harness，再谈 Orchestration ``` ## 四、实际跑通的五步链路 与其重复每一条指令的写法，不如记下几个关键节点——下次再做类似的演示文稿，至少要把这些地方守住。 ### 第一步：深度解读加备忘录 先把两篇文章各自的核心议题、核心主张和边界拆解出来，再合并成备忘录文件。要反复与 AI 确认对齐，直到“这套分享到底在讲什么”能用一句话说清楚。 ### 第二步：备忘录拆成幻灯片提纲 每页只保留一个核心观点，写清楚对应的证据对象。先不追求文案漂亮，重点确认每页是否有存在的必要，以及想让观众记住什么。 ### 第三步：写设计简报 先写清楚“不要像什么”，再写希望接近什么效果。比如说：不要网页截图感、不要仪表盘、不要把事实文字直接拷进图片里。简报写清楚了，后续生成的页面才不容易跑偏。 ### 第四步：用 kz-design 生成 PPTX 和预览 这一步输入的不再是“帮我做个演示文稿”，而是已经确认好的备忘录文件、幻灯片提纲和设计简报。由 kz-design 负责把内容翻译成演示文稿：固定 16:9 画布、可编辑 PPTX、页面节奏、字体层级、图形关系、无文字背景资产、逐页预览和概览页。

### 第五步：根据批注逐项修改加清理文件 反馈要拆分成可执行的小问题：标题是不是像人话，文字框是不是太宽，蒙版有没有跟着文字重新计算，背景安全区有没有被占用，旧文案有没有残留。不要说“帮我整体优化一下”，因为这句指令太模糊了。 最后做一次文件清理。多轮图像生成、导出、预览之后，目录里容易留下各种中间文件。要明确最终保留哪些 PPTX、预览图和可复用资产，否则下次回头很容易分不清哪个才是最终版。 ## 五、视觉目标不等于“高级一点” 制作演示文稿时最容易给 AI 的视觉要求是：做得高级一点，有科技感，适合社区分享。这句话听起来没什么毛病，但很难执行。 因为“高级”这两个字有太多种理解方式，AI 很可能走向一套常见的科技风：蓝紫渐变、玻璃卡片、等距组件、状态点、仪表盘布局。这些不一定难看，但会把页面带向网页、产品 UI、后台截图的方向。 后来不再只写“请帮我优化得更好看”，而是把设计简报写得更具体：

• 不要等距卡片
• 不要按钮感很强的标签
• 不要仪表盘式页面
• 不要把每页都做成产品 UI
• 希望更像社区分享里的纸张笔记、批注、撕边标签和现场讲解

设计不是先定义“要什么”，而是先定义“不要什么”。反例越清楚，AI 越容易避开默认模板。 放到这套读后感演示文稿里，它既不是 OpenAI 官方发布会，也不是产品 UI 演示，所以不需要假装有一堆系统截图、状态点和控制台组件。更合适的方向是做成一份社区分享里的纸面笔记：暖色纸张、黑色文字、撕边标签、少量批注，用流程图和对比页把递进关系讲清楚。 ### 别忘了“背景安全区” 用图像生成做背景时很容易被质感吸引：纸张、胶带、撕边、色块都很好看。但真正往上面放文字的时候才发现：好看的背景不等于可用的背景。右上角有胶带、底部有撕纸边、左下角有大色块——这些地方就不能随便放正文。 所以后来会在设计简报里明确写安全区域，哪怕不精确也要先说清楚： ``` 常规内容尽量放在中间纸面区域。 底部不要贴得太低。 左下角有装饰色块时，正文尽量避开。 页码和来源信息不要压到纹理边缘。 ``` ## 六、图像生成适合做材料，不适合替你写事实 这次对图像生成（AI 图片生成）的看法又变了：它很适合帮演示文稿增加质感，但不适合直接承担所有内容。 **图像生成适合做的**

• 无文字的纸张背景
• 低对比度的工作流纹理
• 撕边标签
• 胶带、纸条、印刷颗粒这些材料

**不让它直接画进去的**

• 标题
• 页码
• 引用来源
• 关键术语

原因很现实：中文可能生成错字，文案后面大概率会改，别人打开还要挪位置。事实文字一旦被拷进图片里，检查和修改都会变得很麻烦。 这次比较有收获的一步，是把一张撕边标签处理成白色 Alpha 蒙版。有了这个蒙版，后面需要黑色、绿色、黄色的标签时，就不用每次重新生成图片了——用代码直接着色，再按文字长度做九宫格缩放，就能在不同页面里反复复用。

这个细节看起来有点工程化，但对演示文稿来说非常有用。一套演示文稿里很多视觉元素不止出现一次，标签、底板、提示条、强调块如果每页都手动调整，后面只会越来越乱。把它们做成可复用的资产，风格会更稳定，修改也更轻松。 这恰恰是 TRAE Work 适合接手的那段工作：它不止帮你“想一个设计”，还能把设计里可重复的部分变成一套能继续用的资产。 ## 七、有些小问题，肉眼一次看不出来 这次遇到一个很小但很典型的问题：有些文字标签看起来上下边距不舒服。第一眼以为是背景图或底图没做好，后来才发现真正影响视觉的是文字框本身——文字框比实际文字宽很多，右边就显得空；宽度估算得太紧了，到了 PowerPoint 里又有可能意外换行。 这种问题非常微妙：单看导出图片只觉得“哪里怪怪的”，一旦选中对象，才能看到文本框和视觉对象并不匹配。 所以后来会把文字框也纳入检查清单：

• 单行文字有没有意外换行
• 短文字的文本框有没有过宽
• 背景底纹有没有跟着文字框重新计算
• 上下左右留白是不是大致均衡
• 文字是不是仍然可以编辑

如果只让 AI “再美化一下”，它不一定能理解你到底在说什么。把问题拆成“文字框宽度”“蒙版尺寸”“内边距是否均衡”这些具体条目，反而更容易改到位。 ## 八、最后一段路，靠预览和验收 演示文稿做完之后，现在不敢只打开第一页看一眼就说完成了。 因为修改演示文稿有一个常见问题：你盯着刚改的那一页，就很容易忘掉整套节奏。封面好看了，中间某页突然变挤；第 9 页文案改顺了，旧文案还残留在隐藏对象里；某个标签宽度调好了，又导致另一页换了行。 所以会让工具做四类检查：

这些检查并不复杂，却很容易被忽略。如果目标是交付一个文件而不是只看一张截图，这些检查就非常值得做——它们能把“凭感觉还行”的地方，变成可以复核的结果。 那套读后感演示文稿也是这样收尾的：每次大改之后重新导出 PPTX，渲染成 11 张预览图，拼成一张概览页。一眼就能看出封面撑不撑得住、第 9 页的边界说明是不是太硬、后面清单页是不是突然像表格了。 尤其是第 9 页，最初标题写的是“别说成官方定义”，意思没错但读起来很生硬。后来改成“关系可以这样讲”，下面补一句“更像一种实践，不是官方定义”。这是演示文稿里很常见的平衡：标题要像人话，但边界不能丢。 ## 九、现在会怎么给 TRAE Work 派任务 如果重新做一套演示文稿，不会再试图把任务写成一句完整的大指令，而是拆成几轮，每轮只解决一类问题。 ### 第一轮 · 先分析、再整理，不生成演示文稿 ``` 请先不要生成演示文稿。 先使用 $kz-article-deep-analysis 分别分析这两篇文章。 每篇都提取核心议题、核心主张、论证框架、认知增量和边界条件。 再基于两份分析结果整理一份读后感备忘录。 不要逐段摘要，重点提取它们之间的递进关系。 然后整理观点主线与 10 页左右的幻灯片提纲。 每页只保留一个核心观点，并写出证据对象。 输出后暂停，等我确认。 ``` ### 第二轮 · 写设计简报 ``` 基于已确认的幻灯片提纲，写设计简报。 重点写清楚： - 这套演示文稿不要像什么 - 视觉方向和参考对象 - 背景安全区 - 哪些文字必须可编辑 - 哪些元素可以用图像生成制作 - 哪些说法只是读后理解，不能写成官方定义 ``` ### 第三轮 · 交给 kz-design 生成和导出 ``` 使用 $kz-design，基于已确认的备忘录、幻灯片提纲和设计简报生成可编辑 PPTX。 不要重新猜测文章逻辑，不要把个人理解写成官方定义。 文字保留为 PPT 文本层。 图片只做背景、材质和装饰。 每页导出 PNG 预览。 生成概览页。 记录验证结果。 ``` ### 第四轮 · 根据批注逐项改 ``` 根据我标注的问题逐项修改。 每次修改后重新导出 PPTX、预览图和概览页。 检查旧文案、文字换行、安全区和 PPTX 的可打开性。 尤其检查底纹和文字这类边界是否合适——不只是看具体参数，更要看视觉效果是否合适。 ``` ## 十、一张可以随手复用的检查清单 把这次经验压成一张清单，可以保留这些关键问题： 这张清单不一定每次都要完整跑一遍。内部草稿可以轻一点；但如果要交付、要分享、要发给别人继续修改，就值得认真走一遍。 ## 写在最后：人的工作没消失，只是换了位置 现在对 TRAE Work 制作演示文稿的期待，比一开始更现实了。 它不一定能一次给出完美作品，也不该替人决定内容主线、事实边界和审美判断。但只要能把这些问题讲清楚，它就很适合接住中间那段繁琐的工作：整理结构、生成页面、调整视觉、导出预览、按反馈继续改，再把文件检查一遍。 过去制作演示文稿，很多时间花在反复挪文本框、换底板、看一页改一页、改完又不放心上。现在这部分工作可以更多交给工具来承担。