docx 件拆解：改 Word，先拆包

概述

官方全家桶的文档三连，本栏已经拆过两件：xlsx 件的答案是「公式不自己算」，pdf 件的答案是「最便宜的先上」。这次轮到三连里最重的一件——docx。它面对的是全世界办公室的默认格式，也是对 Agent 最不友好的一种格式：二进制压缩、XML 嵌套、修订批注满天飞。官方 docx 件给出的答案只有一句话：别把 Word 当文档，把它当压缩包。本文按 SKILL.md 逐段拆它的门牌设计、三岔口路由、解包手术链路，最后给出五维评分、替代路线对比和能直接抄走的三招。

一、它在全家桶里的位置

Anthropic 的 Skills 机制从 2025 年 10 月上线至今约十一个月，官方仓库 anthropics/skills 里的 document-skills 家族（docx、pdf、pptx、xlsx）始终是被二创抄袭最多的一个角落——大量社区件的 SKILL.md 写法，源头都能追到这几份文件。

docx 在这个家族里的特殊之处在于工作量分布：

xlsx 和 pdf 的难点在「算」和「生成」，docx 的难点在「改」——用户递来一份合同、一份标书、一篇导师改了八稿的论文，要求在保留全部格式的前提下动其中三段。这才是 Word 工作流的真实主战场，也是这个 Skill 值得拆到每一行的原因。

二、门牌逐行：frontmatter 的触发词设计

SKILL.md 开头是两行 YAML 门牌：name: docx，加一段 description。Skill 机制的原理决定了这段 description 是全局常驻上下文的——模型随时能看到它，但 SKILL.md 正文只有被命中后才加载。所以这一段是「召回器」，写法上极讲究。

docx 的 description 核心句是 "Comprehensive document creation, editing, and analysis"（大意：文档的创建、编辑与分析全覆盖），随后用编号枚举把场景一个一个列全，大意是：（1）从零创建新文档；（2）修改或编辑既有文档内容；（3）处理修订（tracked changes）；（4）添加批注（comments）；（5）其他一切文档任务。

这个写法值得逐层看：

1. 一个动词一张门票。create、edit、analyze 三个动词对应三类完全不同的用户原话（“帮我写个方案” / “改一下这段” / “总结这份文件”）。少写一个动词，就少一类召回。
2. 编号枚举是防漏网设计。(1) 到 (5) 的清单式写法，把「修订」「批注」这两个冷门但高价值的场景钉死在门牌上。多数人自己写 Skill 只会写“处理 Word 文档”，结果用户说“帮我在修订模式里改”时模型想不起挂载它。
3. 第 (5) 条兜底。“任何其他文档任务”是一张万能票，避免长尾说法漏召回。这个「枚举 + 兜底」的双层结构，是官方件被抄得最多的写法，没有之一。

门牌下面才是正文，而正文的第一原则是：只放路由，不放细节。

三、三岔口路由：读、造、改，各走各的路

docx 件正文的主干，是把一切 Word 需求先分成三个意图，每个意图配一条完全不同的技术路线：

flowchart TD
    A["用户抛来 docx 需求"] --> B{"先判断意图"}
    B -->|只想看内容| C["pandoc 转 markdown"]
    B -->|从零新建| D["写 docx-js 代码"]
    B -->|修改既有文件| E["unpack.py 拆包"]
    C --> F["纯文本通读 结构尽收"]
    D --> G["node 执行 代码吐文档"]
    E --> H["手工编辑 OOXML"]
    H --> I["pack.py 回卷打包"]
    F --> J["交付结果"]
    G --> J
    I --> J

读：pandoc 先行，成本最低。 只是要看内容，就 pandoc 文件.docx -o out.md，一行命令转成 markdown 通读。要看版式和图表效果，再把渲染结果转成图片看一眼。这条路线的前提判断是：大多数「读」的需求根本不需要理解 OOXML。

造：docx-js，代码即文档。 从零创建时，SKILL.md 不让模型手写 XML，而是让它写一段 JavaScript，用 npm 上的 docx 库（即 docx-js，GitHub 上的 dolanmiu/docx）声明式地拼出 Document、Paragraph、TextRun，然后 node 跑一遍吐出文件。理由很直白：OOXML 冗长且极易写错，代码生成是组合式的、可复用的、错了改代码比重排 XML 便宜得多。

改：拆包手术，正文重头。 这是全 Skill 最核心的一条路，也是它敢自称「编辑」的底气，下一节单独开膛。

路由设计里最聪明的是那两条反向护栏：

• 造新文件时，别手写 XML——用 docx-js；
• 改旧文件时，别用 docx-js——直接改 XML。

docx-js 是「从零生成」取向的库，把一份既有 Word 塞进去再导出，各种冷门格式块很容易丢失；反过来，手写 XML 造新文档则是给自己挖坑。一个工具的强项恰好是另一个工具的禁区，SKILL.md 用两句话把这个坑提前焊死。这种「明确告诉模型别干什么」的写法，比堆十个正确示例都管用。

四、核心手术台：unpack → 改 XML → pack

编辑路线的机制，本质是承认一个多数用户不知道的事实：.docx 就是一个 zip 压缩包，里面装着一堆 XML 文件（这是 ECMA-376 / ISO 29500 标准，不是黑科技）。真正的正文在 word/document.xml 里，样式在 styles.xml，编号在 numbering.xml，批注在 comments.xml。

Skill 目录下配了一对 Python 脚本干机械活：

典型用法就是「进目录、出文件」两个参数：先 unpack.py 合同.docx 合同目录/，改完 pack.py 合同目录/ 合同-改.docx。

拆包之后发生的事，才是这个 Skill 的灵魂——模型做的不再是「编辑文档」，而是「编辑文本」：

