大约十年前，我爱上了 Vue.js。其易于学习的语法和响应式特性让开发工作充满乐趣，而热模块替换（HMR）更是带来了令人难以置信的开发体验（DX）。
到目前为止，我已经在前端 JavaScript 上投入了数千小时，并且依然热爱它，但我也必须处理大量的后端工作。
尽管现代前端开发体验令人愉悦（向 Vite 致敬），但相比之下，后端工作显得笨重繁琐。我最不喜欢的任务之一就是使用模板和服务器端库在后端生成 Word 文档。迭代循环缓慢，错误信息晦涩难懂，调试过程痛苦不堪。
我更愿意用 HTML 来构建文档。但现有的 HTML 转 docx 库还有很多不足之处，在此之前我一直没有动力去构建更好的解决方案，直到如今。卡尔帕蒂自动研究循环的出现改变了这一切。
自动研究循环是一个通用概念：利用智能体启动一个针对可客观评分目标的递归自我改进循环。例如，假设你有一个运行缓慢的 SQL 查询（速度作为衡量指标）。你可以启动一个循环，提示词如下：
你是一名 SQL 性能研究员。运行以下 SQL 查询以建立基线，然后提出提高性能的假设。对每个结果进行评分并运行 5 次迭代。避免任何性能回退，每个结果必须包含完全相同的行和列。
这并不完全是暴力破解，但它是一个类似的概念，即在受限任务中自主运行迭代以寻求改进。
在其他几个项目上成功应用自动研究循环后，我突然有了一个想法。我能否通过暴力破解的方式，构建一个高保真度的 HTML 转 DOCX 转换器？
这个想法在我脑海中盘旋了几天，随后我决定尝试一下。于是，我的第一个开源包 dom-docx 诞生了。
循环的实际运作方式
评分循环需要一种方法来判断“这是一个好的 Word 文档吗”，这种方法必须能让机器进行评估，而无需人工逐个检查输出。具体方法如下：
- 渲染一批 HTML 测试用例（标题、列表、表格、弹性盒子行、图片、内联格式、真实模式，而非玩具示例）
- 将每个用例转换为
.docx文件 - 通过 LibreOffice 将结果光栅化，并通过比较渲染后的 HTML 与转换后的 docx 文件的保真度指标，对比布局结构
- 对每个用例进行评分：50% 视觉/布局保真度，35% 可编辑性（真实的 Word 结构，而不是伪装成文档的 1×1 布局表格），15% 编译速度
- 将回退情况反馈回去，调整转换逻辑，重复上述过程
并没有某种单一的巧妙技巧使这一方案奏效。这主要归功于拒绝接受“足够好”的标准，并让循环逐一攻克边缘情况：嵌套列表、表格背景、弹性盒子布局、块引用，以及那些在实际应用中真正导致 HTML 转 docx 转换器失效的问题。
结果
我在 npm 上将 dom-docx 与几个成熟的开源 HTML 转 docx 转换器进行了基准测试，这些转换器是稳固且广泛使用的纯 JavaScript 库，无需无头浏览器支持。我在 37 个真实世界测试用例中使用相同的评分框架进行了对比。
数据出炉后，有几件事格外引人注目：
- 在此评分框架的所有 37 个用例中，dom-docx 均生成了符合架构规范的 OOXML，这是最明显的差距所在。
- 平均布局保真度得分在 90% 中期水平，而所测试的替代方案仅在 60% 中期水平。
- 最大的差距恰恰出现在你预期的地方：块引用内的嵌套列表、表格行背景、弹性盒子布局、内联 SVG。简单的内容（普通段落、居中的
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
