⚠️ 先读完再动手：没见到末行「全文完」标记＝没读完，必须调整 offset 续读直到该标记。

Word

权威经验

1. 注意识别用户的需求：如果用户要求需要交付的产物除了 Word 还包括其他内容，请完成本流程后继续完成对应产物的工作；在多轮情况下，注意用户的指令是否真的与 Word 操作有关，如果无法确认可以向用户询问，不要盲目的直接编辑用户的产物；Word产物大多适用严肃场景，除非用户有明确的要求，否则禁止在产物中使用表情（emoji）
2. 按场景加载参考；加载的 workflow 必须完整读完。明确提供“按需读取”导航的 CLI/XML 参考按导航完整读取公共与命中章节；其他参考默认完整读取；命中 workflow 明确限定某个样式小节时按其范围读取。上述例外不适用于用户附件。
3. 用户附件必须逐一盘点，完整提取结果可以落盘保存，只把当前任务需要的证据载入上下文。
4. 不预先读取无关参考目录，禁止将参考文件的渐进加载规则用于跳过用户附件。
5. 要求的结构读取不可用、失败或结果不完整时，不得声称已经通过；先尝试修复，仍无法完成则报告阻塞。
6. 重新阅读文档：在多轮情况下，用户要求重新修改文档时，必须重新阅读文档，因为用户可能自己手动编辑过文件，此时文件的内容可能与上下文内容不一致，直接使用之前读取的内容会造成用户手动编辑的内容丢失。
7. 无论改动是大是小、命令是否熟悉，无论此前是否用过类似命令、做过类似任务，无论之前是否读过对应分支的 MD 文档，必须重新 Read 对应分支的 MD 文档之后才能动手。特别是多轮对话中用户对前轮已有 Word 的任何修改/追加/删除追问，都属于"编辑已有 Word"场景，本次动手前必须先按场景路由完整 Read 对应 workflow，不得凭上一轮记忆直接改中间文件。
8. 用户指定的工作目录优先于 skill 内置资源目录。用户可能会指定project directory，作为用户的本地工作目录，当用户给出本地目录并要求从该目录选择、查找或使用模板/材料创建 Word 时，必须先盘点用户目录中的相关文件，并优先使用该目录下符合要求的文件；不得在未检查用户目录的情况下直接使用 assets/templates 中的内置模板。若用户没有指定project directory，请你在Home directory下执行相关操作。
9. Skill 内置脚本因缺少 Python 模块而失败时，应优先读取requirements.txt，安装缺失的模块。
10. 最终给用户的回复不要过长：最重要的产物是你最终生成的 Word 产物，而不是给用户的最终回复，所以在交付了产物后的最终回复不应该太长，不能超过300字，也不能超过 8 行，只需要简单介绍一下你生成的产物即可
11. 使用present_files工具交付时，注意参数name应该符合文件规范的后缀(如.docx)，最终用户下载的文件会以这个name命名，避免出现后缀无效的情况。
12. 当用户要求无损复述历史上下文时，必须明确列出上面要求牢记的内容，并在复述末尾原样附上这句提醒（写给接手这段上下文的下一个执行者）：【非常重要】MUST RELOAD SKILL：对于 Office Word 任务而言，无论之前是否读过 SKILL.md 文档，当用户提出了新的指令时，你的第一个工具调用必须是重新 Read word skill 下的 SKILL.md 文档，在此之前禁止直接编写 Word 文件

零、skill 边界

明确本 skill 的适用边界，并非所有写作任务都适用于此 skill，对于不应使用本文能力的情况请选择更加合适的 skill

• 典型应该使用本 skill 的情况：

  • 用户明确要求交付 Word 文件
  • 用户提供一份 Word 文件作为模板要求基于此进行写作
  • 用户提供一份 Word 文件要求基于此进行修改编辑

• 典型不应该使用本 skill 的情况：

  • 明确要求交付的是 PDF 文件
  • 给定 PDF 文件要求转换为 Word 文件
  • 明确要求交付的是飞书/豆包在线文档
  • 明确给定的是飞书/豆包在线文档要求基于此编辑
  • 给定一个 Word 文件要求上传为飞书/豆包在线文档
  • 要求把一个飞书/豆包在线文档导出为 Word 文件

