<!-- title: docx拆解：改Word先拆包 -->

# 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 | 公式算不出来 | 让 LibreOffice 重算，自己不碰数学 |
| pdf | 生成工具太贵太重 | 从最便宜的工具往上试 |
| **docx** | **改文件 ≠ 重写文件** | **拆包改 XML，改完再打包** |

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 需求先分成三个意图，每个意图配一条完全不同的技术路线：

```mermaid
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 脚本干机械活：

| 文件 | 干的事 | 为什么必须是脚本 |
|---|---|---|
| `ooxml/scripts/unpack.py` | 解 zip 到目录，并用 lxml 把 XML 美化缩进 | 模型自己 unzip + 手动排版又慢又易错 |
| `ooxml/scripts/pack.py` | 把目录按 zip 规范重新打包成 .docx | 压缩包结构有讲究，手搓容易打出坏文件 |
| `docx-js.md` | docx-js 用法参考 | 渐进披露：造文档时才需要读 |

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

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

```mermaid
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 件打分：

| 维度 | 权重 | 评分 | 依据 |
|---|---|---|---|
| 功能完整度 | 25% | ★★★★★ | 读、造、改、修订、批注全覆盖，文档任务的完整闭环 |
| 设计质量 | 25% | ★★★★★ | 三岔口路由 + 双向护栏 + 渐进披露，官方写法教科书 |
| 实战效果 | 20% | ★★★★ | 编辑链路极稳；但超长文档的 XML 对上下文窗口压力大 |
| 上手难度 | 15% | ★★★★ | 复制即装；运行时依赖 pandoc、node、python+lxml |
| 社区活跃度 | 15% | ★★★★★ | 官方仓库维护，家族写法被社区大量继承 |
| **加权总分** | | **4.7** | 文档三连里设计最完整的一件 |

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

| 路线 | 新建文档 | 改既有文件 | 保留原格式 | 修订/批注 | 主要风险 |
|---|---|---|---|---|---|
| docx 件 | ★★★★★ | ★★★★★ | ★★★★★ | ★★★★★ | 需要装运行时依赖 |
| 手写 python-docx | ★★★★ | ★★ | ★★ | ★ | 库偏创建取向，改旧文件常丢格式 |
| pandoc 一把梭 | ★★★★ | ★ | ★ | 无 | 转换即有损，改完回不去 |
| 让模型凭空描述 Word | ★★ | ★ | ★ | 无 | 产出的 XML 大概率打不开 |

野路子全部在「改既有文件」这一列塌方——这正是 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 里如果有一段「每次都要重复操作的命令」，它就该变成脚本，而不是一段提示词。

## 九、安装与试用

```bash
# 方式一：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 仓库](https://github.com/anthropics/skills) — document-skills/docx 所在仓库，本文拆解对象的本体
2. [docx SKILL.md 原文（raw）](https://raw.githubusercontent.com/anthropics/skills/main/document-skills/docx/SKILL.md) — 门牌与三岔口路由的原始出处
3. [Equipping agents for the real world with Agent Skills — Anthropic Engineering](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills) — 渐进披露与描述常驻机制的设计背景
4. [docx — npm](https://www.npmjs.com/package/docx) — 创建路线所用的 docx-js 库
5. [Pandoc](https://pandoc.org/) — 读取路线所用的万能转换器

> [!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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)