Ely Office：用 Rust 把办公套件装回本地桌面——LibreOffice 当内核、AGPL 发牌、十一天发八个版本的离线六件套

Tue, 20 Oct 2026 07:50:00 +0800

先给结论：Ely Office 不是又一个"Web office 的桌面壳"，它是一场反向操作——用 Rust + GPUI 写六个原生应用的外壳，把 LibreOffice、MuPDF、Git 这些惯性强依赖"关进"内核层，然后以「无账号、无云、无遥测」为硬约束组织整个产品。官网那句话写得很克制也很狠：“Works with the network off. Your files stay in your folders.”

一、它是什么：十一天、八个 release、三平台

一句话：一套六应用桌面办公套件——文档、表格、幻灯片、PDF、Git 客户端、Markdown 编辑器，全部离线优先，macOS / Windows / Linux 三平台。

数据快照（2026-10-20 通过仓库页面、release 记录与 docs/ 源文档核实）：

维度	数据
仓库	自托管 Gitea：`git.zacharyzhang.com/ZacharyZhang-NY/ElyOffice`
官网	office.elygpui.com（手工 SVG 交互站，无 og 图、无营销文案堆砌）
定位	离线优先桌面办公套件（offline-first in Rust and GPUI）
Stars / Forks	15 / 0（Gitea 平台，非 GitHub，数据安静属正常）
创建时间	2026-10-08（首个提交）
最新 Release	v0.1.8（2026-10-19），累计 8 个 release
平台	macOS（arm64，已公证）/ Windows（setup.exe）/ Linux（AppImage + deb + rpm + Arch）
语言构成	Rust 81.5%、TypeScript 5.1%、Shell 4.7%、C 3.7%、Python 3%
内核版本	LibreOffice 26.2.6.3（+51 补丁）、MuPDF 1.28.5（+5 补丁）、Git 2.56.0、git-lfs 3.8.0
许可	AGPL-3.0（`LICENSE` 文件实核；README 的 Licence 小节写 MIT，与许可文件不一致，见第七节）
仓库体积	53 MiB（含 vendor 与 patches）

两个观察先放在前面：

这不是追 star 的营销项目。 十一天里 8 个 release、版本说明一条条带 issue 号（#3–#6、#8、#9），兼容性文档精确到"Mac 27.0 arm64 验证机"“1e-12 浮点容差"“Windows 真窗口核对到 Microsoft Print to PDF"这种粒度。这种文档风格更像长期使用者给自己写的交接清单，不是给 star 画的饼。

分发走自家 Gitea，不走 GitHub Marketplace。 仓库、release、官网、git-lfs 全部自持，与产品"无云依赖"的气质一致——代价是曝光依赖口口相传，15 star 说明它目前基本还是作者自己的作品，不是社区项目。

二、六个应用的分工

首版六个应用，外加两个"第二批"占位（ElyMail、ElyAgent，README 里只有一行：“Second release —"，没有功能承诺）：

应用	干什么	格式	引擎
ElyDoc	文字处理	DOCX、ODT（保留原格式另存）；DOC/RTF 按原格式保存	LibreOfficeKit
ElyTable	表格	XLSX、ODS、XLS；CSV/TSV/TXT 经导入对话框转新工作簿	LibreOfficeKit
ElyShow	幻灯片	PPTX、ODP；可导出 PDF 讲义与 PNG	LibreOfficeKit + 系统媒体
ElyPDF	PDF 阅读与编辑	页面增删移转、表单、OCR 文字层、密码、数字签名	MuPDF + Tesseract
ElyTree	Git 客户端	暂存/按块暂存、历史追溯、分支合并变基、引用日志找回	随包 Git 2.56.0
ElyMark	Markdown 编辑	$…$ 行内公式经 RaTeX 排版，mermaid 图；输出 HTML/PDF	markdown-rs + RaTeX + mermaid-rs-renderer

每个应用的取舍都不一样，值得单独说两条：

ElyPDF 是六个里功能完整度最高的。 PDF 编辑做到了"内容删除与清理”、OCR 文字层、密码与权限、数字签名（经增量更新写出并重开核对摘要）。这些是很多商业 PDF 工具都要做减法的功能。0.1.2 起扫描页文字可编辑，0.1.6 起"引用了未嵌入字体"不再被误判为文件损坏。

ElyTree 的设计哲学是"绝不替你冒险”。 docs/help.md 里的 Git 安全条款值得整段念：强制推送写明会覆盖的提交、只推所示的那个，远端在上次取回后变了即被拒；变基先问；“把当前分支移到此"保留工作区改动、从不做硬重置；另一个 Git 正在占锁文件时说明原因并可重试、从不删除锁文件；引用日志可找回删掉的分支。每一条都是把命令行 Git 的"回旋镖"逐个焊死。

