为什么我们偏偏要花上一年时间，自己动手打造一款AI协同的Word编辑器？这得从一次艰难的集成经历说起。当时，我们的一个产品急需集成文档编辑能力对外提供服务。在广泛调研了一圈市场方案后，我们遇到了两个核心障碍。
首先，是大厂文档产品的集成成本。它们大多采用按并发次数计费的API模式，就像下面这张图展示的：
如果我们的使用频率较高，每年仅在API调用上的花费就可能高达10到20万元。这还不包括面向客户提供服务的潜在成本，对于初创团队而言，这几乎是一条被堵死的商业化道路。
其次，是国内B端客户，尤其是国企、事业单位和金融企业，普遍要求私有化甚至内网部署。这使得依赖大厂SDK的SaaS模式根本行不通。
除了成本，技术层面的限制同样突出。大厂的产品往往背负着沉重的“技术债”，功能冗余但扩展性不足。我们需要的AI文档场景，更聚焦于核心的编辑与协作能力，其他功能希望开放给企业自定义。
更重要的是，我们发现现有的编辑器大多是“互联网时代的产物”，它们为“人写给人看”而设计。当AI作为新的创作主体介入时，这些工具显得力不从心，AI往往只能充当一个“高级搜索框”。我们认为，内容创作正在从“人驱动”转向“人机协作”，但工具的发展显然滞后了。基于以上分析，再结合团队自身的大厂架构和文档产品研发经验，我们最终下定决心，走上自研之路。
365天，我们做了什么？
规划一年的周期，并非单纯的时间度量。我们将 JitWord 定位为一个长远的产品方向，计划围绕其文档引擎，逐步扩展出企业共建版、JitOffice办公套件乃至JitCloud AI云服务生态。未来一到两年，我们仍将持续深耕“知识内容传承”这个赛道。
第一步：架构重构——从“富文本”到“结构化数据”
启动 JitWord 项目前，我们对Office文档格式和复杂操作进行了深入调研。传统的富文本格式（如HTML）难以驾驭复杂的文档场景。我们也评估了诸多开源方案，如tiptap、quill、editorjs等，最终选择基于tiptap一个早期稳定版本进行深度改造和上层优化，以支持复杂的文档操作。
以下是我们的第一版架构设计：
单纯实现类似Office的UI界面难度不算太高，真正的挑战在于以下硬骨头：
- 如何高效解析文档（需要对docx进行高精度的格式还原）？
- 如何实现高性能的多人协同编辑？
- 如何在Web端处理并渲染复杂的数学公式？
- 如何实现划词评论、版本对比、高级排版、分页视图等复杂操作？
- 如何实现精细的权限控制和百万字数级别的秒级渲染？
这些问题基本都靠我们自研攻克。这里举两个例子：
1. 实现高性能协同编辑
市面上已有如CRDT算法驱动的Yjs等协同方案，我们也是基于Yjs实现的。但仅使用Yjs只能处理基础协同，我们还需要考虑许多复杂场景：
- 操作可交换性：不同用户的操作能以任意顺序执行，最终结果一致。
- 操作可合并性：多个操作能智能合并，减少网络传输。
- 最终一致性：所有客户端最终会收敛到相同的文档状态。
- 无需中央协调：不依赖中央服务器进行冲突解决。
这是我们设计的协同操作流程：
在性能上，我们做了进一步的算法优化，确保在普通服务器（2核4G）上也能支持10-50人的高效协同。若提升服务器性能或采用集群方案，理论上可支持数千上万人同时编辑。下图展示了我们设计的文档协同与存储数据流：
2. 实现Web端复杂公式编辑与渲染
市面上的开源方案大多难以满足我们对公式编辑体验的极致追求。很多方案让用户直接编辑LaTeX代码，但导出到docx后，公式要么丢失，要么无法二次编辑。
针对这一痛点，我们深入分析了docx的数据结构，在算法层做了兼容，并大幅提升了用户编辑公式的体验：
我们提供了可视化的公式编辑面板，支持实时编辑与预览，并内置了100多个高频的数学和科研公式模板。下图是公式在 JitWord 中渲染的效果：
更重要的是，这些包含复杂公式的文档可以直接导出为标准docx文件，并在Microsoft Word中正常打开和二次编辑。
3. 实现百万字文档的秒级渲染
我们对文档渲染性能做了极致优化。下图展示了在文档中加载超过100万字内容的效果，测试表明仍可流畅编辑，仅有轻微延迟：
这一成果得益于全方位的性能测试与优化。我们建立了一套完整的监控指标体系：
4. 实现划词评论、版本对比与分页视图
这些高级功能是传统富文本编辑器的短板。我们投入了大量时间研究，并以每月2-3个版本的速度迭代 JitWord，终于在2025年底实现了这些功能。
- 划词评论：不仅仅是静态功能，我们还打通了多人协同场景下的实时通知机制，让协作者能第一时间看到评论内容。
- 版本管理：支持定期自动保存版本、一键恢复以及直观的版本差异对比。
- 分页视图：这是技术挑战最大的功能之一，难点在于分页后内容的自动排版与位置计算。我们花了两个月时间，结合独创的DOM组织模式和多种性能优化手段，最终实现了类似Word的分页体验。用户可以在
JitWord 共建版中体验此功能。未来，我们还将支持页眉页脚功能，全面对标Office。
第二步：AI协作引擎——让文档“活”起来
我们认为，下一代文档工具应该是 AI Native 的。为此，我们设计了AI驱动的协作架构，力求在文档编辑的全生命周期融入AI能力：
效果演示如下，AI可以直接根据指令创作内容：
此外，用户还可以对现有文本或段落进行二次AI优化，如润色、纠错、续写等：
近期，我们还上线了“AI公文助手”，能够一键生成符合规范的合同或公文：
第三步：技术选型之问——为什么死磕Vue3？
很多人会问：文档编辑器为什么强调 Vue3？React的生态不是更好吗？我们的回答是：响应式性能直接决定了AI协作的流畅度。
技术细节考量：
- 基于Proxy的响应式系统：在处理10万字符级别的文档实时协同时，传统的
Object.defineProperty 可能会造成卡顿，而Vue3的Proxy实现了毫秒级的更新。
- Composition API：对于AI建议卡片、协同光标、公式渲染器等复杂组件的逻辑，使用Composables管理比高阶组件（HOC）更清晰。
- 对Tree-shaking友好：最终打包体积比同类React方案小约40%，在SaaS嵌入场景下，客户对加载速度的感知非常明显。
一个真实案例：某客户将我们的编辑器嵌入其CRM系统。他们原先使用的React方案首屏加载需3.2秒，替换为 JitWord 后降至1.1秒。其CTO评价道：“你们这个Vue3版本，让我们的SaaS看起来像原生应用。”
这就是我们“造轮子”的意义：不是为造而造，是为跑得更快。同时，在国产化环境中，许多客户的技术栈更倾向于Vue，因此从客户和用户体验出发，选择Vue3是完全经得起考验的策略。
拒绝自嗨：在真实场景中持续打磨
技术人常犯的一个错误是“拿着锤子找钉子”。为了避免闭门造车，我们花了两个月时间，将产品投入真实场景验证。我们开源了基础SDK，方便开发者集成到自己的项目中体验：
各行各业的用户给我们反馈了大量宝贵建议。我们内部也建立了详细的需求迭代列表，持续排期优化：
目前，我们已经评估并计划了超过100个有价值的功能点，将在今年陆续上线。我们始终欢迎更多交流与反馈。项目的GitHub地址是：https://github.com/MrXujiang/jitword-sdk
关于开源与商业化的思考
写到这里，必须回答那个最尖锐的问题：你们最后是要卖钱，还是仅仅为了技术情怀？
我们的答案是：部分开源，实现商业闭环。
为什么选择部分开源？
我们开源了基础的文档引擎SDK，包括结构化文档模型、Vue3组件基础、公式渲染模块以及docx导入导出等核心功能。目的不是做慈善，而是建立标准。 如果 JitWord 的文档模型能成为行业事实标准，第三方开发者自然会基于此开发插件，这相当于用社区力量为我们扩展生态——其效果远超招募大量产品经理。这种 开源实战 的策略，旨在汇聚社区智慧，共同推动技术进步。
为什么保留商业版？
商业版将包含AI协作引擎（涉及大模型API调用，成本敏感）、企业级协作功能（如细粒度权限管理、审计日志）以及完整的SaaS嵌入解决方案。
这并非“开源版阉割功能”，而是“开源版定义基础，商业版解决复杂问题”。可以类比Android开源但GMS服务收费，或MySQL开源但企业版提供高级监控，这是经过验证的成熟商业模式。
一个创业者的坦白：我们曾考虑完全开源、靠技术服务变现。但与数十家企业深入交流后，我发现B端客户真正付费购买的往往不是“软件”本身，而是“确定性”——出了问题能找到负责人、能签署SLA协议、能进行定制开发。这些承诺和服务，只能依靠专业的商业团队来支撑。
所以，造轮子从来不是最终目的。让轮子跑得更快，让更多人用上更快的轮子，同时让造轮子的人能够持续、健康地造下去——这才是我们所有努力的目的。 在这个过程中，如何将 人工智能 的能力与生产力工具深度结合，创造真正的价值，是我们持续探索的方向。
结语
以上便是我们团队过去一年在AI协同文档编辑器领域的实践与思考。从遇到集成困境到决定自研，从攻克技术难点到思考开源与商业的平衡，每一步都充满了挑战与收获。我们相信，在AI时代，生产力工具值得被懂产品和技术的人重新打造。如果你对 Vue3、协同编辑或AI应用开发感兴趣，欢迎在 云栈社区 与我们进行更深入的交流。
发表于 昨天 04:16
|
查看: 1|
回复: 0
