技能使用指南

docx（DOCX文档处理技能Skill）Skill 能做什么？

想让 AI 精准修改 Word 又保留修订痕迹？DOCX文档处理技能Skill 支持文本提取、docx-js 创建文档、OOXML 级编辑与红线跟踪更改工作流，自带 grep 校验闭环，法务、咨询、学术场景都能用。本文详解安装步骤、使用方法、竞品对比与真实体验，帮你快速上手。

DOCX文档处理技能Skilldocx
17 个章节 约 17 分钟阅读 AI 智能生成

DOCX文档处理技能Skill：让 AI 像专业文档编辑一样读写 Word

  • 它解决的是「格式」问题：.docx 本质上是一个 ZIP 压缩包，内部由 XML 描述内容、样式、修订和评论。普通 AI 对话只能看到纯文本，样式、批注、修订痕迹全部丢失；这个技能让 AI 直接读写底层结构。
  • 一条决策树覆盖五类任务：读取分析、创建新文档、简单编辑、他人文档修订、法律/学术/商业/政府文档红线修订，不同任务走不同工作流，不会「一把锤子敲所有钉子」。
  • 核心亮点是「红线工作流」：用跟踪更改（<w:ins> / <w:del>）方式做修订，且要求最小化、精确编辑，只标记真正改动的文本，保留未改动内容的原始 RSID，让审阅者能一眼看清改了什么。
  • 工具链明确：创建用 docx-js（JavaScript/TypeScript），编辑用 Document 库（Python），读取用 pandoc，视觉检查用 LibreOffice + Poppler 转图。
  • 适合谁用：法务、咨询、学术、行政、内容运营等经常需要「在别人文档上动刀」的角色，以及需要批量生成规范 Word 文档的开发者。

一、该技能叫什么？如何一键安装 AI 技能提升开发效率？

技能基本信息

项目 内容
中文名 DOCX文档处理技能Skill
英文名 docx
技能ID 12731
授权方式 专有，LICENSE.txt 包含完整条款

它到底解决什么问题

很多人以为「AI 改 Word」就是把文字丢给模型、让它重写一遍再粘回去，但真实办公场景远没这么简单：

  • 合同里改一个日期，需要留下修订痕迹，让对方看到「30天 → 60天」而不是整段重写；
  • 报告里有批注要保留、要新增；
  • 文档有固定样式模板、页眉页脚、嵌入图片和元数据，不能被破坏；
  • 审阅者需要知道改动发生在「第 3.2 节」还是「第四条」，而不是「第 47 行」。

这个技能把这些需求拆成了可执行的工作流：文本提取走 pandoc，结构化操作走解压 + XML 编辑 + 重新打包，全新文档走 docx-js 生成，视觉核对走转图片流程。AI 不再「猜」文档长什么样，而是真的看到了文档结构。

一键安装的思路与步骤

技能详情中并未提供具体的安装命令与市场入口，因此下面给出的是通用流程，具体命令、入口与版本要求请以官方说明为准：

  1. 确认运行环境：需要一个支持「技能（Skill）」机制并已加载本技能的 AI 客户端或开发环境（例如支持技能调用的 Claude 环境）。
  2. 检索并安装技能：在技能市场或技能仓库中，用英文名 docx 或技能ID 12731 进行检索，找到对应条目后执行安装（安装入口与命令以官方说明为准）。
  3. 补齐运行依赖：技能的多数工作流依赖外部工具，详情中列出的必需依赖包括：
    • pandoc：用于文本提取，如 sudo apt-get install pandoc
    • docx：用于创建新文档，如 npm install -g docx
    • LibreOffice：用于 DOCX 转 PDF，如 sudo apt-get install libreoffice
    • Poppler：提供 pdftoppm，用于 PDF 转图像，如 sudo apt-get install poppler-utils
    • defusedxml：用于安全 XML 解析，如 pip install defusedxml
  4. 验证是否生效：上传一个带修订的 .docx，让它执行 pandoc --track-changes=all 文件路径.docx -o 输出.md，如果返回的 Markdown 保留了标题层级并显示出修订内容，说明读取链路已通；再让它解压文档并列出 word/document.xml，若能看到 XML 结构，说明编辑链路也已就绪。
  5. 确认授权边界：该技能为专有授权，使用前请阅读 LICENSE.txt 中的完整条款，避免在受限场景下超范围使用。

