拒绝重复造轮子我们耗时一年基于Vue3打造AI协同Word编辑器

作者:互联网

2026-03-24

Word

在AI技术重塑办公体验的浪潮中,我们历时一年打造了新一代文档编辑器。本文将揭秘产品设计背后的思考,以及如何突破传统文档工具的局限。

为什么"偏偏"要造个Word轮子

我们之所以下定决心做这件事,主要是因为前两年我们的一个产品,需要集成word能力对外服务,但是我们调研了一圈,得到的结论是:1. 大厂的文档产品集成成本过高,对外商业化受限头部大厂做的文档产品,要么是按次付费(并发次数):

比如上面这张,如果高频使用,我们团队算了一笔账,每年api的调用基本都要花10-20w左右,更别说对外给客户服务了,那成本只有大公司能玩了。另一方面,国内B端客户大部分的Saas场景都需要私有化部署,国企事业金融企业更要求内网部署,所以基本上不可能集成大厂的SDK,这条商业模式已经被堵死了。2. 大厂的文档产品技术债过重,扩展度和开放程度受限这基本上是行业的共识了。普通企业只能用大厂的系统,如果要开发,要么动辄百万,要么就等“等更新”。但是我们的AI文档场景,并不需要很多冗余的功能,而是保留最核心的能力,其他的我们希望开发给企业自定义。同时,现有文档编辑器都是"互联网时代的产物",为"人写给人看"设计。AI无法真正理解文档结构,只能当"高级搜索框"。我们结合这两年AI的发展,洞察的结果是:内容创作正在从"人驱动"转向"人机协作",但工具没有跟上。所以综合上面分析,再结合我们团队大厂架构和文档产品的研发经验,我们毅然决定自研。

365天我们做了什么

说实话,规划了1年,其实并不是单纯的时间维度的概念,我们打算将 JitWord 打造成一个未来我们 all in 的一个产品长链路的方向:基于JitWord的文档引擎,扩展出企业共建版,JitOffice办公软件,JitCloud AI云服务生态。所以可能未来1-2年,我们还是会持续深耕在“知识内容传承”这个赛道。

第一步,架构重构:从"富文本"到"结构化数据"

在做 JitWord 之前,我们对 Office 文档做了大量的调研,从docx格式到文档的复杂操作,都意味着传统的富文本格式(html)难以驾驭复杂的文档场景。

我们也调研了很多开源方案,比如 tiptap,quill,editorjs等。最终我们选择了tiptap的一个早期稳定的版本,作为我们的底层文档组件,并对 tiptap 的架构做了上层的优化,已支持复杂的文档操作。

下面是我们第一版的文档设计架构:

其实单纯实现类似 Office 的UI界面,难度不是很大,只需要花时间来开发,我相信每一个前端工程师都能实现,其难点在于:

  1. 如何高效的做文档解析(需要对docx进行高精度格式还原)
  2. 如何基于文档做高性能协同(支持多人协同编辑)
  3. 如何在web文档处理复杂公式编辑和渲染
  4. 实现文档的复杂操作(划词评论,版本对比,高级排版,分页视图等)
  5. 实现文档的权限控制和高性能渲染(100w+字秒级渲染)

等等,每一个骨头都比较硬,基本上都是我们花大量实现自研,比如:

基于文档做高性能协同(支持多人协同编辑)

目前市面上其实有些协同方案,比如CRDT算法驱动的YJS,当然我们也是基于YJS实现的文档协同算法。但是单纯使用Yjs,只能实现基础协同,在协同过程中我们需要考虑很多复杂场景:

  1. 操作可交换性不同用户的操作可以以任意顺序执行,最终结果一致
  2. 操作可合并性多个操作可以智能合并,减少网络传输
  3. 最终一致性所有客户端最终会收敛到相同的文档状态
  4. 无需中央协调不依赖中央服务器进行冲突解决

下面是我们设计的协同操作流程:

在协同编辑的性能上,我们也做了进一步算法优化,保证我们在普通服务器上(2核4G)也能支持10-50人的高效协同编辑,如果扩大服务器性能和集群,我们将有可能支持数千上万人的协同编辑。

下面是我们的文档协同和存储架构数据流:

实现在web端处理复杂公式编辑和渲染

基本上市面上的开源方案都达不到我们对复杂公式的极致追求,大部分是让用户直接编辑latex,但是到了导出docx后,公式要么无法导出,要么导出后无法二次编辑。

基于上面的痛点,我们对docx文件做了数据结构的分析和算法层的兼容,同时对用户编辑公式的体验也做了进一步升级:

我们提供了数学公式的编辑面板,我们可以实时编辑和预览公式,同时我们内置了100+高频的数学和科研公式,方便大家更快速的编写复杂公式。

下面是渲染到 JitWord 中的公式效果:

同时,我们也能直接导出带复杂公式的文档,并在 word 中二次编辑。

文档的高效渲染(100w字秒级渲染)

上面是我们文档中渲染了100w字的效果,目前测试下来还是可以编辑文档,只有略微的延迟。

这一结果归功于我们对文档性能的极致追求,在文档渲染层我们做了极致的优化,并全方面测试了渲染协同稳定性能:

实现文档的复杂操作(划词评论,版本对比,高级排版,分页视图等)

任何一个富文本编辑器,都很难自带划词评论,版本对比,高级排版,分页视图这些高级操作功能。

我们研究这些功能花费了很多时间,也在每个月以2-3个版本的迭代速度更新着JitWord。

终于在2025年底实现了上面提到的这几个功能,下面我也给大家一一介绍一下。

  1. 划词评论

当然大家可不要以为我们只是做了划词评论功能。我们在划词评论之后,还做了通信机制,在多人协同过程中可以实时通知给其他人,让协作者可以第一时间看到划词的内容,这个流程我们完全打通了。

  1. 版本管理功能

我们的操作会定期存储,可以一键恢复,并支持版本的差异对比。这个功能基本上也是市面上web端文档独一份的,当然我们还在持续优化。

  1. 分页视图功能

这个功能是最难坑的,不容置疑。但是我们花了2个月 all in 这个功能,终于实现了类似 word 的分页功能。它的难点在于分页之后内容的排版和位置自动计算机制,需要消耗大量的 js 性能,所以我们各种性能优化的方式都用上了,结合我们设计的独有的dom组织模式,终于实现了分页能力。

大家可以在 JitWord 共建版体验到分页的功能。

相关标签:

拒绝重复造轮子?我们偏偏花365天,用Vue3写了款AI协同的Word编辑器