Office Word

# Office Word

本模块是 `lark-doc` 路由到本地 Word 后的执行入口。上层已经根据用户输入和交付要求决定进入 Office Word；这里不重新判断在线或本地。先识别每个输入的用途，再进入读取、新建或编辑链路。上游内容只有带有完整读取范围和源定位证据时才可直接复用；上游摘要不能替代附件原文。

> ⚠️ **先读完再动手**：本文档共 232 行，单次 Read 可能读不完；没见到末行「全文完」标记＝没读完，必须调整 offset 续读直到该标记。

## 权威经验

- 读取可以作为写入前置阶段重复执行。
- 用户附件必须逐一盘点；完整提取结果可以落盘，只把当前任务需要的证据载入上下文。
- 不预先读取无关参考目录，不把参考文件的渐进加载规则用于跳过用户附件。
- 要求的结构读取或全页渲染不可用、失败或结果不完整时，不得声称已经通过；先尝试修复，仍无法完成则报告阻塞。

## 一、场景路由

先识别每个输入是目标文档、可编辑模板、内容来源还是格式参考，再按最终交付物判断新建或编辑。读取不是与创建、套模板或编辑互斥的分支。

| 场景路由 | 对应分支（必读）|  详细说明 |
| --- | --- | --- |
| 读取 Word | [二、读取 Word](#二读取-word) | 可以获取 Word 的内容和结构信息 |
| 新建 Word | [三、新建 Word](#三新建-word) | 用户提供模板新建以及无模板新建 |
| 修改 DOCX| [`docx-editing.md`](references/workflows/docx-editing.md) | 用户要求修改所提供 DOCX 并交回修改稿 |
| 修改 DOCX（本地打开）| [`local-docx-editing.md`](references/workflows/local-docx-editing.md) | 用户要求修改宿主已打开的本地 DOCX，回写目标为原路径 |


路由时应注意：
- **本地打开判定**：`<system-reminder>` 中同时出现 `<information>` 声明该路径 + `<type>lark_doc</type>` + `<file_path>` 为本地 `.docx` 绝对路径时命中「本地打开」，走 `local-docx-editing.md`；缺一即不适用，走 `docx-editing.md`。
- 只要用户的修改意图能唯一指向所提供的 DOCX，并希望交回该文档的修改稿，就进入上述两个编辑流程之一；不要因用户没有说“本地路径”或“在原文件上修改”而默认重建。
- 用户明确要求新建、把附件作为模板填入一套新内容、仅把附件作为格式参考，或需要重写绝大多数主体内容时，进入`三、新建 Word`。
- 多个 DOCX 无法唯一确定目标，或“修改原稿”和“按其另建”会导致实质不同的交付物时，先澄清；其余小歧义按保守、少改动的方向处理。
- 用户要局部修改旧版 `.doc` 时，先取得经过结构和全页视觉比对的 `.docx` baseline，再按上述判定进入对应编辑流程；只有无法可靠转换或用户要求重建时才进入新建。
- 同一任务可以先读取多个 Word 输入，再进入一个新建或编辑 workflow。多个交付物分别路由并使用独立临时子目录；各自所需的证据、计划及 `SOURCE_DOCX/TARGET_DOCX` 不得跨交付物共用。

### 附件前置处理

用户提供附件时，在路由阶段就在任务临时目录初始化 `attachment_purpose.md`，并随读取和规划持续更新。每份附件占一行，不能静默忽略：

| ID | 附件与角色 | 完整读取证据 | 源定位 | 必须使用的信息或格式 | 目标位置 | 状态、未采用理由或缺口 |
|---|---|---|---|---|---|---|
| `A1` | `<file + target/template/content/style/reference>` | `<pages/sheets/stories + inspected modalities>` | `<page/section/table/cell/object>` | `<facts/structure/image/table/style>` | `<待映射或具体位置>` | `<采用/不采用/待核及理由>` |

- 一个附件可以有多个角色。只有可复制为目标 DOCX 的可编辑 Word 文件才能作为后续填写底稿；PDF、图片或其他不可编辑附件是格式参考，不能伪装成 `SOURCE_DOCX`。
- “完整读取”是覆盖该格式中与任务相关的文本、表格、图片、图表、公式、批注、页眉页脚或其他适用对象，并保留源定位。PDF 等分页附件须结合语义/结构提取与全部页面的视觉检查；截图和纯文本互相不能替代。
- 目标 DOCX 或可编辑模板的完整读取还必须包括结构检查和全部页面渲染；在新建或编辑分支的相应步骤中完成，并保存源文件的结构与视觉结果作为后续差异比较的 baseline。
- 只有上游记录包含读取范围、适用对象和源定位时才视为已经完整读取；只有摘要、纯文本或局部摘录时必须回到源附件补齐。
- `attachment_purpose.md` 是证据索引，不是替代附件的摘要。后续写入具体内容前必须按其中的源定位回读原附件或无损提取结果。
- 除非用户明确要求裁剪、摘取或转换，附件中的图片、表格和公式写入 Word 时须保留所选对象的全部信息；图片保持原始宽高比，不重编码时优先复用原始文件，可以等比缩放。
- **规划检查点**：路由前登记每份附件及其角色；选择写作类型和内容结构前完整读取内容来源。模板和目标 DOCX 在对应分支冻结后完成结构与视觉深读，未深读不得写 `template-plan.md` 或写入 Word。
- **写入检查点**：完成大纲或修改计划后补齐每个相关证据的目标位置。存在未读取附件、未解释的读取缺口或未映射的必用证据时，不得写入 Word。

## 二、读取 Word

直接编写必要代码（如 `python-docx`、`lxml`）读取任务所需的完整内容和结构；不能用纯文本提取替代版式、对象或 OOXML 证据。

## 三、新建 Word

**核心顺序：理解需求确认类型 → 规划内容与格式 → 生成 Word → 交付验收**
> ⚠️ **禁止**使用外部工具或者 skill 校验本次生成的 Word 文件，如`artifact-preview`，`verifier-hub`，**必须**使用本文提供的「交付验收」流程进行校验。

### Step 1 · 理解需求确认写作类型

- **理解用户任务**：确定核心写作类型，确定写作目的、作者或主体、主要读者、交付物，以及用户明确要求和排除项。写作类型决定文档应包含的内容、主体结构和表达方式，也决定下一步需要从附件或外部来源补充哪些信息。同时，尝试理解用户可能的 profile，以确定后续的写作风格。
- **先处理用户模板**：
  - 用户明确指定的可编辑 DOCX 模板是最高优先级底稿。记录唯一文件路径、模板来源和用户要求的使用方式。
  - PDF、图片或其他附件只能作为格式参考时，记录需要遵循的具体版式特征，后续从零创建；不得声称已在模板副本中填写。
  
- **再确定写作类型和内置模板**：
  - 读取 [`writing-taxonomy.md`](references/style/writing-taxonomy.md)，结合用户要求和已经完整读取的附件选择一个体裁，并按需读取对应指南。
  - 只有任务与指南中的内置模板适用边界明确匹配时才使用内置模板；取得并记录唯一模板文件路径和命中理由。近似模板只作参考，不作为填写底稿。
  - 纯模板填充或简单信息处理不重新设计体裁；写作指南只能补充模板未规定的内容规则，不能覆盖用户要求或模板结构。

- **控制推断范围**：只对不改变事实、附件角色、模板边界和交付范围的低风险细节采用保守默认。姓名、日期、文号、数据、修改范围或模板用途不明确时，使用占位符。
- **判断任务是否为强附件和信息遵循类型**：判断用户的指令是否为根据用户给定信息或附件写作，且体裁类型为公文、论文、法律、科研等严谨、严格要求信息准确的场景。
- **多产物处理**：多个独立交付物分别选择类型；单个交付物只使用一个写作类型规则。
- **默认不打断，能推测就直接做**：需求不完全明确时，优先按合理默认推进，不要为小问题反复发问。只有确实无法推进的硬阻塞才停下来，直接回复向用户说明并提问即可。

### Step 2 · 规划内容与格式

- **认真理解附件**：如果用户提供了附件，则需要认真阅读所有附件的格式和内容，理解它们之间的关系和在任务中的作用。若 `attachment_purpose.md` 不存在，必须重新写入到临时目录里。
    - 若 Step 1 中判定任务类型为强附件和信息遵循类型，说明附件原文非常重要，即使在你前序的步骤中，模型可能已经协助压缩附件、理解附件主题、补齐缺失信息，你依然需要非常认真地阅读附件。
    - 若之前获取的附件内容（如有）存在必要信息缺失，请重新阅读。用户附件里有很多关键信息藏在图/表/公式里，只跑 `paragraphs` / `pdftotext` 会丢掉它们。
    - 附件中的图片/表格插入 Word 时，须保留原图表的所有信息，**绝对不允许裁剪，但可以缩放大小来适配 Word 的排版布局**。
    - pdf 必须先通过脚本 `pymupdf.open() 打开` 再跑 `page.get_images` + `page.find_tables` 来获得附件中的图片/表格信息，或使用 `page.get_pixmap` 获得 PDF 页面截图。
    - 其他附件优先通过查找相关 skills 或者工具来获取完整的信息，若没有相关 skill 、工具可以使用代码能力来获取相关信息。
    - 你写的附件作用清单中，应包含每个附件的内容概要、在任务中的作用、在任务哪个环节应该回读，以及附件之间的关系。
- **规划内容**：根据用户要求（如有）、材料（如有）和写作指南建议，写出轻量内容规划大纲 `outline.md` 在临时目录中，明确章节、事实依据、重点内容以及需要保留的附件信息。没有 `outline.md` 时**禁止**直接生成 Word 文件。
    - 若发现缺少必要的素材，可以使用必要的工具获取（如联网搜索、搜图、生图），禁止编造内容。
    - 对于占位性质的内容，请用占位符来表示，而不要自行编造，例如不要写“发文【18】号字”而应该写“发文【XX】号字”；在改写用户的内容时，尤其是公文、论文等正式文件，不要自行发挥增加和改动内容，只有用户明确要求，或者为完成任务确有必要、能够通过可靠材料验证且不改变用户原意时，才可以补充；推断性内容必须明确标识。
    - 附件的重要性远高于自行获取的信息，是用户提供的最核心信息组成部分，在形成大纲时必须明确指出这些附件中的信息应该处于大纲的哪些部分。
    - 若 Step 1 中判定任务类型为强附件和信息遵循类型，那么**附件原文**非常重要，你应该忠实于原文而非压缩物或自己的解释，不要出于润色、完整等写作风格的考虑，自行扩写、增加用户给定以外的信息，你写的每一条重要信息应能溯源到原文或原附件。
    - 完成内容规划后通读一次，确保结构清晰、内容合理、逻辑前后一致
- **确定模板**：若用户明确给定模板，或要求按给定附件格式操作，则用户给定的附件是最高优先级的模板；其次，如果当前任务适用于`writing-taxonomy.md` 中特定体裁推荐的模板，那么应用内置模板执行后续的任务；如果都不适用，那么进行无模板创作。
- **确定格式**： 明确标题层级、目录、封面、页码、表格和可视化元素。
- **确定写作风格**：根据 Step 1 中判定用户可能的 profile，结合任务类型，判断行文风格。例如，正式文件场景不适合出 emoji、口语化表述。

### Step 3 · 生成 Word 文档

根据 `Step 2`确认是否存在模板 ，只执行以下一个 Option。创建方式一旦确定，不在本步重新判断或切换。

#### Option 1 · 有模板创建

模板是必须继承的输出底稿，不只是样式参考。目标内容决定写什么，模板决定文档如何呈现：固定格式必须继承；内容区域优先在原位置填写；原结构无法承载新内容时，只调整必要的内容区域，不重建整份模板。

##### 1. 复制模板并取得唯一目标文档

- **确认输入**：开始前确认已经取得模板文件和模板来源、内容规划、用户材料、补充素材（如有）以及用户明确要求。不得在本 Option 中重新选择写作类型或创建方式。
- **复制模板，不修改原件**：保存一份原始模板快照，作为`SOURCE_DOCX`将地址保存在上下文中，再复制出本次任务唯一的目标文档，作为 `TARGET_DOCX`将地址保存在上下文中。后续读取、填写、渲染、校验和交付都围绕这个目标文档进行，不得新建空白文档后凭印象重做模板。将目标文档地址写在你的上下文中。
- **不自行切换创建方式**：模板无法承载部分内容时，优先调整必要的内容区域；模板损坏、无法读取或与用户要求直接冲突时，应向用户说明问题，不得静默改用其他模板或无模板创建。

##### 2. 完整读取并理解模板

在写入任何内容前，必须使用`python-docx`,`lxml`和`libreoffice`同时完成结构读取和全页渲染检查，不能只读取纯文本，也不能只凭页面截图判断底层结构。

- **读取完整结构**：检查标题与段落层级、样式、编号、表格与合并单元格、图片、图表、文本框、内容控件、书签、链接、脚注尾注、分节、页眉页脚、页码、目录、签署页和附件页。
- **查看全部页面**：渲染模板并逐页检查页面大小、页边距、分页、固定装饰、Logo、品牌元素、各区域容量，以及图片、表格和正文之间的位置关系。
- **识别填写边界**：复杂表格必须确认实际 XML 单元格、逻辑列和合并关系，不能只依赖页面位置或 Word 库展开后的 `rows[x].cells[y]` 下标。
- **区分模板内容**：

  | 内容类型 | 处理方式 |
    |---|---|
  | 固定内容 | 原样保留，例如页面设置、Logo、页眉页脚、页码、文号格式、固定说明、签署结构和必填栏目。 |
  | 示例内容 | 只用于说明格式或填写粒度；按任务替换或删除。 |
  | 占位内容 | 填入真实内容、明确留白或删除，不得遗留无意义占位文字。 |
  | 真实已有内容 | 按用户要求保留、更新或删除，不因其出现在模板中就默认沿用。 |

  模板中的示例文字、虚构数据和原有章节不是事实来源。用户要求和用户材料决定实际内容；所选写作类型及领域文件用于补充内容结构和表达规则，不得覆盖用户明确要求。

##### 3. 制定模板填写计划

根据 `Step 2` 生成的内容计划，重新阅读 `attachment_purpose.md` 和 `outline.md` 后在任务临时目录中创建 `template-plan.md`。计划应轻量但可核验，至少记录每个需要填写、替换、删除或重点保留的区域，格式如下：

| 目标区域 | 内容依据 | 定位方式 | 编辑方式 | 必须保留 | 验收条件 |
|---|---|---|---|---|---|
| `<region>` | `<user-material-or-source>` | `<part + XML path / stable identifier>` | `<replace / insert / delete>` | `<style-or-structure>` | `<content-and-layout-check>` |

定位应来自模板的真实文档结构。目录、章节标题、页眉页脚、书签、交叉引用、复杂表格和签署区域，应记录稳定标识；同一项目在编辑、回读和差异比较时使用同一定位依据。

填写方式按以下顺序选择：

1. **同位置直接填写**：模板已有相同用途的栏目、字段或条款时，在原位置替换内容。
2. **在原结构内改写**：标题、编号、段落或表格结构适用时，只修改内容区。
3. **复制同类结构后扩展**：需要增加段落、表格行或章节时，复制最近的同类完整结构。
4. **按模板样式新建必要区域**：只有模板中没有可复用结构时才新建，并继承最接近的标题、正文、表格或图注样式。

开始填写前确认：用户要求和内容规划都有明确去向；示例、旧数据和占位内容都有处理方式；复杂表格及固定区域已经过结构与渲染检查；所有计划外模板节点默认保持不变。

##### 4. 在模板副本中填写

- **始终编辑同一个目标文档**：所有内容写入 `TARGET_DOCX`，不得中途改为新建文档或换用另一份副本。
- **只修改计划范围**：只编辑 `template-plan.md` 允许变化的内容及其必要关联项。未计划修改的页面设置、样式、编号、关系文件、媒体、页眉页脚、分节、书签、内容控件、脚注尾注、嵌入对象和自定义 XML 应保持不变。
- **继承完整结构**：新增段落、表格行、单元格、图注或图片时，复制最近的同类结构，并继承字体、样式、编号、边框、列宽、合并关系和段落属性，不使用与模板无关的默认格式。
- **分区域填写并及时回读**：每完成一组相关修改，就回读对应区域，确认内容写入正确位置、格式得到继承、示例内容已清理。写入结果不明确时，先检查目标文档，再继续操作。
- **控制内容容量**：新内容过长时，优先精简表达或在同类结构中扩展；只有原结构确实无法承载时，才调整必要的内容区域，不重建整份模板。但注意不得因此删减用户要求、关键事实、必要条款或论证内容。

对副本编辑完成后立即检查：旧标题、示例文字、占位符、旧数据和无关图片是否已按计划处理；新内容是否存在漏填、重复、异常换行、遮挡、错误分页、表格撑破页面或图片引用不一致等问题。

#### Option 2 · 无模板创建

- 从磁盘重新读取 `attachment_purpose.md`（如有）和 `outline.md`，逐项确认用户要求和必用附件证据已经映射；不要凭记忆或附件摘要生成正文。
- 根据 `outline.md` 的内容、边界和格式使用合适的代码方式（如 `python-docx`、`lxml`）创建 Word。
- 创建过程中遵守所选写作类型、用户格式要求和附件使用规则；不得为了套用版式而临时将素材文件或视觉参考改判为模板。
- 不得在生成过程中把内容来源或视觉参考重新判定为模板，也不得为了显得完整自行扩展任务范围。
- 以下经验请**严格**遵循
  - 对于用户没有明确要求生成目录的情况下，默认不生成目录
  - 注意编号的使用，尽量使用自动编号，注意严谨出现自动编号与生成的文本重复
  - 注意检查分节标题，不要因为模型规划将内容分成多块写入出现如"XXX续"这种情况
  - 注意全文表现形式的统一性：
    - 正文字体字号必须保持统一，同一层级标题的字体字号保持统一
    - 表格样式颜色尽量保持统一，不要出现颜色跳跃或过度鲜艳的情况
    - 使用阿拉伯数字或者中文数字前后注意一致性，严肃场景应尽量使用中文数字

### Step 4 · 验收交付

对最终路径验收前，重新读取用户指令、实际使用的模板及 `template-plan.md`（如有）、已选写作类型指南和 `writing-taxonomy.md`，按规则优先级提取本任务实际生效的明确要求，在上下文中形成轻量验收证据表，不新增文件：

| 规则来源与定位 | 验收对象与范围 | 预期值或行为 | 终稿实际证据 | 结果 |
|---|---|---|---|---|
| `<file:line>` | `<Title/Normal/表格/正文结构等>` | `<明确要求>` | `<实际值、检查范围、异常数量与位置>` | `<通过/失败/N/A及理由>` |

后续第 1–5 项必须逐条核销该表，不能仅凭视觉印象或笼统判断通过：

- 字体、字号、颜色、段落、Heading、页面和表格等格式要求，必须从终稿 DOCX 的样式定义、继承链和直接格式中读取实际生效值，并记录检查范围及全部异常位置；只抽查一个段落或只查看渲染页面不算通过。
- 写作方式、内容结构、表格使用条件等语义要求，必须回读对应范围，记录实际落点或全部违反项；“整体符合风格”“看起来专业”不属于验收证据。
- 分页、遮挡、表格跨页和视觉布局使用全页渲染检查；渲染只能补充结构检查，不能代替实际格式值读取。

没有取得终稿实际证据的项目不得标记为通过；不适用时写明 `N/A` 理由，无法验证时标记失败或待核。发现失败项后修复，并重新核验对应项目。最终回复不得只说“检查完成、没有问题”，至少说明实际核验的约束类别以及失败或待核项。

1. **回读全文**，确认内容覆盖用户任务和附件规定的范围。使用 `python-docx`,`lxml` 确认正文、表格、关键数字、图片、目录、页眉页脚、签署页和文末内容均完整且位置正确。用户提出字数或字符要求时，必须撰写必要的代码按用户要求的 story、修订视图和统计口径验收。**禁止**仅仅只检查内容部分
2. **渲染并查看终稿**：使用`libreoffice`渲染输出文件，查看目录中的全部页面，逐页检查标题、编号、目录、字体、段落、表格、图片、页眉页脚、分页和附件顺序。尤其注意：
   - 使用自动编号与生成编号重复
   - 正文字体不统一，尤其在如政务公文等严肃场景
   - 分节标题中出现"XXX续"等不正式的表现形式（常见于模型规划时将内容分成多块写入）
   - 表格颜色跳跃、过于鲜艳，尤其在如政务公文等严肃场景应该保证表格颜色的严肃与统一
3. **模板专项校验**：对于使用模板创建的产物，确认产物遵循了`template-plan.md`要求；并且对比 SOURCE_DOCX 与 TARGET_DOCX 的渲染产物 pdf的效果，确保产物的样式遵循了模板要求
4. **内容与逻辑校验**：请仔细检查写作的内容是否符合事实性要求，逻辑是否前后一致，尤其在对内容真实性和准确性要求较高的任务中（例如公文、论文写作、金融分析）。
    - 必须严格遵循用户给定的信息和附件，如果撰写的内容因为信息/附件本身存在矛盾必须在最终回复用户时明确指出并给出来源。若 Step 1 中判定任务类型为强附件和信息遵循类型，那么务必忠实于信息和附件**原文**，请对照用户给定的信息和附件，一一确认信息来源，确认目标产物中没有自行扩展、编造的额外信息。
    - 充分使用了附件，内容符合附件作用清单的规划
    - 对于未明确的内容，用占位符代替，不得编造
    - 扩写和改编都符合事实和用户意图，若 Step 1 中判定任务类型为强附件和信息遵循类型，还需满足给定信息和附件原文的要求。
    - 确保文章的口径、数据、情节逻辑，前后一致，没有冲突或漏洞。
    - 如果没有用户明确授权，**禁止**直接使用系统中提供的用户信息来进行推测，如姓名、地点等，用户完全可能生成与自身无关的内容。
5. **用户指令遵循校验**：当完成整个内容后必须回看用户指令，确认当前交付内容是否完全满足用户要求
    - **附件**：用户提供的附件是否被充分使用，不仅仅包括文字、还有格式、框架、内嵌表格、图片等等，特别是用户明确要求作为模板的，最终交付产物是否以此为模板；
    - **篇幅规模**：如字数、页数、分章节字数/页数
    - **结构约束**：如顺序、章节、目录
    - **语言约束**：如中文、英文，尤其用户自身输入语种与要求语种不一致时
    - **风格约束**：如严谨、口语化、专业
    - **其他**：如必须包含，严谨包含，等各类用户明确提出的指令，都必须遵循
6. 如果需要修改，修改后**必须**重新进行相关校验。
7. 全部必检项通过，且不存在已知的阻断性问题后，才可以交付。

## 四、参考文档地图
### 总体说明
| 文件夹                        | 说明                            |
|----------------------------|-------------------------------|
| [`assets`](assets)         | 非markdown形式的参考信息，如各类写作模板      |
| [`references`](references) | markdown形式的参考信息，如详细的写作规则、工作流程 |

### [`style`](references/style)
| 文档 | 何时读 |
|---|---|
| `writing-taxonomy.md` | 文档写作通用规则，任何写作任务都必须读取 |
| `academics.md` / `business-agreements.md` / `government-and-party-documents.md` / `professional-domain-documents.md` / `strategy-and-analysis.md` / `teaching-and-training.md` / `workplace-formal-documents.md` | 常见写作场景写作规则，读取前必须优先读取`writing-taxonomy.md` |
| `general.md` | 兜底写作规则，未命中上述具体写作场景时读取，读取前必须优先读取`writing-taxonomy.md`|

### [`workflows`](references/workflows)
| 文档 | 何时读 |
|---|---|
| `docx-editing.md` | 非本地打开场景（附件或云端路径提供 DOCX）下，保留原稿内容主体的 DOCX 修改，包括局部内容或结构修改，以及范围明确的格式统一 |
| `local-docx-editing.md` | 本地打开场景（宿主中已打开的本地 DOCX，system-reminder 含 `<file_path>` + `<type>lark_doc</type>`）下的 DOCX 修改；合并了 `docx-editing.md` 全流程与本地路径锁定、读取重试及交付回复约束 |

===== 全文完（共 232 行）=====