二、该技能的主要功能和特点

  • 文本提取与结构保留：通过 pandoc 把 .docx 转成 Markdown，--track-changes 支持 accept / reject / all 三种取值，能按需保留、接受或拒绝修订痕迹，而不是简单粗暴地输出纯文本。
  • 原始 XML 级访问：解压后可精确处理评论（word/comments.xml）、复杂格式化、文档结构、嵌入媒体（word/media/）与元数据，修订则对应 <w:ins>（插入）和 <w:del>（删除）标签。
  • 从零创建 Word 文档：使用 docx-js，通过 Document、Paragraph、TextRun 等组件编写 JavaScript/TypeScript，最后用 Packer.toBuffer() 导出为 .docx，适合程序化批量生成规范文档。
  • 编辑现有文档：使用 Document 库（Python 的 OOXML 操作库），它自动处理基础设施搭建，常见操作有高级方法封装，复杂场景可直接操作底层 DOM。
  • 红线工作流（跟踪更改）：这是最具差异化的能力。先用 Markdown 规划全部修订，再分批实现；要求「最小化、精确编辑」——只标记真正改动的片段，把一次替换拆成「未改动文本 + 删除 + 插入 + 未改动文本」，并复用原始 <w:r> 和 RSID，避免整句重写导致审阅体验变差。
  • 批处理策略：把相关改动按 3~10 个一组分批实现，每批跑通后再进入下一批，降低调试难度，同时不牺牲效率。
  • 文档转图像做视觉核对：先用 soffice --headless --convert-to pdf 转 PDF，再用 pdftoppm -jpeg -r 150 切成 page-1.jpg、page-2.jpg，支持用 -f / -l 指定页码范围、用 -r 调整分辨率，适合版式校验场景。
  • 强制校验闭环：修订完成后必须重新转 Markdown，用 grep 确认「原始短语已消失」「替换短语已出现」，并检查是否引入意外改动——把「交付前自检」写进了流程。
  • 明确的工作流决策树：读内容走提取、建文档走创建、自己的文档小改用基础 OOXML 编辑、他人的文档默认走红线工作流、法律/学术/商业/政府文档必须走红线工作流。

和普通工具比强在哪？普通方案要么只能读文本、要么只能全量重写，而它能在保留格式与修订语义的前提下做外科手术式修改，并且自带校验步骤。

三、如何使用该技能？

第一步：先判断任务类型

把需求说清楚，让技能走对分支：

  • 「帮我看看这份合同里有哪些条款提到付款周期」→ 读取分析
  • 「生成一份带标题、表格和页脚的项目周报」→ 创建新文档
  • 「把我自己写的这份说明改一下措辞」→ 基础 OOXML 编辑
  • 「在这份供应商合同里把 30 天改成 60 天，留修订痕迹」→ 红线工作流

第二步：读取与分析

pandoc --track-changes=all 合同.docx -o current.md

需要看批注、复杂格式或嵌入媒体时，再解压：

python ooxml/scripts/unpack.py 合同.docx unpacked_dir

解压后重点关注 word/document.xml（正文）、word/comments.xml（评论）、word/media/（图片）。脚本还会建议一个用于跟踪更改的 RSID，记下来备用。

第三步：创建新文档

  1. 完整阅读 docx-js.md（约 500 行，不要设置范围限制）；
  2. 编写一个 JavaScript/TypeScript 文件，用 Document、Paragraph、TextRun 组织内容；
  3. 调用 Packer.toBuffer() 导出 .docx。

