用WorkBuddy做了ppt之后，发现比Codex好太多
昨晚我让 WorkBuddy 从零做了一份《数据中台介绍》PPT，16 页，四个章节。从建目录到最后一页校验通过，实际生成的时间加起来十几分钟。
同一件事，上个月我用 Codex 做过一次。上午 10 点 53 分开工，做到下午快 6 点。最后文件夹里躺着 12 个 pptx，文件名从《数据中台介绍》一路改到《数据中台介绍-高端发布会版-双架构图-功能模块截图版》。
那天我说得最多的一句话是：「PPT好丑。」
一、先把两边的账摆出来
差了大概 30 倍的时间，还有一句「好丑」。
二、Codex 卡在哪
Codex 是个好东西，写代码、改仓库它很在行。但做 PPT 这件事，问题不在模型，在工具链。
1. 它看不见自己做了什么
对 Codex 来说，PPT 就是一堆 XML，或者一份 python-pptx 脚本。它能写出脚本、跑出文件，但它不知道这份文件长什么样。
好不好看、字有没有溢出去，全靠我在旁边当人肉校验器。
所以我那天的工作流是：它生成 → 我打开看 → 我说「好丑」→ 它改脚本 → 再生成 → 我再看。
2. 每一版都是从零重跑
下午 2 点 59 分我跟它说：「你不觉得第4页很奇怪么？第4页里面的内容是数据平台开发的进度啊。」
那页确实放错了。给客户讲产品，塞一页内部项目进度，逻辑上说不通。
但它要改第 4 页，就得重跑一遍脚本，然后第 7 页、第 11 页可能跟着变。改到最后，我自己都分不清哪个文件是哪一版。
3. 内容结构它只能猜
上午 11 点 40 分，我问它：「最后一页的内容是怎么回事？怎么看起来那么奇怪？」
它给一份产品介绍材料的最后，加了一段「下一步建议」。
这是咨询报告的结构。产品介绍不该这么收尾。它不是不懂，是没人告诉过它这两种材料的结构不一样。
4. 越改越像在打补丁
12:07 我说「还是有些丑啊」 12:08 我补一句「高端软件产品发布会风格」 12:38 我说「加上一个架构图，显得高大上一点」 14:08 我把本地技能目录的路径贴给它： <本地技能目录> 用这个目录下ppt skill再弄一版
有用，但也就那样。
那七个多小时，我干的是美工的活。
三、WorkBuddy 是怎么做的
它没有一上来就画页。它先做了一件我认为最关键的事：定契约。
1. 先写两份文档，再动第一页
第一份叫 STORY.md，管的是「讲什么」：16 页怎么分章，哪页是封面、哪页是章节扉页、哪页是内容页、哪页收尾。
第二份叫 DESIGN.md，管的是「长什么样」。这份文档写得很硬：
1 2 3 4 5 6 7 8 9 10 11 12 ## 1. 母版三区（内容页强制一致）
| A · 标题块 | 0–104px | 主标题 36px bold #0A2A43 |
| B · 内容区 | 104–656px | 禁止挤占 A / C 区 |
| C · 页脚条 | 656–720px | 左侧栏名 + 右侧页码 NN/16 |
## 2. 色彩系统（色彩池 5 色）
深海军蓝 #0A2A43 / 科技蓝 #1668E3 / 青绿 #00C9A7 / 浅灰蓝 #F2F6FB
## 7. 自检与返工触发
- 任一页元素溢出色区（A / B / C 越界）→ 返工
- 连续 ≥2 页等宽卡片横排 → 返工
- 全篇出现第 3 种字体家族或第 6 个 hex → 返工
这几条不是装饰。有了它，后面 16 页每一页都是对着同一份规范画的。
我当时的输入和它的输出是这样的：
1 2 3 4 5 6 7 8 9 > 用户：不管之前的，自己重新做一个数据中台介绍的ppt
先产出 STORY.md 的章节骨架，一页没画：
01 封面 / 02 目录
03—05 建设背景与价值
06—09 平台架构与核心能力
10—12 数据治理与应用
13—15 实施与交付
16 结束页
Codex 那会儿我是在跟它「聊天」，WorkBuddy 这次是它在「按图施工」。
2. 它能自己看一眼
每页生成完，先过一道校验：元素有没有出界、有没有溢出、卡片高度对不对。校验通过才渲染成图片，再看一眼，不合格就返工。
我不用再当那个校验器了。
3. 生成的是工程，不是文件
这次产出的目录长这样：
1 2 3 4 5 6 7 8 9 数据中台介绍/
├── STORY.md 叙事结构
├── DESIGN.md 设计规范
├── slides/
│ ├── 01.slide
│ ├── 02.slide
│ └── ... 16.slide
├── assets/ 3 张主视觉配图
└── 数据中台介绍.pptx
想改第 8 页，就打开 08.slide 改第 8 页，不用重跑整份。
Codex 那 12 个文件做不到这件事。它们互相之间没有任何关系，每一个都是上一版被整体重写的结果。
4. 配图能直接生
封面、平台定位页、数据治理页那三张主视觉是直接生成的，同一组风格词、同一套配色。不用我去图库翻，也不用担心三张图看着像三家公司的。
这是它交付的第 7 页，总体架构：
四、差距在哪
中间有没有一层「设计规范」
Codex 的路径是「我说话 → 它出文件」，审美标准在我脑子里，它拿不到。
WorkBuddy 的路径是「我说话 → 它写成规范 → 它照着规范出文件」。规范能被检查、被复用、被追问。
它能不能自己看一眼
生成 PPT 不难，难的是生成完知道它好不好。
有校验闭环的，是自动化。没有的，是把我变成流水线上的一环。
至于第三条，其实是前两条的结果：它交给我的是工程，不是文件。工程可以持续改，文件只能推倒重来。12 个版本和 1 个工程，说的就是这件事。
五、也说点 WorkBuddy 的坑
别神化，它也有坑。这次我踩了 6 个：
图片路径按「当前工作目录」解析，不是按项目目录。写错了不报错，图片静默丢失，你还以为生成了。 图标组件在这个环境里不生效，得手写 SVG 画。 生成的 pptx 内部 zip 条目名用了反斜杠，LibreOffice 和腾讯文档后端都打不开，得手动规范化一遍。 校验命令的项目路径要传 Windows 格式，传 Linux 风格的路径会拼成 E:\e\...然后报文件不存在。校验器会拦住负偏移的装饰元素，装饰元素必须完整落在画布内。 往已有页写内容要带页码参数，否则会追加成新页。
这些坑第一次用大概要花点时间趟过去，趟过之后是可复用的。
Codex 那边的坑是另一回事。它的坑是你永远不知道这一版会不会比上一版更丑。
六、回到那句话
让 AI 做 PPT，别只看模型聪不聪明。
真正决定结果的是它有没有一套为这件事准备的工具链：有没有设计规范、有没有校验闭环、交付的是不是可继续编辑的工程。
同样一句话，一个交给你 12 个需要你自己挑的文件，一个交给你一套能继续改的工程。
以上，既然看到这里了，
如果觉得不错，随手点个赞、在看、转发三连吧，
如果想第一时间收到推送，也可以给我个星标⭐～
谢谢你看我的文章