| name | word-polished-doc-collab |
| description | Use when collaborating with humans to turn Markdown, DOCX, and structured visual assets into polished Word deliverables with explicit Chinese/English typography, caption policy, asset routing, and mode-aware validation. Supports lightweight and refined workflows, DOCX-to-Markdown cleanup, Markdown-to-DOCX rebuild, typography profile selection, and editable Office-native or Python-generated visual routes. |
Word Polished Doc Collab
概览
把“文档任务说清楚 + Markdown 可维护 + Word 版式统一 + 验证证据齐全”作为同一个任务完成。
默认服务 markdown <-> docx <-> visual assets 的往返协作流程，重点是可维护、可复跑、可控版式，不是一次性导出一个看起来差不多的文件。
这个 skill 内部提供 轻量模式 和 精细模式 两条路线。轻量模式负责最小可交付文档，精细模式负责可复用 workspace、资产分流和验证闭环。
什么时候用
- 用户要把 Markdown 稿件稳定地转成正式
.docx，并且对中英文字体组合、字号、标题层级、行距和段前段后有明确要求。
- 用户要把收到的 Word 原件抽取成 Markdown 持续维护，再统一导出风格一致的新
.docx。
- 用户需要把 Python 生成的图、表或后续的 Office 原生图表、插图对象接到 Word 主文档里，并保持编号、标题和说明位置稳定。
- 用户希望未来扩展多个版式档位或字体 profile，而不是把所有格式写死在单个脚本里。
模式路由
轻量模式
- 用户要的是 先把单篇或少量文档快速转顺，重点是把字体、字号、标题层级、行距、表题图题表注位置落对。
- 用户已经把主要版式要求说清楚，不要求 workspace 很重，不要求默认 review，不要求 Office 原生 chart 或复杂 OOXML patch。
- 用户更关心“先出一个干净、好看、能交付的
.docx”，而不是先建设一整套长期基础设施。
精细模式
- 用户要的是 长期可维护的文档体系，或者要处理多文档批量协作、可配置 style profile、Python figure、Office 原生 chart / illustration、模板继承、OOXML patch、自动 QA。
- 用户要求交付物不仅是
.docx，还包括更完整的 workspace、文档体系、验证证据和后续可扩展路线。
路由规则
- 如果用户明确说要走 轻量模式 或 精细模式，就直接听用户的，不要擅自改路由。
- 如果用户没有明确指定模式，优先看硬需求，不看说话口吻。
- 只要出现下列任一信号，默认走 精细模式：正式报告、较多图表或插图、Office 原生可编辑对象、preset/template、section/页眉页脚/多栏、长期维护、多文档批量协作、显式 QA/visual review、可复用 workspace。
- 只有当需求同时满足“单文档、篇幅较短、图表简单、没有模板/preset、没有 Office 原生对象、没有显式 review 证据要求、目标是快速交付”时，默认走 轻量模式。
- 如果任务同时带有轻量和精细两种硬信号，或者文档最终是否需要复用、验证、可编辑对象还不清楚，就应 主动向用户确认，不要凭语气猜。
轻量模式工作流
- 先锁定文档任务和默认样式
- 明确文档用途：合同、制度、报告、汇报附件、研究说明。
- 明确 source of truth：原始
.docx 还是维护中的 Markdown。
- 明确默认字体组合、标题梯度、表图规则，避免导出后才靠人工回修。
- 再保持 Markdown 语义最小可用
- 标题、正文、列表、表格、图片必须先保留为稳定语义，而不是在 Markdown 里硬凑视觉效果。
- 表题、表注、图题要有稳定语义约定。表题和图题优先直接写成
表 3 情景分析摘要、图 2 成本结构变化 这种最终可交付文本，不要强迫作者写 表题： 这种源文本噪声。
- 再走最简单可用的构建路线
- 普通文本型文档优先走
docx -> markdown -> docx 或 markdown -> docx。
- 轻量模式默认不引入 QA gate、不建设复杂 workspace、不要求
meta.json 或 asset_manifest、不预设 Office 原生 chart。
- 再做显式版式映射
- 正文默认
小四 12pt，中文 宋体，英文 Times New Roman，首行缩进 2 字符。
- 正文和标题默认
1.5 倍行距，段前段后统一按 0.5 行落地。
- 表格正文默认
五号 10.5pt，密表允许降到 小五 9pt，段前段后 0，表头居中、左侧索引列左对齐、右侧数值列右对齐。
cn_song_times 默认使用“表题在表上方且加粗、图题在图下方、表注在表下方”的中文正式文档规则；如果 active style_profile 或 preset 显式覆盖 figure_title 位置，就必须让构建与 QA 一起跟随 caption_policy 落地。
- 轻量模式默认不做 review
- 默认交付重点是把
.docx 本体快速、干净地落出来，不自动附带 visual review 或质量 gate。
- 只有用户明确要求自动 review、人工复核或任务已经明显升级成精细模式时，才追加检查步骤。
精细模式工作流
- 先锁定文档任务和 style profile
- 明确文档用途、source of truth、交付标准和后续复用边界。
- 明确
style_profile、caption_policy、资产模式和 future extension boundary。
- 先保持 Markdown 的语义稳定
- 标题、正文、列表、表格、图片必须先保留为稳定语义，而不是在 Markdown 里硬凑视觉效果。
- 表题、表注、图题、图注和来源说明要有稳定语义约定。表题和图题优先直接写成最终交付文本，并结合相对位置识别 role。
- 当文档包含多个图表或 Office 原生对象时，应显式维护
asset_manifest，不要把“这张图怎么生成、是否可编辑、题注放哪”散落在脚本常量里。
- 再选择构建路线
- 普通文本型文档优先走
docx -> markdown -> docx 或 markdown -> docx。
- 需要精确控制 Word 样式槽位、caption 位置、图注来源说明、分节、页眉页脚或原生对象时，再进入 OOXML patch 或 Office 原生对象路线。
- 再做显式版式映射
- 正文默认
小四 12pt，中文 宋体，英文 Times New Roman，首行缩进 2 字符。
- 正文和标题默认
1.5 倍行距，段前段后统一按 0.5 行落地。
- 表格正文默认
五号 10.5pt，密表允许降到 小五 9pt，段前段后 0，表头居中、左侧索引列左对齐、右侧数值列右对齐。
cn_song_times 默认使用“表题在表上方且加粗、图题在图下方、表注在表下方”的中文正式文档规则；如果 active style_profile 或 preset 显式覆盖 figure_title 位置，就必须让构建与 QA 一起跟随 caption_policy 落地。
- 再接 Python 图表或 Office 原生图表 / 插图
- 图表和插图都是文档资产，不是版式例外。
- 需要继续编辑数据、KPI 卡片、流程框或简单示意图时，优先考虑 Office 原生 visual route，并在
asset_manifest 中标记为 office_native_chart 或 office_native_illustration。
- 需要高复杂度研究图时走 Python figure 路线，并在
asset_manifest 中标记为 python_figure。
- 所有资产都必须继承同一份
style_profile 与 caption_policy，不能各自发明题注位置和说明样式。
- 强制做 QA
- 至少检查字体槽位、中英文字体、标题层级、正文首行缩进、行距、段前段后、表图标题位置、图注/来源说明、表格字号、表题加粗、表格对齐、图片裁切和原生对象可编辑性。
- 没有视觉复核或结构核对的
.docx 不算完成。
资源路由
轻量模式
- 默认先读取
references/lightweight_mode.md。
- 这份文档已经包含默认字体组合、标题梯度、caption 规则和最小 workspace。
- 只有当轻量模式已经不能覆盖需求时，才升级到精细模式文档。
精细模式
核心文档
- 需要统一定义对象、版式规范和 references 分层时，读取
references/principles.md。
- 需要执行
docx -> markdown -> docx 的协作流程、Markdown 语义约定和 workspace 组织时，读取 references/doc_workflow.md。
- 需要确定默认字体组合、字号梯度、段前段后、表题图题表注规则时，读取
references/typography_profiles.md。
- 需要明确实现层的技术边界、OOXML 字体槽位和失败条件时，读取
references/technical_support.md。
专项文档
- 需要在
python-docx、Pandoc、OOXML patch 等构建路线之间做选择时，读取 references/build_routes.md。
- 需要接 Office 原生图表或插图时，读取
references/office_chart_support.md。
- 需要接 Python 绘图资产时，读取
references/python_figure_support.md。
- 需要执行交付前质量 gate 时，读取
references/quality_gates.md。
- 需要参考一个已落地的宿主工作区实践时，读取
references/local_pipeline_case_study.md。
- 需要套用咨询报告或品牌近似风格 preset 时，读取
references/preset_style_guides.md，并让 preset 和默认中文正式文档规则显式衔接。
质量标准
cn_song_times 默认正文必须满足 中文宋体 + 英文 Times New Roman + 小四 12pt + 首行缩进 2 字符 + 1.5 倍行距 + 段前段后 0.5 行。- 标题字号必须随层级单调递减，不能出现二级标题比一级标题更大。
- 表格正文默认使用
五号 10.5pt，确有密度压力时才降到 小五 9pt，表头默认居中、左侧索引列左对齐、右侧数值列右对齐。
cn_song_times 默认表题在表上方且加粗，图题在图下方，表注在表下方。其他 preset 或 style profile 可以显式覆盖 figure_title 的位置，但必须在 profile 和 QA 中写清楚。- 轻量模式默认不附带 review 记录；精细模式默认必须带
validation_bundle，并且让 QA 跟随 active style_profile 与 asset_manifest（若存在）执行。
- 没有显式设置
ascii/hAnsi/eastAsia/cs 字体槽位的构建结果，不应被当作“格式已锁定”。
典型宿主命令
如果宿主工作区已经具备自己的 doc_pipeline.py，常见命令会是：
python scripts/doc_pipeline.py docx-to-md
python scripts/doc_pipeline.py md-to-docx
python scripts/doc_pipeline.py rebuild-all
如果宿主工作区还没有自己的实现，这个 skill 现在自带一套参考脚本：
python scripts/init_doc_workspace.py <workspace-dir> --mode refined --doc-slug <doc-slug>
python scripts/check_word_environment.py
python scripts/lint_doc_markdown.py --meta markdown/<doc-slug>/meta.json
python scripts/build_docx.py --meta markdown/<doc-slug>/meta.json
python scripts/export_docx_preview.py --meta markdown/<doc-slug>/meta.json
python scripts/run_docx_qa.py --meta markdown/<doc-slug>/meta.json
这套脚本的职责边界很明确：
init_doc_workspace.py 负责初始化轻量或精细 workspacecheck_word_environment.py 负责检查 python-docx、LibreOffice、Poppler 和字体探测能力lint_doc_markdown.py 负责在 build 前检查标题层级、caption 语义、图片路径和 asset_manifestbuild_docx.py 负责按 active style_profile 生成 .docxexport_docx_preview.py 负责导出 PDF 和逐页 PNGrun_docx_qa.py 负责执行字体槽位、段落契约、表格对齐、section 栏数和 asset 路线 QA
额外说明
- 这个 skill 当前把核心价值放在 文档体系、版式规范和路线选择 上，不假装某一个固定脚本已经覆盖所有 Word 特性。
- 如果宿主脚本没有显式支持字体 profile、caption 语义或 Office 原生图表，不应静默宣称“已经支持”，而应先暴露能力边界。
