GitHub：https://github.com/officecli/officedex

官网：https://officecli.io

1 写在前面：为什么 AI 写得出方案，却做不出"能交付的 PPT"

过去一年，AI 已经能熟练写周报、写方案、写大纲。但凡是真做过几次"用 AI 出 PPT"的人，都踩过几个固定的坑：

HTML 转 PPT 一定跑版：很多 AI 工具走的是"生成一段 HTML / Markdown → 在浏览器里渲染成幻灯片"的路线。导出成真正的 .pptx 之后，字号、行距、表格列宽、图标位置全部错位，拖到客户邮件里前还得人工修一遍。

多轮对话越改越走样：第一次生成还算能看，让它"把第三页的图换成柱状图"或者"把封面换成深色风格"，模型重新吐一遍 HTML/JSON 之后，前面已经调好的样式就丢了——文档的"保真度"撑不过两三轮编辑。

生成结果留在网页里：内容停在聊天记录里，要再下载、再改名、再归档，办公链路被切成好几段。

OfficeDex 的判断很直接：要让 AI 真正接管办公文件，就不能再走"先 HTML 再导出"那条路，必须直接生成原生 OOXML（.docx / .pptx / .xlsx），并且让"修改 → 再修改"过程中文档结构始终稳定。

如果说 Cursor、Codex 把"AI 直接改源代码"做成了开发者的默认工作流，那么 OfficeDex 想做的是 OOXML 文档世界里的同一件事：AI 直接改文件本身，而不是改一段会被反复重新渲染的中间产物。

---

2 为什么是桌面客户端，不是 SaaS

这是发布之前被问得最多的问题。我们选择把它做成桌面应用 + 本地 OfficeCLI runtime，而不是又一个网页服务，有三个非常具体的原因：

维度	SaaS 网页版	OfficeDex 桌面端
数据安全	文档先上传到服务端处理	文档全程留在本机工作区，LLM 调用直连你配置的厂商，OfficeDex 不代理任何模型流量
配置门槛	受限于平台支持的模型	自带配置界面，OpenAI / Anthropic / Azure / DeepSeek / Moonshot / vLLM / Ollama / LM Studio 全都能填一个 baseUrl 就接入
权限与合规	企业要走采购、过安全评审、签 DPA	单机本地运行，IT 不需要为它单独开放数据出境通道
PPT 保真度	浏览器渲染 → 导出，跑版常态	子进程直接写 OOXML，导出即终稿

对于经常处理财务数据、商业计划、内部资料的用户，"我的 PPT 草稿不会先经过谁家的服务器"这件事，比少装一个客户端重要得多。

---

3 OfficeDex 是什么

一句话：告诉它你要什么，它在本机生成 Word / PPT / Excel / 图片给你。

OfficeDex 是开源命令行工具 OfficeCLI 的官方桌面客户端。前端用 React 19 + Ant Design 6 + Notion 风格设计系统；外壳用 Wails v2（Go 后端 + 系统 WebView），打出来的 macOS / Windows 安装包不到 30MB；真正生成 OOXML 文件的工作交给捆绑的 OfficeCLI 子进程，两者之间通过 JSON-RPC over stdio 通信。

典型输入：

做一份 Q3 销售分析报告，重点分析华东区，包含同比、环比、风险提示，目标读者是 CFO。

OfficeDex 返回的不是一段 Markdown，而是一个可以双击打开、可以拖给同事的 .docx 文件。

类似地：

生成一份 8 页产品发布 PPT，面向开源社区，风格简洁，突出桌面端、本地运行和多模型接入。

生成一张适合开源项目 README 首屏的产品宣传图，画面包含文档、幻灯片、表格元素，整体风格简洁。

---

4 架构原理

分层很清晰：

桌面外壳：Wails v2，原生窗口、系统通知、本地文件 API、设置和任务状态都在这一层；

前端：React 19 + Ant Design 6 + 自研 Notion 设计 token（主色 #5645d4、DM Serif Display 标题 + Plus Jakarta Sans 正文）；

生成引擎：解耦的 OfficeCLI 子进程，输入是自然语言，输出是 OOXML 文件，自身可独立作为命令行工具演进；

预览层：docx-preview 渲染 DOCX、pdfjs-dist 渲染 PDF、xlsx 解析 XLSX，整个预览过程不需要本地安装 Office。

这种"GUI + 独立 CLI runtime"的拆分，意味着开发者可以继续用 OfficeCLI 跑 CI / 脚本自动化，而非技术同事用 OfficeDex 也能拿到完全相同的生成结果。