三、底层组装：壳与内核的分界

flowchart TB
 subgraph SHELL["GPUI 壳（Rust，原生窗口）"]
 D["ElyDoc"] 
 T["ElyTable"] 
 S["ElyShow"] 
 P["ElyPDF"] 
 G["ElyTree"] 
 M["ElyMark"]
 end
 D --> LK["LibreOfficeKit
26.2.6.3 + 51 补丁"]
 T --> LK
 S --> LK
 S --> MEDIA["系统媒体框架"]
 P --> MU["MuPDF 1.28.5
+ 5 补丁"]
 P --> TE["Tesseract OCR"]
 G --> GT["随包 Git 2.56.0
git-lfs 3.8.0"]
 M --> RS["markdown-rs /
RaTeX / mermaid-rs-renderer"]
 style SHELL fill:#f0f7ff,stroke:#2f6fb5,color:#1c4570
 style LK fill:#fff7e6,stroke:#d48806,color:#7a4d00

三层结构，每层都有明确的态度：

最外层是壳，全 Rust + GPUI。 GPUI 是 Zed 编辑器的 UI 框架，走原生路径而非 Electron。仓库里能看到一次关键的架构自砍：提交记录里有 “Remove CEF: the web content crate, ElyMark’s page, their packaging, licences and tests”——ElyMark 原来的网页视图整个拆掉了，CEF 从依赖里除名。一个新项目在十天迭代里主动剥离已经引入的大依赖，这不是常见操作。

中间层是打补丁的上游巨人。 三条腿各有自己的补丁集：LibreOffice 26.2.6.3 带 patches/libreoffice 0001–0051（51 个补丁），MuPDF 1.28.5 带 0001–0005（5 个），Git 用 2.56.0 加 git-lfs 3.8.0。构建脚本要求先固定版本取回上游源码（fetch-references.sh 提 pinned commits），LibreOffice 编译约一小时。51 个补丁意味着这个项目不是在"调用” LibreOfficeKit，而是在长期维护一个 LibreOffice 分支——这是整个项目维护成本最高的部分，也可能是它做别人做不了的格式兼容的原因。

最内层是格式本身。 ElyMark 是唯一"现代栈"的应用，不需要 LibreOffice：markdown-rs 解析（不认的语法照原文显示）、RaTeX 排公式（行内 $…$ 和 $...$）、mermaid-rs-renderer 渲染图。它的 Windows/Linux 包曾在 0.1.3 出现 408–448 MiB 的体积异常，0.1.4 回落到约 120 MiB——这个细节也能看出打包链是边发边修的。

四、离线优先：抠到什么程度

“离线"是这类产品的营销词，但 docs/help.md 把它甲方化成了一组可检查的条款：

条款	内容
网络行为	六应用启动与空闲时不连网；ElyMark 连网络图片都不加载，HTML 一律不运行
恢复	每 10 秒本机写恢复点（加密文档其恢复点也加密），只留本机不上传；崩溃后以未命名副本打开，原文件不动
更新	只在手动检查时联网，下载后校验，从不静默安装；启动时检查默认关闭
外部冲突	外部程序改了你正编辑的文件时，Ely 不覆盖——询问从磁盘重载、保留你的版本或另存副本
凭据	ElyTree 只在取回/拉取/推送/克隆时联网，凭据直接用你自己的 credential helper 与 ssh-agent，Ely 不在终端问密码

最狠的是 ElyMark 的"文本即原文"存储条款：只写回你所改的字——不像不少 Markdown 应用那样用自家格式存整个文档再"导出”，所以不存在"应用偷偷规范化了你的 Markdown"的问题。自动保存也是克制的：ElyDoc/Table/Show/PDF 默认手动保存，只有自有格式、无宏无签名的文件才能打开自动保存，保存失败或外部冲突就停下等用户。

这套条款的潜台词是：Ely 对"成为你的文件的唯一入口"没有兴趣，它只想当一个可靠的桌面工具。 恢复点在本地、更新手动、冲突不覆盖——每一处都假设用户"另有安全网”，而不是把用户锁在应用里。

五、兼容清单：怎么证明『支持 DOCX』

这是整个项目里我最欣赏的部分。市面上"支持 Microsoft Office 格式"的说法基本不可证伪，Ely Office 的做法是把证明过程本身写成文档：docs/compatibility.md 随每个版本发布一份，0.1.8 这份的结构是这样的：

第一，往返验证而非打开即过。 每份样本的验证流程是：打开、编辑、保存、关闭、再打开、再编辑、再保存——两轮编辑。一轮会话能打开不是兼容，两轮往返仍保真才是。

第二，用不经 LibreOffice 的读取器复核。 检查脚本 tests/scripts/ooxml.py 自己解 OOXML、自己算预期值，DOCX 另交 macOS 的 textutil 读，PDF 用独立阅读器 PDFKit 读回页序与字段值。也就是说：验证者的证据链刻意绕开了被验证的引擎——LibreOffice 自己说"保存成功"不算数。

具体结果（0.1.8 清单原文）：

用例	检查内容	结果
DOCX 合同	两轮会话键入的文字（含中文）、批注、修订记录的插入、修订开关保留；`textutil` 读得出	通过
XLSX 公式	公式文本与缓存结果：整数、日期序号、`#DIV/0!` 错误值、文本严格相等，浮点按 1e-12 容差	通过
PPTX 演示	三张幻灯片、隐藏的那张仍隐藏、备注文字（含中文）	通过
PDF	PDFKit 读回页序、改动的文字与字段值	通过

第三，“支持一个格式"被拆成了逐功能矩阵。 ElyDoc 的已验证列表精确到：文字与段落格式、样式、页面与分节、页眉页脚、表格、图片锚点与环绕、目录、脚注尾注、书签、交叉引用、题注、公式（含 Word 的 EQ 域）、批注与回复、修订、查找替换、拼写、比较、邮件合并——限制放在同一行：交叉引用只指向书签；公式导出 DOCX 后在 Word 中是否可编辑未验证。ElyTable 则直接写明：不支持的函数显示 #NAME?、原公式保留、缓存值不保留；外部链接不刷新。

第四，风险模式是显式的。 含宏文件（docm、dotm、带 Basic 的 ODF）、已签名 PDF、修复过的 PDF——全部"只可另存副本，宏不运行”，顶部提示条写明原因。兼容性清单写的不只是能做什么，还包括为什么不能做什么。 与之配套对字体问题的处理也透明：缺失字体由内核报出、页面上方列出清单、分页可能与有字体时不同，产品不捆绑微软字体（默认无字体方案的诚实成本）。

这套做法对应的读者不是媒体，是想拿它认真替换 Office 的人：他们需要的正是"哪些功能验证过、哪些没验、哪些根本不支持"的分层清单。实际例子上，0.1.6 不再误报已安装的宋体为缺失、0.1.8 起修复 Word EQ 域公式显示、行内图片与公式不再浮动在行上方——每个修复都能对应回这个清单的条目。

六、十一天的版本演进

flowchart LR
 A["0.1.1/2
10-09
仅 macOS
未公证"] --> B["0.1.3
10-11
+ Windows/Linux
修 Linux 显示"]
 B --> C["0.1.4/5
10-13/16
三平台齐备"]
 C --> D["0.1.6
10-16
六合一安装包
Win/Linux 打印"]
 D --> E["0.1.7
10-17
仅 Win：
右键新建 Office 文件"]
 E --> F["0.1.8
10-19
macOS 公证
EQ 公式/深色修复"]
 style A fill:#fff1f0,stroke:#d9534f,color:#8a2b28
 style F fill:#f0f7ff,stroke:#2f6fb5,color:#1c4570

时间线背后是三条递进线：

平台线：0.1.1–0.1.2 只有 macOS arm64 且未公证（需在系统设置里手动"仍要打开"），0.1.3 加 Windows/Linux（Linux 首包出过无显示环境无法运行的问题，同日重建），0.1.8 完成公证。release 记录对"没做完"毫不遮掩：0.1.7 只有 Windows 包更新（macOS/Linux 维持 0.1.6），0.1.3 特意注明哪部分包是从哪个 commit 重建的。

体验线：0.1.2 是纯 stability release（十多条修复：共享设置损坏仍能启动、第二实例不清空第一实例的恢复数据、导出对话框里关标签不再崩溃），0.1.6 给 Windows/Linux 补上打印（Linux 用桌面 portal、Windows 走系统打印对话框真窗口核对），0.1.8 是深色模式的首轮打磨——文档内容保持文件原色，白纸在深色 app 里仍是白纸，这个细节修了几次才发现它的重要性：阅读体验里"纸"和"屏"不该一个颜色。

诚实线：0.1.5/0.1.4 两版没有任何 release note（只有产物），版本说明没有一句营销措辞，全部是问题清单。README 中 packaging/linux 与 packaging/windows 的构建配方标注 “have not been run on those systems”——但平台产物明明已经持续发布（CI 走 .gitea/workflows），这类自述与实际的时间差本身就是值得注意的真实信号：README 没有跟着实际进展临时改口。

七、诚实的边界：它自己写下的未验证项

兼容清单把自己的软肋列成了表，这是判断项目可信度时比"已验证"列表更重要的部分：

边界	原文口径
验证机	仅 macOS 27.0 arm64；Windows 与 Linux 未验证
Office 交叉检查	本机没有 Microsoft Office，与 Office 的交叉检查未做（待做）
ElyDoc	缺失字体会导致分页与有字体时不同；交叉引用只指向书签
ElyTable	1904 日期系统未专门验证；不支持的函数显示 `#NAME?`
ElyShow	批注不做回复（内核无回复结构）；章节不保留；Windows/Linux 的媒体播放未构建
ElyPDF	XFA 表单不支持；证书吊销状态不核验；Windows/Linux 的证书信任未构建
ElyDoc（遗留项）	公式导出 DOCX 后在 Word 中能否继续编辑，未验证
许可	`LICENSE` 文件为 AGPL-3.0；README 的 Licence 小节写 MIT——两者不一致，以 LICENSE 文件为准，README 疑似未随许可更新

还有一条时间维度的：第二次发布（ElyMail、ElyAgent）所有相关内容只写了一行占位，没有发布窗口、没有功能清单。一个把"第二批"明摆着放在文档里的项目，比一个把路线图写成"—we’re excited to announce—…v2 全部计划中"的项目更可信。

八、成熟度评估

维度	评价	依据
产品概念	高	六应用覆盖与定位明确；“离线优先"落到每条交互条款上，不是标语
工程深度	高	51 个 LibreOffice 补丁、5 个 MuPDF 补丁、主动剥离 CEF、打补丁构建链全部脚本化
兼容性方法	高	往返验证 + 独立读取器复核 + 逐功能矩阵 + 风险模式显式化，业内罕见的文档密度
文档质量	很高	help/compatibility/accessibility/licenses 分册，未验证项与能对齐排在一起
平台覆盖	中	三平台有产物；但兼容验证仅 macOS 实测，Windows/Linux 属"有包、没验证"状态
成熟度	早期	版本号 0.1.8、验证机单台、无 Office 交叉检查、打印/媒体/证书信任等仍有平台缺口
社区与生态	无	15 star、0 fork、自托管 Gitea、无 issue 模板外机制，基本是单人 + AI 协作项目
商业与发布	未知	无定价、无路线图（除"第二批"一行）、无公司主体说明

一句话：这是一个"方法比成熟度先到位"的项目。 它的兼容性文档密度、自查边界与工程自砍记录，都超过大多数 1.0 产品的水准；但产品本体还在 0.1.x，Windows/Linux 没经过验证机的洗礼，批量真实文档格式（尤其是中文 Word 的花式排版）没有证据，ElyMail/ElyAgent 尚未到来。把它当 LibreOffice 的 GPUI 新皮用可以，当主力 Office 替换还需要等验证清单的下一页。

九、结语

看回 2026 年的桌面软件生态，办公套件这个赛道基本被两个模型瓜分：Web 优先的 Google/Microsoft 365，以及 Electron/CEF 时代的批量套件。Ely Office 选择了一条逆流的路：原生壳、本地文件、显式内核、显式验证。 “Six desktop apps. They work offline.” 这句话在 2026 年说出来本身就像一种立场。

它让我注意到的是文档姿态本身：兼容性清单随版本发布、未验证项与已验证写进同一张表、第二个产品只写一行占位、许可文件不一致时至少 LICENSE 文件是可查的。对一个由单人开发者主导（协作者栏里挂着 Claude 的 AI 署名）在十一天里搞出来的项目，这种面对用户的方式，比任何 90 秒演示视频都更能说明意图。

值得等的理由也很具体：等 Office 交叉检查出现在下一页兼容清单里、等 Windows 上的验证机器结果、等六合一包之外的 per-app 选择。或者，直接下一版装一下——反正安装包在自家 release 页，不需要账号。

免责声明：本文基于 2026-10-20 的官网（office.elygpui.com）、自托管仓库快照（main 分支，commit 0d991e1c71，Release v0.1.8）与 docs/help.md、docs/compatibility.md、README、release 记录撰写。文中所有行为条款、内核版本与验证结果均可在仓库 docs/ 与 patches/ 目录核对；「通过」指作者在 macOS 27.0 arm64 验证机记录的结果，非本文本机复测（本文未实际安装运行该软件）。Stars、提交数等动态数据随时间变化；许可证以仓库 LICENSE 文件（AGPL-3.0）为准，README 与许可文件的解释冲突见正文第七节。项目处于 0.1.x 快速迭代期，功能、平台与验证范围随时可能变化。

离线办公 on 我的博客