拒绝 AI 的LibreOffice 为什么下载量暴增?

一百万次下载，为了一句 No AI

2026 年秋天，LibreOffice 的每周下载量稳定在一百万次以上。推动这个数字的，是文档基金会一句明确的承诺：在无法保证用户完全控制、绝对排除遥测、不依赖特定供应商之前，拒绝内置任何生成式 AI。对受够了被强制植入 Copilot 的用户来说，数据永不出本地就是最大的卖点。企业用户担心文档内容被上传到云端训练模型，律师事务所和医疗机构尤其敏感，一份泄露的合同或病历可能带来巨额罚款。个人用户厌烦工具栏上那个关不掉的 AI 按钮，它时不时弹出建议，打断工作节奏。微软 Office 的 Copilot 嵌在界面最显眼的位置，Google Docs 的帮我写弹窗不时跳出来。用户没有拒绝的选项，只能接受。LibreOffice 的承诺，给了他们一个明确的拒绝选项。他们用脚投票，涌向这个承诺不内置 AI 的办公套件。

但下载量暴涨的同时，社区正在给 LibreOffice 装上各式各样的 AI 外挂。Nelson MCP 把它变成一台 MCP 服务器，让 Claude Code、OpenCode 这类 Agent 通过 HTTP 连进来，调用 160 多个文档工具：Writer 下约 100 个，Calc 下 65 个。WriterAgent 让 AI 重写段落时保留加粗、斜体这些样式，还能跨文档读取、自己上网搜资料并同步更新。LibreAssist 集成 Claude Code CLI，让 Agent 的修改可以撤销重做。在 Calc 单元格里输入 =PROMPT()，就能直接调大模型生成内容。这些扩展都来自社区开发者，托管在 GitHub 上，更新频繁，讨论热烈。

一个拒绝 AI 的软件，反而成了 AI Agent 生态里最热闹的试验田。用户为了躲开 AI 而来，社区却用 AI 把它填得更满。这个矛盾指向一个更深的机制：官方不把 AI 锁死在界面里，开发者就能自由地把 Agent 做成底层工具。那些内置 AI 的套件，把能力边界画在厂商的菜单上；LibreOffice 的开放边界，让 Agent 获得了菜单之外的完整城市。当一个平台拒绝在核心产品中内置某种能力时，它往往会把这种能力的实现空间完整地交给第三方。而第三方因为不受厂商战略的约束，反而能做出更大胆的尝试。浏览器拒绝内置 Flash，结果催生了更强大的 HTML5 生态；操作系统拒绝捆绑特定浏览器，结果浏览器市场反而更繁荣。LibreOffice 对 AI 的拒绝，正在重复这一规律。

无 AI 的承诺，有 AI 的现实

文档基金会拒绝内置 AI，理由很明确：在无法保证用户完全控制执行、绝对排除遥测、不依赖特定供应商之前，生成式 AI 不能进入 LibreOffice。这个立场击中了隐私敏感用户的痛点，也划出了一条清晰的边界：官方版本里，没有 AI 助手，没有云端模型，没有后台数据收集。

但这条边界只约束了官方。LibreOffice 底层的 UNO API 有二十多年历史，最初是为了让第三方开发宏和扩展。它把文档对象模型完整暴露出来：每一段文字、每一个单元格、每一张图片，都是可独立调用的对象。官方不内置 AI，不等于锁死 AI 进入的通道。相反，因为官方没有预先占用这些接口，社区扩展获得了最大的自由度。如果官方内置了 AI，这些接口很可能被锁定，只供官方助手使用。第三方扩展要么无法接入，要么受到限制。官方的不作为，给社区留下了完整的操作空间。

于是出现了一种看似分裂的格局：用户打开的是一个无 AI 的软件，但他们安装的扩展可能让 AI 比在任何套件里都更深入。一个 WriterAgent 用户，可以让 AI 跨文档读取资料、自己上网搜索、同步更新到当前文档，同时保持本地记忆。这些操作都不经过厂商的云，模型可以在本地运行，也可以接外部 API，选择权在用户手里。这种格局让 LibreOffice 同时承载了两种看似相反的需求：一边是想要彻底远离 AI 的用户，一边是想让 AI 深度接管文档的用户。两者在同一个软件上相安无事，因为边界清晰：官方保证基础环境无 AI，用户自行决定是否引入 AI 以及引入多少。