flowchart TD
    A["合同.docx"] -->|zip 解包| B["word/document.xml"]
    B --> C["定位目标段落"]
    C --> D["套上 w:ins 修订块"]
    D --> E["被删文字改 w:del"]
    E --> F["pack.py 回卷打包"]
    F --> G["Word 打开 满屏修订记录"]

OOXML 的段落结构是标准的俄罗斯套娃：w:p 是段落，w:r 是文字运行块，w:t 才是真正的文字。模型改字，就是在正确的 w:t 里动字符；要保留修订痕迹，就把新增内容套进 <w:ins> 块、把删除文字改写成 <w:del> 里的 w:delText，作者和时间戳都写在属性里。

这套设计的高明之处在于分工切得极干净：

• 脚本只干哑活——解包、美化、回卷，零智能，永远不出错；
• 模型只干灵活——读 XML、理解上下文、决定在哪改、改什么。

xml 经过美化缩进后是规整的纯文本，正是语言模型最擅长的疆域。所谓「降维打击」，就是把一个需要 Word 界面、需要鼠标点选的 GUI 问题，压扁成一个 sed 都能参与的文本问题。

五、修订与批注：律师场景的杀手锏

三岔口里最值钱的分支是 tracked changes。审合同、改论文、过法务，全世界的严肃文档协作都开着修订模式——而市面上绝大多数「AI 处理 Word」方案到这里就露馅：要么把修订记录全洗掉直接改文（法务看到会跳起来），要么只能重做一份新的。

docx 件的解法是直接操纵修订标记：新增写 w:ins，删除写 w:del，每处修改自带作者名和时间戳。最终文件在 Word 里打开，就是一份标准的、可以逐条接受或拒绝的修订稿——AI 不是替你改文件，而是像人类协作方一样递交一份修改建议稿。批注同理：往 comments.xml 里写 w:comment，正文里打上锚点，AI 就能在第几段第几行「贴便签」。

这两个能力在 description 门牌里被专门枚举（还记得第 (3)、(4) 条吗），门牌与正文在这里形成了闭环：召回靠这两条，交付也靠这两条。

六、五维评分与替代路线对比

按本栏固定维度给 docx 件打分：

再和三条常见的「野路子」比一比，看看绕开这个 Skill 的代价：

野路子全部在「改既有文件」这一列塌方——这正是 docx 件存在的理由。

七、什么时候别用它

诚实的拆解要说清边界，四类场景建议换工具：

1. 画册级排版。精密版式设计不是 OOXML 的强项，走 HTML/CSS 或 pdf 件更合适。
2. 几百页的大部头。document.xml 美化后可能膨胀到几十万行，通读不现实，必须先 grep 定位再局部读——上下文窗口是硬约束。
3. 复杂内嵌对象。嵌入图表（chart 部件）的 XML 极其庞杂，pandoc 转读时也会丢信息，这类需求要先降低预期。
4. 只想写 markdown。如果你的一切产出终点是 .md，这个 Skill 一辈子不会被触发，装了纯属占目录。

八、能抄走的三招

不管你下个 Skill 想做什么，docx 件有三处写法可以直接搬：

1. 枚举式门牌。description 里一个动词一张门票，冷门高价值场景单独编号列出，最后加一条兜底。召回是 Skill 的生死线，正文写得再好，门牌没写全就一切免谈。
2. 意图路由 + 反向护栏。正文先按用户意图分岔，每条岔路给「该用的工具」的同时，明确写「别用的工具」。禁令比示例便宜，一条禁令顶十个范例。
3. 哑脚本 / 灵模型分工。把一切机械、确定、易错的环节（解包、打包、格式转换）下沉成脚本，模型只负责判断和编辑。你的 Skill 里如果有一段「每次都要重复操作的命令」，它就该变成脚本，而不是一段提示词。

九、安装与试用

# 方式一：skills CLI 一键装全家族
npx skills add anthropics/skills

# 方式二：手动克隆，只取 docx 一件
git clone https://github.com/anthropics/skills
cp -r skills/document-skills/docx ~/.claude/skills/docx

装完在 Claude Code 里新开会话（技能列表启动时扫描），直接丢一份真实文档试三条路各一遍：

1.「读一下这份合同，总结各方义务」        → 应走 pandoc 路线
2.「帮我起草一份项目周报模板，带表格」    → 应走 docx-js 路线
3.「在修订模式下把第 3 条的违约金改掉，并加批注说明理由」
                                          → 应走拆包手术路线

第 3 条是试金石：如果返回的文件在 Word 里显示为规范的红色修订记录，这件 Skill 就是真金白银；如果它悄悄洗掉了修订痕迹，那就是仿品。

推荐排行榜

• 最该装：合同/标书/论文修订流的重度玩家——w:ins/w:del 手术链路无可替代；
• 该装：批量生成周报、报告、通知的办公自动化选手——docx-js 代码生成又稳又可复用；
• 可装可不装：偶尔转个格式的轻用户——pandoc 单曲循环够用；
• 不必装：纯 markdown/网页产出党，以及期待它做平面设计的用户。

文档三连拆完，官方件的家族基因也看全了：xlsx 不算数学，pdf 不买贵的，docx 不开 Word。三件的共同哲学是同一句——把 GUI 软件的问题降维成文本问题，然后把文本问题交给最会读写的那个东西。

参考来源

1. anthropics/skills — 官方 Skills 仓库 — document-skills/docx 所在仓库，本文拆解对象的本体
2. docx SKILL.md 原文（raw） — 门牌与三岔口路由的原始出处
3. Equipping agents for the real world with Agent Skills — Anthropic Engineering — 渐进披露与描述常驻机制的设计背景
4. docx — npm — 创建路线所用的 docx-js 库
5. Pandoc — 读取路线所用的万能转换器

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。