夜雨聆风周末，我又凭感觉写了一个小想法：用 Swift 写一个 PowerPoint 查看器。因为我已经有一个技能可以生成幻灯片、XLSX 和 DOCX，所以我最开始 只是想把 DOCX、XLSX、PPTX 打开，能预览、搜索、缩放，未来可以更方便添加更多的功能。
当在看到 Claude for Microsoft 365、ChatGPT for PowerPoint 之后，我的想法变了。
我们不再只是打开一个 PPT，然后自己一页页调标题、文本框、版式和动画。更自然的动作开始变成：我告诉 Agent 这组材料要讲给谁听、压成几页、 像咨询汇报还是像产品演示、要不要加强结论、哪些技术细节要删掉；Agent 在后台修改文档，查看器实时把结果呈现出来。
所以，只需要给我的 PPT Viewer 添加 ACP + 聊天窗口能力，就可以快速变成为一个 AI PPT 工具了。
这就是我想说的 Office 的 Cursor 时刻，Office 开始经历 Cursor 曾经带给 IDE 的那次界面重排：复杂编辑器不再天然是人的主入口， Agent 开始成为主要操作者。
编程 Agent 的参考，从逐行编辑到结果反馈闭环
最先把这件事讲清楚的，不是 Office，而是 AI 编程工具。
过去，我们打开 IDE，是为了写代码。文件树、编辑器、补全、跳转、调试器、终端、Git 面板，共同组成了一个围绕“人亲手修改代码”的工作流。即使有 Copilot 这样的补全工具，核心界面仍然是代码编辑器，人仍然是逐行改动制品的人。这样的工作实现是太复杂了，记得我还在 Thoughtworks 的时候， 我们有的培训只是为了教会大家用 IDEA 的重构快捷键，它可以更快地让你完成任务。
但 Codex、Claude Code、Qoder 这一代工具，把关系改掉了。这些工具的差异很大，但共同结构很清楚：人不一定先打开文件、定位函数、手动改几行，而是描述目标，让 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 走到了哪一步，也让修改过程不再是黑盒。
一旦工具能理解文档结构、执行 Agent 返回的修改动作，并把每次修改重新渲染出来，它就变成了 Office Agent 的工作台。
验证：没有测试的 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，用来检查文本框、位置、尺寸和命名对象； • 然后看缩略总览图，判断整套材料的节奏、层级和重复版式有没有失控； • 最后回到全尺寸渲染图，检查溢出、贴边、低对比度、连接线浮空、图表线段断裂这些肉眼才能确认的问题。
这套验证逻辑更像代码里的测试，只是测试对象换了。很多问题不是文件格式错误，而是“看起来不可信”：一个数字颜色太浅，一个标签离图形太远， 一个色块只是装饰却抢走了信息层级。
否则 Agent 只是生成了一份看似完整的文件，人仍然要从头到尾用肉眼兜底。
逻辑验证层：从格式正确到内容可信
代码 Agent 的模式之所以成立，一半是因为 Agent 能改代码，另一半是因为测试能跑。差异对比和测试报告 可以代替“盯着代码写”成为新中心，本质上是因为结果有相对明确的判定方式：测试过没过，构建成不成功，代码检查有没有报错。
PPT Agent 的逻辑验证只能是：
• 数字一致性：检查同一份 PPT 里前后出现的数字是否矛盾（比如第 2 页说"增长 30%"，第 5 页说"增长 50%"） • 引用一致性：检查某个说法是否能在原始材料里找到对应来源 • 事实幻觉检测：用 fact-checker 子 Agent，对每张幻灯片的具体声明去网上溯源，判断是否有依据 • 术语统一性：检查同一概念是否在不同页面用了不同名称 • 结构完整性：检查是否有空页、标题缺失、图表无标注等格式问题
否则所谓 Agent 工作台，就会退化成“Agent 黑盒加人肉验收”，效率反而不如人自己改。
小结：复杂编辑器让位的三个条件
把代码、文档、Web 界面、配置文件这些案例放在一起，可以抽出一条更通用的判别原则：复杂编辑器要让位的领域，制品通常都满足三条： 可定位、可比较、可验证。
• 可定位，意味着制品能被拆成有名字的对象，Agent 可以精确指向“改这一处”。 • 可比较，意味着改前改后能做差异对比，人能在结果层面看到变化。 • 可验证，意味着至少有一部分变化能被机器判，剩下的能被人快速判。
代码最先跑通，是因为它天然满足这三条。文档、表格、幻灯片、Web 界面、配置文件，也接近这个条件。反过来，视频、3D、复杂 CAD 更难，不是因为 AI 不能生成，而是因为它们的制品往往不够可定位、可比较、可验证。
未来的 Office，不一定从空白页开始，也不一定从工具栏开始。它可能从一个 AI 生成的候选状态开始，从一次修改请求开始，从一轮渲染、对比和验证开始。
复杂编辑器不会消失，但它会退到新的位置：不再是人逐点操作的主战场，而是 Agent 工作台里的现场、证据和验收界面。
