用 TRAE Work 做 PPT，最重要的不是「生成」
来源：互联网
时间：2026-07-07 07:50:31
# 前言
TRAE Work 并不是一个输入主题就能变出完美 PPT 的魔法按钮。它的真正价值在于，能把文章整理、页面设计、素材生成、导出验收这些零零碎碎的活儿，塞进一条可以不断迭代的流程里。但前提是，你得先把“怎样才算做好”这件事，给它讲明白。
过去做 PPT，心里一直有个朴素念头：只要 AI 能把页面生出来，后面的事儿就轻松了。等真正上手多跑几轮才发现，根本不是这么回事。
所以这篇文章想聊的，不是“怎么写一句万能 Prompt”，而是完整记录一次具体经验——用 TRAE Work 做 PPT 时，先定义清楚“怎样才算好”，再让工具一步一步往前推的过程。
全程会穿插一个真实例子：把 OpenAI 的两篇文章整理成一次社区分享。
## 一、为什么说“生成 PPT”根本不是最难的部分
PPT 这东西有点特别。它既不是一篇文章，也不是一张海报。文章写清楚就能读，海报做得好看就能发出去，但 PPT 往往还得能讲、能改、能导出、能被批注，打开以后文字最好还能继续编辑。
所以很多问题不是在生成之前冒出来的，而是在生成之后才慢慢浮出水面：
文字框比文字本身宽出一大截，选中后才能发现对象和视觉并不一致
这些问题单独拎出来都不算大，但叠在一起，就会让一份 PPT 卡在“差不多有了”和“可以交付”之间的灰色地带里出不来。
### 具体实战
比如读完 OpenAI 的两篇文章，一篇讲 Harness Engineering，另一篇讲开源的 Codex 编排工具 Symphony。单独看都是技术文章，但放在一起读，能看到背后的递进关系：先让单个 Agent 在工程环境里跑稳，再解决多个 session 同时运行时人手盯不过来的问题。
于是把这些读后感整理成了一套社区分享 PPT。这个例子恰好能说明：一份好 PPT 不是把两篇文章翻译成页面，而是先把“我读完以后真正想讲什么”这个核心抽出来。
## 二、一开始也以为，难的是生成 PPT
很多人第一次用 AI 做 PPT，大概率都是从一句话开始的：
```
帮我把这篇文章做成一份分享 PPT。
```
这句话可以当入口，但只给到这一步，后面往往很难收场。因为 PPT 不是把内容塞进页面就结束了，它涉及一连串判断：
这套视觉应该像分享材料，还是像产品后台、网页组件、信息图？
这些问题不说清楚，AI 就会按它自己最容易理解的方式去做：生成一套很规整的页面，每页有卡片、标题、小点、状态条，看起来完整。但放到分享场景里一看就不对了——像网页截图，像后台页面，像设计 demo，就是不像一套能站在台上讲的 PPT。
所以动笔之前需要一份粗暴的 memo。这份 memo 不需要很复杂，但至少要回答：
拿这次 Codex Symphony 的分享来说，一开始就确认了一条主线：不是把 Harness、Symphony、Loop Engineering 并排解释一遍，而是讲一个递进过程。
主线一旦定下来，后面的页面就不再是随便摆内容了：封面为什么讲“人站的位置变了”，第 9 页为什么不能写成“官方定义”，每页标题为什么要短一点——这些判断都有了依据。
这也正是“读后感做 PPT”和“文章摘要做 PPT”之间的根本差别。
摘要会拆成“第一篇讲什么、第二篇讲什么、最后总结一下”，能做出来但太平了。真正适合分享的，是把读完以后形成的判断讲出来。这次的判断就是：
```
AI 编程的新词不是凭空冒出来的。
先有 Harness 解决“Agent 怎么跑稳”。
再有 Symphony 回应“Agent 多起来以后，人怎么盯得住”。
真正变化的，不只是工具，而是人站的位置。
```
所以现在更习惯把第一步写成：
```
请先不要生成 PPT。
先使用 $kz-article-deep-analysis 分别分析这两篇文章。（这是自己的专属 skill）
每篇都提取核心议题、核心主张、论证骨架、认知增量和边界条件。
然后基于两份分析结果，整理一份 memo、主线以及每页要表达的核心判断。
输出后停住，等我确认。
```
这里还有一个很实用的小技巧：让 AI 把 memo 保存成文档，而不是在对话框里临时说一版。
文档化之后，和 AI 之间的沟通就有了固定锚点，可以直接围绕 memo.md 来改：这句是不是主线，哪页多讲了一个观点，某个判断有没有越过事实边界。这比生成一整套 PPT 后再回头改要轻得多。
PPT 一旦生成，问题就会混在一起：可能主线不对、标题不自然、视觉不舒服、文本框太宽。你说“整体调一下”，AI 很难判断该改内容、改设计还是改文件。但停在 memo 阶段，修改成本就低得多。
## 三、长文要先变成“每页一个判断”
文章和 PPT 最大的区别不是字数，而是观看方式。文章可以慢慢铺垫，分享型 PPT 不行——观众每页停留的时间非常有限，一页塞三个观点，讲的人累，听的人也容易走神。
所以第一步往往是先做个 slide plan，不追求多漂亮，但要把每页的功能说清楚：
```
Slide 03
Claim： AI 编程的痛点在往后移。
Proof object： Harness -> sessions -> supervision overload -> Symphony。
Layout： process sequence。
```
这次 PPT 改过很多标题。早期的偏概念化：“认知递进”“模式变化”“官方边界”——在文章里能解释，放到标题上就感觉太重了。后来改成了更像现场会说的话：
**偏概念的旧标题**
**像人话的新标题**
- AI 新词不是凭空冒出来的
- 痛点在往后移
- session 多了，人盯不过来
- 关系可以这样讲
这套读后感 PPT 最后拆成了 11 页，是按读后的认知顺序来拆的，而不是按两篇文章的目录：
```
01 封面：从 Harness 到 Symphony，真正变的是人站的位置
02 Hook：AI 没改掉技术演进规律，只是把问题暴露得更快
03 递进：AI 编程的痛点在往后移
04 Harness：第一阶段不是调度，而是先让 Agent 跑稳
05 现场：项目现场越清楚，单个 Agent 越容易跑稳
06 新瓶颈：Agent 跑稳后，瓶颈从写代码转向盯 session
07 Symphony：session 多起来之后，调度实践就变得自然
08 模式变化：真正变的是人站的位置
09 边界：可以用 Loop Engineering 理解，但不能说成官方定义
10 给小团队：别急着抄 Symphony，先看自己卡在哪一层
11 收束：先补 Harness，再谈 Orchestration
```
## 四、实际跑通的五步链路
与其重复每一条 prompt 的写法，不如记下几个关键节点——下次再做类似的 PPT，至少要把这些地方守住。
### 第一步：深度解读 + memo
先把两篇文章各自的核心议题、核心主张和边界拆出来，再合并成 memo.md。要反复和 AI 确认对齐，直到“这套分享到底在讲什么”能用一句话说清楚。
### 第二步：memo 拆成 slide plan
每页只保留一个 claim，写清楚对应的 proof object。先不追求文案漂亮，重点确认每页有没有存在的必要，以及想让观众记住什么。
### 第三步：写 design brief
先写清楚“不要像什么”，再写希望接近什么效果。比如说：不要网页截图感、不要 dashboard、不要把事实文字直接拷进图片里。brief 写清楚了，后面生成的页面才不容易跑偏。
### 第四步：用 kz-design 生成 PPTX 和预览
这一步输入的不再是“帮我做个 PPT”，而是已经确认好的 memo.md、slide plan 和 design brief。由 kz-design 负责把内容翻译成 deck：固定 16:9 画布、可编辑 PPTX、页面节奏、字体层级、图形关系、无文字背景资产、逐页预览和 contact sheet。
### 第五步：根据批注逐项修改 + 清理文件
反馈要拆成可执行的小问题：标题是不是像人话，文字框是不是太宽，mask 有没有跟着文字重算，背景安全区有没有被占用，旧文案有没有残留。不要说“帮我整体优化一下”，因为这句指令太模糊了。
最后做一次文件清理。多轮 image-gen、导出、预览之后，目录里容易留下各种中间文件。要明确最终保留哪些 PPTX、预览图和可复用资产，否则下次回头很容易分不清哪个才是最终版。
## 五、视觉目标 ≠ “高级一点”
做 PPT 时最容易给 AI 的视觉要求是：做得高级一点，有科技感，适合社区分享。这句话听起来没什么毛病，但很难执行。
因为“高级”这两个字有太多种理解方式，AI 很可能走向一套常见的科技风：蓝紫渐变、玻璃卡片、等距组件、状态点、仪表盘布局。这些不一定难看，但会把页面带向网页、产品 UI、后台截图的方向。
后来不再只写“请帮我优化得更好看”，而是把 design brief 写得更具体：
希望更像社区分享里的纸张笔记、批注、撕边标签和现场讲解
设计不是先定义“要什么”，而是先定义“不要什么”。反例越清楚，AI 越容易避开默认模板。
放到这套读后感 PPT 里，它既不是 OpenAI 官方发布会，也不是产品 UI 演示，所以不需要假装有一堆系统截图、状态点和控制台组件。更合适的方向是做成一份社区分享里的纸面笔记：暖色纸张、黑色文字、撕边标签、少量批注，用流程图和对比页把递进关系讲清楚。
### 别忘了“背景安全区”
用 image-gen 做背景时很容易被质感吸引：纸张、胶带、撕边、色块都很好看。但真正往上面放文字的时候才发现：好看的背景不等于可用的背景。右上角有胶带、底部有撕纸边、左下角有大色块——这些地方就不能随便放正文。
所以后来会在 design brief 里明确写 safe area，哪怕不精确也要先说清楚：
```
常规内容尽量放在中间纸面区域。
底部不要贴得太低。
左下角有装饰色块时，正文尽量避开。
页码和来源信息不要压到纹理边缘。
```
## 六、image-gen 适合做材料，不适合替你写事实
这次对 image-gen（AI 图片生成）的看法又变了：它很适合帮 PPT 增加质感，但不适合直接承担所有内容。
**image-gen 适合做的**
- 无文字的纸张背景
- 低对比度的工作流纹理
- 撕边标签
- 胶带、纸条、印刷颗粒这些材料
**不让它直接画进去的**
原因很现实：中文可能生成错字，文案后面大概率会改，别人打开还要挪位置。事实文字一旦被拷进图片里，检查和修改都会变得很麻烦。
这次比较有收获的一步，是把一张撕边标签处理成白色 alpha mask。有了这个 mask，后面需要黑色、绿色、黄色的标签时，就不用每次重新生成图片了——用代码直接着色，再按文字长度做九宫格缩放，就能在不同页面里反复复用。
这个细节看起来有点工程化，但对 PPT 来说非常有用。一套 PPT 里很多视觉元素不止出现一次，标签、底板、提示条、强调块如果每页都手动调整，后面只会越来越乱。把它们做成可复用的资产，风格会更稳定，修改也更轻松。
这恰恰是 TRAE Work 适合接手的那段工作：它不止帮你“想一个设计”，还能把设计里可重复的部分变成一套能继续用的资产。
## 七、有些小问题，肉眼一次看不出来
这次遇到一个很小但很典型的问题：有些文字标签看起来上下边距不舒服。第一眼以为是背景图或底图没做好，后来才发现真正影响视觉的是文字框本身——文字框比实际文字宽很多，右边就显得空；宽度估算得太紧了，到了 PowerPoint 里又有可能意外换行。
这种问题非常微妙：单看导出图片只觉得“哪里怪怪的”，一旦选中对象，才能看到文本框和视觉对象并不匹配。
所以后来会把文字框也纳入检查清单：
如果只让 AI“再美化一下”，它不一定能理解你到底在说什么。把问题拆成“文字框宽度”“mask 尺寸”“padding 是否均衡”这些具体条目，反而更容易改到位。
## 八、最后一段路，靠预览和验收
PPT 做完之后，现在不敢只打开第一页看一眼就说完成了。
因为改 PPT 有一个常见问题：你盯着刚改的那一页，就很容易忘掉整套节奏。封面好看了，中间某页突然变挤；第 9 页文案改顺了，旧文案还残留在隐藏对象里；某个标签宽度调好了，又导致另一页换了行。
所以会让工具做四类检查：
这些检查并不复杂，却很容易被忽略。如果目标是交付一个文件而不是只看一张截图，这些检查就非常值得做——它们能把“凭感觉还行”的地方，变成可以复核的结果。
那套读后感 PPT 也是这样收尾的：每次大改之后重新导出 PPTX，渲染成 11 张预览图，拼成一张 contact sheet。一眼就能看出封面撑不撑得住、第 9 页的边界说明是不是太硬、后面 checklist 页是不是突然像表格了。
尤其是第 9 页，最初标题写的是“别说成官方定义”，意思没错但读起来很生硬。后来改成“关系可以这样讲”，下面补一句“更像一种实践，不是官方定义”。这是 PPT 里很常见的平衡：标题要像人话，但边界不能丢。
## 九、现在会怎么给 TRAE Work 派任务
如果重新做一套 PPT，不会再试图把任务写成一句完整的大 Prompt，而是拆成几轮，每轮只解决一类问题。
### 第一轮 · 先分析、再整理，不生成 PPT
```
请先不要生成 PPT。
先使用 $kz-article-deep-analysis 分别分析这两篇文章。
每篇都提取核心议题、核心主张、论证骨架、认知增量和边界条件。
再基于两份分析结果整理一份读后感 memo。
不要逐段摘要，重点提取它们之间的递进关系。
然后整理 claim spine 和 10 页左右的 slide plan。
每页只保留一个 claim，并写出 proof object。
输出后停住，等我确认。
```
### 第二轮 · 写 design brief
```
基于已确认的 slide plan，写 design brief。
重点写清楚：
- 这套 PPT 不要像什么
- 视觉方向和参考对象
- 背景安全区
- 哪些文字必须可编辑
- 哪些元素可以用 image-gen 生成
- 哪些说法只是读后理解，不能写成官方定义
```
### 第三轮 · 交给 kz-design 生成和导出
```
使用 $kz-design，基于已确认的 memo、slide plan 和 design brief 生成可编辑 PPTX。
不要重新猜文章逻辑，不要把个人理解写成官方定义。
文字保留为 PPT 文本层。
图片只做背景、材质和装饰。
每页导出 PNG 预览。
生成 contact sheet。
记录验证结果。
```
### 第四轮 · 根据批注逐项改
```
根据我标注的问题逐项修改。
每次修改后重新导出 PPTX、预览图和 contact sheet。
检查旧文案、文字换行、安全区和 PPTX 的可打开性。
尤其检查底纹和文字这类边界是否合适——不只是看具体参数，更要看视觉效果是否合适。
```
## 十、一张可以随手复用的检查清单
把这次经验压成一张清单，可以保留这些关键问题：
这张清单不一定每次都要完整跑一遍。内部草稿可以轻一点；但如果要交付、要分享、要发给别人继续修改，就值得认真走一遍。
## 写在最后：人的工作没消失，只是换了位置
现在对 TRAE Work 做 PPT 的期待，比一开始更现实了。
它不一定能一次给出完美作品，也不该替人决定内容主线、事实边界和审美判断。但只要能把这些问题讲清楚，它就很适合接住中间那段繁琐的工作：整理结构、生成页面、调整视觉、导出预览、按反馈继续改，再把文件检查一遍。
过去做 PPT，很多时间花在反复挪文本框、换底板、看一页改一页、改完又不放心上。现在这部分工作可以更多交给工具来承担。
