docx（DOCX文档处理工具包）Skill 是什么？怎么用？

docx（DOCX文档处理工具包Skill）：让 AI 像文档工程师一样创建、编辑与审阅 Word 文档

一句话定位：这不是一个“能打开 Word 的插件”，而是一套围绕 .docx 文件（本质是 ZIP + XML）的完整工程化工作流，覆盖读取分析、创建、编辑、修订留痕、视觉校验全链路。
核心能力：文本提取（pandoc）、原始 XML 访问（unpack/pack 脚本）、用 docx-js 从零建文档、用 Document 库改文档、以“红线工作流”实施标准跟踪更改。
差异化亮点：把“改别人的文档必须留修订痕迹”写成了默认规范，并提供批处理、RSID 复用、最小精确编辑等可落地的操作原则。
附加价值：内置科学示意图生成思路（配合 scientific-schematics 技能与 generate_schematic.py），以及 DOCX→PDF→图片的视觉检查通道。
适合谁用：法务/合规审阅、咨询与研究写作、需要批量处理 Word 的技术团队，以及想把文档操作自动化的开发者。

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

技能中文名：DOCX文档处理工具包Skill 技能英文名：docx 技能ID：13070

它解决的是一个非常具体的痛点：Word 文档在人类眼里是“排版好的页面”，在程序眼里其实是 ZIP 归档里的一堆 XML（word/document.xml、word/comments.xml、word/media/ 等）。普通工具要么只能“读出一段纯文本”，要么只能“重写整个文档”，而一旦涉及保留格式、保留评论、保留修订痕迹，大多数自动化方案就会退化成“改完面目全非”。这个技能的价值，就是把这条从“读懂 XML”到“安全改完并打包回去”的路，固化成一套可复用的流程和规范。

“一键安装”的思路与步骤：

安装前提：需要一个可以加载 AI 技能的运行环境（技能市场、技能管理面板或对应客户端的技能入口），并具备执行 Shell 命令与 Python/Node 脚本的能力，因为该技能的多条工作流依赖命令行工具。
获取技能：在技能入口中按技能ID 13070 或英文名 docx 检索并添加。具体的安装命令、按钮位置与账号权限要求，请以官方说明为准。
补齐依赖（这一步最容易被忽略，但必须做）：技能详情明确列出了所需依赖，可按需安装——
- 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
验证是否生效：让 AI 执行一次最小任务，例如对一个测试 .docx 运行 pandoc --track-changes=all 测试.docx -o 输出.md，能正常产出 Markdown 即说明文本提取通道打通；再试一次 python ooxml/scripts/unpack.py 测试.docx 解包目录，能看到解包后的 word/ 目录，说明 XML 编辑通道可用。
开始使用：直接用自然语言描述需求（“把这份合同第 3 条的 30 天改成 60 天，并保留修订痕迹”），技能会按工作流决策树自动选择路径。

该技能的主要功能和特点

文本提取与结构保留：通过 pandoc --track-changes=all 将 DOCX 转为 Markdown，--track-changes 支持 accept / reject / all 三种模式，能直接看到修订内容，而不是被“最终版”掩盖。
原始 XML 深度访问：unpack.py 解包后可直接读取/修改评论、复杂格式、文档结构、嵌入媒体与元数据；修改完成后用 pack.py 重新打包。跟踪更改通过 <w:ins>（插入）与 <w:del>（删除）标签表达。
从零创建文档（docx-js）：用 JavaScript/TypeScript 的 Document、Paragraph、TextRun 组件构建内容，再通过 Packer.toBuffer() 导出 .docx，适合批量生成报告、模板化文档。
编辑既有文档（Document 库）：基于 Python 的 OOXML 操作库，常见操作有高级封装方法，复杂场景可直接访问底层 DOM，兼顾效率与可控性。
红线工作流（跟踪更改）：这是最核心的差异化能力。它不是“直接改”，而是先在 Markdown 层面规划改动，再分批（每批 3–10 处）落到 OOXML 修订中，改完打包并做最终验证（grep 原文应消失、grep 新文应存在、确认无意外改动）。
最小精确编辑原则：技能明确规定只标记真正变化的文本，把替换拆成「未改动文本 + 删除 + 插入 + 未改动文本」，并复用原始 <w:r> 的 RSID。这直接决定了修订稿是“专业可审”，还是“满屏红字没法看”。
视觉呈现增强：创建文档时默认建议补配科学示意图，调用 python scripts/generate_schematic.py "您的图表描述" -o figures/output.png 生成出版质量插图，输出保存在 figures/ 目录，并强调色盲友好与高对比度。
文档转图像做视觉校验：soffice --headless --convert-to pdf 再配合 pdftoppm -jpeg -r 150（支持 -f / -l 指定页码范围），把文档变成可逐页查看的图片，用于版式核对。
工作流决策树：读/分析走文本提取或 XML；新建走 docx-js；改自己的文档走基础 OOXML 编辑；改他人的文档、以及法律/学术/商业/政府文档，必须走红线工作流。