---

5 办公文件生成：从"输出一段回答"到"产出一个文件"

5.1 三类高频办公产物

Word 文档：报告、方案、白皮书、会议纪要、产品说明；

PPT 演示文稿：项目启动、业务汇报、产品发布、路演、培训课件；

Excel 表格：竞品分析、任务拆解、数据整理、结构化清单、财务模型。

这三类的共同点是：用户要的不是一段文字，而是可打开、可继续编辑、可发给同事的文件。

OfficeDex 支持从内置场景（季度报告 / 启动 PPT / 竞品分析）入手，也可以完全自由输入：

帮我写一份内部产品启动文档，产品名是 Lumen，包含背景、目标、里程碑、风险、负责人矩阵，读者是产品、研发和管理层。

对比 Notion、Coda、飞书文档三款产品，从功能、定价、目标用户、生态四个维度输出 Excel。

5.2 流式任务流，不是黑盒等待

生成一份完整文档不是瞬时动作。OfficeDex 在界面上流式呈现 AI 当前在做什么：理解需求、判断文件类型、组织结构、生成正文、写入文件、保存到工作区。AI 不确定的时候会主动反问，用户随时可以取消、重启或在中途追加要求——比如"刚刚那页加一段风险评估"。

5.3 本地工作区，文件即结果

OfficeDex 默认把所有产物落盘到本地工作区：

macOS：~/Library/Application Support/OfficeDex/workspace

Windows：%APPDATA%/OfficeDex/workspace

也可以在设置里改到任意目录。生成完成后直接"在文件夹中显示"，文件就进入用户自己的项目目录、团队资料库或版本管理流程，不需要再从聊天记录里捞。

---

6 图片生成 与 参考图输入

6.1 生图能力

开源项目发布前，README 首屏图、新闻稿封面图、PPT 封面图、功能示意图——这些过去要去单独的生图站点拼凑。OfficeDex 把生图能力放在同一个工作台里，生成结果同样直接进入本地工作区，可以马上嵌入到刚刚生成的 PPT 或文档里。

6.2 参考图（视觉理解 + 风格参考）

OfficeDex 支持粘贴或上传参考图，有两类用法：

视觉理解：传一张产品架构图，让它"根据这张图，写一份给非技术管理层看的产品说明文档"，AI 会把图里的结构翻译成文字材料；

生图参考：传一张已有的宣传图或界面截图，让 AI 生成风格更统一的新图，比从空白 prompt 起步更可控。

---

7 模型与运行时配置

OfficeDex 不绑定任何单一模型供应商。Settings → LLM Provider 里支持：

OpenAI 官方协议及兼容服务（DeepSeek / Moonshot / 自部署 vLLM）；

Anthropic Claude；

Azure OpenAI；

本地模型：Ollama / LM Studio（把 baseUrl 指向 http://localhost:11434/v1 即可，完全离线）。

面向三类用户：

个人：直接用自己的 API Key；

团队：连内部模型网关或统一代理；

本地化部署：把模型跑在本机或内网。

OfficeCLI runtime 也可换：首次启动会从 GitHub Releases 拉对应平台的官方二进制；开发者可以通过 OFFICECLI_DESKTOP_BINARY 环境变量、或在 Settings → OfficeCLI Runtime 里指定本地路径，离线环境也能跑。

---

7 未来展望：VibeOfficing 的完整形态

什么是 VibeOfficing

VibeCoding 的核心体验是：程序员不再逐行敲代码，而是用自然语言描述意图，AI 理解编程语言、框架和设计模式，直接产出可运行的程序。

VibeOfficing 是同一件事在办公领域的映射：用户不再手动调字号、拖对齐线、一页页排版，而是用自然语言和 AI 对话——描述需求、调整细节、迭代修改——AI 理解文档的范式、模板和排版习惯，直接产出对人类展示友好的、可交付的 Office 文件。

类比一下：

编程世界	办公世界	AI 需要理解的
编程语言（Python / Go / TS）	文档格式（OOXML：.docx / .pptx / .xlsx）	底层语法
框架（React / Django / Spring）	文档模板（季报模板、路演 PPT、竞品分析表）	结构范式
设计模式（MVC / Observer / Factory）	排版习惯（标题层级、配色方案、图表风格、页面节奏）	风格惯例

VibeCoding 之所以好用，是因为 AI 不只会写语法，还懂框架和设计模式。VibeOfficing 要好用，AI 也必须不只会填文字，还要懂模板结构和排版习惯。 这正是 OfficeDex 正在深入研究的方向。

 

