Skip to main content

Word 文档(profy-docx)

创建、编辑、分析 Word 文档。理解这个能力的关键是先接受一个事实:.docx 是一个装着 XML 的 ZIP 包。所有看起来奇怪的约束,都来自这个结构。

激活方式

profy-docxuser_selectable: false——自动可用,不需要勾选
contracts 只有 skills: ["skills/"]没有 tools。专家在沙箱里用 bash 跑脚本,技能文档规定跑法。 触发词包括:Word 文档、.docx、要求产出带目录/标题/页码/信头的正式文档,以及从 docx 提取或重排内容、图片替换、查找替换、修订与批注处理。PDF、电子表格、Google Docs 不走这条路径。

三条主路径

读取

旧版 .doc 转换

.doc 是完全不同的二进制格式,必须先转换才能编辑。

转成图片(用于视觉检查)

接受修订

需要 LibreOffice。产出的是所有修订均已接受的干净文档。

文本替换:用现成脚本,别自己写

退出码:
不要为简单查找替换手写 python-docx 脚本。 Word 会把一句话拆进多个 run(比如中间有一个字加粗,或者拼写检查插了标记),你搜索的字符串在 XML 里根本不是连续的。手写脚本因此静默失败——不报错,就是没替换成功。docx_replace.py 处理了跨 run 边界并在替换后验证结果,退出码 2 就是这道验证在起作用。

新建文档:docx-js 的关键约束

这些约束不是风格建议,每一条都对应一种”生成出来打不开或者显示错乱”的具体故障。

结构类

列表与表格

目录

支持的排版能力

页面尺寸、样式覆盖、多级列表、表格、图片、分页符、超链接、脚注、制表位、多栏布局、目录、页眉页脚。

边界与失败态

  • .doc 必须先转换,直接编辑会失败。
  • 手写替换脚本会静默失败(见上文 run 边界)。
  • 接受修订依赖 LibreOffice,没有它 accept_changes.py 跑不通。
  • 拆包改 XML 是有风险的操作。XML 结构错了 Word 会直接拒绝打开文件而不是宽容降级,所以改完必须验证。
  • 表格在不同渲染器上表现不一致。上面那批约束(DXA、双份宽度、CLEAR 底纹)多数是为了在 Word 之外的 Google Docs、WPS、预览器里也保持正确。

排错

验证你的产出

  1. 生成后转成图片看一眼:soffice.py --convert-to pdfpdftoppm这一步能抓住绝大多数排版事故,比读 XML 快得多。
  2. 有目录的话,确认目录条目数与实际标题数一致。
  3. 有表格的话,在 Google Docs 里也开一次——它对宽度定义最不宽容,能过它基本哪都能过。

相关页面

办公文档总览

四类文档能力的定位与选型

PDF 文档

需要精排交付物时的另一条路径
核对日期 2026-08-11。来源:services/agent-runtime/src/plugins/builtin/docx/plugin.jsonskills/SKILL.mdskills/scripts/office/docx_replace.pyskills/scripts/accept_changes.pyskills/scripts/office/{unpack,pack,soffice}.py