周末，我又凭感觉写了一个小想法：用 Swift 写一个 PowerPoint 查看器。因为我已经有一个技能可以生成幻灯片、XLSX 和 DOCX，所以我最开始 只是想把 DOCX、XLSX、PPTX 打开，能预览、搜索、缩放，未来可以更方便添加更多的功能

而当看到 Claude for Microsoft 365、ChatGPT for PowerPoint 之后，我的想法变了，当这类能力进入文档工作流之后，这个查看器的意义就变了。 我们不再只是打开一个 PPT，然后自己一页页调标题、文本框、版式和动画。更自然的动作开始变成：我告诉 Agent 这组材料要讲给谁听、压成几页、 像咨询汇报还是像产品演示、要不要加强结论、哪些技术细节要删掉；Agent 在后台修改文档，查看器实时把结果呈现出来。

这就是我想说的 Office 的 Cursor 时刻，Office 开始经历 Cursor 曾经带给 IDE 的那次界面重排：复杂编辑器不再天然是人的主入口， Agent 开始成为主要操作者。

引子：编程 Agent 的参考，从逐行编辑到结果反馈闭环

最先把这件事讲清楚的，不是 Office，而是 AI 编程工具。

过去，我们打开 IDE，是为了写代码。文件树、编辑器、补全、跳转、调试器、终端、Git 面板，共同组成了一个围绕“人亲手修改代码”的工作流。即使有 Copilot 这样的补全工具，核心界面仍然是代码编辑器，人仍然是逐行改动制品的人。这样的工作实现是太复杂了，记得我还在 Thoughtworks 的时候， 我们有的培训只是为了教会大家用 IDEA 的重构快捷键，它可以更快地让你完成任务。

但 Codex、Claude Code、Qoder 这一代工具，把关系改掉了。Codex 更像一个能读仓库、改文件、跑命令、提交候选结果的软件工程 Agent；Claude Code 把 Agent 带进终端、IDE 和桌面工作流；Qoder Canvas 则更明确地把 AI 工具推向一种协作界面，而不只是更好的输出。

这些工具的差异很大，但共同结构很清楚：人不一定先打开文件、定位函数、手动改几行，而是描述目标，让 Agent 修改一组文件，再通过 差异对比、测试结果、运行日志和评审流程判断是否接受。

IDE 没有消失，但它的位置变了。它从主要生产界面，变成了 Agent 执行、用户审查和结果验证的工作台。

生成：从聊天回复到制品生产，PPT 技能打通了第一段链路

把这个逻辑带回 Office，就会发现 PPT、Word、Excel 正站在同一个拐点上。

现在的 AI Agent 多数是以技能方式写 PPT，常见的做法是先用 Python/JS 把每一页写成可编辑的幻灯片：标题、图表、文本框、图片、 连接线都尽量是结构化对象，而不是一张贴死的图。然后通过工具导出 PPTX，再把它渲染成 PNG 和版式 JSON，做一张缩略总览图 先看整套材料的节奏。

和代码一样，这一步之后，人仍然要继续改。因为 PPTX 能打开，只说明文件没坏；每一页渲染出来没有文字溢出、没有对象漂移、没有低对比度、没有图表断裂， 才算版式没有炸。再往后，还要判断标题有没有压住主线，页面之间的节奏是不是突然断掉，信息密度是不是适合这个汇报场景。如果环境里有 LibreOffice， 它也只能作为额外的兼容性检查器，看看文件在另一个 Office 生态里会不会暴露字体、图形或导出问题，而不是最终生产链路本身。

所以，当 Office 内置了一个 Agent 能真正修改 PPT 时，用户最需要的就不是一个满是工具栏的编辑器，而是一个能实时看到结果的查看器。 Agent 在背后改标题、改结构、改图表、改版式；人看当前页面、对比变化、要求局部重试、接受或撤回。

生成只是把"从无到有"这一段链路打通，真正决定体验的，是接下来的编辑和验证。

编辑：从文件预览到现场理解

生成 PPT 只是第一步，真正难的是后续编辑。编辑不是重新生成一份文档，而是在已有现场里工作：当前页面、文字层级、图片位置、图表数据、演讲备注， 以及用户选中的对象，都会影响 Agent 接下来怎么改。

1. 读取现场，而不是看截图。 Agent 拿到的不是截图，也不是几段复制出来的文字，而是当前文档的结构化上下文。PowerPoint 的任务窗格可以读取演示文稿、页面、对象、文本、图片、备注和选中状态；必要时，还能取出完整 PPTX 继续拆解。Agent 面对的不是“屏幕上有什么”，而是“这份 PPT 由哪些对象组成”。

2. 理解文档，而不是只理解指令。 用户说“把这一页重设计一下”，Agent 不能只看这句话，还要理解这一页原本想表达什么， 哪些内容要保留，哪些结构可以重排，哪些视觉元素可以替换。编辑的基础不是单句提示词，而是演示文稿上下文。

3. 调用工具，而不是只返回回答。模型返回的也不是一句“我改好了”，而是一组面向 PowerPoint 的操作：读取页面、读取对象、 修改文字、调整版式、插入图片、重绘页面。对应到工具层，就是 list_slides、list_objects、read_slide_text、edit_slide_text、 edit_slide_ooxml、replace_rendered_slide、generate_image 这一类能力。真正的修改发生在 Office 执行器里，不发生在聊天回复里。

