这是文中提到的那套示例 PPT：把 OpenAI Harness Engineering 和 Symphony 两篇文章整理成一次社区分享。后面聊到的主线拆解、视觉 brief、image-gen、文字框检查和验收，都是围绕这套 PPT 的迭代过程展开的。
前言
过去我做 PPT 时，一直有个很朴素的想法：只要 AI 能帮我把页面生成出来，后面的事情应该就轻松了。
真正多做几轮以后，才发现不是这样。
PPT 这个东西有点特殊。它不是一篇文章，也不是一张海报。文章写清楚了就能读，海报好看了也能发，但 PPT 往往还要能讲、能改、能导出、能被别人批注，最好打开以后文字还能编辑。
所以很多问题，不是在生成之前出现的，而是在生成之后才慢慢冒出来。
比如封面第一眼不够抓人，页面看起来像网页截图，标题读起来不太像正常人会说的话。再细一点，背景纹理压住了文字，某个标签的边距看起来不舒服，文字框比文字本身宽出一大块，选中之后才发现对象和视觉效果并不一致。
这些问题单独看都不大，但叠在一起，就会让一份 PPT 卡在“差不多有了”和“可以交付”之间。
这也是我后来重新理解 TRAE Work 的地方。
它不是一个把主题丢进去、等着产出完美 PPT 的魔法按钮。更适合的用法，是把一件原本散在文章整理、页面设计、素材生成、文件导出和反复检查里的工作，放进一条可以持续迭代的链路里。
所以这篇文章想聊的，不是“怎么写一句万能 Prompt”。我更想记录一次比较具体的经验：用 TRAE Work 做 PPT 时，我后来是怎么先把“怎么才算做好”讲清楚，再让工具一点点往前推进的。
下面我会穿插一个真实例子。
先说一下适用边界。
这套方法更适合对外分享、需要反复修改、最后还要交付 PPTX 的场景。如果只是内部讨论草稿，没必要把每一步都跑满，可以先保留 memo 和 slide plan，等内容确实值得做成正式 PPT，再补设计、image-gen 和验收流程。
前阵子我读了 OpenAI 的两篇文章，一篇讲 Harness Engineering，一篇讲 开源的 Codex 编排工具 Symphony。它们单独看都是技术文章，但放在一起读，就能感受到背后的递进关系：先让单个 Agent 在工程环境里跑稳，再面对多个 session 同时运行以后，人开始盯不过来的问题。
于是，我就想把这份读后感整理成了一套社区分享 PPT。这个例子刚好能说明：一份 PPT 不是把两篇文章翻译成页面，而是要先把“我读完以后真正想讲什么”抽出来。
我一开始也以为，难的是生成 PPT
很多人第一次用 AI 做 PPT，大概率都会从一句话开始：
帮我根据这篇文章做一份分享 PPT。
这句话当然可以作为入口，但如果只给到这里，后面通常会比较难收。
因为 PPT 不是把内容放进页面就结束了。它还涉及一连串判断：
这套内容是给谁看的？
每一页到底想让观众记住什么？
哪些是事实，哪些只是我的理解？
这套视觉应该像一份分享材料，还是像产品后台、网页组件、信息图？
最终怎么判断它已经可以交付？
这些问题不先说清楚，AI 也不是不能做，只是它会按照自己最容易理解的方式去做。
它可能会生成一套很规整的页面。每页都有卡片，有标题，有小点，有状态条，看起来完整，但你放到分享场景里，会觉得不太对。像网页截图，像后台页面，像一个设计 demo，就是不像一套可以站在台上讲的 PPT。
这不是工具的问题。更多时候，是我们没有先把判断标准讲出来。
我后来会先做两件事。
第一件事，不急着让它生成 PPT，而是先用 kz-article-deep-analysis 技能分别分析两篇文章。
这一步不是为了多产出一份报告，而是先把原文里的核心议题、核心主张、论证骨架和认知增量拆出来。尤其是两篇文章放在一起时，不能只看“各自讲了什么”，还要看它们之间有没有递进关系。
第二件事，再基于分析结果整理 memo。
这样得到的 memo 就不是两篇文章的摘要拼接，而是已经带着判断的二次组织。
这份 memo 不需要很复杂，但至少要回答几个问题：
-
两篇文章各自在回应什么问题？
-
这次分享的主线是什么？
-
读者或者听众是谁？
-
文章里哪些判断必须保留？
-
哪些说法有事实边界？
-
这套 PPT 最后要输出什么文件和预览？
拿这次 Codex Symphony 的分享来说，前面先确认了一条主线：不是把 Harness、Symphony、Loop Engineering 这些词并排解释一遍，而是讲一个递进过程。
先有 Harness，让单个 Agent 在项目里跑稳。等 session 多起来以后，人开始盯不过来，于是才自然出现 Symphony 这种调度实践。
这个主线一旦确认，后面的页面就不再是随便摆内容。封面为什么要讲“人站的位置变了”，第 9 页为什么不能写成“官方定义”，每页标题为什么要短一点，这些判断都有了来源。
这也是“读后感做 PPT”和“文章摘要做 PPT”的差别。
如果只是摘要，大概率会拆成：第一篇讲什么，第二篇讲什么，最后总结一下。这样当然也能做，但会比较平。真正适合分享的，是把读完以后形成的那个判断讲出来。
这次的判断就是：
AI 编程的新词不是凭空冒出来的。
先有 Harness 解决“Agent 怎么跑稳”。
再有 Symphony 回应“Agent 多起来以后，人怎么盯得住”。
真正变化的，不只是工具，而是人站的位置。
有了这几句话，PPT 才开始有方向。
所以我现在更习惯把第一步写成：
请先不要生成 PPT。
先使用 $kz-article-deep-analysis 分别分析这两篇文章。
每篇都提取核心议题、核心主张、论证骨架、认知增量和边界条件。
然后基于两份分析结果，整理一份 memo、主线和每页要表达的核心判断。
输出后停住，等我确认。
这个停顿很重要。
它让人先把方向看一遍，也让后面的修改不至于变成无休止的“再高级一点”“再好看一点”。
这里还有一个小技巧：不要只让 AI 在对话里临时说一版 memo，最好让它把 memo 保存成一个文档。
文档化以后，你和 AI 的沟通就有了一个固定锚点。你可以直接围绕这份 memo.md 来改：这句话是不是主线，哪一页是不是多讲了一个观点，某个判断有没有越过事实边界，读者看到这里会不会跟得上。
这比直接生成一整套 PPT 以后再回头改要轻很多。
PPT 一旦生成出来，问题会混在一起：可能是主线不对，也可能是标题不自然，也可能是视觉不舒服，还可能是某个文本框太宽。你再说“整体调一下”，AI 很难判断到底该改内容、改设计，还是改文件。
但如果还停在 memo 阶段，修改成本就低得多。先把核心议题定住，再把每一页具体讲什么定住。等这两件事过关，再去做 slide plan 和 PPT，后面的大部分修改都会更有方向。
长文要先变成每页一个判断
文章和 PPT 最大的区别，不是字数多少，而是观看方式不一样。
文章可以慢慢铺垫，PPT 不太行。尤其是分享型 PPT，观众每一页停留的时间很短。如果一页里面同时有三个观点，讲的人会很累，听的人也很容易散。
所以我后来会先做 slide plan。
它不需要一开始就写得很漂亮，先把每页的功能说清楚就行：
Slide 03
Claim: AI 编程的痛点在往后移。
Proof object: Harness -> sessions -> supervision overload -> Symphony。
Layout: process sequence。
这里最有用的是 Claim。
它不是正式标题，也不是页面文案，而是这一页必须讲清楚的那句话。先有这句话，标题和设计才有依附的东西。
这次 PPT 后来改过很多标题。早期有些说法偏概念，比如“认知递进”“模式变化”“官方边界”。这些词在文章里可以解释，但放到 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
你会发现，这不是按两篇文章的目录来拆，而是按读后的认知顺序来拆。
先给一个问题，再解释为什么先是 Harness，然后让读者看到新的瓶颈，最后才引出 Symphony 和人的位置变化。这样现场讲起来会顺很多。
我现在判断 PPT 标题有一个很简单的办法：把标题单独读一遍。
如果这句话我不会在现场说出来，那它大概率就不适合放在页面最上面。可以再短一点，再直一点，少一点概念包装。
这套 PPT 我实际是这样跑的
上面那张截图已经把具体操作过程露出来了，所以这里不再逐条复述每一条 prompt。我更想留下的是几个关键节点：如果下次再做一套类似的 PPT，至少要把这些地方守住。
第一步，不是生成 PPT，而是先做深度解读和 memo。
先把两篇文章各自的核心议题、核心主张和边界拆出来，再合并成一份 memo.md。这一步要反复和 AI 对齐，直到“这套分享到底讲什么”能一句话说清。
第二步，把 memo 拆成 slide plan。
每页只保留一个 claim，并写清楚对应的 proof object。这里先不要追求文案漂亮，重点是确认每页有没有存在的必要，以及这一页到底要让观众记住什么。
第三步，再写 design brief。
我现在会先写清楚“不要像什么”，再写希望接近什么效果。比如不要网页截图感，不要 dashboard，不要把事实文字烤进图片里。这个 brief 写清楚了，后面生成页面才不容易跑偏。
第四步，使用 kz-design 技能生成 PPTX 和预览。
到这一步，输入给 kz-design 技能的不再是一句“帮我做个 PPT”，而是已经确认过的 memo.md、slide plan 和 design brief。也就是说，内容主线、每页 claim、边界 caveat 和视觉禁区都已经在前面定过了。
$kz-design 主要负责把这些内容翻译成 deck：固定 16:9 画布、可编辑 PPTX、页面节奏、字体层级、图形关系、无文字背景资产、逐页预览和 contact sheet。它不应该重新猜文章逻辑，也不应该把个人理解改成官方定义。
PPTX 只是交付文件，逐页截图和 contact sheet 才是验收工具。每次大改后都要重新看整套节奏，而不是只盯着刚改的那一页。
第五步，根据批注逐项修。
反馈要尽量拆成可执行的小问题：标题是否像人话，文字框是不是太宽，mask 有没有跟着文字重算，背景安全区有没有被占用，旧文案有没有残留。不要只说“整体优化一下”，那样 AI 很难知道该从哪里下手。
最后再做一次文件清理。
多轮 image-gen、导出和预览以后，目录里很容易留下很多中间文件。最终要保留哪些 PPTX、预览图和可复用资产，最好也明确一下。否则下一次回头看，很容易分不清哪个才是最终版。
视觉方向不是一句“高级点”
做 PPT 时，最容易给 AI 的视觉要求是：
做得高级一点，有科技感，适合社区分享。
这句话听起来没问题，但其实很难执行。
因为“高级”有太多种理解。AI 很可能会走向一套常见的科技风：蓝紫渐变、玻璃卡片、等距组件、状态点、仪表盘式布局。
这些元素并不一定难看，但它们会把页面带向另一种东西：像网页、像产品 UI、像后台截图。
这次最有帮助的反馈，反而是一个反向判断：整体风格太像网页截图了，不像 PPT。
这句话一下子把问题说清楚了。
后面我就不再只写“更好看”，而是把设计 brief 写得更具体：
-
不要等距卡片。
-
不要按钮感很强的标签。
-
不要 dashboard 式页面。
-
不要把每一页都做成产品 UI。
-
希望更像社区分享里的纸张笔记、批注、撕边标签和现场讲解。
这个变化看起来只是审美调整，其实很关键。
因为很多时候，设计不是先定义“我要什么”，而是先定义“我不要什么”。反例越清楚，AI 越容易避开默认模板。
放到那套 Harness / Symphony 的读后感 PPT 里，这个设计 brief 也很具体。
它不是 OpenAI 官方发布会，也不是产品 UI 演示，所以不需要假装有一堆系统截图、状态点和控制台组件。更合适的方向，是把它做成一份社区分享里的纸面笔记：暖色纸张、黑色文字、撕边标签、少量批注，用流程图和对比页把递进关系讲清楚。
这里有一个小取舍也挺重要：不使用 OpenAI logo，不伪造产品截图。因为这套 PPT 讲的是我的读后理解，不是官方物料。视觉可以有质感，但事实层要干净。
还有一个细节，是背景安全区。
一开始用 image-gen 做背景时，很容易被它的质感吸引。纸张、胶带、撕边、色块，都挺好看。但真正放文字时才会发现：好看的背景不等于可用的背景。
右上角如果有胶带，底部如果有撕纸边，左下角如果有大色块，这些地方就不能随便放正文。
所以后来我会让设计 brief 里明确写 safe area。哪怕不是非常精确，也要先说清楚：
常规内容尽量放在中间纸面区域。
底部不要贴得太低。
左下角有装饰色块时，正文尽量避开。
页码和来源信息不要压到纹理边缘。
这一步不华丽，但很实用。它能减少很多后面才发现的遮挡问题。
image-gen 适合做材料，不适合替你写事实
这次我对 image-gen 的看法也变了。
它很适合帮 PPT 增加质感，但不适合直接承担所有内容。
尤其是有事实、有标题、有术语、有中文说明的地方，我会尽量让文字留在 PPT 的可编辑文本层里。图片负责气质，文字负责事实。
这样分工以后，image-gen 的用法反而更清楚了。
它可以生成无文字纸张背景，可以生成低对比的工作流纹理，可以生成撕边标签，也可以生成一些胶带、纸条、印刷颗粒之类的材料。
但标题、页码、引用来源、关键术语，不让它直接画进去。
原因很现实。
中文可能会生成错。
文案后面大概率会改。
PPT 打开以后，别人可能还要挪位置。
事实文字一旦烤进图片里，检查和修改都会变麻烦。
这次比较有收获的一步，是把一张撕边标签处理成白色 alpha mask。
有了这个 mask，后面需要黑色标签、绿色标签、黄色标签时，就不需要每次重新生成图片。只要用代码着色，再根据文字长度做九宫格缩放，就能在不同页面复用。
这一步生成的不是最终页面，而是一批无文字底板素材：纹理、标签、badge、面板和高亮条。后面再按颜色和尺寸复用，文字仍留在 PPT 文本层。
这个细节看起来有点工程化，但对 PPT 很有用。
因为一套 PPT 里，很多视觉元素并不是只出现一次。标签、底板、提示条、强调块，如果每页都手工调，前面几页还能忍，后面就会越来越乱。
把它做成可复用资产以后，风格会稳定很多，修改也轻松很多。
这也是我后来觉得 TRAE Work 适合接住的一段工作：它不只是帮你“想一个设计”，还可以把设计里可重复的部分变成一套能继续用的资产。
有些小问题，不是肉眼能一次看出来的
这次还有一个很小、但挺典型的问题。
有些文字标签看起来上下边距不舒服。第一眼会以为是背景图的问题，或者是底图没做好。
后来仔细看，发现不完全是。
真正影响视觉的，可能是文字框本身。比如文字框比实际文字宽很多，右边就会显得空；如果文字宽度估算太紧，到了 PowerPoint 里又可能意外换行。
这种问题很微妙。单看导出的图片，也许只是觉得“哪里怪怪的”。但一旦选中对象，就能看到文本框和视觉对象之间并不匹配。
所以后来我会把文字框也纳入检查。
不是只看它有没有显示出来，而是看：
-
单行文字有没有意外换行。
-
短文字的文本框有没有过宽。
-
背景底纹有没有跟着文字框重新计算。
-
上下左右留白是不是大致均衡。
-
文字是不是仍然可以编辑。
这一步听起来很细，但它决定了 PPT 最后的完成感。
很多 PPT 看起来不够精致，不一定是因为设计方向错了，而是这些小关系没有对齐。
在 Harness / Symphony 那套 PPT 里，类似的小问题出现过好几次。
比如封面右侧有一个 Human on the Loop 标签，刚开始背景宽度偏大，文字看起来没有问题，但整个标签在画面里有点松。后来不是简单把图缩小，而是重新计算文字框宽度，再按文字框和留白重新生成 mask。
还有一页短标签也是这样。第一眼以为是上下边距不舒服，后来发现真正的原因是文字框比文字本身宽太多，导致右侧空白看起来特别明显。
这种问题如果只让 AI “再美化一下”，它不一定知道你在说什么。反而是把问题拆成“文字框宽度”“mask 尺寸”“padding 是否均衡”，更容易改到位。
最后一段路，还是要靠预览和验收
PPT 做完以后，我现在不太敢只打开第一页看一眼就说完成。
因为改 PPT 有一个很常见的问题：你盯着刚刚改的那一页，就很容易忘掉整套的节奏。
比如封面好看了，但中间某一页突然变挤。第 9 页文案改顺了，但旧文案还残留在某个隐藏对象里。某个标签宽度调好了，却又导致另一页换行。
所以我会让工具做几类检查。
第一类是逐页预览。每页导出 PNG，看有没有明显遮挡、错位、旧文案。
第二类是 contact sheet。把所有页面拼成一张总览图，快速看整套 PPT 的节奏。它很适合发现某一页突然太密、某几页风格跑偏、封面和结尾撑不住这种问题。
第三类是文件检查。PPTX 包有没有坏，slide 数量对不对，能不能重新导入，媒体文件是不是正常。
第四类是文本和布局检查。旧标题有没有残留，placeholder 有没有漏掉，文本有没有意外换行，背景安全区有没有被占用。
这些检查并不复杂，但很容易被人忽略。
我以前会觉得，这些是不是有点太工程化了。后来发现，如果目标是交付一个文件，而不是看一张截图，这些检查就很值得。
它们能把很多“凭感觉还行”的地方，变成可以复核的结果。
那套读后感 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。
输出后停住，等我确认。
第二轮，再写设计 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 可打开性。
尤其检查底纹和文字这类边界是否合适，不只是具体的参数，更要检查视觉效果是否合适。
这样拆看起来慢一点，但实际更稳。
因为每一轮只解决一类问题。方向错了，就停在方向层改；设计不对，就停在设计层改；文件有问题，就回到导出和验证层改。
最怕的是一开始就把所有事情混在一起，最后你也说不清到底是内容不对、设计不对，还是文件本身有问题。
我会留下的一张小清单
如果把这次经验压成一张小清单，我会保留这些问题：
-
这套 PPT 的一句话主线写清楚了吗？
-
每页是不是只讲一个判断？
-
标题是不是现场真的会说的话？
-
哪些是事实，哪些是个人理解，边界有没有说清？
-
视觉 brief 里有没有写清楚“不要像什么”？
-
背景有没有留出安全区？
-
image-gen 是否只承担背景、材质和无文字资产？
-
事实文字是否保留为可编辑文本？
-
标签、底板、mask 是否能复用，而不是每页手工调？
-
有没有导出逐页预览和 contact sheet？
-
有没有检查旧文案、placeholder、意外换行和遮挡？
-
PPTX 是否能正常打开或重新导入？
-
如果是读后感做 PPT，有没有把“文章摘要”变成“你的判断”？
这张清单不一定每次都要完整跑。
如果只是内部草稿，可以轻一点；如果是要交付、分享、发给别人继续改，那就值得认真一点。
写在最后
我现在对 TRAE Work 做 PPT 的期待，比一开始更现实了。
它不一定一次就给我一份完美作品，也不应该替我决定内容主线、事实边界和审美判断。
但如果我能把这些东西讲清楚，它就很适合接住中间那段繁琐的工作：整理结构、生成页面、调整视觉、导出预览、根据反馈继续改，再把文件检查一遍。
这其实已经很有价值。
过去做 PPT，很多时间花在反复挪文本框、换底板、看一页改一页、改完又不放心。现在这部分可以更多交给工具跑起来。
人的工作没有消失，只是换了位置。
以前人站在每个细节里，一点点手工改。现在更像是站在流程上面，先讲清楚要什么，再看结果哪里不对，最后判断能不能交付。
对我来说，这可能才是用 TRAE Work 做 PPT 最值得沉淀的地方：它不是让人少思考，而是让人把思考放在更前面，也放在更关键的位置。
参考资料
- kz-design 【Skill 创作】受够了 AI 味设计后，我做了 K叔Design
- kz-article-deep-analysis 【Skill 创作】看完很多文章却说不出收获？我做了这个深度解读 Skill
- TRAE Work 官方产品页: solo | TRAE - Collaborate with Intelligence
- TRAE SOLO / Work 官方文档入口: TRAE Work 概述 - TRAE SOLO - TRAE
- TRAE.ai 官方 LinkedIn: Introducing TRAE Work: https://www.linkedin.com/pulse/introducing-trae-work-traeai-hy6lc
- TRAE.ai 官方 LinkedIn: Introducing Design Mode in TRAE Work: https://www.linkedin.com/pulse/introducing-design-mode-trae-work-traeai-8x4dc
- OpenAI: Harness engineering: https://openai.com/zh-Hans-CN/index/harness-engineering/
- OpenAI: Open-sourcing Codex orchestration with Symphony: https://openai.com/index/open-source-codex-orchestration-symphony/