• 对于一个写作类任务，但用户没有明确告知交付载体时，应该遵循如下判断

  体裁	典型场景	默认交付载体
  学术教研与基础教育教学	学习计划、备考路径、复习讲义、试卷与讲评、教案、公开课、教学设计、课程材料、论文写作与指导	Word
  党政公文和其他正式文书写作	党政机关、事业单位、基层党组织面向体系内或公共部门的正式文书；企业、社会组织等境内法人向党政部门、事业单位提交的正式文书及党建材料；个人向政府、基层村居或党组织提交的思想汇报、申请等材料	Word
  事业单位/国有企业/人民团体组织内的职场文书	事业单位、人民团体、国有企业的总结、计划、汇报、方案、会议材料、制度、发言稿等非党建公文材料正式文书	Word
  专业法律文书与商务协议	围绕具体案件、法律问题或权利义务关系的法律意见、律师函、催告、起诉、答辩、上诉、代理、辩护、仲裁及程序申请；采购、服务、合作、买卖、租赁、承揽、补充协议、履约约定	Word
  专业领域文书	工程技术方案与医疗文书、财务与审计报告，以及其他需要适用于现行专业规则的文书	Word
  简历	生成简历或依据已有简历美化排版	Word
  媒体与传播	微信公众号推文、小红书图文笔记、邮件、短视频口播稿、短视频分镜脚本、平台标题、封面文案和标题库	云文档
  创意写作	网文、小说、故事、同人、剧本、互动叙事、故事大纲	云文档
  品牌营销	营销策划、品牌认知、产品上市、内容种草、活动战役、增长转化、客户经营、渠道动销与整合营销	云文档
  生活应用与攻略	旅行计划、旅行路书、城市或景点攻略、健身计划、减脂计划、生活指南	云文档
  分析报告与决策支持	基于表格、数据、调研材料、多个附件或可核验来源形成详细分析、研究、比较、诊断或建议	云文档
  市场化企业职场文书	民营、外资及一般商业组织的项目提案、工作总结、正式汇报、项目提案、岗位说明、培训材料、会议纪要（非政务党建类）	云文档
  无法判断	没有明确载体要求，且无法匹配以上体裁	Word

  交付载体为 Word 的才应该使用本 skill，交付体裁为在线文档时请使用lark-doc

⚠️ 本 skill 可以与其他 skill 一起共同解决用户的问题。比如使用别的 skill/工具获取用户提供的非 Word 文件信息，再使用本 skill 的能力输出 Word 文件；或者使用本 skill 的能力先读取 Word 文件，然后交由别的 skill/工具完成后续的非 Word 产物交付。

一、场景路由

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

场景路由	对应分支（必读）	详细说明
读取 Word	二、读取 Word	可以获取 Word 的内容和结构信息
新建 Word	三、新建 Word	用户提供模板新建以及无模板新建
修改 DOCX（附件模式）	docx-editing.md	用户以附件的形式提供 DOCX 并要求修改
修改 DOCX（代码模式）	local-docx-editing.md	用户使用本地电脑要求修改所提供 DOCX，且判定处于代码模式
修改 DOCX（Canvas模式）	canvas-doc.md	用户使用本地电脑要求修改所提供 DOCX，且判定处于 Canvas 模式

环境判定与模式定义：

• 本地云端判定：关注 SystemPrompt 或 <system-reminder> 中关于 Computer OS 的描述，若为 "Linux" 则用户使用的是云电脑，若为 "macOS" 或者 "Windows" 则使用的是 本地电脑
  • 特别的，如果判定发现用户使用Windows，Windows 上 Python PowerShell 的使用方式与 Mac, Linux存在显著差异，所以如果涉及到任何新建或修改的逻辑，都必须读取windows-compat.md
• 模式定义：如用户要求修改提供的 DOCX 时，关注 <system-reminder> </system-reminder>包含的内容：
  • 出现 "User-added attachments" 或者 "User-uploaded attachments" 相关内容，代表以附件形式传入文件，此时为附件模式；
  • 若用户使用本地电脑，且 path 为本地路径 + token 不为空 + type == "word" + file_status == "open" 时，则此时为 Canvas模式；
  • 若用户使用本地电脑，且 path 为本地路径 + token 不为空 + type == "word" + file_status == "closed" 时，则此时降级到 附件模式；
  • 若用户使用本地电脑，且 path 为本地路径 + type == "lark_doc"，则此时为 代码模式