第四步：编辑现有文档（红线工作流）

  1. 转 Markdown 并保留修订，通读全文，列出所有需要的改动；
  2. 按章节、类型或页码把改动分成 3~10 个一批的批次；
  3. 解压文档，记录建议的 RSID；
  4. 逐批实现：每次写脚本前先 grep word/document.xml 确认文本当前如何跨 <w:r> 分割（脚本运行后行号会变化，必须重新确认），用 get_node 定位节点、完成修改后 doc.save()；
  5. 全部完成后打包：python ooxml/scripts/pack.py unpacked reviewed-document.docx；
  6. 最终校验：
pandoc --track-changes=all reviewed-document.docx -o verification.md
grep "30 天" verification.md   # 不应找到
grep "60 天" verification.md   # 应找到

输入示例：「把第 4.2 条中的『30 天』改为『60 天』，其余不变，用修订模式。」 输出说明：得到一个 .docx，其中只有「30」被标记为删除、「60」被标记为插入，句中其余文字仍是原始 run，审阅者看到的是一条干净的修订记录。

第五步：视觉核对（可选）

soffice --headless --convert-to pdf document.docx
pdftoppm -jpeg -r 150 -f 2 -l 5 document.pdf page

得到第 2~5 页的 JPEG 图片，用于确认版式、分页与表格是否错位。

代码风格提醒

技能明确要求生成的代码简洁、避免冗长变量名和冗余操作、避免不必要的打印语句——这会让脚本更容易复现和排查。

四、同类型竞品对比分析

方案名称 定位 核心功能 安装/使用门槛 适用场景 优势与不足
DOCX文档处理技能Skill（docx，ID 12731） AI 驱动的全流程文档处理技能 文本提取、XML 级读写、docx-js 创建、Document 库编辑、红线修订、批注、转图校验 需支持技能机制的环境，并安装 pandoc、docx、LibreOffice、Poppler、defusedxml 等依赖 合同修订、批量文档生成、结构分析、格式保真编辑 优势：保留修订与格式语义，流程自带校验闭环；不足：依赖较多，红线工作流需要理解 OOXML 基础概念
人工使用 Word / WPS 传统办公套件 手动编辑、手动开启修订、批注、排版 门槛最低，人人会用 单份文档的精细修改、最终定稿 优势：所见即所得，控制力最强；不足：无法批量，重复劳动多，难以让 AI 参与内容生成
python-docx 自行编程 开发者自建脚本 段落、表格、样式的读写 需要编程能力，需自行设计所有流程 固定模板的批量生成 优势：轻量、可控；不足：跟踪更改、批注、复杂结构支持有限，往往需要自己写大量 XML 处理逻辑
pandoc 命令行单独使用 通用文档格式转换器 各类格式互转，支持 --track-changes 一条命令即用，门槛低 快速阅读、格式转换、内容抽取 优势：简单可靠；不足：只能「读」和「转」，不能精细编辑，更无法生成带修订的定稿
直接把全文粘贴给通用 AI 对话 通用大模型对话 文本改写、摘要、翻译 零门槛 快速润色、摘要 优势：最快；不足：样式、批注、修订全部丢失，回填成本高，长文档容易截断

五、该技能的典型应用场景与实际体验情况

场景一：法务合同修订 角色：法务专员。痛点：对方发来一份 60 页合同，只需要改 12 处条款，但每处都必须留痕，且不能用「整段重写」的方式，否则对方审阅成本极高。使用方式：走红线工作流，先转 Markdown 通读并列出改动清单，按「定义条款」「付款条款」「违约责任」分成 3 个批次依次实现，最后用 grep 双向校验。体验：改动位置精准，未改动文本保留原 RSID，输出文档打开后修订痕迹干净，符合法律文档的严格要求；注意点是每跑完一个脚本都要重新 grep 确认行号，不能沿用上一轮的位置。

