用友实施交付文档生成

第一要素 · 技能维护边界（最高优先级，先于一切能力与约定）

本技能是"写文档的工具"，只沉淀通用的写文档方法论，绝不收录某一个具体文档 / 项目交付物的内容性细节——否则破坏通用性、影响专业性。

技能覆盖用友实施交付文档（各类用友实施交付文档，可按需扩展）。各文档版式共用「通用版式约定」与「核心生成纪律」，差异仅在结构骨架与各 reference 中体现。

只收录（通用方法论）：
- 版式规范（字体、缩进、分页、表格、自动编号等）；
- OOXML / python-docx 技术坑与修复方案；
- 通用写作红线（如：单一业务场景测试报告面向最终用户、不写补丁/代码层；用户给的元指令 / 要求性说明不写入交付物；图片段落不缩进；已确认功能用确认口径而非疑问口径等）。

绝不收录（具体文档内容，一律不放）：
- 具体客户名 / 项目名 —— 技能内一律用 XX公司 / XX模块 / XX功能 占位，不写死；
- 具体补丁名 / 版本号、具体内部函数名、具体测试点编号与内容；
- 用户在某次具体任务里给的原话、元指令、要求性说明文字。

溯源标注泛化： 技能内提到规则来源时，写"由多次单一业务场景测试报告实践沉淀"等泛化表述，不点名具体项目 / 交付物。

归类去向： 从具体项目新总结的规律与场景，应单独提炼成总结文档或笔记（不与技能绑定），而非塞进本技能。

> 新增任何内容前先自问：这是跨项目可复用的通用方法论，还是某个具体文档的内容？后者一律不放进来。

> 本规则优先级高于下方所有章节。红线只在此声明一次。

核心生成纪律（单源 · 运行 gen_*.py 前与写入正文时均须遵守）

下列各条是所有能力共用的通用红线，统一收口本节；各能力章节只保留专属结构，不再重复。试错/根因叙述统一收口 references/common/faq.md，本节只写结论规则。