和普通工具相比，它强在两点：一是有规矩——什么场景该用哪条路径、哪些必须留痕，写得很死；二是有闭环——从解包、修改、打包到验证，流程完整，而不是只给一个 API 让你自己摸索。

如何使用该技能？

第 1 步：判断你的任务属于哪条路径。 只是想知道文档写了什么 → 走文本提取；要改自己写的文档且不需要留痕 → 走基础 OOXML 编辑；要改别人的文档或合同、论文、标书类文档 → 走红线工作流。

第 2 步：读取内容。

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

需要看评论、页眉页脚、嵌入图片时，改为解包后直接读 XML：

python ooxml/scripts/unpack.py 合同.docx 解包目录

第 3 步：创建新文档（如需要）。 按技能要求，先完整阅读 docx-js.md（约 500 行，禁止设置阅读范围限制），再用 Document / Paragraph / TextRun 组织内容，最后 Packer.toBuffer() 导出。

第 4 步：规划并分组修改。 把需求拆成 3–10 处一批的批次，按章节、按类型或按页面顺序分组。定位时用章节号、段落标识或唯一上下文文本做 grep，不要用 Markdown 行号——它和 XML 结构不对应。

第 5 步：落地修订。 每批修改前先 grep word/document.xml 确认文本当前的切分方式（一次脚本运行后行号就会变，所以必须每次重新确认），再用 Document 库的 get_node 定位并修改，最后 doc.save()。

输入示例（自然语言即可）：

“这份服务协议第 4 条把‘30 天’改为‘60 天’，签署方名称由‘甲方’统一改为公司全称，全部以修订形式呈现。”

输出说明：返回一个带跟踪更改的 .docx，在 Word 中打开可直接看到插入/删除标记，未改动文字保持原有格式与 RSID。

第 6 步：打包与验证。

python ooxml/scripts/pack.py 解包目录 审阅-文档.docx
pandoc --track-changes=all 审阅-文档.docx -o 验证.md

然后 grep 原文短语（应找不到）、grep 新文短语（应找到），并通读确认没有引入意外改动。

第 7 步（可选）：视觉检查。 先 soffice --headless --convert-to pdf 审阅-文档.docx，再 pdftoppm -jpeg -r 150 -f 2 -l 5 审阅-文档.pdf 页面，只导出第 2–5 页看版式。

同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
docx（本技能）	AI 驱动的 DOCX 工程化工作流	文本提取、原始 XML 访问、docx-js 建文档、Document 库编辑、红线修订、转图像校验	需技能环境 + pandoc/LibreOffice/Poppler/Node/Python 依赖	合同审阅、报告生成、批量文档处理	优势：修订留痕规范、闭环验证、可批量；不足：依赖较多，需具备命令行基础
Microsoft Word 手动操作	通用办公软件	可视化编辑、修订、批注、样式排版	安装即用，几乎零技术门槛	单份文档人工精修、临时小改	优势：所见即所得、直观；不足：无法批量，重复劳动多，难以自动化与审计
python-docx 等编程库	面向开发者的文档自动化	段落/表格/样式操作、基础读写	需编程能力，自己搭流程	程序化生成模板文档	优势：轻量、可控；不足：修订痕迹与评论等 OOXML 细节支持有限，格式保留容易翻车
pandoc 命令行	通用文档格式转换器	DOCX↔Markdown/PDF/HTML 等互转，支持修订显示	一条命令即可，学习成本低	内容提取、格式转换、快速预览	优势：稳定、生态成熟；不足：只“转”不“改”，无法实施精确修订或处理评论

