作者 | 卢阳
大家已经很熟悉 Vibe Coding 的工作方式了，但 Vibe Officing 鲜有人提及。本文将站在资深研发的视角，从技术层面探讨现在市面上 AI+ 文档的工具与 Vibe Officing 之间的距离，分析为何 HTML 和 Markdown 都无法承载这种工作方式，并给出基于 OOXML 的解决方案。
我是一个出海创业者，用 Vibe Coding 写了好几个产品。在产品的推广和运营阶段，我的时间基本上都花在写材料了，为此统计了一下自己的时间成本：因为 Vibe Coding 是异步的，我真正投入其中的时间只占两成，而处理 Reddit、X、投资人的文档等工作花了八成时间。
体验过很多 Office+AI 产品，我发现没有一款完全符合我的需求，写文档还是很浪费时间。我原以为是我用的方式不对，但经过对这些产品原理的研究，我认为现在很多 Office+AI 工具的路根本就走错了，走的方向并不是 Vibe Officing。
刚开始使用 Manus 和 Genspark 的时候，我觉得应该能省不少时间，只需要输入一句话，浏览器里过一会儿就出现了“成品展示”，有标题有配色有排版，像模像样的。可当我真的把 pptx 下载下来，在本地打开它时，就发现很多细节上的不一致：标题位置跑掉，原本应该可编辑的数据图表变成图片，复杂布局被压平等等。我花了很多时间去一个个对齐、重调，终于改好了，又觉得第 6-10 页的文案有点问题，需要让 AI 批量改下，这时才发现这个 PPT 无法回传给 AI 继续处理。这些产品只能算是素材生成器，还远谈不上 Vibe Officing。
现在的 Vibe Coding 也需要人与 AI 的交互，人的 review 和修改还是必不可少的。Vibe Coding 能成立，是因为它的用户是程序员，程序员会读也会写代码，AI 和人改了代码后，对方都能读懂，也会修改，这个循环是通的。
但同样的场景搬到 AI 办公来就不行了，办公文件不是一段纯文本。它有页面，有图片，有图表，有批注，有主题，有母版，还有很多看起来像“排版细节”的业务信息。人改过之后，AI 需要能读懂，AI 改完后，人也要能看到效果并自己上手改。如果做不到这种程度，第一轮生成再快也救不了后面的返工，所以很多 Office+AI 的产品 demo 看上去很顺，可一旦放进真实工作里就很别扭。
上文提到，Vibe Coding 能成立，是因为代码天然适合人机共同维护，源码可读、可改、可执行、可测试。现在大多数 Office+AI 不能成立，有以下三大原因：
Office + AI 的软件和用户需求之间隔着执行鸿沟和评估鸿沟。用户想让 AI 做的是“修改 PPT 第 6 到 10 页的正文内容，但版式、配色都不要变”，但 AI 做的是 “重新生成了一份看起来符合用户需求的 PPT”，这是执行鸿沟。AI 生成的产物在浏览器上预览没问题，但下载下来后样式出现错乱，对象属性变了，这里出现了评估鸿沟。这两大鸿沟直接决定了人机协作无法闭环。
受限于用户自身对需求的理解以及提示词撰写能力， AI 生成的产物几乎不可能做到首版即可用。因此在所有的 AI 生成领域，“局部修改”都是用户极为看重的能力。例如 AI 生成图片后，如果无法稳定局部微调，就只能多次“抽卡”来祈祷获得想要的结果，在局部微调稳定后，AI 生图就迈向了 AI 生视频的时代。同样，AI 生成文档必须要能回传给 AI 执行继续修改，在实际工作中才有意义。
协作介质指的是人和 AI 多轮协作时共同操作的格式。人会通过协作介质的效果来做出判断，所以协作介质必须权威：AI 修改、人工编辑、预览、最终导出都要以它为准。例如开发前端静态页面时，HTML 就具有权威性。在生产办公文当时，协作介质就必须在预览时与最终交付产物完全相同。
Claude 团队早些时候发了一篇文章： Using Claude Code: The unreasonable effectiveness of HTML 激起了 Vibe Coding 社区的讨论。我很认同这个观点，人类在 Vibe Coding 的过程中与 AI 同样重要，Markdown 是迁就 AI 的方案，对人类并不友好，给人演示设计方案的时候 HTML 比 Markdown 更高效。
在办公文档领域，Markdown 很适合做 README、笔记和简单的技术说明，它很轻，源码可读。但它本质上是线性文本格式，图片在其中通常只是一个 ![]() 引用。
在非开发者环境下的办公文档需要的东西多得多，图片要有锚点，要能裁剪，要能和正文发生位置关系，幻灯片里还有占位符，母版，主题和图表对象等元素，这都是 Markdown 难以表达的东西。HTML 在表达能力比 Markdown 强很多，Claude 团队力推 HTML 就是因为它能让 AI 输出可浏览的页面来供人类决策。
但在办公文档场景，HTML 也不合适。首先它只能阅读，程序员才知道怎么编辑它。其次它存在导出失真的问题，就如前文说的 Manus 和 Genspark 的体验，基于 HTML 的预览都只能说是“仅供参考”。
我更看好原生的 OOXML 。ECMA-376 对 Office Open XML 做了标准化定义，包括文档的 vocabulary、document representation 和 packaging 方式。Microsoft 的 Open XML 文档也明确说明，Open XML 文件由 package、parts 和 relationships 组成；WordprocessingML、PresentationML、SpreadsheetML 分别对应 Word、PowerPoint、Excel 的文档结构。
DOCX、PPTX、XLSX 本质上都是一个 ZIP 包，解压后，里面是一组 XML parts，这组数据文件包含了正文内容、样式、主体、图片图标、批注、文件关系等。 每种 part 一类信息，parts 之间再通过 relationships 连接起来。所以一份原生的 Office 文件是一个小型文档 Project。AI 把它当做代码项目，需要修改时可以按需读取和修改关键文件，对 AI 来讲，就是在写代码。
LLM 对 OOXML 是非常熟悉的，Office Open XML、Open Packaging Convention、Office 自动化、格式转换、python-docx、python-pptx 这类工具链，长期存在于公开文档和代码仓库中。对模型来说，解开 ZIP 包、遍历 XML 树、按命名空间定位节点、根据 relationships 追踪图片和图表引用，都是接近代码理解和代码修改的任务。
OOXML 的特性对应了前面提到的三道坎：
它能让协作闭环成立，AI 修改的是原生文件结构，人看到和继续编辑的也是同一个文件，不需要在 HTML 预览和 Office 文件之间来回转换。执行对象和评估对象一致，执行鸿沟和评估鸿沟都会小很多。
OOXML 支持可持续修改，它是个小型代码项目，AI 可以做到局部修改，保留其他不涉及到的内容。
它可以成为权威协作介质。DOCX、PPTX、XLSX 既是 AI 操作的对象，也是用户本地编辑的对象，还是最终交付的对象。协作介质、编辑介质和交付介质是同一个东西，多轮人机协作不会在格式转换中断掉。
所以 OOXML 是 Vibe Officing 最合适的底座。
我的日常工作中文档调整占比很大，市面上又找不到真正好用的工具，所以我基于上文的思路，自己做了一个工具，叫 OfficeDex。该工具基于我日常工作中的实际需求而开发，我会在使用过程中不断优化它。
OfficeDex 把目标文件设为原生 .docx/.pptx/.xlsx，这对应了前面说的人机协同、原生格式、图文混排和 OOXML。这也是我理解的 Vibe-Officing：并不是模仿 Vibe Coding 的命名，因为他它本质上仍然是在写代码，OOXML 的代码。Vibe Coding 的产物是应用和服务。Vibe Officing 的产物落是办公文档：OOXML 负责结构，图表对象负责数据可视化，样式系统和版式规则负责页面，数据绑定把内容接回业务信息。
用户说“帮我做一份能给客户看的方案”时，Vibe Officing 产品不仅要输出一个文档，更重要的是，用户和 AI 可以围绕同一个文件对象继续工作。OfficeDex 以桌面客户端的形式，在践行这个理念。
作者简介：
出海产品创业者，Founder of OfficeDex & OfficeCLI，如果你也对出海有兴趣，欢迎一起交流。微信：Delay_M
今日好文推荐
Anthropic冲刺IPO：Claude一个月烧掉客户5亿美元，却成了上市前最强广告
Token 卖疯了挣的也是小钱，Snowflake 盯上了 AI 时代最贵的资产
Codex 500万用户福利被怼“作秀”！Claude Code 吃掉近九成 Token，OpenAI 抢用户败在“小气”上？
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。