路由说明：

• 用户明确要求新建、把附件作为模板填入一套新内容、仅把附件作为格式参考，或需要重写绝大多数主体内容时，进入三、新建 Word
• 若用户以附件形式提供 DOCX 文件，且要求进行修改，阅读 docx-editing.md
• 若用户使用本地电脑且要求修改所提供的 DOCX （不以附件形式提供）时
  • 若处于Canvas模式，阅读 canvas-doc.md，完成前不并行发起任务动作，注意，同一文件的读取、编辑、整篇重写、状态分支、验收和交付均由该 workflow 处理，不因修改范围或任务复杂度改走本页通用分支。
  • 若处于代码模式，阅读 local-docx-editing.md
  • 特别的，如果处于Canvas模式，但该模式提供的能力无法完成用户的要求时应该退回至附件模式
• 其他说明：
  • 多个 DOCX 无法唯一确定目标，或“修改原稿”和“按其另建”会导致实质不同的交付物时，先澄清；其余小歧义按保守、少改动的方向处理。
  • 用户要局部修改旧版 .doc 时，先取得经过结构和全页视觉比对的 .docx baseline，再按上述判定进入对应编辑流程；只有无法可靠转换或用户要求重建时才进入新建。
  • 同一任务可以先读取多个 Word 输入，再进入一个新建或编辑 workflow。多个交付物分别路由并使用独立临时子目录；各自所需的证据、计划、各类临时文件不得跨交付物共用。

附件前置处理

用户提供的一切材料都是本次任务的第一手事实来源，如果之前没有读取附件，那你必须解析附件内容获得更多相关信息。对于非 Word 类型文件优先通过查找相关 skills 或者工具来获取完整的信息，若没有相关 skill、工具可以使用代码能力来获取相关信息。

当用户明确指定一个本地工作目录时，该目录也视为本次任务的一手输入来源。进入模板选择或内容规划前，必须先列出并检查该目录下与任务相关的 Word、PDF、图片、表格等文件，记录其可能角色；只有确认用户目录中没有合适模板或用户明确允许使用内置模板时，才考虑 assets/templates。

用户提供附件时，在路由阶段就在任务临时目录初始化 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

• Canvas 例外：当前 Canvas 文档按 canvas-doc.md 读取；仅其关闭文件分支或已取回的 OOXML 本地文件使用以下脚本规则。

• Word 读取的默认入口是 scripts/read.py。执行参数为scripts/read.py <文件路径> -d <0-9> -o <输出文本路径>。遇到 .docx、.doc、SOURCE_DOCX 或 TARGET_DOCX 时，必须先用本脚本读取任务需要的维度，再判断是否需要补充读取。

• .doc 由 scripts/read.py 调用 LibreOffice 转换为临时 .docx 后读取；这属于内置读取路径，不需要另写转换脚本。缺少 LibreOffice 或转换失败时，先尝试修复环境，若尝试失败，需要及时通知用户。

• 不得因为脚本参数较多、输出较长、只想快速看正文或认为临时写脚本更简单，就自写简化 Word 读取器替代 scripts/read.py。临时脚本容易漏掉页眉页脚、字段、文本框、图片关系、样式继承、分节设置和表格合并，不构成完整附件读取。

• 如果 scripts/read.py 运行失败或参数不清楚，先检查命令路径、依赖、参数和脚本自身说明，必要时修复或扩展现有脚本；不得把一次失败当作改用自写读取器的理由。

• python-docx、lxml 或其他代码只能作为补充：用于 scripts/read.py 已覆盖基础维度后核验某个缺口、统计某类对象、排查异常 XML，或为脚本缺失能力做临时精确读取。补充结论必须回写到 attachment_purpose.md 或任务记录中，并说明它补充的是哪个 scripts/read.py 维度之外的信息。

