zhy200308/ai-ppt-plugin：AI 进入 PowerPoint/WPS 编辑现场之后

做一个 AI PPT 插件，难点不是调用模型写几段文案，而是它必须活在 PowerPoint 或 WPS 的真实编辑现场。当前页、选中对象、整份文档、历史操作、模型配置、失败回滚，全都会影响体验。

zhy200308/ai-ppt-plugin 的代码结构正好指向这个复杂性。它用 React/TypeScript 做插件界面，通过 OfficeJs/WPS adapters 连接不同办公环境，还支持多种模型服务和结构化操作 JSON。它不是单独生成 PPT 文件的工具，而是试图让 AI 进入桌面编辑动作。

它先面对 Office 和 WPS 的双现场

插件要进入 PowerPoint 和 WPS，就不能只写一个通用生成函数。不同宿主的对象模型、权限、文件读取方式和操作能力都不一样。仓库里的 adapters/interface 和相关适配层，说明它把宿主差异放进了设计里。

这一步很现实。AI 插件如果不能稳定读到当前页、选区和文档结构，后面的智能编辑都只是空话。

多模型配置是为了让插件留在现场

项目支持 AnyRouter、one-api、new-api 等模型入口，意味着它没有把能力锁死在单一供应商上。对桌面插件来说，这很重要：团队可能已有内部模型网关，也可能需要切换不同模型能力。

多模型不是炫耀列表，而是部署弹性。插件越贴近办公现场，越要适应不同组织的模型接入方式。

结构化操作比一句自然语言更可靠

AI 如果只输出“帮我优化这一页”，插件很难知道下一步是改标题、重排卡片、换配色还是补图表。这个仓库强调 structured operation JSON，把自然语言意图转成可执行动作。

这样做能减少误操作，也方便记录历史。桌面插件最怕模型一口气改坏很多对象，结构化操作至少让每一步更可追踪。

历史和回滚决定它能不能被放心使用

办公插件不是一次性生成器。模型改完之后，使用者可能发现方向不对、版式错了、文字不合适。仓库里把 history、rollback、documents 等能力纳入界面状态，说明它理解“可撤回”是生产工具的基本要求。

如果没有历史，AI 插件会让人害怕；有了历史和回滚，使用者才敢让它介入真实文件。

它适合研究 AI 如何接管编辑动作

ai-ppt-plugin 的价值不在于展示一个最终 deck，而在于展示 AI 如何读文件、理解上下文、生成操作、执行修改、保留历史。它是桌面办公插件路线，不是后端批量生成路线。

这也带来更高门槛：宿主适配、权限、对象模型、模型网关、错误恢复都要处理。它越贴近真实 PowerPoint/WPS，就越不可能像一个简单网页生成器那样轻。