DOCX文档创建与编辑技能：让 AI 像专业文档工程师一样处理 Word 文件
- 它解决什么问题：把「Word 文档的创建、编辑、审阅、分析」这类原本需要人工反复操作的工作，交给 AI 按标准化工作流来完成，并且能保留格式、支持跟踪更改与评论。
- 核心工作流：读取分析用 pandoc 转 Markdown；新建文档用 docx-js；编辑现有文档用 OOXML 文档库；审阅他人或法律/学术/商业/政府文档时，默认走「红线工作流」（跟踪更改）。
- 差异化亮点：它不是简单「改写一段文字」，而是直接操作 .docx 底层的 XML 结构，能精确到只标记真正变化的字符，让修订记录干净、专业、可审阅。
- 适用范围：合同审阅、报告生成、批量文档处理、文档结构分析、文档视觉审查（转图片）等。
- 安装门槛：技能本身通过技能市场/技能ID 12509 一键装配，但运行前需准备好 pandoc、docx、LibreOffice、Poppler、defusedxml 等依赖，具体以官方说明为准。
该技能叫什么？如何一键安装 AI 技能提升开发效率？
这个技能的中文名是 DOCX文档创建与编辑技能Skill，英文名（也是调用时使用的技能标识）是 docx，技能 ID 为 12509。
它面向的是这样一类高频痛点：.docx 文件看起来「只是个文档」，本质上却是一个包含 XML 文件与其他资源的 ZIP 存档。普通人想批量改几十份合同、想给一份别人的方案加修订批注、想把一份文档转成图片做视觉排版检查，往往只能在 Word 里手工一遍遍点。而通用大模型对话窗口里直接让它「改一下这份文档」，结果常常是格式丢失、修订记录混乱、甚至改错位置。
docx 技能的价值在于：它把「解包 → 定位 → 精准修改 → 打包 → 验证」这一整套专业文档工程流程，封装成 AI 可以直接执行的标准化工作流。你不再需要描述「怎么改」，只需要说明「改成什么」，剩下的由技能按既定规则落地。
一键安装的思路与步骤
第一步：确认安装前提。 你需要一个支持「技能（Skill）」机制的 AI 助手运行环境（例如支持 Skills 的 Claude 环境），并具备基本的命令行执行能力。技能本身是文档处理能力层，真正干活的是它调用的工具链，因此还需要准备依赖项（详情中给出的必需依赖，若环境已具备可跳过）：
- 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
第二步：装配技能。 在技能市场或技能管理入口中搜索英文名 docx，或直接通过技能 ID 12509 定位并添加该技能。具体的装配命令、入口路径与账号权限要求，请以官方说明为准。技能授权方式为专有许可，完整条款见随技能提供的 LICENSE.txt。
第三步：验证是否生效。 装配完成后，不要直接上复杂任务，先用一句轻量指令试探，例如：「帮我读取这份 .docx 的正文内容，并告诉我它的章节结构。」如果技能被正确触发，你会看到它调用 pandoc 转换（或解包读取 XML）的过程，并返回结构化的文本结果。若没有任何工具调用、或提示缺少依赖，说明技能未生效或依赖未装好。
第四步：小任务跑通再放大。 建议先用一份无关紧要的文档做一次「创建新文档」和一次「简单替换」测试，确认打包后的 .docx 能被 Word 正常打开、格式没有错乱，再投入正式业务文档。
该技能的主要功能和特点
- 全面的文档生命周期覆盖：创建新文档、修改或编辑内容、处理跟踪更改、添加评论，以及任何其他 .docx 相关任务，都在能力范围内。
- 智能工作流决策树：技能内置分诊逻辑——只读内容走文本提取，新建走 docx-js，改自己的文档且改动简单走基础 OOXML 编辑，改他人文档走红线工作流，法律、学术、商业或政府文档则强制走红线工作流。用户无需自己判断该用哪套方法。
- 格式保留能力强：通过直接操作 OOXML 层级，而非「重新生成一篇文档」，最大限度保留原有样式、编号、嵌入媒体与元数据。
- 精确到字符的跟踪更改：这是它区别于普通改写工具的关键。技能明确要求「最小化、精确编辑」——只标记真正变化的文本，未改动部分保留原始
<w:r>元素与 RSID。示例中把「30 天」改成「60 天」，正确做法是只对30与60做删除/插入标记，其余文字原样保留，而不是把整句话删掉重写。 - 批处理策略，避免一次性崩盘：将相关修改按 3–10 个一组分批实现，每批测试通过再进入下一批，把调试范围控制在可管理粒度内。
- 定位方法有章可循：用章节/条款编号、段落标识、唯一上下文文本的 grep 模式、文档结构（如「第一段」「签名块」）来定位，并明确禁止使用 Markdown 行号（因为它不映射 XML 结构）。
- 可读性与可验证性并重：先用 pandoc 把文档转成 Markdown 做整体审阅与计划，改完再转一次 Markdown 做最终验证，用 grep 检查「原始短语应消失、替换短语应出现」，并排查是否引入意外改动。
- 支持评论与原始 XML 深度访问：需要处理评论、复杂格式、文档结构、嵌入媒体和元数据时，可解包后直接读取
word/document.xml、word/comments.xml、word/media/等关键文件。 - 可做视觉分析：通过 LibreOffice 转 PDF、再用 pdftoppm 以指定 DPI 与页码范围转 JPEG/PNG，让 AI 能「看」文档的实际排版效果。
- 代码风格有约束：生成 DOCX 操作代码时要求简洁、避免冗长变量名与冗余操作、避免不必要的打印语句，减少噪音输出。
如何使用该技能？
下面按典型任务给出分步骤指南，可直接参考。
场景 A：只想知道文档写了什么（读取与分析）
- 直接描述需求，例如：「把
合同草案.docx转成 Markdown，保留跟踪更改，我要通读一遍。」 - 技能会执行
pandoc --track-changes=all 文件路径.docx -o 输出.md，其中--track-changes支持accept、reject、all三种模式，审阅场景通常用all。 - 你会得到保留文档层级结构的 Markdown 文本，插入与删除痕迹一并呈现。
场景 B：从零创建一份新文档
- 说明结构要求，例如：「生成一份项目周报 .docx，含标题、三段正文、一个要点列表。」
- 技能会先完整通读
docx-js.md（约 500 行，且明确要求不设阅读范围限制），再编写 JavaScript/TypeScript 文件，用 Document、Paragraph、TextRun 等组件组织内容，最后以Packer.toBuffer()导出为 .docx。 - 输出即为可直接用 Word 打开的文件。
场景 C：编辑自己拥有、改动简单的文档
- 解包：
python ooxml/scripts/unpack.py <office_file> <output_directory> - 使用文档库（用于 OOXML 操作的 Python 库）编写脚本，该库自动处理基础设施设置，常见操作有高级方法，复杂场景可直接访问底层 DOM。
- 打包：
python ooxml/scripts/pack.py <input_directory> <office_file>
场景 D：审阅他人的文档（红线工作流，推荐默认）
- 先转 Markdown 通读：
pandoc --track-changes=all 文件路径.docx -o current.md，据此列出所有需要修改之处，并按章节、类型或页序分成每批 3–10 项的批次。 - 完整阅读
ooxml.md（约 600 行，重点看「文档库」与「跟踪更改模式」两部分），然后解包文档，并记下解包脚本建议的 RSID，后续标记修订时使用。 - 逐批实施：每批开始前先用 grep 在
word/document.xml中确认目标文本被拆分在哪些<w:r>元素里（每次脚本运行后行号都会变化，所以必须现改现查），再用get_node找到节点、实施修改、doc.save()保存。 - 打包回文档：
python ooxml/scripts/pack.py unpacked reviewed-document.docx - 最终验证：把成品再转一次 Markdown，用
grep "原始短语"确认原句已不存在、grep "替换短语"确认新句已存在，并通读检查有无意外改动。
场景 E：需要「看」文档排版
soffice --headless --convert-to pdf document.docxpdftoppm -jpeg -r 150 document.pdf page，生成page-1.jpg、page-2.jpg等文件。- 可按需调整参数：
-r 150控制分辨率以平衡质量与体积，-jpeg换成-png可输出 PNG，-f 2 -l 5只转换第 2 至第 5 页。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| docx 技能（本技能） | AI 驱动的 .docx 全流程处理工作流 | 创建、编辑、跟踪更改、评论、文本提取、转图片、原始 XML 访问 | 需支持 Skills 的环境，并准备 pandoc、docx、LibreOffice、Poppler、defusedxml 等依赖 | 合同红线审阅、批量文档处理、报告生成、文档结构分析 | 优势：格式保留好、修订记录精准、有决策树与验证闭环；不足：依赖本地工具链，初次配置有一定门槛 |
| Microsoft Word 手工编辑与审阅 | 传统桌面文档编辑器 | 所见即所得编辑、修订模式、批注、样式管理 | 安装 Office 客户端即可，几乎无学习成本 | 单人精修排版、正式发文定稿 | 优势：排版控制最直观、生态成熟；不足：无法批量自动化，长文档多点修改耗人力，难以让 AI 直接接管 |
| 通用文档编程库（如 Python 的 docx 类库） | 面向开发者的文档自动化工具 | 以代码方式读写段落、表格、样式 | 需具备编程能力，自行搭建脚本与异常处理 | 固定模板的批量生成、数据填充 | 优势：可编程、可集成到流水线；不足：跟踪更改与复杂 OOXML 场景支持弱，格式易跑偏，需自己写大量胶水代码 |
| 在线协作文档（如云端文档平台） | 多人实时协作与评论 | 实时协同编辑、评论、版本历史 | 浏览器即用，零安装 | 团队并行撰写、快速评审 | 优势：协作体验好、上手最快；不足：对本地 .docx 的格式还原与底层修订保真度有限，涉密文档存在合规顾虑 |
| 无技能的通用大模型对话 | 纯文本层面的内容生成 | 改写、润色、总结 | 打开对话窗口即可 | 灵感起草、文字润色 | 优势：门槛极低；不足：无法真正操作 .docx 文件，格式与修订记录无法保证，容易把「整句重写」当成「精准修改」 |
该技能的典型应用场景与实际体验情况
场景一：法务人员的合同红线审阅。 法务拿到对方发来的合同稿，需要在保留原格式的前提下逐条标记修改并回传。痛点是手工修订几十处条款极易遗漏，且对方需要清晰看到「改了什么」。使用本技能时，先把文档转 Markdown 通读并列出全部待改点，分批用跟踪更改实现，最后用 grep 做双向验证。实际体验：上手难度中等，需要理解 RSID 与 <w:ins>/<w:del> 标签的概念；效果上修订痕迹干净、只标记真正变化的字符，专业度明显高于「整句删除再重写」；注意事项是必须逐批测试，且每写脚本前都要重新 grep 确认当前 XML 结构。
场景二：行政与市场团队的标准化文档生成。 周报、项目计划、活动方案往往结构固定、内容变动。痛点是每次复制旧文档改内容容易残留上一版信息。使用本技能走 docx-js 路径，用 Document、Paragraph、TextRun 组件从零构建，通过 Packer.toBuffer() 导出。实际体验：上手最友好的路径，因为不涉及修改既有 XML；效果稳定、样式统一；注意事项是必须先完整阅读 docx-js.md 再动手，跳过这一步容易在格式规则上踩坑。
场景三：知识管理与内容分析。 研究人员或运营需要快速消化几十份文档，提取结构与要点。痛点是逐个打开阅读效率太低。使用本技能调用 pandoc 转 Markdown，保留层级、表格与跟踪更改。实际体验：几乎零门槛，一句指令即可；输出结构清晰，可直接用于后续摘要或检索；注意事项是纯文本提取不包含版式信息，若关心排版就需要走转图片路径。
场景四：排版质检与视觉核对。 需要确认最终稿的分页、图表位置是否正常。痛点是打开 Word 逐页翻看，且难以截取给他人确认。使用本技能先转 PDF 再转 JPEG，按需指定 DPI 与页码范围。实际体验：上手简单，两条命令即可；配合视觉分析能发现纯文本提取看不到的问题；注意事项是分辨率要按用途调整，过高会让图片体积膨胀。
该技能能为用户带来的价值
把「会写代码」这件事从文档处理中拿掉。 过去要让 AI 批量处理 Word，用户往往得自己写脚本、自己处理 OOXML 的坑。现在技能内置决策树，明确什么任务走哪条路，用户只需描述目标。
把「改动是否可信」变成可验证的流程。 技能要求改完必须转 Markdown 回验、用 grep 做正反双向检查。这意味着 AI 的每一次修改都有证据链，而不是「它说改好了」。
把修订记录做到可交付的专业水准。 只标记实际变化的文本、保留未改动内容的原始运行元素与 RSID，这些细节直接决定了对方打开文档时的观感。在合同、公文、学术稿件这类场景里，这种专业度本身就是价值。
用批量策略压缩返工成本。 每批 3–10 项、逐批测试的机制，把「一次大改出错重来」变成「小步快跑即时纠偏」，长文档处理的时间可预期性大幅提升。
长期价值在于流程资产化。 一旦某类文档的红线审阅流程跑通，它就可以被重复调用到后续每一份同类文档上，边际成本持续下降。
常见问题 FAQ
Q1：这个技能怎么安装？需要付费吗？ 在支持技能机制的环境里，用英文名 docx 或技能 ID 12509 定位并装配即可，随后按需安装 pandoc、docx、LibreOffice、Poppler、defusedxml 等依赖。技能采用专有许可，完整条款见随附的 LICENSE.txt；具体的获取方式、是否收费与授权范围，请以官方说明为准。
Q2：它和直接在对话里让 AI 改 Word 有什么区别？ 直接对话通常只能处理「文本层面」，容易丢失格式，也很难生成规范的跟踪更改。本技能会真正解包 .docx、定位到 XML 节点、按最小化原则标记修订，再打包回文档并做验证，属于工程级处理，并未停留在改写层面。
Q3：适合谁用？不会写代码能用吗？ 适合法务、行政、市场、研究、产品等需要频繁处理 Word 文档的角色，也适合做文档自动化的开发者。读取分析、创建新文档、转图片这几类任务基本一句话即可触发，不需要写代码；但红线审阅场景涉及 XML 细节，理解能力越强，效果越稳。
Q4：为什么改别人的文档一定要用「红线工作流」？ 因为他人文档的格式、版本和权属都不在你掌控内，直接改正文既不可追溯，也容易引发争议。红线工作流会以跟踪更改的形式呈现每一处修改，对方的文档可原样恢复，这是专业协作的基本要求。法律、学术、商业、政府文档更是强制要求走这条路径。
Q5：改完之后怎么确认没有问题？
按技能内置的最终验证步骤：先把成品转成 Markdown，用 grep 检查「原始短语」应找不到、「替换短语」应能找到，再通读一遍排查是否引入了意外改动。这一步不建议省略。