用 AI 辅助手写纯浏览器 DOCX 渲染器的一些踩坑记录

又忘取消续费 · 2026-09-22T09:29:36.901Z

在做文档翻译工具 O.Translator（ https://otranslator.com/zh ）和商译 AI（ https://shangyiai.com/zh ）的时候，需要支持在浏览器里直接预览 DOCX、PDF、PPTX。一开始 DOCX 预览选了开源的 VolodymyrBaydalka/docxjs。常规小文件还行，遇到 20M 以上或者 XML 超过 500 个的复杂大文件，页面经常卡死甚至让标签页崩溃。当时只能加限制：超过 20M 就禁止在线预览，逼用户下载看。但这很影响交付体验，加上它对复杂样式支持有限，我一直想重写一套。我的思路是走 Worker-first 架构：解析、测量、排版计算全扔进 Web Worker，主线程只管拿计算好的页面模型做绘制。这样以后换渲染端也灵活，不管是 DOM、Canvas 还是搬去小程序都行。但整个复杂度太高，单靠自己纯手写成本太大。 #AI模型后来我开始加大 AI 编程的比例，主力换成 GPT-5.4 之后，感觉可以启动了。给它定好三层分工：Worker 算排版和模型，Viewer 负责拉取调度，Renderer 纯消费模型画页面，明确禁止 Renderer 偷偷退回 DOM 走老路。 5 月中旬搭完骨架，我写了一套自动化测试：拿自研引擎和 Word 分别打开同一个文档，逐页截图后跑 Python 脚本比对相似度，低分的挑出来人工排查。真实文档一压进去，问题全暴露在分页上，单位里混着 twips、pt、px 和各种 CSS 字符串，很多地方还挂着针对特定表格写的硬编码补丁。接着开始重构分页单位，拉齐 Word 行盒、换页模型和来源几何信息，把 getBoundingClientRect 和动态回流计算彻底从 Renderer 里掐死。但很快踩了新坑：修好一个排版，另一个地方就崩，打包出来的体积也涨得不对劲。翻代码发现 AI 面对具体排版问题时，偷懒写了海量场景特判代码，骨架是对的，里面全是补丁。 7 月份又推翻搞了单一分页内核。因为之前段落、表格、浮动对象都在自作主张决定当前页塞不塞得下、要不要截断换页，到处都是分页决策分支，边缘情况必飘。让 AI 写复杂系统，这种逻辑分支多头决策是最容易翻车的点。后面干脆推倒重理对象模型，把 XML 解析和样式族严格拆成单一主责模块，在 prompt 规则里严禁跨层做多重决策，才算把整个排版流水线稳下来。

讨论话题

发现产品榜单精选讨论