scripts/read.py 必须指定单个读取维度和 UTF-8 输出文件；结果输出到stdout的同时，写入 -o 指定的文件，供后续可能的二次读取。脚本按结构维度读取，输出过长时，使用各维度的记录块标识和定位字段筛选，例如 SECTION、P、T、OBJECT、PART、section、part、loc 及对象索引；紧凑文本中的底层 record_type 通常被省略，source_path 和 location 通常显示为 part 和 loc。

⚠️ PDF、图片等其他类型的附件不能使用 scripts/read.py 读取，参照下文中描述的对应方法处理。scripts/read.py只负责读取用户上传的.doc和.docx附件，不负责读取最终产物。

常用读取维度

-d 每次只能指定一个维度，取值范围为 0–9。维度 0 输出便于直接阅读的 Markdown；维度 1–9 输出带说明头的自定义结构化文本。记录会按维度使用块标识、部件路径、OOXML 路径或对象索引定位，但不是每种记录都同时具有这些字段。下表只列出常规读取需要的维度；按任务涉及的对象选择，不要求无差别运行全部维度。不同维度回答的问题不同，不能只读取正文后就声称已经读取了格式、对象或排版。

维度	读取内容	主要用途与边界
0	按正文顺序输出段落和表格文本。	用于快速理解正文主题、章节和表格中的文字。
1	输出分节记录，包括分节索引、纸张大小、方向、页边距、分栏、首页不同、页眉页脚引用及页码设置。	用于确认分节结构和页面设置。
2	逐段输出正文和表格单元格内的段落记录，包括文本、段落/表格/行/单元格索引、OOXML 路径、分节索引、样式 ID、对齐、缩进、段前段后与行距、同页控制、段前分页、边框、底纹、制表位及直接编号绑定。	用于定位具体段落、分析标题层级和段落格式。该维度主要反映段落自身的属性与样式引用；判断最终生效格式时还需结合维度 4 的样式定义，样式继承的编号还需结合维度 8。可对产物进行Grep搜索，快速定位到需要关注的位置。
3	逐 Run 输出文字片段及其所在段落、表格单元格、分节索引和 OOXML 路径，并记录 Run 样式、字体、字号、粗体、斜体、下划线、颜色、字符间距、语言，以及超链接、书签、字段代码、批注锚点和图片锚点。	用于检查同一段落内的局部格式差异，定位链接、域、批注和图片所在位置。可对产物进行Grep搜索，快速定位到需要关注的位置。
4	输出 styles.xml 中的段落、字符和表格样式，以及样式名、basedOn、后继样式、关联样式、优先级等关系；同时附带字体表和主题 XML。	用于追踪样式继承、主题字体和模板样式来源。
5	逐表输出表格位置、分节索引、样式、宽度声明、网格列、边框、底纹、单元格边距，以及每行高度、重复表头、禁止跨页设置和每个物理单元格的文字、宽度、gridSpan、hMerge、vMerge、边框、底纹与垂直对齐。	用于理解表格结构、合并关系和版式约束。不要只按 rows[x].cells[y] 推断逻辑列；复杂合并表格应依据物理单元格、网格列和合并标记共同还原。
6	输出 word/media/、word/embeddings/、word/charts/、word/diagrams/、word/activeX/ 和 altChunk 等包内对象的部件路径、类型、大小、SHA-256、引用关系，以及正文 Run 中的绘图锚点；指定 --asset-dir 时按包内路径导出对象，指定 --include-media-base64 时在结果中附加 Base64。	用于盘点和提取媒体、图表及嵌入对象，并根据本维度的 ANCHOR 记录或维度 3 确认正文位置。
7	逐个输出页眉、页脚部件中的文字、段落、表格、图片锚点和字段。	用于读取页眉页脚的实际内容；维度 1 只提供分节中的引用关系，不能替代本维度。
8	输出图片项目符号、抽象编号、层级定义、编号实例，以及正文段落的直接或样式继承编号绑定。	用于分析标题、列表和条款的编号定义与绑定。
9	输出字段、超链接、书签、内容控件、公式、批注锚点、修订节点、绘图等特殊节点，批注、脚注、尾注等特殊部件，以及文档属性和 VBA 宏清单。	用于检查普通段落和 Run 记录无法完整表达的特殊内容。

