2.2 office-docx：Word 三件套之一

一句话定位

创建、读取、编辑并校验 Word 文档（.docx）。官方描述原文极简：“Create, read, edit, and validate Word documents (.docx).”

四个动词覆盖了完整生命周期，其中校验（validate）是最容易被忽略、却最值钱的一个——它是这个技能相对“随便生成一个 docx”的核心差异。

动词 对应场景
创建 从零生成规范文档：报告、公文、合同
读取 抽取条款、汇总信息、体检结构
编辑 改样式、换模板、批量统一格式
校验 交付前确认结构没有问题

为什么 docx 需要专门技能

.docx 不是文本格式，它是打包的 XML。一个 docx 文件展开后是一堆 XML 部件：正文、样式、关系、设置，彼此用关系文件串起来。这意味着“能打开”和“结构正确”是两件事，程序写出来的文件完全可以在 Word 里打开时报错。

这就是结构性问题的来源，常见的四种症状和根因：

症状 根因
Word 打开提示“内容有问题” 某个 XML 片段不合规，或部件间关系断裂
目录域显示“错误！未定义书签” 标题样式被手工改过，域找不到锚点
图片在某些客户端消失 关系文件里缺对应条目，或媒体部件没打进包
批注作者信息错乱 作者标识字段不规范

每一条都值得多说一句。

“内容有问题”是最常见的：程序拼 XML 时漏一个闭合、多一个非法字符，人眼在文本层看不出来，Word 的解析器却拒绝配合。目录域错误更隐蔽：Word 的目录不是静态文字，是靠书签锚点动态生成的，标题样式被改成普通加粗段落，域就找不到锚点。图片丢失几乎总是关系文件的问题——媒体文件明明在包里，但没有一条关系把它和正文挂起来。批注作者错乱则是字段规范问题，单人写作时不明显，多人批注汇总时才暴露。

人手工在 Word 里操作时，这些问题由软件兜底；程序批量生成时，兜底没有了，风险全部转移到交付环节。文档越是给外人看、越是要长期归档，这些隐患的代价越大。

校验环节的价值

office-docx 的校验环节，就是在交付前把这些结构性风险挡掉。具体来说它值三样东西：

  1. 可信度。过法务、财务或客户审阅的文档，打开时弹一个“内容有问题”，整份材料的专业性归零。
  2. 可归档性。需要保存多年的文档，结构隐患不会自己消失，只会在某次迁移或版本升级时爆发。
  3. 可返工性。校验报告指出具体是哪个部件、哪类问题，修起来有明确靶子；没有校验，出了问题只能全文重生成。

对一次性、只给自己看的草稿，可以跳过校验；对交付级文档，这一步不能省。实操上把“完成后做结构校验”写进任务提示词，它才会执行——不写，模型默认只保证文件能生成。

典型任务

任务一：从零创建一份规范文档。

请用 office-docx 技能创建一份项目周报，要求：
1. 标题用 Heading 1，五个章节用 Heading 2
2. 每个章节先一段摘要再列要点
3. 页脚加页码域
4. 完成后做结构校验，报告结果

这类任务的关键是结构声明：标题层级、页码域这些在提示词里写死，比生成后再调整省一轮往返。

任务二：批量格式统一。

用 office-docx 技能把 docs/ 下三份 docx 的标题样式统一成公司模板，
列出每份改了哪些样式，改完逐个校验。

批量任务的要点是变更清单：让模型列出改了哪些样式，你才能判断它有没有动不该动的地方。

任务三：读取并抽取。

用 office-docx 技能读取这份合同，抽取所有甲乙双方义务条款，
按条款编号整理成表格，不要改写原文表述。

读取类任务同样有校验价值：抽取结果是否完整，取决于文档结构是否被正确解析。注意提示词里“不要改写原文表述”这句——合同类材料，表述即效力，转述即风险。

任务四：套模板生成。

用 office-docx 技能基于 company-template.dotx 生成一份立项报告，
正文用我提供的大纲，保持模板的样式表与页脚不变，
输出到 output/ 目录，不要改动模板文件。

保留源文件，输出到新路径

这是所有文档类操作的通用纪律，值得单独说：让模型输出到新路径，不要覆盖原始 docx。

理由很直接：

做法 风险
覆盖原文件 一次失败的操作就可能毁掉唯一原件，且不可逆
输出到新路径 原件永远在，新旧可对比，返工零成本

这个纪律对编辑类任务尤其重要。批量改样式、套模板都是有损操作，覆盖之后想回看原样只能靠备份。在任务描述里写一句“输出到 output/ 目录，不要覆盖原文件”，成本为零，收益是永远的后悔药。

常见问题速查

你遇到的情况 先查什么
Word 提示内容有问题 跑一次校验，看报告指向哪个部件
目录是错的或空的 标题是不是用了真正的 Heading 样式，而不是加粗大字
图片不见了 校验报告里的关系条目，确认媒体部件在包内
生成的文档打不开 大概率是 XML 片段问题，让模型重建而不是打补丁
批注信息混乱 检查作者标识字段，必要时清空批注重来

规律：结构性问题不要反复微调，重建通常比打补丁快且干净。

与其他技能的分工

需求 用哪个
写 / 改 .docx office-docx
最终交付 PDF 再加 office-export-pdf
确认排版效果 再加 office-render

改填充色、对齐这类外观时，按官方规则即使你没要求视觉检查也要走 office-render，详见 2.5 节。

什么时候不该用它

写个几百字的说明、留个便签，纯文本或 Markdown 更轻，启动成本更低。office-docx 的价值在正式交付物：要打印、要审阅、要归档、要发给外部人的文档。判断标准很简单——这份东西会不会以 docx 的形式离开你的电脑。

实践建议

建议一：把模板也交给它。 如果公司有 .dotx 模板，先说清“基于此模板”，比事后改样式可靠。模板决定母版、样式表和默认字体，这些正是批量统一时最容易出错的部分。

建议二：校验失败就停下来问。 校验报错时不要让模型“再试试”，结构性问题反复重试通常越改越乱，人工介入更划算。

建议三：保留源文件。 输出到新路径，别覆盖原始 docx。

建议四：创建类任务先定结构再动笔。 标题层级、章节顺序、页码域这些在提示词里写死，比生成后再调整省一轮往返。

建议五：长文档分段生成。 几十章的文档一次性生成，后半部分质量容易滑坡；分章节生成再合并，每段都能得到充分注意。

建议六：批量任务先试一份。 拿一个文件跑通全流程，确认无误再批量，比三份一起改完发现方向错了省事。

小结

  • office-docx 覆盖创建、读取、编辑、校验四件事。
  • docx 是打包 XML，“能打开”不等于“结构正确”，四类高频症状要认识。
  • 校验是它相对“随便生成一个 docx”的核心差异，归档级文档必做。
  • 永远输出到新路径，保留源文件。
  • 复杂需求配合 office-export-pdf 与 office-render 形成闭环。

延伸阅读