做文档自动化的人，迟早会撞上同一堵墙。

我接过一个招投标的活：客户每天出几十份标书，格式固定、字段固定，人工填一份要几个小时。听起来正是"该让程序干"的典型场景。

结果第一周就卡住了。不是模型不行，是 

.docx 这个格式本身就不是给程序准备的

它外面是一个文件，里面是一个 ZIP。解开来是一堆 XML：

 管样式，另外还有编号、页眉页脚、批注、修订——统称 OOXML。

想让程序拼出一份"人能看"的文档，得同时维护：段落层级、样式继承、编号计数、表格合并、分节符。

任何一项对不上，Word 打开就报"内容有问题"。

更麻烦的是那些看不见的东西——修订痕迹、域代码、交叉引用。它们不在你生成的 XML 里，但会影响打开后的行为。

所以行业里的主流做法一直是绕开：拿一个 Word 模板，用脚本替换占位符。

 模板一改、格式一动，脚本报废；想加一种新段落，就得重新对齐一次 XML。

最近看到一个项目 WordCraft（GitHub 10275 star，Apache-2.0），做法比较彻底：

用纯 Rust 从零写一个文字处理器

它不是模板引擎。它复刻的是 Word 的工作流——功能区、样式、表格、修订、引用、邮件合并；读写 .docx（OOXML），同时支持 .odt/.rtf/.html/.md/.tex/.txt。macOS/Windows/Linux/BSD 原生，另有 WASM 版本可跑在浏览器里。

README 里有一句自我定位挺关键：

文档从一个"用鼠标点开的东西"，变成可以被程序调用、被 agent 编排的对象。它的 workspace 里带了 

文档自动化的瓶颈在格式层，不在模型层。

现在大多数项目把两件事一起压给模型，让它直接吐 XML 或者吐 markdown 再转换，然后被样式和编号反复教育，效果自然不稳。

如果有一个真正可编程的文档引擎，链路就能变成：模型只产出结构化内容，引擎负责排版落盘，中间用命令行或 API 串起来。

把确定性工作交给确定性工具，别让模型去拼 XML。

git clone https://github.com/storytold/wordcraft
cd wordcraft

现在拿它做生产文档引擎，我认为为时过早。

等哪天"文档"真的变成可编程对象，企业文档自动化才算有解；在那之前，大家只能停在替换占位符的水平，而这套东西在真实业务里三天两头出问题。

中文版 README（含中文快速上手：Rust 版本、构建方式、格式支持、国内加速提示）：

Rust 重写一个 Word 值不值？先说清 .docx 为什么这么难伺候

编程语言

开发工具

职业发展

WordCraft用纯Rust重写文字处理器，支持OOXML格式，可被命令行和AI agent驱动，解决传统模板替换脚本脆弱的痛点，让文档自动化从内容生成到格式排版形成稳定闭环，值得关注。

Markdown

Windows

GitHub

Linux

MacOS

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

Rust 重写一个 Word 值不值？先说清 .docx 为什么这么难伺候

Rust 重写一个 Word 值不值？先说清 .docx 为什么这么难伺候

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