• 维度说明：只需理解正文内容时先读维度 0；涉及模板、编辑、格式复刻时，按任务对象选取维度 1–9：分节与页面设置用 1，段落、Run 和样式用 2–4，表格用 5，图片、图表或嵌入对象用 6，页眉页脚用 7，自动编号用 8，字段、批注、脚注尾注、修订或其他特殊结构用 9。不得用单一维度代替任务所需的其他证据。

三、新建 Word

核心顺序：理解需求确认类型 → 规划内容与格式 → 生成 Word → 交付验收

⚠️ 禁止仅使用外部工具或者 skill 校验本次生成的 Word 文件，如artifact-preview，verifier-hub，必须使用本文提供的「交付验收」流程进行校验。

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

• 理解用户任务：确定核心写作类型，确定写作目的、作者或主体、主要读者、交付物，以及用户明确要求和排除项。写作类型决定文档应包含的内容、主体结构和表达方式，也决定下一步需要从附件或外部来源补充哪些信息。同时，尝试理解用户可能的 profile，以确定后续的写作风格。

• 先处理用户模板：

  • 用户明确指定的可编辑 DOCX 模板是最高优先级底稿。记录唯一文件路径、模板来源和用户要求的使用方式。
  • 用户指定本地目录并要求“从目录里选模板”“使用目录里的模板/材料”时，必须先盘点该目录并从其中选择最匹配的可编辑 DOCX；不要跳过用户目录去使用 skill 自带模板。
  • PDF、图片或其他附件只能作为格式参考时，记录需要遵循的具体版式特征，后续从零创建；不得声称已在模板副本中填写。

• 再确定写作类型和内置模板：

  • 读取 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 中写入一张引用核查表，预期要出现的每一部法规、标准、文件等都必须在此表登记，状态为 "待查" 的不得写入正文。没有 outline.md 时禁止直接生成 Word 文件。
  • 引用核查表按照如下标准写入

    | 引用名称 | 标准编号/文号 | 发布机关 | 发布/修订年份 | 现行有效性 | 核实状态 | 搜索来源URL |
    |---|---|---|---|---|---|---|
    | 《中华人民共和国消防法》 | — | 全国人大常委会 | 2021年修正 | 现行有效 | 已核实 | https://... |
    | 《医疗机构消防安全管理》 | WS/T 785—2021 | - | - | - | 待查 | - |
    

  • 若发现缺少必要的素材，可以使用必要的工具获取（如联网搜索、搜图、生图），禁止编造内容。
    • 对于涉及时效性敏感的任务（如法律、金融、新闻、赛事、天气、招聘、政策等），必须重新通过联网获取最新信息，禁止直接使用模型内部知识，同時注意搜索的时候务必带上时间信息，获取到信息之后更新outline.md中的核查表状态。
    • 对于要提供重要引用或者来源的任务（如政策文件、法律条例、行业标准、医疗指南、统计数据、财务披露、官方技术文档、论文期刊、教材、新闻报道等），必须通过联网复核信息的准确性与来源的有效性（即使法规/标准名称属于常识，其标准编号、 发布/修订年份、发文机关、是否现行有效等具体信息也必须联网核实），获取到信息之后更新outline.md中的核查状态表，禁止直接使用模型内部知识作为引用或参考信息。
  • 对于占位性质的内容，请用占位符来表示，而不要自行编造，例如不要写“发文【18】号字”而应该写“发文【XX】号字”；在改写用户的内容时，尤其是公文、论文等正式文件，不要自行发挥增加和改动内容，只有用户明确要求，或者为完成任务确有必要、能够通过可靠材料验证且不改变用户原意时，才可以补充；推断性内容必须明确标识。
  • 附件的重要性远高于自行获取的信息，是用户提供的最核心信息组成部分，在形成大纲时必须明确指出这些附件中的信息应该处于大纲的哪些部分。
  • 若 Step 1 中判定任务类型为强附件和信息遵循类型，那么附件原文非常重要，你应该忠实于原文而非压缩物或自己的解释，不要出于润色、完整等写作风格的考虑，自行扩写、增加用户给定以外的信息，你写的每一条重要信息应能溯源到原文或原附件。
  • 完成内容规划后通读一次，确保结构清晰、内容合理、逻辑前后一致
