ArtCraft 连 Word 和 Excel 都重做了,接下来谁来维护?

前面还在讨论用 Rust 重做 Adobe 那一套，转眼间，WordCraft、GridCraft、DeckCraft 又来了，分别瞄准文字处理、电子表格和演示文稿。官网目前已经列出十二款应用。

“干脆把 Word 和 Excel 也重写一遍”这种愿望，如今还真有了可以下载的产品。

我也试用了其中的 PrintCraft 和 WordCraft。PrintCraft 在中文处理上遇到了不少 bug，WordCraft 则让我觉得，很多地方还很简陋。

再看它不断增加的产品列表，另一个问题也越来越明显：一下子铺开这么多条线，后面的维护跟得上吗？

于是我去翻了官网、GitHub，以及 Reddit 和 Hacker News 上的讨论。发现有类似疑问的人确实不少，讨论也远不止一句“AI 写的东西不行”。

先交代一下：这篇文章结合了我对 PrintCraft、WordCraft 的试用感受，以及公开资料和其他人的反馈。我没有把整套软件逐个实测，也没有对自己的试用做系统测试。资料查阅截至 2026 年 10 月 12 日，早期项目变化很快，个人体验和具体问题报告都需要放在当时的版本与环境里看。

从 Adobe 替代品，一路做到 Office

ArtCraft 这波关注，很容易理解。

免费、开源、熟悉的操作界面，再加上 Rust 和 AI 编程，几个关键词放在一起，就很有吸引力。对于希望摆脱现有软件限制、又不想重新学习一整套操作习惯的人来说，这样的项目很值得看。WordCraft 官网、GridCraft 官网

而且，至少从官方展示看，它们已经有相当具体的功能：WordCraft 面向文档编辑，GridCraft 展示了公式、图表和数据透视表，也宣称支持 XLSX 文件读写。这已经超出了几张概念图的范围。不过，这些是产品方的功能介绍，覆盖范围和可靠性还需要验证。GridCraft 功能介绍

问题是，“用 Rust 重做了 Word 和 Excel”，很容易被听成“现在已经可以替代 Word 和 Excel”。

两句话之间，还有很长的距离。

官网总览中，WordCraft 和 GridCraft 都还标着“开发中”；WordCraft 的官方路线图也把项目定位为 alpha。它的仓库 README 写着“由 ArtCraft 团队开发”。所以，既不应该把这些早期成果直接当成成熟替代品，也不宜仅凭“一位开发者重做整套软件”的传播叙事，就认定所有维护工作都由一个人承担。官方产品列表、WordCraft 路线图、WordCraft 仓库

评论里的 AI slop，是什么意思？

翻这些讨论时，还会碰到一个带着明显贬义的词：AI slop。

Slop 本来有泔水、稀烂食物等意思。放到 AI 的语境里，可以理解为“AI 垃圾内容”：用 AI 批量生成、质量却很低的文字、图片或视频。Merriam-Webster 的词条也强调了“低质量”和“通常大量生成”这两个特点。Merriam-Webster 词条

在 ArtCraft 的讨论里，有人把这个词延伸到软件，用来表达对快速生成、完成度和可靠性不足的产品的嫌弃。我的理解是，这类批评担心的是：界面和功能列表看着已经像那么回事，真正用起来却还有很多地方需要补齐。Hacker News 讨论

不过，AI slop 是个评价标签，不是经过测试得出的技术结论。用过 AI、有 bug，或者还处在早期阶段，都不足以单独判定一款软件就是 AI slop。

我更想继续问的是：具体哪里不能用？问题有没有人处理？更新之后，用户能不能把工作做完？这些比一个标签更能说明产品的状况。

真正让我在意的，是那些基础操作

一款早期软件有 bug，很正常。

我自己的体验，也让我更在意那些日常会碰到的细节。中文支持对于我使用 PrintCraft 来说，就是基本需求；WordCraft 那些简陋的地方，也会影响对整款产品完成度的判断。

这是我的试用感受，还不能代表所有人的体验。但它让我更想看看，其他用户实际用起来怎么样。

其中有些反馈尤其让我在意，因为它们关系到一次工作能不能完整做完。

TechRadar 在 10 月 10 日发布的试用文章里，作者用 Intel MacBook Pro 测试了 PhotoCraft 和 FilmCraft。他认可熟悉的界面，也确实完成了一些基本编辑；但同时报告了选区操作不稳定、保存项目时只得到 JPG，以及视频素材音频播放成噪声等问题。TechRadar 试用文章

办公软件的仓库里，也能看到更具体的兼容性报告。

WordCraft 的一个 issue 报告：用 0.5.0 版命令行工具读取再保存 DOCX 后，文档里的嵌入字体丢失。报告者举出的表单，在另一款软件中重新打开时，字体发生替换，页数从八页变成六页。WordCraft #770

GridCraft 的另一个 issue 报告：0.5.0 版命令行工具导出 PDF 时，部分非拉丁字符变成问号；原来的工作簿里，文字却能正常存储和显示。GridCraft #446

这些都是他人的报告，我没有独立复现，也不能据此断言新版仍然如此。但它们说明了值得测试的地方。

打开文件、编辑、保存，再换一个环境打开，整个过程能不能保住原来的内容？

对于文字处理软件，分页和字体就是日常需求。对于电子表格，导出给别人看，也是日常需求。用户未必在乎一共实现了多少功能，却很在乎今天交出去的文件会不会变样。

我担心的是，每个产品都开始欠维护工作

在 Reddit 的那条讨论里，楼主的疑问就很直接：Adobe 替代品才刚出现，又加了 Word 和 Excel 的替代品，这样的工作量能处理得过来吗？

