用 Rust + AI 几天重造 Office？ArtCraft 的技术架构与开发速度

几天时间，能不能做出一个 Word、Excel 或 PowerPoint？如果考虑复杂文档排版、公式引擎、文件兼容和跨平台交互，这听起来几乎是不可能完成的任务。但在 2026 年 10 月初，ArtCraft / storytold 在公开了一套 Adobe 风格的 Rust 创作软件后，又连续推出了 WordCraft、GridCraft、DeckCraft 三款 Office 替代品。

它们不仅有像模像样的 Ribbon、工具栏和编辑区域，还包含独立的文档引擎、文件格式读写、CLI 与 MCP 自动化接口。更惊人的是：根据项目自己的 Roadmap，三款软件 10 月 5 日已经有初步的核心实现，10 月 7—8 日就公开了 v0.1.0。¹

不过，这里有两个不同的问题：它们在几天内究竟做出了什么？又是否意味着 AI 真的只花了几天就「完成了 Office」？ 本文尝试从源码架构、项目时间线与真实可用性三个角度回答。

1从 Adobe 到 Office：ArtCraft 的软件家族

ArtCraft 此前已经推出 PhotoCraft（Photoshop）、VectorCraft（Illustrator）、FilmCraft（Premiere Pro）、EffectCraft（After Effects）、LightCraft（Lightroom）、PdfCraft（Acrobat）以及 DesignCraft（InDesign）等独立实现的创作工具。此前我在《用 Rust 和 egui 重造 Adobe 全家桶？》中，主要讨论了它们的 UI、egui 与原生桌面应用的体验。²

Office 系列更适合从业务引擎切入，而不只是观察 GUI：三款软件虽然看上去同属办公套件，解决的问题却完全不同。

Word 的文档会随着文字流动；Excel 的单元格会随着数据变化重新计算；PowerPoint 的图形则会随着时间展示和运动。 正是这种区别，决定了三个项目不可能只共用一个编辑器内核。

2Office 三件套：分别如何实现？

2.1WordCraft：从字符到页面

一个普通文本框只需处理字符串、光标和选区。Word 却必须理解段落、样式、分节、表格、图片环绕、脚注、修订与分页。修改第一页的文字，可能影响后面很多页的断行；改变一个字体的字宽，就可能改变整篇文档的布局。

WordCraft 把这些职责拆成独立的 Rust crate：doc 管理文档语义和编辑操作，fonts 处理字体与字形，layout 计算断行、分页、表格和浮动对象，docx 读写 WordprocessingML，render 把布局结果绘制成页面。它使用 HarfRust 做字形塑造、vello_cpu 栅格化页面，并通过 krilla 导出 PDF。³

这里最值得注意的是，它不是直接在 egui 的富文本控件里「模拟 Word」，而是先拥有一个可独立排版和导出的文档模型，再把页面交给 UI 展示。这样的引擎既可以供人类编辑，也可以直接由 CLI 批处理、由 AI Agent 生成文档或运行测试。

但真正与 Word 兼容，远比「可以自动分页」困难。不同字体的度量、复杂脚本、脚注跨页、历史兼容规则，都可能使两款软件在同一个 DOCX 上得到不同版面。能打开文件不代表能保真地修改、保存并交还给 Word。

2.2GridCraft：电子表格是一种计算运行时

Excel 的网格很容易画出来，困难的其实是它背后的计算语义。例如 C1 = A1 + B1，只要 A1 或 B1 改变，C1 就要更新；如果其他单元格又引用 C1，整个依赖链都要随之失效和重新计算。再加入跨工作表引用、循环依赖、动态数组、LET / LAMBDA 等机制，Excel 就接近一种嵌入在表格中的编程语言。

GridCraft 为此区分了 formula（词法分析、AST、引用调整）、functions（函数库）、calc（依赖图和求值器）、model（工作簿与单元格）和 xlsx（文件格式）等模块。单元格存储使用共享的 Copy-on-Write 结构，计算器处理溢出数组与循环引用。GUI 则使用虚拟化网格，只处理可见范围，不会真的为一百多万行创建一百多万个 UI 控件。⁴

这体现了 Rust 在 Office 中与图像软件不同的价值：不只是 GPU 渲染，更是大量数据、规则和状态变化的组织。不过，计算引擎的正确性不能用「支持多少函数」直接衡量。数字精度、日期系统、类型转换、边界情况，以及大型 XLSX 的往返保真度，才是难以一次做对的地方。

2.3DeckCraft：具有时间轴的二维场景

PowerPoint 的幻灯片可以看成一个二维图形场景：文字、形状、图片、表格与图表拥有自己的几何、层级和样式；母版、版式和主题构成继承关系；切换动画、对象动画与音视频播放则引入时间轴。