• 确定模板：
  • 若用户明确给定模板，或要求按给定附件格式操作，则用户给定的附件是最高优先级的模板。
  • 若用户给定的是目录而非单个文件，则先在该目录中查找候选模板并说明选择依据；用户目录中的合适模板优先于本 skill 的 assets/templates。
  • 其次，如果当前任务适用于writing-taxonomy.md 中特定体裁推荐的模板，那么应用内置模板执行后续的任务。
  • 如果都不适用，那么进行无模板创作。
• 确定格式：明确标题层级、目录、封面、页码、表格和可视化元素。
• 确定写作风格：根据 Step 1 中判定用户可能的 profile，结合任务类型，判断行文风格。例如，正式文件场景不适合出 emoji、口语化表述。

Step 3 · 生成 Word 文档

根据 Step 2确认是否存在模板 ，只执行以下一个 Option。创建方式一旦确定，不在本步重新判断或切换。
注意，在写 Word 文档的脚本时，单行中文正文默认使用单引号包裹，而不是使用双引号，例如：add_body(doc, '成为道德高尚的人')

在生成word时，需要注意：

• 默认用户给出的参考资料都是正确的，有明显冲突或者错误的地方给与提示
• 使用其他工具（如联网搜索）获取的第三方信息必须判断正确性，特别是时效性内容注意去除过期内容，如果你无法判断获取的第三方信息是否可使用，那么你应该默认不使用，禁止为了更多内容盲目使用错误信息
• 对于写作中需要给出引用或来源（如法规名称、标准编号、文号、年份、统计数据）之前， 必须确认该引用已在 outline.md 引用核查表中登记为"已核实"并附搜索来源，禁止直接使用模型内置信息作为引用，如果此时缺乏第三方信息，需要重新使用必要的工具进行获取。
• 当内容涉及脚注、尾注或文献交叉引用时，必须先读取 citations.md 选择结构。模板已有相关结构时，修改前运行 inspect。正文和引用锚点就绪后，使用专项工具先 apply --dry-run，成功后执行 apply --in-place。

Option 1 · 有模板创建

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

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

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

2. 完整读取并理解模板

在写入任何内容前，必须使用python-docx和lxml完成结构读取，不能只读取纯文本。

• 读取完整结构：检查标题与段落层级、样式、编号、表格与合并单元格、图片、图表、文本框、内容控件、书签、链接、脚注尾注、分节、页眉页脚、页码、目录、签署页和附件页。

• 识别填写边界：复杂表格必须确认实际 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及理由>

后续各项必须逐条核销该表，不能仅凭印象或笼统判断通过：

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

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

1. 执行audit校验：完整读取 audit.md 后执行 audit。循环执行 audit，直至最新版本通过：每次生成或修改 TARGET_DOCX 后，都必须运行完整 audit。无模板新建使用 scripts/audit.py audit TARGET_DOCX；模板创建使用 scripts/audit.py audit TARGET_DOCX --source SOURCE_DOCX，用户给出 Word 字数下限、上限或区间时，必须追加对应的--word-count-min / --word-count-max参数；没有明确字数要求时不设置。完整审计结果会直接打印在 audit 命令的标准输出（stdout）中 BEGIN/END AUDIT REPORT JSON 之间，直接从该 stdout JSON 逐项获取错误的 code、location、evidence 和 repair_hint，优先修改生成代码或样式定义，并循环执行“audit → 修复 → 重新生成 → audit”，直至最新一次退出码为 0。退出码为 1 或 2 时不得交付。
2. 渲染校验：audit 通过后，使用 scripts/render.py 的 render 操作，将 TARGET_DOCX 作为位置参数，将 --output-dir 设为本任务临时目录。脚本通过 WPS 转换通道取得 PDF，再生成全部页面 PNG；退出码 0 表示渲染成功，1 表示未成功。成功后必须逐张查看返回的全部页面图片，抽样、只读文本或只看改动页不算通过。逐页检查标题、编号、目录、字体、段落、表格、图片、页眉页脚、分页和附件顺序。注意：
   • 渲染后正文字体是否存在非预期的不统一，尤其是政务公文等严肃场景。
   • 渲染后是否因分块写入而留下“XXX续”等不正式的分节标题。
   • 渲染后表格颜色是否跳跃、过于鲜艳；政务公文等严肃场景应保持配色严肃、统一。
   • 渲染后是否存在标题孤悬、图表与题注分离、表格跨页异常、内容截断或非预期空白页等分页问题。
   • 使用模板时，对照原模板检查应保留的版式和结构；发现问题后修复，不改动用户明确要求保留的内容和格式。
   • 渲染可能会超时，如果超时就直接跳过渲染检查的步骤，不需要用其他的方式来渲染。
   • 渲染图中公式结构可能不会正确显示，不要去尝试解决这个问题。
