作者 | 盧陽

開源地址：https://github.com/officecli/officedex

大家已經很熟悉 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 Officing 的三道坎

上文提到，Vibe Coding 能成立，是因為代碼天然適合人機共同維護，源碼可讀、可改、可執行、可測試。現在大多數 Office+AI 不能成立，有以下三大原因：

人機協作無法閉環

Office + AI 的軟件和用戶需求之間隔著執行鴻溝和評估鴻溝。用戶想讓 AI 做的是“修改 PPT 第 6 到 10 頁的正文內容，但版式、配色都不要變”，但 AI 做的是 “重新生成了一份看起來符合用戶需求的 PPT”，這是執行鴻溝。AI 生成的產物在瀏覽器上預覽沒問題，但下載下來后樣式出現錯亂，對象屬性變了，這里出現了評估鴻溝。這兩大鴻溝直接決定了人機協作無法閉環。

缺少可持續修改性

受限于用戶自身對需求的理解以及提示詞撰寫能力， AI 生成的產物幾乎不可能做到首版即可用。因此在所有的 AI 生成領域，“局部修改”都是用戶極為看重的能力。例如 AI 生成圖片后，如果無法穩定局部微調，就只能多次“抽卡”來祈禱獲得想要的結果，在局部微調穩定后，AI 生圖就邁向了 AI 生視頻的時代。同樣，AI 生成文檔必須要能回傳給 AI 執行繼續修改，在實際工作中才有意義。

協作介質不夠權威

協作介質指的是人和 AI 多輪協作時共同操作的格式。人會通過協作介質的效果來做出判斷，所以協作介質必須權威：AI 修改、人工編輯、預覽、最終導出都要以它為準。例如開發前端靜態頁面時，HTML 就具有權威性。在生產辦公文當時，協作介質就必須在預覽時與最終交付產物完全相同。

Markdown 和 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 為什么更合適

我更看好原生的 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 最合適的底座。

我的 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