DeckCraft 使用 model 描述演示文稿、母版、Slide 和 Shape，使用 text、anim、media 分别处理文字、动画与媒体，再交由 render 和 pptx 完成绘制和文件交换。它的文本同样使用 HarfRust，页面绘制使用 vello_cpu，PDF 输出通过 krilla。仓库中还包含 H.264、HEVC、VP9、AV1 等 Rust 编解码模块；这些媒体子系统与 FilmCraft 的方向存在明显复用关系。⁵

所以它并不是一个只会显示几张图片的幻灯片播放器，而是具有场景模型、动画状态机和格式交换能力的编辑器。但 PowerPoint 的实际难点仍然在于大量细节：复杂 SmartArt、主题继承、字体替代、对象动画，以及编辑保存后 PPTX 是否还能被原版 PowerPoint 完整还原。

3Rust + egui：共同架构与 PhotoCraft 的差别

三款软件都采用 Rust Cargo Workspace + egui / eframe 构建原生桌面 GUI，以 wgpu 作为桌面图形后端。它们既不是 Electron，也不是简单包一层 WebView。但这不意味着所有文档计算都交给 egui 或 GPU：egui 管界面，业务引擎管文档，图形库负责页面或内容绘制。³⁴⁵

三个项目都倾向 Engine-first：核心模型与命令系统不能反向依赖 UI 框架，并用 cargo xtask layers 之类的检查维护依赖层级。整体可概括为：

这是三款软件共同设计的抽象图，而非任一仓库逐文件对应的模块图。

3.1Engine-first：为什么 Command 如此关键？

统一 Command 的好处是：同一个动作可以同时由按钮、快捷键、CLI 和 AI Agent 触发，而不是为每个入口重新写一遍业务逻辑。DeckCraft 的 README 就提供了直接通过命令创建幻灯片、启动 MCP 的示例：⁶

deckcraft-cli commands format.
deckcraft-cli run --sample --cmd 'slide.new={"layout":"titleOnly","title":"Hello"}' --save hello.deckcraft
deckcraft-cli mcp

对普通用户来说，CLI 只是额外入口；对 AI 编程来说，它改变了开发成本。Agent 可以直接执行命令、检查文档状态、保存、重新读取并验证，而不必每次都打开软件点击 Ribbon。UI 的拖拽、焦点和视觉反馈仍然需要额外测试，但大量业务逻辑已经能够在无窗口环境下迭代。

3.2与 PhotoCraft 相比，各自的难点在哪里？

PhotoCraft 使用 256×256 稀疏 Tile、Copy-on-Write 和专门的 CPU/GPU 合成器处理大幅图像；Office 则分别围绕页面、计算图与幻灯片场景组织算法。四款软件相同的是原生 Rust UI 和分层理念，不是底层的编辑器内核。⁷

还有一个值得澄清的细节：wgpu 给 egui 画窗口，不等于 WordCraft 的分页也靠 GPU，更不意味着 GridCraft 的公式一定在 GPU 上运行。文档内容与窗口合成是不同层级。

4它们到底用了几天？

如果只看宣传标题，「几天重造 Office」很容易让人想象成一个程序员（或者一个模型）连续工作几天就交付了全部产品。实际上需要分清三套指标：

公开日历时间（wall-clock）：从可追溯的工程记录到版本发布经过了多少天。Agent-hours：多个 Agent 累计执行任务的工时。完成度：发布物在实际用户工作中能替代多少原软件的能力。三者没有直接换算关系。

4.1三款 Office 的公开时间线

前三款的起点来自各自的 Roadmap，首版日期采用 GitHub Releases 页面。值得注意的是，DeckCraft 的 Roadmap 把首版写在 10 月 7 日，但 GitHub Release 页面显示为 10 月 8 日；可能涉及时区或日志记录口径，这里统一使用 Releases 的页面日期。¹⁸⁹

所以，「两三天做出首个可发布版本」在公开记录意义上成立。但我们无法从中证明事前没有架构规划、模型生成、素材准备，也无法知道每款产品全部 Agent 的精确累计运行时间。更不能把这些天数当作单个开发者的工作量。

4.2和 Adobe 系列的十多天相比

2026 年 9 月 30 日前后，PhotoCraft、FilmCraft、VectorCraft、LightCraft、PdfCraft 相继启动公开项目活动；10 月 1 日前后，EffectCraft 与 DesignCraft 也出现了初期代码或 Roadmap 记录。到 10 月 12 日，这一批仓库的公开历史大约覆盖 11—12 个日历日。Office 三款从 10 月 5 日的最早明确工程记录算起，则只有约一周。²¹⁰

但请注意，七款 Adobe 软件并不是分别串行开发十二天。它们可以同时推进，甚至复用字体、媒体、图形、构建脚本和测试规范。项目创建日期不是开工审计，首次 Release 也不是项目完成证明。

4.3PhotoCraft 的并行开发数据说明了什么？