3. 模板专项校验：对于使用模板创建的产物，确认产物遵循了template-plan.md要求。
4. 内容与逻辑校验：请仔细检查写作的内容是否符合事实性要求，逻辑是否前后一致，尤其在对内容真实性和准确性要求较高的任务中（例如公文、论文写作、金融分析）。
   • 必须严格遵循用户给定的信息和附件，如果撰写的内容因为信息/附件本身存在矛盾必须在最终回复用户时明确指出并给出来源。若 Step 1 中判定任务类型为强附件和信息遵循类型，那么务必忠实于信息和附件原文，请对照用户给定的信息和附件，一一确认信息来源，确认目标产物中没有自行扩展、编造的额外信息。
   • 充分使用了附件，内容符合附件作用清单的规划
   • 对于未明确的内容，用占位符代替，不得编造
   • 扩写和改编都符合事实和用户意图，若 Step 1 中判定任务类型为强附件和信息遵循类型，还需满足给定信息和附件原文的要求。
   • 确保文章的口径、数据、情节逻辑，前后一致，没有冲突或漏洞。
   • 如果没有用户明确授权，禁止直接使用系统中提供的用户信息来进行推测，如姓名、地点等，用户完全可能生成与自身无关的内容。
   • 对于时效性敏感内容，必须通过工具获取最新信息，禁止直接使用模型内置知识，同时需要校验产物内容是否满足时效性要求
5. 用户指令遵循校验：当完成整个内容后必须回看用户指令，确认当前交付内容是否完全满足用户要求
   • 附件：用户提供的附件是否被充分使用，不仅仅包括文字、还有格式、框架、内嵌表格、图片等等，特别是用户明确要求作为模板的，最终交付产物是否以此为模板；
   • 篇幅规模：如字数、页数、分章节字数/页数
   • 结构约束：如顺序、章节、目录
   • 语言约束：如中文、英文，尤其用户自身输入语种与要求语种不一致时
   • 风格约束：如严谨、口语化、专业
   • 其他：如必须包含，严禁包含，等各类用户明确提出的指令，都必须遵循
6. 引用来源专项核查（涉及法规、标准、文号等作为依据数据时强制执行）
   • 从终稿 DOCX 中提取所有引用的法规、标准、文件名称、编号、文号、年份
   • 逐一核对是否在 outline.md 引用核查表中有记录且状态为"已核实"
   • 逐一核对是否有搜索结果 URL 支撑
   • 无搜索记录支撑的引用必须删除或改为"××"占位
   • 本项不通过不得交付
7. 如果需要修改，修改后必须重新进行相关校验。
8. 完成全部校验及必要修复，并确认所有必检项均已通过且不存在已知阻断性问题后:
   • 若终稿含脚注、尾注或文献交叉引用时，按 citations.md 引用与注释流程运行 inspect 与 validate，核对引用对应关系、编号和域缓存。
   • 必须执行 scripts/catalogue.py --file TARGET_DOCX 来检查并更新文档目录。若文档中存在 TOC 域，脚本将自动更新目录；若不存在，默认不会进行操作。

四、参考文档地图

总体说明

文件夹	说明
assets	非markdown形式的参考信息，如各类写作模板
references	markdown形式的参考信息，如详细的写作规则、工作流程、使用指令
scripts	用于辅助任务的脚本

style

文档	何时读
writing-taxonomy.md	文档写作通用规则，任何写作任务都必须读取
academics.md / legal-business-document.md / government-and-party-documents.md / professional-domain-documents.md / strategy-and-analysis.md / learning-and-training.md / workplace-formal-documents.md	常见写作场景写作规则，读取前必须优先读取writing-taxonomy.md
general.md	兜底写作规则，未命中上述具体写作场景时读取，读取前必须优先读取writing-taxonomy.md

