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

目录

1. 它是什么：十一天、八个 release、三平台
2. 六个应用的分工
3. 底层组装：壳与内核的分界
4. 离线优先：抠到什么程度
5. 兼容清单：怎么证明『支持 DOCX』
6. 十一天的版本演进
7. 诚实的边界：它自己写下的未验证项
8. 成熟度评估
9. 结语

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

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

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

两个观察先放在前面：

这不是追 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 —"，没有功能承诺）：

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

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 的"文本即原文"存储条款：只写回你所改的字——不像不少 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 清单原文）：

第三，“支持一个格式"被拆成了逐功能矩阵。 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 没有跟着实际进展临时改口。

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

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

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

八、成熟度评估

一句话：这是一个"方法比成熟度先到位"的项目。 它的兼容性文档密度、自查边界与工程自砍记录，都超过大多数 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 快速迭代期，功能、平台与验证范围随时可能变化。