结论式建议：只读不改用 pandoc；程序化生成用 docx-js 或编程库；必须留痕地改别人的文档，这类需求才是本技能的主场。

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

场景一：法务/合规的合同修订。 角色：法务专员。痛点：对方发来的合同要改十几处，手工改容易漏、且必须逐条留痕供对方确认。使用方式：先 pandoc --track-changes=all 出一份 Markdown 通读，再按条款分批（如“批次 1：第 3 条金额”“批次 2：第 5 条期限”）落到修订中。实际体验：技能强制“改他人文档必须走红线流程”，从机制上避免了“直接覆盖”的低级错误；最小精确编辑让修订稿干净到可以直接发给对方；注意点是批次不宜过大，否则出错难定位。

场景二：咨询/研究报告的成稿与配图。 角色：研究分析师。痛点：报告要反复套模板，还要为流程图、架构图单独找工具。使用方式：用 docx-js 搭建文档骨架，同时用 generate_schematic.py 生成工作流图、系统架构图，输出到 figures/。实际体验：一次描述即可得到出版级插图，且工具会自动迭代优化并考虑色盲友好；注意首次使用须完整读完 docx-js.md，前期投入时间换来后续稳定。

场景三：批量文档内容抽取与比对。 角色：运营或数据岗。痛点：几十份周报、标书要汇总关键信息。使用方式：批量 pandoc 转 Markdown 后做检索统计，遇到批注、表格、嵌入对象等复杂结构时切到解包读 XML。实际体验：结构保留效果好，标题层级不丢；注意 --track-changes 选 all 还是 accept 会直接影响结果口径，需先统一。

场景四：交付前的版式自检。 角色：文档工程师。痛点：内容没问题，但分页、图表位置在别人电脑上错位。使用方式：转 PDF 再转 JPEG 逐页看图。实际体验：-f / -l 指定页码范围很实用，不必整本渲染；-r 150 在清晰度与体积间比较平衡，需要更清楚可调高分辨率。

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

把“改文档”从体力活变成工程活：过去改一份合同要人工逐字核对，现在可分批脚本化实施，并在最后用 grep 做机械验证，“漏改”和“误改”都能被系统性排除。
显著降低格式返工率：最小精确编辑 + 复用原始 RSID，避免了“整段替换导致格式崩坏”这一最常见的自动化事故。
让修订稿真正可交付：跟踪更改是法律、学术、政府采购场景的硬要求，技能把它设为默认与必需路径，等于把合规要求前置到了工具层。
降低工具门槛：不需要精通 OOXML 规范，也能通过自然语言 + 少量命令完成解包、修改、打包、验证的全流程；需要深入时又能直接访问 DOM，上限不封顶。
长期价值：这套“提取—规划—分批实施—验证”的方法论可沉淀为团队标准作业流程，配合模板与示意图生成，形成可复用的文档生产线。

常见问题 FAQ

Q1：这个技能怎么安装？需要准备什么？ 在技能入口按技能ID 13070 或英文名 docx 添加，然后补齐 pandoc、docx（npm）、LibreOffice、Poppler、defusedxml 等依赖。技能本体的具体安装入口与命令以官方说明为准；依赖安装命令在技能详情中有明确给出，可直接照抄。

Q2：收费吗？ 技能详情标注许可证为“专有”，LICENSE.txt 中包含完整条款。具体授权范围与是否收费请以该许可证和官方说明为准。

Q3：它和直接用 python-docx 有什么区别？ 区别在“规范”和“闭环”。python-docx 给你操作对象，剩下全靠自己；本技能额外规定了工作流决策树（什么文档必须走红线流程）、批处理粒度（3–10 处一批）、最小精确编辑原则，以及打包后的验证动作（grep 原文/新文）。简单说，前者是零件，后者是带质检的产线。

Q4：适合谁用？我完全不会写代码能用吗？ 适合法务、研究、咨询、文档工程与需要批量处理 Word 的开发者。可以用自然语言驱动，技能会自动调用脚本；但如果要精细控制修订节点，了解一点 XML 结构和命令行会更顺手。

Q5：改完的文档格式会不会乱？ 技能明确要求只标记实际变化的文本，未改动部分复用原始 <w:r> 元素与 RSID，并对每批改动单独测试，最后还要做整篇验证。按要求操作，格式稳定性是这套流程的强项；反之，如果跳过验证步骤直接交付，风险需自行承担。