写代码可以 Vibe Coding 了，为什么办公还不能 Vibe Officing？
Vibe Coding 为什么能成功？
Vibe Coding 能成立，是因为代码天然适合人机共同维护：
- 源码可读、可改、可执行、可测试
- AI 和人改了代码之后，对方都能读懂，也会修改
- 这个循环是通的
办公场景为什么不行？
办公文档不是一段纯文本，它有页面、图片、图表、批注、主题、母版，还有很多看起来像"排版细节"的业务信息。人改过之后，AI 需要能读懂；AI 改了之后，人也要能看到效果并自己上手改。
迈向 Vibe Officing 的三道坎
1. 人机协作无法闭环
用户想让 AI 做的是"修改 PPT 第 6 到 10 页的正文内容，但版式、颜色都不要变"，但 AI 做的是"重新生成了一份看起来符合用户需求的 PPT"——这是执行鸿沟。AI 在浏览器上预览没问题，但下载下来后样式出现错乱，对象属性变了——这里出现了评估鸿沟。
2. 缺少可持续修改性
在所有 AI 生成领域，"局部修改"都是用户极为看重的能力。AI 生成图片后，如果无法稳定局部微调，就只能多次"抽卡"。同样，AI 生成文档必须要能回传给 AI 执行继续修改，在实际工作中才有意义。
3. 协作介质不够权威
协作介质指的是人和 AI 多轮协作时共同操作的格式。AI 修改、人工编辑、预览、最终交付都要以它为准。在生产办公文档当时，协作介质必须在预览时与最终交付产物完全相同。
Markdown 和 HTML 都不适合
Markdown 的局限：本质上是线性文本格式，图片只是一个引用，无法表达锚点、占位符、母版、主题和图表对象等元素。
HTML 的局限：表达能力比 Markdown 强，但只能阅读，导出失真问题严重，预览只能说"仅供参考"。
OOXML 为什么更适合
DOCX、PPTX、XLSX 本质上都是一个 ZIP 包，解压后里面是一组 XML parts——这组数据文件包含了正文内容、样式、母版、图片图表、批注、文件关系等。一份原生的 Office 文件是一个小型文档 Project，AI 可以像改代码一样修改它。
OOXML 的特性对应了三道坎：
- 闭环：AI 修改的是原生文件结构，人看到和继续编辑的也是同一个文件，执行对象和评估对象一致
- 可持续修改：是个小型代码项目，AI 可以局部修改，保留其他不涉及到的内容
- 权威协作介质：DOCX/PPTX/XLSX 既是 AI 操作的对象，也是用户本地编辑的对象，还是最终交付的对象
作者的 Vibe Officing 尝试：OfficeDex
作者基于以上思路做了 OfficeDex 工具，把目标文件设为原生 .docx/.pptx/.xlsx。本质上 Vibe Officing 还是在写代码——OOXML 的代码。Vibe Coding 的产物是应用和服务，Vibe Officing 的产物是办公文档。
当用户说"帮我做一份能给客户看的方案"时，Vibe Officing 产品不仅要输出一个文档，更重要的是用户和 AI 可以围绕同一个文件对象继续工作。