ChatGPT/Codex 应用捆绑了 LibreOffice 的完整副本

原文 ↗ Hacker News 讨论 ↗

OpenAI 的 ChatGPT/Codex 桌面应用被发现捆绑了一个庞大的无界面 LibreOffice 安装包（以及其他重量级运行时），用于在本地读取、写入和渲染 Office 文档，这引发了关于软件臃肿、攻击面和许可合规性的争论。评论者指出，尽管体积成本高，而且与用户可能已经安装的工具重叠，但 LibreOffice 是少数几个足够稳健、可脚本化、能可靠处理混乱的旧式 Office 格式的选择之一——这既凸显了办公文件复杂性的残酷现实，也说明了让 AI“直接搭建自己的技术栈”的局限。讨论还延伸到对新应用 UX 和性能的批评，以及对这样一种前景的猜测：随着 AI 代理越来越多地直接操作文档，像 Microsoft Office 这样的套件可能会逐渐主要充当查看器，而不是人类的创作工具。

发现了什么

  • 桌面版 ChatGPT/Codex 应用会将一个约 400+ MB 的无界面（headless）LibreOffice 运行时安装到缓存目录中，显然用于文档处理（DOCX/XLSX/PPTX、PDF、转换、截图）。
  • 在某些系统上，它是在首次运行/较长的“初始化”之后才出现，而不是在安装程序执行时出现。在 Windows 上，其他原生工具（git、poppler 等）也会被下载到同一个缓存中。

为什么是 LibreOffice，以及还有哪些替代方案

  • 一些评论者说，他们之所以独立地最终捆绑了 LibreOffice，是因为：
    • Office/Google 的 API 和 CLI 很脆弱、碎片化，或者很难可靠地自动化。
    • 旧的/奇怪的 Excel 文件和复杂文档最好由 LibreOffice 处理。
  • 提到的替代方案包括：Microsoft 365/Google Workspace CLI、Apache POI、pandoc、自定义 PowerPoint/Office 导出器，以及一个 .NET OpenXML 后端（“walnut”）。
  • 有人指出，像 POI 这样的库可以计算公式，但并不能取代完整的办公套件 API。

臃肿、性能和资源方面的担忧

  • 许多人认为捆绑完整办公套件是“臃肿之巅”，尤其考虑到：
    • 一些用户已经安装了 LibreOffice。
    • SSD 磨损、占用空间巨大，以及本地运行着多个重量级 AI 应用/VM。
  • 另一些人则认为，与 token 和开发时间相比，存储成本很低；一个已知、经过实战检验的依赖是合理的。

安全、许可和来源

  • 有人担心，捆绑大型第三方二进制文件会扩大攻击面，并可能包含未修补的漏洞。
  • 也有人质疑许可证合规性；在缓存捆绑包中发现了 LibreOffice 的 MPL 许可证文件。
  • 这是否算作“随安装程序捆绑”还是“按需下载”尚不清楚，但大多数人认为，通过包含许可证，大概率已经满足了 MPL 的义务。

应用行为与 UX

  • 对新版 ChatGPT/Codex 应用的体验褒贬不一：
    • 有些人认为性能不错，并喜欢这个面向编码代理的三栏界面。
    • 另一些人则称其凌乱、缓慢、资源占用高，而且令人困惑（ChatGPT 与 Codex、Chat 与 Work 分离、快捷键缺失/变更）。
    • 尤其是 Windows 用户，报告了卡死、高 CPU 占用，以及难以访问移动端聊天的问题。

对 Office 和 AI 的影响

  • 一些人认为这反映出一种趋势：Office 变得主要只是查看器，而 AI 代理通过开放格式和非微软工具生成并修改文档。
  • 也有人认为，这既凸显了 Office 格式的复杂性，也体现了当前 AI 的局限：与其让 AI“重新实现 Word”，不如直接打包 LibreOffice 更容易。