有人认为，基础功能已经足够自己使用；也有人回应，生成大量代码之后，能不能持续维护和改进，仍然要靠时间证明。Reddit 原帖与评论

我更关心的也是后面这件事。

有过 vibe coding 经验的人，应该很容易理解这种感受：开头把一个产品的雏形做出来，往往很快。界面搭起来，主要流程跑通，很快就能看到成果。

但继续做下去，大量时间其实都花在细节的打磨上。同一个操作在不同状态下是否一致，换一份文件还能不能正常处理，修了这里会不会影响那里，都得反复调整和验证。

我对 ArtCraft 的疑问就在这里：后续这些细节需要花的时间，它能不能持续投入？ 尤其同时铺开这么多产品，这份投入也要跟着覆盖每一条产品线。

一个文件打不开，先得拿到能复现问题的文件。一个按钮没反应，得弄清楚是操作状态、界面事件，还是底层功能的问题。修好之后，还得检查：其他文件有没有被影响？其他平台会不会出现新问题？旧项目还能不能正常打开？

这些工作，AI 可以参与，自动化也可以参与。但总要有人确定正确结果是什么，并决定这个版本是否可以交给用户。

文字排版、表格计算、视频剪辑、图像处理，各自需要不同的知识和测试素材。它们可以共享一部分基础设施，却不能只靠同一套演示就证明可靠。

产品越多，这些需要核对、修复和持续验证的事情，也会一起增加。

每新增一款软件，都意味着以后多一批用户、多一批真实文件，以及多一批需要解释和解决的问题。

开发速度越快，我就越想知道，它消化这些问题的速度有多快。

放到 GitHub，大家就会来修吗？

看到这一整套开源仓库，我也冒出过一个念头：是不是先把产品做出来，放到 GitHub 吸引大家，再让大家一起测试、一起改？

公开资料确实能看出，ArtCraft 在邀请用户参与。官网引导大家报告 bug、提出功能需求、加入 Discord；仓库也有 issue 和代码贡献。WordCraft 反馈入口、WordCraft Pull Requests

但这还不足以证明，它“全靠社区维护”。

而且，已经能看到具体的反馈闭环。WordCraft 有个字体菜单卡死的 issue，经过讨论和版本更新后，一位同样遇到问题的用户反馈：在 Zorin OS 上使用 0.4.0，字体选择恢复正常。这个案例至少说明，有问题被处理，也有人回来确认了结果。WordCraft #59

另一类记录还处在修复过程中。GridCraft 的一个公式兼容性 issue 下，能看到贡献者表示正在处理，也有贡献者和项目方账号提交相关代码的记录。只是，有响应、有提交，还不能直接等同于修复已经进入发行版、用户的问题已经解决。GridCraft #374

真正让我好奇的是，这些参与能不能持续。

用户能帮忙发现问题，贡献者能帮忙写补丁。接下来仍然需要维护者判断：这个改动对不对？是否影响其他功能？谁来验收？什么时候发布？

如果参与的人多了，这些判断也会变多。把更多代码收进仓库，还要让它们能够一起工作。

ArtCraft 也并非没有考虑这些事情。PhotoCraft 的贡献指南要求改动附带测试，文件格式相关改动要做读写往返和异常输入测试，相关模块还需要用真实文件语料验证，界面改动则要求视觉检查。PhotoCraft 贡献指南

有这样的规范，是个好信号。接下来要看的是它们是否持续落实，以及能否随着产品和贡献增加继续运转。

所以，开源在这里很有价值：它让别人有机会检查、修改和接手。但要形成稳定的协作，还需要清楚的优先级、可重复的测试，以及持续处理贡献的人。

我没有查到足以判断 ArtCraft 长期维护人力、资金投入和分工的完整资料。现在就说它肯定维护不了，或者肯定能靠社区撑起来，都太早。

“大多数人只用基础功能”，还要往下问一步

支持者的一个观点也值得认真对待：很多人确实不需要原版软件的所有能力。

一个新工具只解决一小部分需求，也完全可能有价值。它不必等到功能全面对齐，才能被人使用。

但我会继续问：它选择支持的那部分功能，能不能稳定地完成？

只做简单文档，可以不支持某些复杂排版，但保存后还要能继续编辑。只做日常表格，可以暂时没有宏，但支持的公式要算对，交出去的文件要能正常阅读。

Hacker News 上的讨论也触到了这个问题：有人看好先做一个足够小的核心，再逐步扩展；也有人强调真实使用、交互体验和兼容细节仍需要大量验证。这些是讨论者的判断，不能当成整个行业的共识。Hacker News 讨论

对我来说，如果一款软件明确说“目前就支持这些场景”，而且这些场景确实可靠，我会更愿意试。

功能边界小一点，用户反而容易知道自己能把什么工作交给它。

我想看它接下来收拾好哪一件事

ArtCraft 已经让我对这类项目产生了兴趣。能把这么多想法做成可以下载、可以试用的东西，这个进展值得关注。

不过，接下来我更想看的，是几个具体变化：

• 有多少真实用户报告的问题，经过复现、修复和验收，进入了正式发布的版本。
• 已经修过的问题，是否有对应的测试，后续更新还能不能保持正确。
• 是否有持续参与的贡献者，能在某个产品或模块上承担责任。
• 产品是否越来越清楚地告诉用户：哪些场景可用，哪些文件和功能暂时不支持。

这些变化，比再多一个以 Craft 结尾的产品名，更能回答维护能力的问题。

我希望它能走下去，也愿意给早期项目时间。但我的期待很具体：先让一个常用流程稳定下来，让用户敢把真实工作放进去。

比如一份带着字体和复杂分页的文档，打开、修改、保存，再交给别人，仍然是原来的样子。

等这样的事情一件件做成，再回头看今天这波上新，才更能知道它最终走了多远。