workflows

文档	何时读
docx-editing.md	云端编辑场景（附件或云端路径提供 DOCX）下，保留原稿内容主体的 DOCX 修改，包括局部内容或结构修改，以及范围明确的格式统一
local-docx-editing.md	本地代码模式场景下的 DOCX 修改；合并了 docx-editing.md 全流程与本地路径锁定、读取重试及交付回复约束
canvas-doc.md	本地Canvas模式场景，目标通过 <token> 使用 CLI 时读取；由此入口按需加载 Canvas 编辑、恢复、OOXML 及 CLI/XML 参考
canvas-doc-editing.md	读取 canvas-doc.md 之后，判定需要通过 Local CLI 命令对文档进行新增、修改、删除或格式调整的编辑流程
canvas-doc-ooxml.md	读取 canvas-doc.md 之后，判定需要通过 OOXML 取回、编辑并提交的方式完成文档修改，含结构审计与提交后校验
canvas-doc-recovery.md	读取 canvas-doc.md 之后，Canvas 操作出现失败、警告或写入状态不明时，确认已写入内容、分类处理异常并决定是否继续
canvas-doc-close.md	读取 canvas-doc.md 之后，Canvas 操作出现文件状态关闭时的操作逻辑
audit.md	Word 格式与结构自动审计，发现存在的问题或提供统计信息
citations.md	脚注、尾注和文献交叉引用的统一操作与验收
windows-compat	用户运行平台为 Windows 时必须读取

cli

Canvas 场景专用；仅在 canvas-doc.md 或其编辑/OOXML 流程导航到具体命令时读取，不预先加载

文档	何时读
canvas-doc-fetch.md	用 +local-fetch 读取打开态 Word 前，查参数、scope/detail 与返回值
canvas-doc-update.md	用 +local-update 写入前必读的公共更新契约（str_replace、block 操作、返回值与 warning）
canvas-doc-update-table.md	增删表格行列、合并单元格等表格结构更新命令
canvas-doc-update-layout.md	分页、分节、页边距、页眉页脚等布局相关更新
canvas-doc-update-domain.md	水印、自动目录（TOC）领域命令
canvas-doc-chart.md	图表创建、数据替换、尺寸与删除的命令流程
canvas-doc-media-insert.md	图片上传、插入、资源替换与属性更新的命令流程
canvas-doc-style.md	样式读取与受控写入
canvas-doc-ooxml.md	+ooxml-fetch / +ooxml-update 取回与提交 DOCX 候选的命令契约
canvas-doc-revisions.md	本地 Word 的修订模式和待审内容
canvas-doc-update-structured.md	本地 Word 的结构化读取与领域更新

xml

Canvas 场景专用；生成或修改对应 DocxXML 片段时按标签命中读取

文档	何时读
canvas-doc-xml.md	生成任何 DocxXML 前必读，公共结构、身份、颜色、单位与转义规则及语法索引
canvas-doc-text.md	段落、标题、富文本、公式、列表、制表位、书签
canvas-doc-table.md	表格结构、列宽行高、单元格与合并关系
canvas-doc-layout.md	分页符、分节、分栏、纸张、页边距、页眉页脚、页码域、脚注尾注
canvas-doc-media.md	<img/> 属性、取值及浮动/嵌入结构
canvas-doc-chart.md	<chart/> 占位语法与图表数据 JSON 结构
canvas-doc-drawing.md	Shape、TextBox、WordArt、轮廓及文字效果
canvas-doc-drawing-presets.md	新建 Drawing 或更换预设时查合法预设值
canvas-doc-field-note.md	SEQ/REF/PAGEREF/NOTEREF 域、题注、脚注与尾注
canvas-doc-toc.md	自动目录阶段的规划与执行规则
canvas-doc-content-control.md	<content-control>；只更新现有控件 children

scripts

非必要无需读取执行脚本，直接使用即可

文档	说明
audit.py	audit.md需要用到的执行脚本
docx_citations.py	citations.md需要用到的执行脚本
read.py	执行 word 读取需要使用的脚本
catalogue.py	更新目录 TOC 域的脚本
render.py	渲染文档的脚本

===== 全文完 =====