PhotoCraft 在 10 月 10 日的一份工程回顾中记录：从 9 月 30 日第一次提交起，约 10.5 天里有 1,152 次 main 提交、1,004 个合并 PR。项目以每个 PR 约 2—4 Agent-hours 粗估，总工作量约 2,000—4,000 Agent-hours，并称期间曾维持 10—20 个 Agent 并行。⁹

这份数据至少证明了另一个事实：ArtCraft 的速度不能简单理解为「一个 AI 写代码特别快」，而更接近大量独立任务并行实施、不断合并与验证。Office 三款缺少同样完整且统一的 Agent-hours 统计，因此不能照搬 PhotoCraft 的数字替它们计算开发工时。

5AI 为什么能把开发周期压缩得这么短？

我认为原因不止是模型能力强，而是整个仓库开始按照适合 Agent 并行开发的方式组织。

5.1分层，使不同 Agent 可以并行工作

在 WordCraft 中，字体、排版、文件读写、编辑命令可以各自推进；GridCraft 的公式解析与 UI 网格、DeckCraft 的动画系统与 PPTX 导入也可以分成不同工作流。明确的 crate 边界与依赖方向，降低了多个 Agent 同时修改同一模块的冲突概率。即使并行编程无法消除集成成本，也为任务划分提供了自然边界。³⁴⁵

5.2Command，使测试不必围绕 UI 打转

当「新建幻灯片」「修改段落」「给单元格设置公式」是一条稳定 Command，AI 就能从 CLI 调用它，再检查返回值或保存后的模型。GUI 可以继续做交互测试，但业务层的大量验证不必依赖模拟鼠标与截图。换句话说，可自动化的产品架构，也是可自动化的开发架构。

5.3CI、真实文件与回归测试，形成反馈闭环

三个项目均使用 xtask 执行格式检查、Clippy、单元测试、层级检查、WASM 构建等任务。GridCraft 的更新日志还描述了随机 Command 序列的 fuzzing：随机操作之后检查撤销重做、XLSX 往返和重新计算结果，借此暴露内部状态不一致。¹¹

另外，这些项目并非从零开发全部基础设施。egui、wgpu、HarfRust、vello_cpu、krilla 等库，以及 Craft 家族中可以共用的媒体组件，都在替开发者承担通用工作。选择生态成熟的技术，通常比「全都自己手写」更有利于快速迭代。

不过并行也有代价。大量 PR 需要持续合并，接口需要协调，CI 会排队；而 Photoshop 的像素保真、Word 的分页一致性、Excel 的语义正确性，很难靠简单堆更多 Agent 就线性缩短时间。

6Alpha 并不等于替代 Office

项目维护者在 10 月 10—11 日前后的 Roadmap 中，给出了比功能清单更保守的「能否替代目标软件完成真实工作」自评：

以上数据来自各项目 Roadmap / Parity 文档，并非统一的第三方测评。不同软件的加权项与使用人群不一致，不能把「60% 大于 55%」直接解释为 WordCraft 的质量高于 DeckCraft。^1211139

目前最明显的限制是真实文件互操作和稳定性。WordCraft 的 DOCX 复杂对象、分页和印刷输出需要进一步验证；GridCraft 的大工作簿、计算边界与 Excel 文件往返仍有缺口；DeckCraft 则缺少大规模真实 PPTX 样本验证，需要改善编辑后丢失对象或样式等问题。

尤其值得注意的是 PhotoCraft 的自我修正：早期项目曾给出相当乐观的功能完成估计，随着真实问题单、文件对照和更严格的标准进入评估，剩余工作量被大幅上调。GridCraft 的 Roadmap 同样明确记录了从早期乐观预估到纳入本地化、遗留格式、稳定性和真实用户反馈后的重新测量。⁹¹¹

创建一套「看起来功能很全」的软件，与打造能被长期信任的生产工具，是两个不同阶段。 前者的代码数量和功能表很容易快速增长；后者却需要大量边界用例、专业用户反馈和与既有生态的长期磨合。

7结语：改变的是软件开发的起点

ArtCraft 最值得关注的，并不是「Rust 已经击败 Microsoft Office」，也不是「一个人只用三天写完 Word、Excel 和 PowerPoint」。它真正展示的是：借助 AI 与开源生态，复杂桌面软件的第一轮可运行实现可以在非常短的公开周期内出现；而通过清晰的业务引擎、统一 Command 与自动化验证，大量模块可以并行推进。

对开发者而言，这可能比它们到底用了 egui 还是 Web UI 更有启发。无论是写编辑器、图形工具还是游戏引擎，都应该思考：核心逻辑能否不启动 GUI 就运行？每个编辑行为能否表示成稳定的命令？修改完成后，能否自动验证而不是反复手动点击？

AI 让「先做出来」变得越来越容易，也让另一个事实更加清晰：决定软件能否真正被人使用和信任的，从来不只有把代码写出来的速度。