和传统方式的对比

维度	手动操作 Office	AI 生成 Markdown	VibeOfficing（OfficeDex）
交互方式	鼠标点击、拖拽、菜单	复制 AI 回答 → 手动排版	自然语言对话，说"把第三页换成深色风格"就行
输出质量	取决于个人排版能力	纯文本，无样式，阅读体验差	原生 OOXML，格式完整，打开即可交付
迭代修改	每次改动都是手工活	重新生成整段文本，前后不连贯	对话式迭代，AI 理解上下文，改哪里说哪里
批量处理	10 份报告 = 10 次重复操作	10 次复制粘贴 + 10 次手动排版	"用同样的模板，帮我把这 10 个区的数据各出一份报告"
风格一致性	靠个人经验和模板文件	无法保证	AI 记住你的范式和偏好，自动延续

Markdown 作为 AI 输出的默认格式有一个根本缺陷：它是写给程序员看的，不是写给领导、客户和同事看的。 一份没有分页、没有配图、没有品牌色的 Markdown，离"可以发出去的文件"还差一个排版师的工作量。VibeOfficing 跳过这一步——AI 的输出本身就是排好版的 Office 文件。

正在推进的方向

1. OOXML 记忆：AI 不只记住你说了什么，还记住你的文档长什么样

目前所有 AI 工具的记忆都基于 Markdown 或纯文本——模型记得住你聊过什么内容，但记不住你的文档风格：标题用什么字体、配色方案是深色还是浅色、表格偏好什么列宽、封面习惯什么布局。

这就像一个程序员换了项目，AI 忘了他用的是 React 还是 Vue、Tab 缩进还是 Space 缩进。每次都要从头教。

我们正在深入研究 OOXML 级别的记忆能力：让 AI 理解并记住你的文档范式——模板结构、样式体系、排版偏好。当你反复生成季报、周报、汇报 PPT 时，AI 自动延续已有的风格规范，而不是每次从零开始猜。这是 VibeOfficing 从"能用"到"好用"的关键一步。

2. 批处理：一句话出十份文件

VibeCoding 能一次重构整个项目，VibeOfficing 也应该能一次批量生成。"用 Q3 的模板，帮我把华东、华南、华北、西南四个区的数据各出一份分析报告"——这在手动操作里是四倍工作量，在 VibeOfficing 里应该是一句话的事。

3. 格式互转：PDF ↔ Word / PPT / Excel

收到一份 PDF 合同要改条款，拿到一份 PDF 报告要拆成 PPT 汇报——这些场景目前还需要第三方转换工具。OfficeDex 计划在引擎层直接支持 PDF 与 OOXML 三件套之间的双向转换，让"收到什么格式，就能改什么格式"成为默认能力。

4. 指定页导出为 PNG

"把 PPT 第 3 页导出成图片发到群里"、"把报告封面页存成 PNG 放进 README"——在对话里直接说"把第 5 页转成图片"即可。

5. 引擎层结构化操作：做 AI 单独做不到的事

大模型擅长理解语义、组织内容，但 OOXML 有大量纯技术性的细节——嵌套关系、命名空间、样式继承、母版引用、图表数据绑定——这些不是靠"更聪明的模型"就能解决的。OfficeDex 的引擎层会持续补齐这些结构化操作能力：精确的跨页元素定位、样式层级合并、图表数据源替换、母版批量应用等。让 AI 负责"想"，引擎负责"做对"，两者配合才能产出真正可交付的文件。

---

8 总结

OfficeDex 让 AI 办公从 "复制一段回答" 变成 "原生生成一份文件"。

它把需求描述 → 模型调用 → OOXML 文件生成 → 本地保存 → 内置预览 → 继续编辑这条原本被切碎的链路重新串了起来。

对开发者：是把 OfficeCLI 的命令行能力产品化的方式；

对办公用户：是一个不用再在三个工具之间来回复制粘贴的 AI 工作台；

对企业：是一个不会偷偷把你 PPT 草稿传到云端、IT 不用单独走采购的本地方案。

代码靠 Cursor、Codex，办公就交给 OfficeDex。

---

9 资料

GitHub：https://github.com/officecli/officedex

官网：https://officecli.io

使用文档：https://github.com/officecli/officedex#readme

OfficeCLI 引擎仓库：https://github.com/officecli/officecli

Discord 社区：https://discord.gg/ezAHMkdG

技术栈：Go、Wails v2、React 19、Ant Design 6、TypeScript

支持重点：Word、PPT、Excel、图片生成、参考图输入、本地工作区、多模型配置