最近有人翻開 ChatGPT 的底牌，發現這隻吞金獸在處理 Office 檔案時，竟然是靠塞進一整套 LibreOffice 核心來撐場面。這事聽起來滑稽，堂堂頂尖 AI 公司，寫代碼、寫詩、畫圖無所不能，結果一遇到你要它轉個 Excel 或是改個 Word，它就默默在後台啟動了那套上個世代的開源套裝軟體。這不只是應用程式肥大的問題，這是在告訴全世界，OpenAI 根本懶得為了那點文件處理的精準度，去重寫一套現代化的解析引擎。
我們在用 ChatGPT 進行 Data Analysis 或是上傳文件時，常會遇到排版走樣、公式失效，甚至有些複雜的巨集直接消失。現在破案了。LibreOffice 本身就是個妥協的產物，它對微軟格式的逆向工程從來就沒完美過。OpenAI 選擇直接把這塊「沈重的補丁」打包塞進 Sandbox，意味著在他們的權重分配裡，讓用戶能「看見」文件比「正確處理」文件重要得多。這種工程上的偷懶，反映的是一種極其犬儒的技術邏輯：只要大模型生成的文字夠漂亮，底層格式碎成什麼樣，用戶大概也不會太在意。
從技術細節看，這套做法讓 ChatGPT 的運作成本與效率變得異常笨重。每次你在對話框丟進一個文件，Sandbox 就要調用這套龐大的依賴庫。為什麼不考慮 Rust 重寫？為什麼不追求原生的高效能解析？理由很簡單，這太費工了。對於現在的 OpenAI 來說，他們正忙著追逐 AGI 的幻影，哪有心思去優化一個 PDF 渲染器或是 Word 解析器。這就像是在法拉利的引擎蓋下面，用膠帶黏了一個老舊的蒸汽鍋爐來驅動雨刷。雖然能動，但總讓人覺得這美感缺了一大塊。
對比之下，Claude 在這方面的處理顯然「體面」一些。Claude 對於長文本和代碼結構的尊重，讓它在處理複雜文件時更傾向於純粹的文本提取與結構化重建，而不是硬塞一個 Office 複製品進去。雖然 Claude 在某些極端排版的還原度上偶爾會翻車，但至少它不會讓你的瀏覽器或客戶端因為加載了一堆無用的二進制文件而顯得氣喘吁吁。Gemini 則是另一種極端，背靠 Google Docs 的原生生態，它處理文檔的邏輯是直接「雲端對雲端」，這種血統優勢讓它完全不需要像 OpenAI 這樣，在客戶端裡偷渡一個開源軟體包。
這種路徑依賴在特定情境下顯得特別諷刺。當 Qwen3.8-Flash-Next 在追求極速響應與輕量化佈署時，OpenAI 卻在不斷加厚它的脂肪層。相較於 Qwen3.8-Flash-Next，ChatGPT 的做法更像是一種資源上的霸凌。它賭定你的電腦效能過剩，賭定你不在乎那幾百 MB 的內存占用，只要它能吐出你想要的摘要。這種「大力出奇跡」的思維，不只用在參數訓練上，連軟體工程的細節都充滿了這種暴發戶式的粗糙。
Grok 則是另一種風格，那種帶著點工程師傲氣的狂放，讓它在處理數據時更偏好直接操作底層邏輯，雖然穩定性有待商榷，但至少它沒打算把整個辦公室軟體都搬進你的對話框。OpenAI 的這種「打包思維」其實是一種警訊，代表這家公司正在失去對技術優雅的追求。當一個標榜未來的 AI 公司，必須依賴二十年前的開源軟體來解決最基礎的文件格式問題，這說明他們內部的技術架構已經出現了某種程度的板結。
我們是不是已經進入了一個「算力換懶政」的時代？開發者不再思考如何精簡代碼，而是思考如何把現有的垃圾堆封裝得更像樣一點。如果連 OpenAI 這種級別的公司，都覺得為了用戶體驗去優化文件解析引擎是不划算的投資，那我們還能期待誰來打破這種「軟體膨脹」的惡性循環？
當你下次發現 ChatGPT 處理 Word 檔案出錯時，別怪 AI 笨，它只是在那套老舊的 LibreOffice 程式碼裡迷了路。這不免讓人想問，當我們所有的現代效率工具，底層都疊加了無數層這種「不得不為之」的歷史垃圾，我們離真正的 AGI 到底是在縮短距離，還是在原地堆砌更高、更不穩定的廢墟？還是說，在這個追求速度的時代，優雅本身就是一種被首選拋棄的奢侈品？