4. 闭环验证，而不是黑盒生成。编辑 PPT 更像一轮小型编程 Agent 循环：读取、规划、执行、验证。用户看到的“正在读取页面”、 “正在生成图片”、“正在应用修改”、“正在验证结果”，不应该只是加载文案，而应该来自 Agent 和执行器之间真实的事件流。它让用户知道 AI 走到了哪一步，也让修改过程不再是黑盒。

这件事对我编写 PowerPoint 查看器的启发很直接：如果查看器只能打开、缩放、搜索文档，它仍然只是阅读工具；但一旦它能理解文档结构、执行 Agent 返回的修改动作，并把每次修改重新渲染出来，它就变成了 Office Agent 的工作台。

聊天只是指令入口。真正让用户相信 AI 的，是查看器里持续更新的现场。

验证：没有测试的 PPT，才是文档 Agent 的真问题

Office 要复刻代码 Agent 的成功，还需要一个不可获取的内容：测试和验证。

视觉验证层：先相信渲染结果

早期，各类 Office Agent 验证界面的方式，是先落到 HTML 上：

1. 结构天然可检查。每张幻灯片都可以被视为一个独立的 HTML 文件，DOM、CSS、版式树天然就是检查对象，不需要额外适配层。
2. 渲染截图 + 溢出检测。content-review 工具会在 1280×720 视口中渲染截图，并自动检测 element_overflow、 image_accessibility 等问题。
3. 3px 阈值：严重问题。一旦溢出超过 3px，就应视为严重问题，必须立即触发 full-file-rewrite 这类整稿重写修复，而不是继续生成后面的内容。
4. 闭环直到零问题。每批生成后立即进入机器验证，按照“生成 → 检查 → 修复 → 复查”的循环反复修正，直到零问题后才进入下一张 幻灯片，从而形成可重复的质量保障闭环。

但我在用 ChatGPT / Codex 生成 PPT 的时候，走的是另外一条路。它不是先证明某个 HTML 页面没有炸，而是把结果当成一个真实制品来验：

• 先生成可编辑的 PPTX，确认文件、页数、媒体资源都正常；
• 再把每一页渲染成 PNG，同时导出版式 JSON，用来检查文本框、位置、尺寸和命名对象；
• 然后看缩略总览图，判断整套材料的节奏、层级和重复版式有没有失控；
• 最后回到全尺寸渲染图，检查溢出、贴边、低对比度、连接线浮空、图表线段断裂这些肉眼才能确认的问题。

这套验证逻辑更像代码里的测试，只是测试对象换了。很多问题不是文件格式错误，而是“看起来不可信”：一个数字颜色太浅，一个标签离图形太远， 一个色块只是装饰却抢走了信息层级。

所以这里的区别是，HTML 验证更适合检查界面有没有坏，PPT 验证更像在检查一个结果能不能被人接受。文档 Agent 的前台不是只有按钮和输入框，它还包括一页页被修改过的制品状态。这个状态必须能被读、能被比较、能被质疑。

否则 Agent 只是生成了一份看似完整的文件，人仍然要从头到尾用肉眼兜底。

逻辑验证层：从格式正确到内容可信

代码 Agent 的模式之所以成立，一半是因为 Agent 能改代码，另一半是因为测试能跑。差异对比和测试报告 可以代替“盯着代码写”成为新中心，本质上是因为结果有相对明确的判定方式：测试过没过，构建成不成功，代码检查有没有报错。

PPT Agent 的逻辑验证只能是：

• 数字一致性：检查同一份 PPT 里前后出现的数字是否矛盾（比如第 2 页说"增长 30%"，第 5 页说"增长 50%"）
• 引用一致性：检查某个说法是否能在原始材料里找到对应来源
• 事实幻觉检测：用 fact-checker 子 Agent，对每张幻灯片的具体声明去网上溯源，判断是否有依据
• 术语统一性：检查同一概念是否在不同页面用了不同名称
• 结构完整性：检查是否有空页、标题缺失、图表无标注等格式问题

否则所谓 Agent 工作台，就会退化成“Agent 黑盒加人肉验收”，效率反而不如人自己改。

小结：复杂编辑器让位的三个条件

把代码、文档、Web 界面、配置文件这些案例放在一起，可以抽出一条更通用的判别原则：复杂编辑器要让位的领域，制品通常都满足三条： 可定位、可比较、可验证。

• 可定位，意味着制品能被拆成有名字的对象，Agent 可以精确指向“改这一处”。
• 可比较，意味着改前改后能做差异对比，人能在结果层面看到变化。
• 可验证，意味着至少有一部分变化能被机器判，剩下的能被人快速判。

代码最先跑通，是因为它天然满足这三条。文档、表格、幻灯片、Web 界面、配置文件，也接近这个条件。反过来，视频、3D、复杂 CAD 更难，不是因为 AI 不能生成，而是因为它们的制品往往不够可定位、可比较、可验证。

未来的 Office，不一定从空白页开始，也不一定从工具栏开始。它可能从一个 AI 生成的候选状态开始，从一次修改请求开始，从一轮渲染、对比和验证开始。

复杂编辑器不会消失，但它会退到新的位置：不再是人逐点操作的主战场，而是 Agent 工作台里的现场、证据和验收界面。