场景二：咨询/行政的批量文档生产 角色：项目助理。痛点：每周要出十几份格式统一的周报、会议纪要、验收单。使用方式：用 docx-js 写一个模板脚本，把数据填进 Document、Paragraph、TextRun 结构，Packer.toBuffer() 批量导出。体验：一次搭好模板，后续产出稳定、样式统一，比手工排版快得多；注意点是首次使用前要完整读一遍 docx-js.md，否则容易在样式继承上踩坑。

场景三：学术与研究资料审读 角色：研究人员。痛点：需要从大量 .docx 文献稿件中抽取结构与关键段落，还要看合作者留下的批注。使用方式：pandoc 转 Markdown 快速通读，遇到批注和复杂格式时解压看 word/comments.xml 与 word/document.xml。体验：结构保留得比纯文本复制好很多，批注能定位到具体位置；注意长篇文档建议分段处理，避免一次性塞入过多内容。

场景四：交付前的版式核对 角色：内容运营。痛点：文档内容改完了，但担心中文字体、表格分页在对方电脑上错位。使用方式：soffice 转 PDF，再用 pdftoppm -r 150 切成图片逐页看。体验：不需要打开 Word 就能快速确认版式；注意分辨率越高文件越大，日常核对 150 DPI 已够用。

整体上手难度：读取和转图几乎零门槛；创建文档需要一点 JavaScript 基础；红线工作流门槛最高，需要理解 <w:ins>、<w:del>、RSID 等概念，但技能文档对流程描述得相当细，按步骤走能跑通。

六、该技能能为用户带来的价值

  • 效率提升：一份几十页文档的十处修订，人工逐条定位 + 手动开修订可能要一两个小时，走红线工作流分批处理后通常能压缩到十几分钟，且重复性工作可以脚本化。
  • 降低门槛：不需要成为 OOXML 专家，也能完成「保留格式 + 保留修订」的专业级编辑；创建规范 Word 文档从「学一套库」变成「读一份说明 + 写一个脚本」。
  • 质量可量化：技能内置了校验环节——用 grep 确认原文案消失、新文案出现，并检查是否引入意外改动，把「交付前自检」从依赖人的细心变成流程的一部分，返工率明显下降。
  • 长期价值：工作流可沉淀为团队模板与脚本库，模板一次搭好、长期复用；对法务、咨询、学术等强合规场景，「必须走红线工作流」的硬性规则本身就是一种风险控制。

七、常见问题 FAQ

Q1：这个技能怎么安装？需要准备什么？ 在支持技能机制的环境中，用英文名 docx 或技能ID 12731 检索并安装（具体入口与命令以官方说明为准）。安装后还需要补齐运行依赖：pandoc、docx（npm）、LibreOffice、Poppler、defusedxml。验证方式是让它把一个带修订的 .docx 转成 Markdown，看修订和结构是否保留。

Q2：它收费吗？ 技能详情标注的授权方式为「专有」，完整条款写在 LICENSE.txt 中。是否收费、如何计费取决于官方授权说明，建议使用前先阅读许可条款，以其为准。

Q3：它和直接让 AI 改文档有什么区别？ 直接改只能拿到纯文本，样式、批注、修订痕迹都会丢，回填还得手工重排。这个技能是在 OOXML 层面操作，能保留格式、保留并生成跟踪更改、处理批注，还能在完成后用 grep 做双向校验。

Q4：适合谁用？我不会写代码能用吗？ 读取分析、转图核对这类任务，只要会描述需求就能用。创建文档和红线修订需要一点 JavaScript/Python 基础，但技能已经把流程和示例写得很细，按步骤执行即可；对法务、学术、咨询、行政等经常处理他人文档的岗位收益最大。

Q5：和 python-docx、pandoc 这些工具怎么选？ 如果只是格式转换或快速阅读，pandoc 一条命令足够；如果是固定模板的批量生成，python-docx 也很轻量。但当你需要跟踪更改、批注、格式保真，或者要处理法律、学术、商业、政府类文档时，选这个技能更合适——它把红线工作流和校验步骤都内置了，而其他工具通常要自己从零搭建。