ps：开源版SDK已发布，github地址：github.com/MrXujiang/j…
又到了我们定期AI创业复盘的时间了。今天和大家分享一下，我们决定花1年时间打造AI 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界面，难度不是很大，只需要花时间来开发，我相信每一个前端工程师都能实现，其难点在于：
- 如何高效的做文档解析（需要对docx进行高精度格式还原）
- 如何基于文档做高性能协同（支持多人协同编辑）
- 如何在web文档处理复杂公式编辑和渲染
- 实现文档的复杂操作（划词评论，版本对比，高级排版，分页视图等）
- 实现文档的权限控制和高性能渲染（100w+字秒级渲染）
等等，每一个骨头都比较硬，基本上都是我们花大量实现自研，比如：
基于文档做高性能协同（支持多人协同编辑）
目前市面上其实有些协同方案，比如CRDT算法驱动的YJS，当然我们也是基于YJS实现的文档协同算法。但是单纯使用Yjs，只能实现基础协同，在协同过程中我们需要考虑很多复杂场景：
- 操作可交换性不同用户的操作可以以任意顺序执行，最终结果一致
- 操作可合并性多个操作可以智能合并，减少网络传输
- 最终一致性所有客户端最终会收敛到相同的文档状态
- 无需中央协调不依赖中央服务器进行冲突解决
下面是我们设计的协同操作流程：
在协同编辑的性能上，我们也做了进一步算法优化，保证我们在普通服务器上（2核4G）也能支持10-50人的高效协同编辑，如果扩大服务器性能和集群，我们将有可能支持数千上万人的协同编辑。
下面是我们的文档协同和存储架构数据流：
实现在web端处理复杂公式编辑和渲染
基本上市面上的开源方案都达不到我们对复杂公式的极致追求，大部分是让用户直接编辑latex，但是到了导出docx后，公式要么无法导出，要么导出后无法二次编辑。
基于上面的痛点，我们对docx文件做了数据结构的分析和算法层的兼容，同时对用户编辑公式的体验也做了进一步升级：
我们提供了数学公式的编辑面板，我们可以实时编辑和预览公式，同时我们内置了100+高频的数学和科研公式，方便大家更快速的编写复杂公式。
下面是渲染到 JitWord 中的公式效果：
同时，我们也能直接导出带复杂公式的文档，并在 word 中二次编辑。
文档的高效渲染（100w字秒级渲染）
上面是我们文档中渲染了100w字的效果，目前测试下来还是可以编辑文档，只有略微的延迟。
这一结果归功于我们对文档性能的极致追求，在文档渲染层我们做了极致的优化，并全方面测试了渲染协同稳定性能：
实现文档的复杂操作（划词评论，版本对比，高级排版，分页视图等）
任何一个富文本编辑器，都很难自带划词评论，版本对比，高级排版，分页视图这些高级操作功能。
我们研究这些功能花费了很多时间，也在每个月以2-3个版本的迭代速度更新着JitWord。
终于在2025年底实现了上面提到的这几个功能，下面我也给大家一一介绍一下。
- 划词评论
当然大家可不要以为我们只是做了划词评论功能。我们在划词评论之后，还做了通信机制，在多人协同过程中可以实时通知给其他人，让协作者可以第一时间看到划词的内容，这个流程我们完全打通了。
- 版本管理功能
我们的操作会定期存储，可以一键恢复，并支持版本的差异对比。这个功能基本上也是市面上web端文档独一份的，当然我们还在持续优化。
- 分页视图功能
这个功能是最难坑的，不容置疑。但是我们花了2个月 all in 这个功能，终于实现了类似 word 的分页功能。它的难点在于分页之后内容的排版和位置自动计算机制，需要消耗大量的 js 性能，所以我们各种性能优化的方式都用上了，结合我们设计的独有的dom组织模式，终于实现了分页能力。
大家可以在 JitWord 共建版体验到分页的功能。
当然，我们还会支持页眉页脚功能，全面对标 Office。
第二步，AI协作引擎：让文档"活"起来
上面是我们设计的 AI Native 驱动的模式架构，保证我们在文档编辑的全生命周期里，都能体验AI创作的乐趣。
下面是演示效果：
我们除了直接让AI创作内容，还可以基于文本和段落，进行二次AI优化，比如文本润色，纠错，续写等：
最近我们还迭代上线了AI公文助手，可以通过AI一键生成合同和公文：
当然后续会实现更多和AI结合的场景，提高用户办公的效率。
第三步，Vue3的执念：为什么死磕Vue？
很多人问：文档编辑器为什么要强调Vue3？用React不是生态更好？
我们的回答是：响应式性能决定了AI协作的流畅度。
技术细节：
- Proxy-based响应式：10万字符文档的实时协作，传统
Object.defineProperty会卡成PPT，Vue3的Proxy实现了毫秒级更新 - Composition API：AI建议卡片、协作光标、公式渲染器……这些复杂组件的组合逻辑，用Composables管理比HOC清晰10倍
- Tree-shaking友好：最终打包体积比同类React方案小40%，SaaS嵌入时客户感知明显
一个真实案例：
一个客户把我们的产品嵌入他们的CRM系统，原先用的React方案首屏加载3.2s，替换为 JitWord 后降到1.1s。客户CTO的原话："你们这个Vue3版本，让我们的SaaS看起来像原生应用。 "
这就是"造轮子"的意义：不是为造而造，是为跑得更快。
并且国产化环境，很多客户都是更倾向用 Vue 技术栈，所以站在客户和用户体验的角度，我们Vue的策略是完全经得起考验的。
拒绝自嗨，持续打磨应用场景
技术人最容易犯的错：拿着锤子找钉子。
我们花了两个月时间，把产品扔到真实场景里验证，我们上线了我们开源SDK，让大家可以集成到自己的真实项目中来体验：
目前有各行各业的客户给我们反馈了大量的建议，我们也在持续排期优化，下面分享一下我们内部的需求列表：
目前已经有100多个我们评估后觉得非常有价值的功能点，在今年的一年里，我们会陆续上线。
当然大家有好的建议，也欢迎随时交流反馈～
github地址：github.com/MrXujiang/j…
开源与商业化思考
写到这里，必须回答那个最尖锐的问题：
你们最后要卖钱吗？还是说只是技术情怀？
我的答案是：部分开源，商业闭环。
为什么开源？
开源了基础的文档引擎SDK，包括：
- 结构化文档模型
- Vue3组件基础
- 公式渲染模块
- docx导入导出功能
目的不是做慈善，是建立标准。
如果 JitWord 的文档模型成为行业事实标准，第三方开发者自然会基于我们的格式开发插件。这等于用社区力量帮我们扩展生态——比招100个产品经理都有效。
为什么保留商业版？
商业版包含：
- AI协作引擎（调用大模型API，成本敏感）
- 企业级协作功能（权限管理、审计日志）
- SaaS嵌入解决方案
这不是"开源版阉割功能"，是"开源版定义基础，商业版解决复杂问题"。
类比：Android开源，但GMS（Google服务）收费；MySQL开源，但企业版有高级监控。这是经过验证的商业模式。
一个创业者的坦白：
我们考虑过完全开源、靠服务变现。但过去一年和几十家企业聊过后，我发现B端客户真正付费的不是"软件"，是"确定性" ——出了问题能找到人、能签SLA、能定制开发。这些只能靠商业团队支撑。
所以，造轮子不是目的。
让轮子跑得更快，让更多人用上更快的轮子，同时让造轮子的人能持续造下去——这才是目的。
关于作者：前大厂技术专家，现 JitWord 联合创始人。相信AI时代的生产力工具，应该由懂产品和技术的人重新做一遍。
我们团队均来自一线中大厂，资深工程师和技术专家，配合3个Agent，开启6人协作的创业之旅～
如果大家有好的建议，想法，欢迎留言反馈～