用户下载 LibreOffice，以为自己是在远离 AI。但他们远离的，是被厂商安排好的 AI：那种嵌在工具栏里、数据上传到云端、功能由订阅决定的 AI。拒绝内置，不等于拒绝 AI。

当文档变成一座 API 城市

LibreOffice 能被 Agent 深度操控，根基在于它二十多年前设计的 UNO API。这套接口把文档对象模型完整暴露出来：每一段文字、每一个单元格、每一张图片，都是可独立调用的对象。开发者可以像操作代码库一样，对文档进行增删改查。这种设计在当时是为了灵活性和自动化，二十年后，它成了 AI Agent 的完美接口。

MCP 协议的出现，给这套老接口开了一扇新门。MCP 由 Anthropic 提出，原本是为了让 Claude 等模型能标准化地调用外部工具。Nelson MCP 这个社区项目，把 LibreOffice 的 UNO API 包装成 MCP 工具集，让任何支持 MCP 的 Agent 都能直接操控文档。Agent 不再需要理解 LibreOffice 的内部细节，只需要调用标准化的工具描述。这就像给一座老城装上了现代化的交通指挥系统，每一辆车都能精准到达目的地。UNO API 允许程序通过本地进程通信或 TCP/IP 管道直接操控文档，LibreOffice 可以作为一个无头服务运行。Nelson MCP 正是利用这一点，把它变成了一个常驻的后台服务，Agent 随时可以通过 HTTP 请求来操作文档。

具体到功能上，Nelson MCP 提供了 160 多个文档工具。Writer 下约 100 个，Calc 下 65 个，覆盖了从读写文字到改格式、插图片、管表格的几乎所有操作。甚至在 Calc 单元格里输入 =PROMPT()，就能直接调大模型生成内容。WriterAgent 解决了一个让很多用户头疼的问题：AI 重写文本时，原有的格式往往被洗掉。它通过直接操作文档对象模型，在替换文字的同时保留样式标记。LibreAssist 的撤销重做功能，让用户第一次可以像对待自己的编辑一样，随时撤回 AI 的修改。Agent 成为一个可监督、可纠正的协作者。

这些能力，是内置 AI 助手很难提供的。内置助手大多只能做厂商预设的动作：生成文本、总结段落、翻译。它们无法自由操控文档对象模型，更不可能让用户自定义工具链。LibreOffice 的开放架构，把文档变成了一座 API 城市，每栋建筑都可以被 Agent 访问和改造。自由度来自边界之外。

谁为开放买单

这种开放模式并非没有代价。官方不内置 AI，所以普通用户打开 LibreOffice 时，看不到任何智能辅助。他们需要自己去发现社区扩展，去 GitHub 下载，去配置 API 密钥，去理解 MCP 服务器怎么搭。对于不熟悉技术的用户，这几乎是一道无法跨越的门槛。相比之下，微软 Office 的 Copilot 虽然受限，但开箱即用，点一下按钮就能生成文本。对于习惯了一键开启的用户，LibreOffice 的 AI 之路需要花几个小时阅读文档、配置环境，最后还不一定能成功。

安全风险同样存在。社区扩展没有经过官方审核，有些可能引入遥测，有些可能依赖外部模型而泄露数据。用户虽然握有数据主权，但握不握得住，取决于自己的技术能力和警惕性。官方不内置 AI，自然也不为 AI 相关的安全问题负责。出了事，用户只能自己承担。

但这种不替用户决定的做法，让选择权重回用户手中。套件厂商把 AI 锁进自家界面，边界画在厂商的云、厂商的模型、厂商的订阅上。用户只要使用，就必须接受全套安排。LibreOffice 的选择是官方不画这条线，把边界留给第三方和用户自己。结果 Agent 获得了最大的自由度，用户也获得了最大的决定权：用什么模型，跑在本地还是云端，让 AI 碰哪些文档，不让它碰哪些。

这种模式并非适用于所有人。它要求软件本身具备成熟的 API 体系，要求有一个活跃的开发者社区愿意维护扩展，也要求用户群体中有足够多的技术爱好者愿意充当早期使用者。对于大多数普通用户，内置 AI 仍然是更实际的选择。但 LibreOffice 的存在，至少证明了一点：当用户被给予选择权时，他们能够创造出比厂商预设更丰富的 AI 应用场景。

深度自动化和数据主权，可以靠一条清晰的边界同时满足。拒绝内置，不等于拒绝 AI；拒绝被安排，才是最核心的需求。你下一个文档助手，是套件里自带的那个，还是从外面接进来的那个？