DOCX文档处理工具Skill：让 AI 精准创建、编辑与红线审阅 Word 文档
- 它是什么：
docx是一个面向.docx文件的专业文档工具包，覆盖新建文档、编辑现有文档、跟踪更改（红线）、评论、格式化保留与文本提取全流程。 - 核心思路：把
.docx当作由 XML 组成的 ZIP 归档来处理，既能用高级库做常规操作，也能深入原始 XML 处理评论、复杂格式与嵌入媒体。 - 最适合谁：需要审阅他人合同/报告的法务与咨询人员、要批量提取文档内容的数据分析者，以及希望把 Word 处理自动化的开发者。
- 最大亮点：内置「红线工作流」，可以在 markdown 中先规划改动，再以最小化、精确的跟踪更改写回文档，改完还能验证有没有误改。
- 额外加分：可联动 scientific-schematics 技能，为文档自动生成出版级科学示意图，让图文表达一次到位。
该技能叫什么？如何下载安装 AI 技能提升开发效率？
这个技能的中文名是 DOCX文档处理工具Skill，英文名是 docx，技能 ID 为 13097。它解决的核心痛点是：Word 文档表面上是「一个文件」，实际上是一个包含大量 XML 与资源的压缩包，人工用图形界面做批量修改、精确修订、结构提取时既慢又容易破坏格式。该技能把这些操作沉淀为可复用的工作流与脚本命令，让 AI 能像专业文档工程师一样处理 Word 文件。
它主要解决四类问题：一是从文档中稳定提取文本与结构；二是从头创建规范的新文档；三是在他人文档上做可审计的修订（跟踪更改 + 评论）；四是对文档做视觉化检查与格式保留。
一键安装 AI 技能的整体思路：在支持该技能的 AI 客户端或平台中，通过技能市场/技能列表搜索英文名 docx 或技能 ID 13097 完成添加，随后在对话中直接调用。具体的安装入口、命令与账户要求，请以官方说明为准。
安装前提与环境依赖：该技能在运行时会调用若干外部工具，官方详情中列出的依赖及安装命令如下（按需安装即可）：
- pandoc（文本提取）：
sudo apt-get install pandoc - docx（创建新文档）：
npm install -g docx - LibreOffice（DOCX 转 PDF）：
sudo apt-get install libreoffice - Poppler（PDF 转图片）：
sudo apt-get install poppler-utils - defusedxml（安全解析 XML）：
pip install defusedxml
如何验证是否生效：安装完成后，先用一个简单任务做冒烟测试，例如让它「用 pandoc 把某个 .docx 转成 markdown 并保留跟踪更改」。如果能正常返回结构清晰的 markdown 内容，说明文本提取链路已通；再让它「解包一个 .docx 并列出 word/document.xml、word/comments.xml 等关键文件」，能返回目录结构即说明 XML 访问链路正常。
许可证提醒：该技能为专有许可，LICENSE.txt 中包含完整条款，商用前建议先阅读确认使用边界。
该技能的主要功能和特点
- 文本提取与结构保留：通过 pandoc 将文档转为 markdown，支持
--track-changes=all/accept/reject三种模式，能把修订痕迹一并带出来，便于审阅。 - 原始 XML 深度访问：评论、复杂格式、文档结构、嵌入媒体和元数据这些「图形界面看得到但抓不出」的内容，可通过解包后读取
word/document.xml、word/comments.xml、word/media/获取。 - 新建文档（docx-js）：用 JavaScript/TypeScript 的 Document、Paragraph、TextRun 组件搭建文档，再用
Packer.toBuffer()导出为.docx，适合批量生成格式统一的文档。 - 编辑现有文档（Document 库）：基于 Python 的 OOXML 操作库，常见操作有高级方法，复杂场景可直接访问底层 DOM。
- 红线工作流（跟踪更改）：这是最有差异化的能力。先在 markdown 中规划全部改动，再分批（每批 3–10 个改动）写回 OOXML，用
<w:ins>与<w:del>标记增删。 - 最小化精确编辑原则：只标记真正变化的文本，未改动部分复用原始
<w:r>与 RSID。比如把「30 天」改成「60 天」，只把30标为删除、60标为插入，而不是整句替换——这让修订稿读起来专业、好审。 - 文档转图像做视觉分析：先用
soffice --headless --convert-to pdf转 PDF，再用pdftoppm -jpeg -r 150转成逐页 JPEG，可指定页码范围。 - 科学示意图联动：创建文档时可调用 scientific-schematics 技能，用
python scripts/generate_schematic.py "图表描述" -o figures/output.png生成色盲友好、高对比度的出版级示意图。 - 工作流决策树：按「读/建/改」分流；改文档时再按归属分流——自己的文档做简单改动走基本 OOXML 编辑，他人的文档以及法律、学术、商业、政府文档必须走红线工作流。
和普通工具相比，它强在「懂文档的内部结构」：不是把 Word 当纯文本读写，而是在 XML 层面保证格式不丢、修订可追溯、评论不失效。
如何使用该技能？
第 1 步：判断任务属于哪条路径。 读内容 → 走文本提取或原始 XML；建新文档 → 走 docx-js；改文档 → 判断归属，他人的或正式的文档一律走红线工作流。
第 2 步：读文档先做文本提取。
让它执行 pandoc --track-changes=all 文件.docx -o current.md，得到带修订痕迹的 markdown 底稿。需要评论、复杂格式或媒体时，改为解包：python ooxml/scripts/unpack.py <office_file> <output_directory>。
第 3 步（创建场景）：先读规范再动手。
官方要求强制完整阅读 docx-js.md（约 500 行），且读取时不要设置范围限制。读完后用 Document/Paragraph/TextRun 写脚本，Packer.toBuffer() 导出。
第 4 步（编辑场景）：分批实现跟踪更改。
先完整阅读 ooxml.md（约 600 行），重点关注「Document Library」与「Tracked Change Patterns」；解包后记下脚本建议的 RSID；然后按节、按类型或按位置把改动分成 3–10 个一批，每批跑完先验证再进下一批。定位时用章节号、段落标识、grep 特征串，不要用 markdown 行号，它不映射到 XML。
第 5 步：打包并验证。
执行 python ooxml/scripts/pack.py <input_directory> <office_file> 生成成品，再转成 markdown 做终检：grep 原文短语应找不到、grep 新短语应能找到，同时确认没有引入非预期改动。
第 6 步（可选）：视觉校验与配图。 需要看排版效果时，转 PDF 再转图片；需要配图时，用自然语言描述生成示意图。
一次典型调用的输入示例：
「这是一份服务协议，请用红线工作流把付款周期从 30 天改成 60 天，把乙方名称统一为『某某科技有限公司』，并为付款条款加一条评论说明依据。改完给我修订稿和一份改动清单。」
输出说明：会得到一个带跟踪更改的 reviewed-document.docx、一份用于核对的验证用 markdown，以及逐条列出的改动位置说明（章节、原文、新文、改动类型）。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| docx（本技能） | AI 驱动的专业 Word 文档处理工具包 | 创建、编辑、跟踪更改红线、评论、格式保留、文本提取、转图像、示意图联动 | 需安装 AI 技能及 pandoc、docx、LibreOffice、Poppler、defusedxml 等依赖 | 合同审阅、报告批量生成、结构化提取、自动化文档流水线 | 优势：修订精确可审计、能深入 XML 处理评论与媒体、决策树给出明确方法论；不足：需一定命令行与 OOXML 认知，首次配置依赖较多 |
| Microsoft Word / WPS 手动操作 | 图形界面办公软件 | 编辑、批注、修订、排版、打印 | 装软件即用，几乎零门槛 | 单人日常文档编辑 | 优势：所见即所得、上手最快；不足：批量任务靠人力，跨文档统一改法费时，难以脚本化与自动化 |
| python-docx 等原生库 | 面向开发者的文档操作库 | 段落、表格、样式读写 | 需写代码，熟悉库 API | 程序化生成与轻度编辑 | 优势：轻量、免费、可控；不足：跟踪更改与评论等复杂特性支持有限，深度操作仍需手写 XML |
| pandoc 命令行 | 通用文档格式转换器 | 多种格式互转、保留跟踪更改 | 一条命令即可，门槛低 | 文本提取、格式迁移 | 优势：转换质量高、结构保留好；不足：偏「转换」而非「修订编辑」，创建与评论能力弱 |
从上表可以看出：如果你只是改一份文档，Word 最快；如果你要写程序批量生成，python-docx 够用；而当你需要一份带真实修订痕迹、可供他人审阅的正式文档，或者需要在一批文档上执行一致的内容操作时，docx 技能的方法论与工具链组合优势最明显。
该技能的典型应用场景与实际体验情况
场景一：法务合同审阅（甲方律师 / 法务专员）
痛点：对方发来的合同需要逐条标注修改，手工修订容易漏改，且必须留下可追溯的痕迹。使用方式：走红线工作流，先 pandoc --track-changes=all 得到 markdown 底稿，列出全部改动并分批（如「批次 1：付款条款」「批次 2：违约责任」），每批用 Document 库的 get_node 定位后写回，最后打包并 grep 验证。
实际体验：改动位置一旦找对，写回非常稳；<w:ins>/<w:del> 生成的修订在 Word 里打开就是标准红线，审阅方接受度很高。注意事项是每跑完一次脚本，word/document.xml 的行号会变化，必须在写脚本前立刻重新 grep 确认，否则容易定位失败。
场景二：咨询/研究报告制作（咨询顾问、研究员）
痛点：报告里大量流程与架构靠文字描述，读者难以理解，配图又要另找工具。使用方式：用 docx-js 搭建文档骨架，同时描述需要的流程图，调用 python scripts/generate_schematic.py "描述" -o figures/output.png 生成示意图，再插回文档。
实际体验：从「只有文字」到「图文并茂」的路径很短，示意图会经过多轮自审优化并考虑色盲友好与对比度。注意首次要让 AI 完整读完 docx-js.md，否则容易在样式与编号上踩坑。
场景三：批量文档内容提取（数据分析师、知识管理者）
痛点：几十上百份 Word 报告需要提取正文与修订信息做统计分析，手工复制粘贴不现实。使用方式：统一用 pandoc 转 markdown，按需选择 --track-changes=accept/reject/all；需要评论或元数据时改为解包读 XML。
实际体验：结构保留效果明显好于「全选复制」，标题层级和表格基本能还原。注意不同来源文档的样式差异较大，建议先抽样两三份验证，再批量跑。
场景四：文档视觉与版式校验（排版、设计、交付前检查）
痛点：只看 XML 看不出实际渲染效果，漏页、错位、图片丢失难以发现。使用方式：soffice --headless --convert-to pdf 转 PDF，再用 pdftoppm -jpeg -r 150 -f 2 -l 5 只转关键页，逐张检查。
实际体验：按页范围转换非常实用，既能控制检查粒度又不浪费算力；-r 参数可按需调整，在清晰度与文件大小间取平衡。
总体上手评价：功能覆盖面广但分层清晰，简单任务（提取文本）几乎零学习成本，复杂任务（红线修订）需要一点耐心读规范。最重要的三条注意事项：完整读完 docx-js.md 与 ooxml.md 再动手；坚持最小化精确编辑，不要整句替换；坚持分批实现与逐批验证。
该技能能为用户带来的价值
效率层面：把「打开文档—逐处查找—手动改—检查格式」的线性人工流程，变成「规划改动—批量写回—脚本验证」的可复用流程。改动以 3–10 个为一批并行推进，配合 grep 式终检，避免了反复肉眼比对的隐性耗时。
质量层面：跟踪更改做到「只标真正改的字」，未改动文本保留原始 RSID，修订稿干净专业；同时因为直接操作 XML，评论、嵌入媒体、复杂格式这些容易被工具「吃掉」的内容得以完整保留。
门槛层面：把 OOXML 这类偏底层的知识封装成决策树与固定工作流——「读/建/改」三分支、他人文档走红线、法律学术商业政府文档必须走红线。使用者不需要成为 OOXML 专家，也能产出符合专业审阅要求的文档。
长期价值：这些命令与脚本可以沉淀为团队的标准作业流程，用于合同模板批量生成、报告统一排版、历史文档结构化归档等重复性工作；配合示意图生成能力，还能让文档表达从「能看懂」升级到「看得舒服」。
常见问题 FAQ
Q1：这个技能怎么安装？安装完还要做什么？
在支持技能的 AI 客户端或平台中搜索英文名 docx 或技能 ID 13097 添加即可，具体入口与步骤以官方说明为准。添加后建议补齐依赖：pandoc、docx（npm 全局）、LibreOffice、Poppler、defusedxml，再用「提取一份 .docx 的文本」做冒烟测试验证链路是否打通。
Q2：它是免费的吗？
官方详情标注为专有许可，LICENSE.txt 中包含完整条款。是否收费、如何授权、能否商用，请以官方说明与许可证条款为准，商用前务必先阅读。
Q3：适合谁用？我不会写代码能用吗？ 最适合三类人：需要审阅他人 Word 文档并留痕的法务/咨询/学术人员、需要批量处理文档的内容与数据岗位、以及想把文档操作自动化的开发者。不会写代码也能用——你可以直接用自然语言描述需求，由 AI 生成并执行脚本；但完全不懂命令行的话，首次配置依赖会比较吃力。
Q4：为什么强调「他人的文档必须走红线工作流」？ 因为红线工作流是唯一能保证改动可追溯、可被对方逐条接受或拒绝的方式。自己的文档做简单改动可以走基本 OOXML 编辑；但法律、学术、商业、政府类文档在详情中被明确要求必须走红线，否则会丢失审阅价值。
Q5：和直接用 Word 修订、或 python-docx 比，怎么选？
单份文档、改动零散、需要即时看效果——直接用 Word 最快。写程序批量生成、很少涉及修订——python-docx 类库足够。需要一份带标准跟踪更改、含评论、格式完整保留且可供他人审阅的正式文档——选 docx 技能更合适，它把「怎么改才专业」的方法论也一起给了。