1. 主体名已锁定：封面客户名 / 文档主体以用户明确指定为准；截图里出现的公司名 / 账簿名可能是其下级主体，不得直接当作文档主体名写入封面，仅作查询示例保留在正文。
2. OCR 硬门（唯一权威说明见下「OCR 强制流水线」）：写任何菜单 / 按钮名前必须 OCR 逐字取得或由用户文字提供，严禁凭视觉经验臆造；本机已装 OCR 则强制跑、未装则自动放宽（写名改由用户提供）。
3. 仅用用户提供的章节，不自撰：文档章节严格对应客户提供素材（截图 + 每步概述 / 各主题），不得新增概述章 / 总述章 / 背景章等素材里没有的章节；素材给几步就写几章。
4. 代码块字体与正文统一：SQL / 配置项代码块字体字号随统一正文字体（9pt），非 Courier New。
5. 不写补丁 / 代码层：交付物聚焦"系统功能是否实现"，绝不写补丁 / 代码层内容——不出现补丁问题编号、提供方 / 作者、内部函数名、SQL 内部实现、修复分支逻辑等；只保留"期初 / 本期 / 累计 / 期末"等标准业务术语。
6. 用户元指令不进正文：用户给的"要求性说明 / 元指令"只用于指导生成，绝不写进交付文档正文。
7. 业务流程只描述场景、用确认口径：描述业务流程只列场景（操作路径 + 查询条件组合），已确认事项用确认口径（"与…一致""正确"），不写"是否一致 / 是否正确"的疑问口径；验证结论放到对应结论区而非场景描述中。
8. 图片段落不首行缩进；思考痕迹不进正文：截图 / 图片段落不缩进；红框标注、图片张数、"（图 N 红框…）"等自述句均属思考 / 改稿痕迹，一律不进正文（脚本已强制拦截，命中即中止生成）。
9. 范围数字四方一致（生成后必检）：文档内所有"范围计数"（N 个主题 / M 张大屏 / K 项功能等）须在四处完全对齐——① 表格行数 ② 正文描述数字 ③ 图标题计数（「图 N」序号最大值）④ 实际插入图片张数；含图章节展示顺序须与建设范围清单顺序一致。
10. 关键实体与 OCR 逐字一致（字母易混）：视图名 / 表名 / 字段名 / 单据类型编码（如 S 与 3、0 与 O、1 与 l 极易误认）必须与截图 OCR 输出逐字比对一致，禁止凭近似经验写；OCR 个别字认错时用多模态视觉交叉验证。
11. 步骤标题带序号语义时用 Plain 样式：若源素材步骤标题本身带序号（如"问题 1 / 问题 2"），用 YonyouTitle1Plain（不进自动编号）承载，避免与模板自动编号 N. 叠加成"1. 问题 1"双编号；自动编号仅在步骤标题为纯业务名时启用。
12. 文档属性（docProps）默认全部清空（分享 / 外发安全）：所有产物落盘后须清空文档属性中的生成工具 / 作者信息（creator、lastModifiedBy、description、Category、Company、Application、时间戳等），不得残留 python-docx、generated by python-docx、Microsoft Macintosh Word、Normal.dotm、2013 年时间戳等痕迹——否则对方在「文件 → 属性 → 详细信息」中一眼可见生成方式与模板来源。清理由 common.scrub_doc_properties() 实现，并统一收口在 bake_toc_pagenums() 内且先行执行（各 gen_*.py 只需在 doc.save 后调用 bake_toc_pagenums，即便页码烘焙失败属性也已清空）；verify_doc() 设门禁，读回 docProps/*.xml 命中残留即中止生成。

OCR 强制流水线（代码硬门 · 唯一权威说明）

含截图时强制执行的两步流水线；纪律已下沉为代码级拦截（不 OCR / 臆造节点即运行脚本时直接报错，而非产出错误文档）。

Stage 1  识别：python scripts/_ocr_rapid.py <图片1> <图片2> ... [目录]
              → 把每张图的「tree 树形层级 + 整图文字」写入 ./ocr_evidence.txt
Stage 2  生成：运行对应 gen_*.py（build_* 开头自动调用 require_ocr_evidence）
              → 先检测本机是否装 OCR：未装则自动放宽（文档照常生成，写菜单/按钮名须由用户文字提供）
              → 已装 OCR 且引用了真实截图却无 ocr_evidence.txt：直接 FriendlyError 中止
              → 写出的路径节点（按 -> 拆层）在证据中找不到：直接 FriendlyError 中止（疑似臆造）

硬门规则（common.require_ocr_evidence，所有 gen_*.py 共用）：
- 本机未装 OCR（先 is_ocr_available() 检测 rapidocr-onnxruntime / tesseract 均不可得）→ 自动放宽 OCR 证据校验，文档照常生成并打印提示；无需手工传 skip_ocr。此时写菜单 / 按钮名须由用户文字提供。
- 文档未引用真实存在的截图 → 放行（模板示例因此仍可直接运行）。
- skip_ocr=True 且附 skip_reason（用户已文字提供全部菜单 / 按钮名）→ 放行但打印告警（仅本机已装 OCR 却有意跳过的合法豁免，不得静默跳过）。
- 本机已装 OCR 且引用了真实截图 → 必须存在 ocr_evidence.txt；缺失或路径节点对不上 → FriendlyError 中止，不生成错误文档。
- 节点比对：每条 A -> B -> C 路径拆成 A/B/C 各节点，逐节点在证据中做子串匹配；OCR 漏识真实节点时，把该节点原文补录进 ocr_evidence.txt 即可（证据文件即真理源，补录视为人工确认）。

路径写法格式硬约束（与是否装 OCR 无关）：每个节点单独 【】 包裹、节点间用 ASCII -> 连接、不以 【首页】 开头；整条路径包进一个 【】、用全角 → 作分隔符、节点不包裹、或以 【首页】 开头，均由 common.require_path_format 直接 FriendlyError 中止。

概览

用 python-docx 生成符合用友实施交付规范的 Word 文档。本技能把与用户原文档逐字对齐验证过的版式规范、关键 OOXML 技术坑、以及历次反馈修正经验固化下来，保证每次产出格式一致，不用反复返工。

技能包含以下能力（按项目实施过程排序）：

> ⚠️ 表格按行扩展：新增文档类型时追加一行（并在"适用阶段"列填其所在阶段），不再横向加列——横向加列会随类型增多不断压窄列宽、终至不可读。

适用范围：面向不同客户的用友实施项目（YonBIP 等）。技能不绑定任何单一客户——公司名、业务术语、菜单路径以实际客户为准；各生成脚本均以 XX公司 / XX项目 / XX模块 / XX功能 占位。版式规范对各客户通用。

> 📌 出问题先查 references/common/faq.md（按症状找答案，集中路径/字体/编号/红线等常见坑）；对照「怎么填 data / steps」看 references/common/scenario-examples.md。

通用功能约定

• 文件名一律带 【待确认】 后缀，以便与用户自己的正式文档区分；用户确认无误后再去掉后缀。
• 绝不覆盖用户原文件——用户已有同名文件时新建带后缀的新文件。
• 输出目录 = 当前工作空间绝对路径（如 <当前工作空间>/项目目录/），严禁放桌面 / 下载 / Documents。
• 命名格式：日期-客户-功能名称【待确认】.docx。
• 客户名不写死：未指定时用 XX公司 占位，技能分享后不能出现任何具体客户名。
• 负责人不写死：get_user_name() 读取 WorkBuddy 用户档案 ~/.workbuddy/USER.md 的 Name / What to call them 字段（本机=使用者本人，分享后自动变对方姓名），不写死原作者、也不落 XX 占位。
• 日期不写死、统一写法：get_date()（common 提供）返回当前日期，统一 YYYY年MM月DD日（中文、月日零填充）；所有日期均调它，绝不各脚本各写 datetime.now() 或混用 ISO / 中文写法。
• 菜单 / 按钮统一用 【】 标注，路径用 -> 连接。
• ⚠️ 搬运表格序号必须重编：从 PPT / 参考文档搬表时，文字内容可借鉴，但「序号」列须按 Word 内连续编号（01/02/03…，两位补零，N=数据行数）重写——PPT 常按模块共用序号，照搬会重复不连续。改号只改单元格文字、保留原字体格式，切勿整格重写（会丢失中文统一字体）。
• ⚠️ 终版化流程：用户确认测试通过、补完截图后，测试点表「测试结果」从"待验证"据实改为通过 / 失败 / 部分通过，并把文件名【待确认】去掉另存终版（不覆盖草稿）。
• ⚠️ 章节三类属性（通版约定 · 一次定义）：骨架中按章的性质标注三类——① 【条件章】：素材缺失即整体删除的章（可附简短条件说明）；② 【复用章】：数量随项目变化、结构同构、可重复出现的一级章（如方案类业务域章），骨架中只写一次、只写中性名（如 XX业务域），不得逐个列举成 XX业务域一 / 二 或使用 ~N / N、 / N+1、 占位编号（会与 Word 自动编号冲突、误导使用者），实际出现多个时其后各章一级编号依次顺延、二级随所属一级重排，骨架编号按「复用章出现一次」计；③ 【固定章】：固定存在的章，一律不标注属性——不标 【条件章】 / 【复用章】 的即为固定章，不得再写 【固定章】 造成冗余。
• ⚠️ 条件章节省略后编号顺延（通版约定）：各文档含「条件章」（素材缺失即整体删除的章，如实施范围子类、数据集成章、业务域专题等）时，任一条件章省略后，后续章节一级编号自动顺延、二级编号随所属一级章重排；骨架编号均为含全部条件章时的完整编号，断不可因省略某章而保留空号或跳号。
• ⚠️ 多业务域编排（通版约定 · 一次定义）：含「业务域章（【复用章】）」的文档按两级编排——① 单册多域：业务域数量可控、每域篇幅适中时，全部业务域收在同一份文档，每域占一个一级章；② 按域分册：业务域数量多，或某域单章篇幅已长到一册难承载时，拆成多份分册交付，各册沿用同一套骨架与同一类单元模板，册内编号独立起算。判据是「读者能否一本读完并逐域对照」，不以页数为硬指标。
• ⚠️ 公用输入项（通版约定 · 一次定义）：生成任一类文档前，以下各项通用、缺什么就问用户——① 公司名（未指定则 XX公司 占位）与项目名；② 文档控制（版本修订：日期 / 版本 / 修订人 / 说明；审阅确认：角色 / 姓名 / 职务 / 日期，可留空待签）；③ 签章方名称（公用类「确认并签署」签章表两列表头：两签署方，默认 XX公司 / XX公司）。各能力章节的「输入清单」只列本能力特有项，公用项一律回本条、不复述。
• ⚠️ 「确认并签署」签章区版式（通版约定 · 一次定义）：签批区双栏，每列 9 个独立 paragraph（行 1–4 留白 / 行 5 签章 / 行 6 空 / 行 7 项目负责人 / 行 8 空 / 行 9 日期），单元格 12pt 对齐，日期行右对齐制表位贴边。本条是签章区实现细节的唯一权威出处，各文档类型不再复述。

通用版式约定

> 版式格式与实现方法统一从本节取，各能力章节只描述版式结构（封面 / 页 / 章节骨架），不重复列格式细节。本节是「格式 + 方法」的单一权威源；OOXML 标签与实现细节收口 template.py / references/，改版式只改一处。

一、通用版式要点

• 字体（单源声明 · 本条是字体规则唯一权威出处）：全文统一正文字体，默认仿宋，经 scripts/font_config.json 配置（font=正文字体、code_font=代码块字体，code_font 缺省跟随 font；缺文件 / 非法配置回落仿宋）。首次为某用户 / 环境生成前须与用户确认字体：configured 为 false 时先询问（默认仿宋），确认后写入并置 configured=true；用户选非仿宋字体时提醒其确认宿主机已装该字体。字体由 template.py 一次性写入 docDefaults / 各级标题样式 / 编号 numFont，全文档继承；其余章节、references、脚本注释一律指针引用本条，不得重复写死字体名。列宽算法按全角字符宽=字号计，配置字体不影响列宽。
• 行距：全文 1.5 倍行距；段前段后 0。
• 缩进：正文首行缩进两字符（非固定厘米）。
• 代码块：配置项 / SQL 等用统一正文字体 9pt（非 Courier New）。
• 辅助小字统一 9pt（本条是字号分层唯一权威出处）：四类辅助小字——① 接口文档表格内文字；② 常规文档表格内文字（表头与正文单元格均 9pt，表头额外加粗）；③ 代码块；④ 页脚页码——统一 9pt，字体随统一正文字体。正文与章节标题保持 12pt（标题另有分级规格）。
• 标题分级（统一）：三级体系——一级 16pt 加粗（不缩进）；二级 14pt 不加粗（首行缩进 1 字符）；三级 12pt 不加粗（首行缩进 2 字符）。正文 12pt 缩进 2 字符。层级递减、统一字体、自动编号原则不变。
• 标题样式实现纪律（基于内置 Heading 双保险）：YonyouTitle1/2/3 以 basedOn=Heading1/2/3 + outlineLvl 双保险，让 WPS / Word 刷新目录可正确收集进 TOC；由此须显式覆盖内置样式继承的颜色与加粗（否则会继承 Heading 的蓝色 / 二三级误加粗）。所有属性改动只改 template.py 一处。

二、编号管理

• 章节编号一律用自动编号，禁手写死文本：编号走 Word 自动编号体系（非手敲 "3.1"），编号与正文间用空格间隔。
• 自动编号由模板内置、一次定义三文档共用：多级编号统一定义在模板内（一级 N. / 二级 N.M / 三级 N.M.x）并挂在内置 Heading 1/2/3 样式上，标题样式经 basedOn 继承，写标题即自动渲染。
• 编号数字字体必须与标题 run 字体一致（即统一正文字体）：否则章节编号数字会回退为 Arial / 默认字体（必检红线）。
• 悬挂缩进、编号残留等实现细节收口至 references/。

三、表格管理

• 统一纪律（黑边 + 底纹 + 对齐统一）：所有表格统一黑色实线边框 + 表头底纹浅灰 C0C0C0；表头行水平居中、其余行水平居左、所有单元格文字上下居中；表头 9pt 加粗、正文 9pt 不加粗（字体随统一正文字体）；正文表与文档控制表共用同一套规则。
• 表格整体居中：单元格文字对齐之上，表格容器本身在页面内容区内水平居中（否则会整体偏左）。
• 列宽统一策略：固定布局铺满正文区，列宽由内容智能分配并保下限（避免空 / 短列被压垮），余量按语义权重分摊；按列 min_w 不得低于该列内容最小 need（违反会把短列压到内容放不下），长列要宽应缩字 / 减列 / 传 weights 腾挪，而非反向压缩短列下限。列宽算法与精确字符宽度估算见 references/common/column-width.md（单一权威源）。
• 从源文档整表移植须全量重置（normalize_transplanted_table）：从源 .docx 整表 XML 深拷贝移植时须调用它做全量重置——删浮动属性、表头文字清黑、统一最小行高、表头仿宋 9pt、真空单元格 9pt 托底、复用黑边与表头底纹并保留源列宽。重置纪律详规见 references/common/column-width.md「六、移植表全量重置」。
• 统一最小行高（atLeast=200，两路径一致）：每表每行设 atLeast=200 消除空数据行被默认撑高；build_table 与 normalize_transplanted_table 已统一落实。生成后门禁扫描 >360 异常行高，但签章表签批区刻意留白（atLeast=3780）按签批关键词白名单豁免。
• 空单元格保持真空，绝不用占位符（如 —）填充：占位符会掩盖建表数据抽取阶段真实丢失的内容（尤其合并单元格 / 多段落单元格），制造"源文档该格为空"的假象；若交付物出现无字单元格，应先回查源数据是否漏抽，而非用占位符遮盖。真空单元格 9pt 托底由引擎统一落实。
• 枚举 / 状态列用中文表述（禁用英文 / 数字缩写）：是否类、状态类列一律用中文（如「已上线 / 未上线」「是 / 否」「通过 / 未通过」），禁用 Y/N、Yes/No、0/1 等。
• 表格三类区分（位置 / 来源 / 纪律例外）：① 审阅 / 版本信息类（文档控制页，生成器统一产出，含空签批行真空保持）；② 正文表格类（数据矩阵新建 build_table / 源文档移植 normalize_transplanted_table）；③ 末尾签章类（确认并签署，2 行 × 2 列双栏，签批区 atLeast=3780 留白豁免、水平左对齐）。差异详见各 references/format/*-format.md。
• 确认并签署章节禁止跨页（防签字页被替换）：含「确认并签署」章的文档，该章整体不得跨页——三管齐下：签章表每一行设 cantSplit（单行内部不拆）、除末行外行内所有段落设 keepNext（表头行与签批行绑成整块，防「表头留上页、签批掉下页」的行间分页）、章节标题设 keepNext（标题随表同页）；单一权威源 = add_signature_table（生成器统一落实），改此一处即覆盖验收 / 上线 / 建设方案三类。

四、封面 / 目录 / 标题页版式

• 封面主标题（操作手册封面客户名 / 手册名、验收 / 上线报告公司名 + 「<项目>验收 / 上线报告」两行）：22pt 加粗、居中；项目名未指定时第二行写「XX项目验收报告」/「XX项目上线报告」占位。
• 封面辅助信息（编写时间、版本等）：14pt、居中。
• 单一业务场景测试报告文档标题：16pt 加粗、居中（等价于一级标题规格 + 居中）。
• 无封面文档首行标题 = 文件名主体（对齐约定）：接口文档 / 功能补丁测试报告等无封面文档，首行大标题（走 add_title 公用类，16pt 加粗居中）须与文件名主体逐字一致（含「客户名-」前缀）：即文件名去掉「日期-」段与「【待确认】」后缀（如 20260914-XX公司-XX功能补丁测试报告【待确认】.docx → 首行标题 XX公司-XX功能补丁测试报告）；首行标题不得出现文件名里没有的成分（如 XX模块）。与有封面文档「封面页=文件标题」同属一个公用类对齐口径。
• 文件名日期段 = 文档编写时间（同源约定）：文件名开头的 YYYYMMDD 段与文档内部日期（封面「编写时间」/ 文档控制页版本修订行日期）须出自同一数据源——生成器 __main__ 里单次 _NOW = datetime.now()，内部日期走 get_date(_NOW)、文件名日期段走 get_date(_NOW, fmt='%Y%m%d')；禁止两处各自取时或写死日期常量（写死会与内部日期漂移，实证：文件名 20260914 vs 内部 2026年09月18日）。
• 目录标题：18pt 加粗、居中；目录由 WORD 自动目录域收集一~三级标题并预渲染所有章节条目（打开 docx 即见带点引导线、页码右对齐的完整目录，刷新域按真实页码重算）。适用验收 / 上线报告；操作手册 / 测试报告无目录页。
• 对齐分档：封面主标题、文档标题、目录标题均居中；章节正文标题随自动编号左对齐 / 两端对齐，不居中。

五、截图管理

> 截图相关版式与处理纪律统一收口本节，各能力章节只描述"有无截图"，不重复截图版式。

• 截图段落不首行缩进：缩进只针对文字段，截图 / 图片片段落不缩进。
• 图片插入统一走通用引擎：各文档插入图片统一走 common 的通用图片插入能力（按宽度插入并居中、缺失则打印提示并跳过、不崩溃）；路径解析 / 缺失策略全部收敛于 common，需求变化只改 common 一处。
• 红框只作定位标记，思考痕迹不进正文：各文档统一具备两层红线自检——① 落字即拦截（正文 / 标题 / 代码写入时即时拦截「红框」「（N图）」）；② 收尾逐段扫描兜底；任一命中即中止生成。完整规则与反例见 references/format/manual-format.md。
• 菜单 / 按钮名必须先 OCR 再写（硬纪律）：见「核心生成纪律」#2 与「OCR 强制流水线」。
• 图文混排顺序：截图前用一句文字说明操作意图，截图后配简短说明；一步多图时按操作顺序标注（图 1 / 图 2…），不强行占位、不空挂"见下图"。
• 清晰度与比例：截图需文字清晰可读、不拉伸变形；是否配图由用户判断，并非每个场景都必须配图（无截图则正常编写，不占位标注）。
• 源档图片提取（可选）：客户常提供含截图的 .doc / .docx 原稿，生成前需先抽出；旧版二进制 .doc 该能力常返回空，须改用字节切片 + Pillow 校验 + md5 去重的兜底提取，并过滤非内容图（logo / 装饰图标）。具体切片脚本细节收口 references/common/faq.md。
• 从素材手册批量选图（素材即配图语料时的规范链）：当要求"参考某目录下的素材（培训 PPT / 官方用户手册等）配套截图"时，不得把素材图直接当客户文档配图，必须走完整四步链——① 批量抽取：按文档流顺序抽出每份素材的内嵌图，同步建立「完整标题路径 → 图」索引（只存标题名会丢失父级，路径必须含全部中间层级）；② 收敛候选：平均哈希去重 + 宽高比/尺寸过滤（剔窄条、超长条等装饰件）；③ 按路径选图：以完整标题路径匹配目标章节（如【数据治理】->【元数据管理】->【元数据采集管理】->【操作说明】），禁止只凭功能名模糊匹配；④ 拼版视觉核查：候选图拼 contact sheet 一次性核查定稿，不得只看文件名或缩略图目测。四条硬判据：素材图剔除模板底板（同一素材内复用多次的封面 / 目录页 / 渐变底图）与他项目语境（其它客户名、培训演示命名、个人测试命名）；路径冲突以截图 OCR 真实文字为准改正文、不改截图（素材手册的文档路径与界面实况常不一致）。完整方法收口 references/common/faq.md。

六、页眉页脚管理

• 清空（通用 · 防御性）：各功能生成开头统一清空页眉页脚，避免继承模板 / 残留内容。
• 页码域（通用能力）：所有文档清空之后统一由脚本写入页脚页码域（第 N 页 / 共 M 页），是所有交付文档类型的标准收尾动作。
• 页脚页码字号（通用）：统一 9pt、居中对齐（字体随统一正文字体）。

通用执行方式

所有能力均通过以下两种方式之一生成，各能力 references/format/*-format.md 末尾含 data 结构定义：
- 方式 A（推荐）：构造 data 字典，传给对应 build_<xxx>(data, out_path)（操作手册 gen_manual.py 改顶部常量 OUT / IMG_DIR / COMPANY / MANUAL_NAME / steps）；
- 方式 B：直接改对应 scripts/gen_<xxx>.py 的 __main__ 示例（REPORT / DATA / DOC 等）后运行。

能力① 生成建设解决方案（常规类）

触发条件：用户说"生成 / 写一份 建设解决方案 / 项目方案 / 方案建议书 / 建设方案"，且内容以业务流程为主线（常规业务模块）。

输入清单（公用项见「通用功能约定 · 公用输入项」，此处只列本能力特有项）：
1. 方案标题
2. 章节素材：按 references/format/solution-convention-format.md 骨架（文档说明 / 项目背景与建设目标 / 整体架构及建设内容 / 实施范围 / 建设流程清单 / 现状与关键需求 / 基础设置 / 业务域章 / 专项章 / 项目价值与预期成效 / 文档附件及结论 / 确认并签署 等）；条件章无素材整体删除
3. 单元模板选型：写第一个业务域章之前，按 references/format/unit-template-selector.md 一次性确定全文共用哪一类（A 流程驱动型 / B 单据场景型 / C 现状对照型 / D 功能实现型），A 型另定基础版 / 完全体档位

产出结构：

封面（公司 / 项目 / 标题）
  ↓ 硬分页
文档控制（版本修订表 + 审阅确认表）
  ↓ 硬分页
目录（WORD 自动目录域）
  ↓ 硬分页
正文（固定章 + 条件章 + 复用章）：
  一、文档说明【条件章】  1.1 定位与目的  1.2 阅读对象与范围  1.3 术语定义  1.4 流程图说明【条件章】
  二、项目背景与建设目标  2.1 项目背景  2.2 建设目标
  三、整体架构及建设内容  3.1 设计原则  3.2 系统总体架构  3.3 系统总体流程
  四、实施范围  4.1 组织范围【条件章】  4.2 业务范围【条件章】  4.3 产品模块范围【条件章】  4.4 功能范围【条件章】
  五、建设流程清单【条件章】  5.1 流程概览  5.2 流程目录【条件章】
  六、现状与关键需求  6.1 业务现状  6.2 关键需求  6.3 问题分析【条件章】
  七、XX基础设置【条件章】  7.1 组织及人员  7.2 公共数据与客商类  7.3 编码规则  7.4 参数设置  7.5 权限与流程配置  7.6 预警信息【条件章】
  八、XX业务域【复用章】  每个业务域一个一级章，域内按流程 / 单据拆二级节，各节套用同一类单元模板
  九、专项章【条件章】
  十、项目价值与预期成效【条件章】  10.1 管理提升  10.2 预期成效
  十一、文档附件及结论【条件章】
  十二、确认并签署

> 章节三类属性与编号顺延规则见「通用功能约定 · 章节三类属性」「通用功能约定 · 条件章节省略后编号顺延」。
> 单元模板四类节结构与选型口径见 references/format/unit-template-selector.md（不进本表正文）。

能力② 生成建设解决方案（数据类）

触发条件：用户说"生成 / 写一份 建设解决方案 / 数据分析大屏建设方案 / 看板建设方案"，且内容以数据分析 / 看板为主线。

输入清单（公用项见「通用功能约定 · 公用输入项」，此处只列本能力特有项）：
1. 方案标题
2. 章节素材：按 references/format/solution-data-format.md 骨架（文档说明 / 项目背景与建设目标 / 整体架构及建设内容 / 实施范围 / 建设流程清单 / 现状与关键需求 / 数据集成与数据仓库方案【条件章】/ 业务域章 / 项目价值与预期成效 / 文档附件及结论 / 确认并签署 等）；条件章无素材整体删除
3. 各业务域的看板 / 专题素材：每个看板按「业务描述 / 指标清单（表）/ 大屏展示（图）」三段式提供

产出结构：

封面（公司 / 项目 / 标题）
  ↓ 硬分页
文档控制（版本修订表 + 审阅确认表）
  ↓ 硬分页
目录（WORD 自动目录域）
  ↓ 硬分页
正文（固定章 + 条件章 + 复用章）：
  一、文档说明【条件章】  1.1 定位与目的  1.2 阅读对象与范围  1.3 术语定义  1.4 流程图说明【条件章】
  二、项目背景与建设目标  2.1 项目背景  2.2 建设目标
  三、整体架构及建设内容  3.1 设计原则  3.2 系统总体架构  3.3 系统总体流程
  四、实施范围  4.1 组织范围【条件章】  4.2 业务范围【条件章】  4.3 功能(模块)范围【条件章】
  五、建设流程清单【条件章】  5.1 流程概览  5.2 流程目录【条件章】
  六、现状与关键需求  6.1 业务现状  6.2 关键需求  6.3 问题分析【条件章】
  七、数据集成与数据仓库方案【条件章】  7.1 数据源与集成方式  7.2 数据集成架构  7.3 维度建模方案  7.4 数据更新机制  7.5 数据填报管理
  八、XX业务域【复用章】  每个业务域一个一级章，其下按看板 / 专题拆二级节，统一「业务描述 / 指标清单 / 大屏展示」三段式
  九、项目价值与预期成效【条件章】  9.1 管理提升  9.2 预期成效
  十、文档附件及结论【条件章】
  十一、确认并签署

> 章节三类属性与编号顺延规则见「通用功能约定 · 章节三类属性」「通用功能约定 · 条件章节省略后编号顺延」。

能力③ 生成开发方案

触发条件：用户说"生成 / 写一份 开发方案 / 技术方案 / 二开方案 / 实施方案"。

输入清单（缺什么就问用户）：
1. 需求名、需求描述与业务背景
2. 调研结论与可行性判断依据（含核实方式：反汇编 / 数据字典 / 现场实测 / 接口实调）
3. 方案设计要点：建设方式 / 挂钩方式、清单（事件 / 接口）、契约或通用约定、关键设计（含备选方案与否决理由）、规则
4. 实现要点：复用哪些平台能力、关键处理规则（校验 / 事务 / 异常）、交付物与包结构
5. 验证要求：测试点、验证方法、通过标准
6. 条件章取舍：是否需要「现状调研」「开发与交付计划」「风险与对策」「待确认事项」「文档附件及结论」「附录」（确认并签署为固定章，不可省略）

产出结构：

封面（公司 / <需求名>开发方案）
  ↓ 硬分页
文档控制（版本修订表 + 审阅确认表）
  ↓ 硬分页
目录（WORD 自动目录域）
  ↓ 硬分页
正文（固定章 + 条件章）：
  一、业务需求          1.1 需求来源与原始诉求  1.4 需求点（表）
  二、现状调研与证据    【条件章】
  三、可行性分析        3.1 分维度可行性结论（表）  3.2 关键技术难点与对策  3.3 可行性总体结论
  四、方案设计（章名随方案类型：技术方案 / 接口设计）
      4.1 总体方案      建设方式 + 清单（事件 / 接口）+ 通用契约
      4.2 XX 功能点一   4.2.1 业务需求 + 4.2.2 开发方案    ← 每个功能点成对展开
      4.3 XX 功能点二   4.3.1 业务需求 + 4.3.2 开发方案
  五、实现方案          5.1 整体实现思路  5.3 平台能力复用映射（表）  5.4 关键处理规则  5.5 交付物与包结构
  六、开发与交付计划    【条件章】
  七、验证方案          7.1 测试点清单（表）  7.2 验证方法  7.3 通过标准
  八、风险与对策（表）  【条件章】
  九、待确认事项【条件章】
  十、文档附件及结论【条件章】
  十一、确认并签署
  附录 A / B …【条件章】  非编号标题承载

> 骨架取舍规则（固定章 / 条件章、功能点成对子结构、第四与第五章分工、附录用非编号标题）见 references/format/devplan-format.md。
> 条件章节省略与编号顺延规则见「通用功能约定 · 条件章节省略后编号顺延」。

能力④ 生成接口文档

触发条件：用户说"生成 / 写一份 接口文档 / 接口说明 / 对接文档"。

输入清单：
1. 各接口的名称、描述、测试 / 正式环境地址、接口类型、数据格式、请求方式
2. Header 参数（token 接口的鉴权表单参数另给）
3. 业务接口的请求字段、调用样例（JSON 报文）、返回结果样例

产出结构：

文档标题（无编号）
接口清单表（序号 / 接口描述 / 部署方式）
一、获取token接口（第一章固定）
   └ 分区整表：接口基本信息 / Header参数 / Params参数 / 服务调用样例 / 返回结果样例
二、XX单新增接口
   └ 分区整表：接口基本信息 / Header参数 / [请求字段说明] / 调用样例 / 返回结果样例

关键约定：
- 第一章固定为获取 token 接口（业务接口调用前须先取 token），其分区与调用样例与业务接口不同。
- 无封面 / 修订记录 / 目录 / 概述，直入主题；接口清单表紧跟文档标题，不另立「接口清单」标题行。
- 环境地址未明确前统一 ip:port 占位；部署方式默认「本地部署」。

能力⑤ 生成单一业务场景测试报告

触发条件：用户说"生成 / 写一份 测试报告（单一业务场景）/ 功能补丁测试报告 / 测试记录"。

输入清单：
1. 需求描述、需求分析（用户通常直接给）
2. 开发方案文档 / 需求确认文档 → 我据此自行补全 3~6 章
3. 测试截图：有则插入；无则正常编写即可，不强制、不占位标注

产出结构（固定标准章节，细化至二级标题）：

文档标题
一、需求描述          一句话讲清客户要什么
二、需求分析          实现思路、过滤条件、边界情况
三、系统配置          3.1/3.2… 配置项、SQL 视图、插件注册
四、补丁/功能测试点   测试点汇总表：序号 / 测试点 / 测试结果 / 测试问题
五、补丁/功能测试记录 5.1/5.2… 操作步骤（二级标题）+ 每步截图证据
六、测试结果          结论 + 调整项(加粗) + P.S. 备注

能力⑥ 生成单功能操作手册

触发条件：用户说"生成 / 重做 / 更新 操作手册（单功能）/ 流程手册 / 步骤手册 / 交付文档"。

输入清单（缺什么就问用户；客户名属公用项，见「通用功能约定 · 公用输入项」）：
1. 手册名（如"资金计划项目新增操作手册"）
2. 每个操作步骤的一句话概述 + 对应截图（截图目录路径）

产出结构：

第 1 页 封面      客户名 / 手册名 + 编写时间 / 版本
第 2 页 版本修订   4 列表格（日期 / 负责人 / 版本 / 说明）
第 3 页 正文      一级标题 + 说明段落 + 步骤截图

能力⑦ 生成上线报告

触发条件：用户说"生成 / 写一份 上线报告 / 系统上线报告 / 项目上线报告"。

输入清单（公用项见「通用功能约定 · 公用输入项」，此处只列本能力特有项）：
1. 上线概况素材：项目背景、建设目标、上线系统清单、业务模块【条件章】、组织范围【条件章】、上线成果、应用价值、上线结论、后期计划【条件章】
2. 截图：有则插入；无则正常编写即可，不强制、不占位标注

产出结构：

封面（公司 / 项目 / 标题）
  ↓ 硬分页
文档控制（版本修订表 + 审阅确认表）
  ↓ 硬分页
目录（WORD 自动目录域）
  ↓ 硬分页
正文（固定标准章节，细化至二级标题）：
  一、概述        1.1 项目背景  1.2 建设目标
  二、上线范围    2.1 上线系统  2.2 业务模块【条件章】  2.3 组织范围【条件章】
  三、上线成果及价值  3.1 上线成果  3.2 应用价值
  四、上线结论
  五、后期计划【条件章】
  六、确认并签署

> 条件章节省略与编号顺延规则见「通用功能约定 · 条件章节省略后编号顺延」。

能力⑧ 生成验收报告

触发条件：用户说"生成 / 写一份 验收报告 / 总结验收报告 / 项目验收报告 / 结项报告"。

输入清单（公用项见「通用功能约定 · 公用输入项」，此处只列本能力特有项）：
1. 项目概况素材：建设目标、实施历程 / 阶段、组织范围 / 用户范围 / 业务范围 / 功能(模块)范围、项目价值 / 总体评价、经验总结、待跟进事项、持续支持与未来规划、验收结论等
2. 截图：有则插入；无则正常编写即可，不强制、不占位标注

产出结构：

封面（公司 / 项目 / 标题）
  ↓ 硬分页
文档控制（版本修订表 + 审阅确认表）
  ↓ 硬分页
目录（WORD 自动目录域）
  ↓ 硬分页
正文（固定标准章节，细化至二级标题）：
  一、项目概述        1.1 项目建设背景  1.2 项目建设目标
  二、实施历程        2.1 项目实施阶段（规划→蓝图设计→系统建设→上线运行→持续支持 五阶段）
  三、建设范围        3.1 组织范围【条件章】 3.2 用户范围【条件章】 3.3 业务范围【条件章】 3.4 功能(模块)范围【条件章】
  四、项目价值与总体评价  4.1 主要应用成效  4.2 总体评价
  五、经验总结
  六、待跟进事项【条件章】  6.1 遗留问题与风险  6.2 后续优化建议
  七、持续支持与未来规划  7.1 运维与持续支持  7.2 未来规划
  八、验收结论
  九、确认并签署

> 条件章节省略与编号顺延规则见「通用功能约定 · 条件章节省略后编号顺延」。

前置准备（复用优先 · 禁止无脑重装）

> 适用场景：当你在本机运行任一 gen_*.py 生成文档、或首次跑 _ocr_rapid.py 做截图识别时，若解释器报 ModuleNotFoundError / 依赖缺失，或准备在全新环境首次生成——此时不要从零 pip install 重装整套环境。正确顺序是先复用已装好的隔离 venv，只补装真正缺失的包：依赖装进隔离 Python 环境是为了不污染全局，不是为了每次重装一遍。

1. 先复用：本机已有 WorkBuddy 隔离 venv（依赖通常已齐），直接用它的 python，不新建、不重装：
   C:\Users\<用户名>\.workbuddy\binaries\python\envs\default\Scripts\python.exe
2. 再自检（一条命令判定，不靠猜）：
   bash python scripts/check_env.py --py <上述解释器路径> # 不带 --py 时检查当前解释器
   逐包标注 OK / MISSING，结论行给出「仅补装缺失项」的命令；必需依赖齐备时打印「无需任何 pip 安装」，直接进入生成 / OCR 步骤。
3. 缺什么补什么：仅当自检报 MISSING 时对缺失项 pip install <缺包>，禁止全量重装。
4. 仅当 venv 不存在才创建隔离 venv 并安装（属例外，非常规动作）：
   python -m venv <venv 路径> 后 pip install python-docx lxml rapidocr-onnxruntime pillow numpy。

• python-docx + lxml：生成 Word 文档（必需）。
• rapidocr-onnxruntime + pillow + numpy：截图中文识别辅助、按字体度量精算文本宽度（可选；缺 pillow 时宽度改走全角 / 半角估算，不影响生成；首次运行 OCR 会自动下载 ONNX 模型，之后离线可用）。
• 系统需安装统一正文字体（默认仿宋；配置为其他字体时须安装对应字体，缺字体中文回退默认字体、版式仍成立但非规范字体）。
• OCR 硬纪律按本机是否装 OCR 自动分派（代码硬门 + 自动检测，不卡死分享场景）：见「OCR 强制流水线」与「核心生成纪律」#2。

文件清单

yonyou-js-djw-word/
├── SKILL.md     本技能说明：用友实施交付类 Word 文档生成（各类交付文档，可按需扩展）
├── references/
│   ├── common/
│   │   ├── faq.md                技能问题题库（试错归此，正文不重述）
│   │   ├── column-width.md       表格列宽分配 + 移植表全量重置通用方法论（单一权威源）
│   │   └── scenario-examples.md  场景示例库
│   └── format/
│       ├── acceptance-report-format.md    验收报告版式规范
│       ├── devplan-format.md              开发方案版式规范
│       ├── interface-doc-format.md        接口文档版式规范
│       ├── manual-format.md               操作手册版式规范
│       ├── online-report-format.md        上线报告版式规范
│       ├── solution-convention-format.md  建设解决方案（常规类）版式规范
│       ├── solution-data-format.md        建设解决方案（数据类）版式规范
│       ├── test-report-format.md          测试报告版式规范
│       └── unit-template-selector.md      常规类方案单元模板选型速查库
└── scripts/
    ├── _ocr_rapid.py             OCR 辅助脚本；批量跑全部截图生成 ocr_evidence.txt，供各 gen_*.py 的 OCR 硬门校验
    ├── check_env.py              环境自检脚本：逐包判定 OK/MISSING 并给出「仅补装缺失项」命令
    ├── common.py                 公共函数库
    ├── measure_text.py            文本渲染宽度测量与超宽行诊断（供装饰横线自适应与版式超宽自检复用）
    ├── font_config.json          统一正文字体配置（font/code_font/configured；默认仿宋）
    ├── gen_acceptance_report.py  验收报告生成器
    ├── gen_devplan.py            开发方案生成器
    ├── gen_interface_doc.py      接口文档生成器
    ├── gen_manual.py             操作手册生成器
    ├── gen_online_report.py      上线报告生成器
    ├── gen_solution.py           建设解决方案生成器（常规类 / 数据类双入口）
    ├── gen_test_report.py        测试报告生成器
    └── template.py               文档模板（字体单源加载入口）