技能介绍

要解决什么问题

用友实施项目里，操作手册、测试报告、验收报告往往要反复对齐版式：仿宋与标题层级、自动编号、黑边表格、封面分页、页脚「第 N 页 / 共 M 页」等。手写 Word 或零散脚本容易在 OOXML / python-docx 上踩坑（标题继承 Heading 变蓝加粗、编号数字回退 Arial、表格整体偏左等），返工也常集中在「交付物写了不该写的内容」——补丁编号、内部函数、用户给的元指令、红框自述句混进正文。

本技能把跨项目可复用的版式约定和三类交付物的结构骨架固化下来，用脚本一次性生成 .docx，并与既有规范文档做过逐字对齐验证。

技能如何工作

按交付物类型选用能力，共用 template.py 与 通用版式约定（字体行距、三级标题 + 自动编号、表格居中与列宽、截图段落不缩进、统一页眉页脚清空后写入页码域）：

操作手册：封面 + 版本修订 + 图文步骤正文；改 scripts/gen_manual.py 顶部常量（客户名、手册名、steps 与截图目录）。
测试报告：固定六段章节结构；构造 data 字典调用 build_report，或由需求/方案文档补全中间章节。
验收报告：封面 → 文档控制 → 自动目录域 → 正文 → 签章表；build_acceptance_report(data, out_path)，签章双栏结构见格式 reference。

生成纪律包括：文件名带 【待确认】、输出到当前工作空间绝对路径、不覆盖已有文件；菜单/按钮名建议先 RapidOCR 对照截图再落字；从 PPT 搬表时 序号列须按 Word 内 01/02/03 重编。

边界与注意点

技能是「写文档的方法论 + 生成器」，不收录具体客户名、补丁名、某次任务的原话；占位用 XX公司 / XX模块。测试报告正文聚焦系统功能验证，不写补丁/代码层；用户元指令只指导生成，不进交付正文。终版流程：测试结果据实改为通过/失败后，去掉【待确认】另存，不覆盖草稿。详细红线与 data 范例见技能内 references/（如 faq.md、scenario-examples.md、各 *-format.md）。

截图预览

使用场景

某资金/供应链等模块即将上线，手头有一组逐步截图，要生成带封面、版本修订页与自动编号步骤的操作手册。
客开或补丁功能测完后，需按固定六章结构写测试报告，正文只写系统功能与结论，不写补丁编号和内部实现。
阶段或项目验收前，要把建设目标、模块范围、评价与待跟进事项填入模板，产出带目录域和甲乙签章表的验收报告。
参考 PPT 里的表格搬进 Word 交付物时，需把序号列改成 01/02/03 连续编号，并套用黑边表头与表格整体居中版式。

适合人员

用友或 YonBIP 实施顾问，在单模块交付时要交操作手册并保证仿宋、分页与截图段落版式与客户规范一致。
负责客开/补丁场景验证的实施测试人员，要把需求分析与测试点表写成面向最终用户的测试报告而非开发记录。
项目经理在验收节点需把项目概况、模块范围与甲乙确认信息整理成可签署的验收报告 Word。
维护客户交付物模板的实施文档负责人，希望操作手册、测试报告、验收报告共用同一套编号、表格与页码域实现。

用友实施交付文档生成