@zeyue0329/xiaoma-cli 1.11.0 → 1.13.0

package/patent-disclosure-optimized/SKILL.md

@@ -0,0 +1,416 @@
+---
+name: patent-disclosure
+description: "软件专利交底书撰写技能。从完整的软件项目（代码仓库、设计文档、需求文档等）中挖掘专利创新点，并生成符合专利代理人要求的技术交底书 Word 文档（.docx）。核心输出三要素：解决的技术问题、采用的技术手段、达到的技术效果。输出文档模拟人类开发工程师写法，去除 AI 味道。当用户提到以下任何内容时务必触发此技能：专利交底书、技术交底、专利挖掘、专利申请材料、发明创造点、从代码中提取专利、软件专利撰写、知识产权交底、创新点挖掘、写交底书、patent disclosure。即使用户只是随口问'这个项目有没有能申请专利的点'、'帮我看看能不能写个专利'、'这个功能能申请专利吗'，也应当触发本技能。也包括用户要求分析项目代码或文档来寻找可申请专利的技术方案，或者讨论某个技术实现是否有专利价值、如何将代码逻辑转化为专利方案等场景。"
+compatibility: "Requires docx skill for Word document generation. Requires bash and Node.js runtime."
+---
+
+# 软件专利交底书撰写技能
+
+## 概述
+
+本技能指导 Claude 从软件项目全量材料（源代码、设计文档、需求规格、架构图等）中系统性地挖掘专利创新点，并输出规范的技术交底书 Word 文档。
+
+**执行前必读**：在开始任何工作前，先读取以下两份参考文档——它们是本技能的权威参考，遇到细节冲突时以参考文档为准：
+
+- `references/mining-principles.md` — 专利挖掘判定原则（三要素判定法、否定/肯定情形、常见规避问题）
+- `references/disclosure-template.md` — 交底书模板（章节结构、各部分撰写要求、注意事项）
+
+---
+
+## 第一阶段：项目理解与材料收集
+
+拿到项目后，先建立全局认知，不要急于寻找专利点。
+
+### 1.1 扫描项目结构
+
+根据项目语言选择合适的扫描方式。优先使用 `Glob` 工具按文件类型模式匹配（如 `**/*.java`、`**/*.py`、`**/*.ts`），再用 `Read` 工具阅读关键文件。同时检查构建配置文件（pom.xml、build.gradle、package.json、pyproject.toml 等）了解技术栈。
+
+### 1.2 阅读文档材料
+
+按优先级阅读：
+1. README 和项目说明
+2. 架构设计文档、概要设计
+3. 需求规格说明书
+4. 数据库设计文档（DDL、ER图描述）
+5. 接口文档、API 说明
+
+### 1.3 分析核心代码
+
+重点关注：
+- 核心业务逻辑层（Service / Domain）
+- 自定义算法和策略模式实现
+- 中间件集成和自研组件
+- 分布式协调、缓存策略、消息处理
+- 数据库查询中的复杂逻辑（存储过程、复杂SQL）
+- 异常处理和容错机制
+
+### 1.4 现有技术调研（可选但推荐）
+
+如果环境中有搜索工具（如 Tavily MCP 或 WebSearch），可用于辅助调研：
+- 搜索同领域已有专利的技术方案，帮助定位创新点的差异化
+- 了解行业通用做法，为"技术背景"章节提供素材
+- 确认候选创新点是否已有类似公开专利
+
+### 1.5 形成项目认知备忘
+
+整理出：项目所属技术领域、整体架构模式、技术栈清单、核心业务流程、与外部系统的集成关系。
+
+---
+
+## 第二阶段：专利点挖掘
+
+这是整个流程中最关键的判定环节。**必须先阅读 `references/mining-principles.md`**，其中包含完整的三要素判定法、否定情形、肯定情形示例、常见表述陷阱等核心判定标准。
+
+### 2.1 判定流程
+
+对每个候选创新点，按三要素公式自检（详见参考文档）：
+
+**因为（技术问题）** → **所以（技术手段）** → **结果（技术效果）**
+
+三步都能填满且逻辑自洽 = 合格专利点。某一步含糊或填不出来 = 不够成熟。
+
+### 2.2 关键排除项（速查）
+
+以下情况不构成合格专利方案（详细说明和示例见 `references/mining-principles.md`）：
+- 泛化业务需求、非技术问题、模糊描述
+- 非技术手段、简单组合现有技术、纯智力/管理规则
+- 仅有商业收益、运营效果、主观体验
+- 纯代码/纯公式/纯算法原理（建议走软著）
+- 直接使用开源框架的标准功能
+- 纯 CRUD 操作
+- 通用设计模式的常规应用
+
+### 2.3 高价值方向识别
+
+在软件项目中，以下方向容易产出合格专利点：
+
+- **架构层**：新型服务拆分/聚合策略、自研服务治理机制、多数据源协同一致性方案、特定场景的缓存架构
+- **算法层**：业务规则引擎实现方式、自定义数据匹配/校验算法、复杂查询优化策略、状态机流转控制逻辑
+- **流程层**：多步骤审批编排机制、异步任务调度和补偿策略、跨系统数据同步方案、批量处理分片并行策略
+- **可靠性层**：数据加密/脱敏机制、分布式锁应用和实现、幂等性保障方案、灾备和故障恢复策略
+
+### 2.4 输出候选专利点清单
+
+完成分析后，向用户呈现候选列表，每个点包含：
+- 创新点名称（一句话概括）
+- 所属模块/代码位置
+- 三要素初步描述（问题→手段→效果，各1-2句话）
+- 建议优先级（高/中/低）
+
+**在此暂停，等待用户确认要撰写哪些点后再进入下一阶段。**
+
+同时收集交底书所需的基本信息（如果用户尚未提供）：
+- 发明人姓名（可以有多位）
+- 技术问题联系人及联系方式（电话、邮箱）
+- 是否有特定的保密要求
+
+---
+
+## 第三阶段：交底书撰写
+
+### 3.1 文档结构
+
+交底书结构来自 `references/disclosure-template.md`，按以下章节顺序输出：
+
+```
+交底书名称：一种基于XXX的YYY方法/系统
+发明人：（由用户提供）
+技术问题联系人：（由用户提供）
+
+该发明所属技术领域：
+术语解释：
+
+1、详细介绍技术背景，并描述已有的与本发明最相近似的实现方案
+2、现有技术的缺点是什么？针对这些缺点，说明本发明的目的
+3、本发明技术方案的详细阐述（结合附图说明）
+   3.1 基本原理
+   3.2 详细的技术方案
+4、与第1部分所述的现有技术相比，本发明有何优点
+5、本发明的关键点和欲保护点是什么？
+6、针对第3部分的技术方案，是否还有别的替代方案同样能完成发明目的？
+```
+
+### 3.2 各章节撰写要点
+
+#### 交底书名称
+格式："一种基于XXX的YYY方法/系统/装置"。体现核心技术手段和应用领域，不出现商标/产品名/公司名，控制在25字以内。
+
+#### 技术领域
+一句话说明。示例："本发明涉及计算机软件技术领域，具体涉及一种分布式系统中的数据一致性保障方法。"
+
+#### 术语解释
+列出代理人可能不理解的专业术语。英文缩写必须有中文译文。全文对同一事物叫法统一。
+
+#### 第1部分：技术背景与最相近方案
+- 描述行业中处理同类问题的通用做法（不点名竞品）
+- 客观分析现有做法的技术局限，要有技术细节支撑
+- 可以引用技术原理解释为什么现有方案存在瓶颈
+
+#### 第2部分：现有技术缺点与发明目的
+- 缺点要与本发明的优点对应——本发明不能解决的缺点不必写
+- 找不出对比方案缺点时用反推法：根据本发明优点找对应缺点
+- 缺点描述要具体：成本高、效率低、误码率高、反应速度慢等
+
+#### 第3部分：技术方案详细阐述（核心章节）
+
+这是交底书最重要的部分，代理人写权利要求书主要依赖此章节。
+
+**3.1 基本原理**：从原理层面概括说明如何解决上述技术问题。
+
+**3.2 详细技术方案**，必须做到：
+- 说明系统包括哪些模块，各模块如何连接和协作
+- 各模块分别起什么作用、完成什么功能
+- 哪个部件、哪种连接是创新点，具体描述结构细节
+- 方法类专利需说明流程步骤，从数据流角度详细描述
+- 涉及数据结构的要说明字段含义
+- 涉及算法的要描述完整逻辑流程
+- 异常场景的处理也要覆盖
+
+**容易踩的坑**（专利法第26条"充分公开"要求）：
+- 只写原理不写实现步骤——审查员无法判断方案是否可行
+- 只描述功能不说明技术手段——"功能限定"是最常见的驳回理由
+- 标准是：本领域技术人员读完后不需要额外创造性劳动就能实现
+
+#### 第4-6部分
+- **第4部分**：结合技术方案，用因果关系推理说明优点，对应第2部分发明目的
+- **第5部分**：提炼关键创新点列表（1、2、3...），对应第4部分有益效果的关键技术点
+- **第6部分**：写明替代方案（部分结构/方法步骤的替代或完整替代方案），有助于扩大保护范围
+
+#### 附图说明
+列出建议配图内容（实际绘图由用户完成）：方法专利必须提供流程图，并提供相关的系统装置图。所有附图都应有详细文字描述，附图中的标注尽量用中文。
+
+---
+
+## 第四阶段：去 AI 味道——工程师写作风格
+
+专利代理人每天审阅大量交底书，AI 生成的文档有明显的"机器感"。以下风格指南帮助输出更接近真实工程师的写作习惯。
+
+### 4.1 用词替换表
+
+| 避免（AI 味道重） | 改用（工程师习惯） |
+|---|---|
+| 本发明创造性地提出了 | 本方案采用了 |
+| 显著地提升了性能 | 实测吞吐量提升约40% |
+| 巧妙地解决了 | 通过XX方式解决了 |
+| 革命性的/突破性的 | （删除，直接说效果数字） |
+| 不可忽视的优势 | 主要改进在于 |
+| 值得注意的是 | （删除，直接说） |
+| 在一个实施例中 | 以XX场景为例 |
+| 综上所述 | （一般不需要，直接写结论） |
+| 确保了系统的鲁棒性 | 当XX异常时，系统通过YY机制恢复 |
+| 本发明旨在 | 本方案的目标是 |
+| 进一步地 | 在此基础上 |
+| 需要说明的是 | （直接说，不加前缀） |
+| 可以理解的是 | （删除） |
+| 作为一种可选的实施方式 | 另一种做法是 |
+
+### 4.2 工程师句式特征
+
+- 喜欢用具体数字："响应时间从3s降到200ms"而不是"大幅提升"
+- 会提到具体技术组件："使用 Redis 的 SETNX 命令实现分布式锁"
+- 描述逻辑偏好时序结构："先...然后...最后..."
+- 解释设计决策："之所以选择XX，是因为..."、"这里用XX而不是YY，主要考虑是..."
+- 坦诚取舍："这种方式会增加约15%的内存开销，但换来了..."
+- 常用短句，段落不超过3-6句话
+- 夹杂技术术语英文原词（failover、sharding、backpressure）
+- 用括号补充说明："消息队列（本方案使用 RocketMQ）"
+
+### 4.3 内容真实感
+
+- 性能数据要合理（不写不可能的数字）
+- 技术选型符合实际生态（Java 项目不会用 Go 的库）
+- 可以轻描淡写提一句方案局限性，显示作者客观性
+- 适当使用"实际运行中"、"生产环境下"等词汇增强真实感
+
+### 4.4 自检清单
+
+撰写完成后，逐段检查：
+- [ ] 有没有"显著"、"创造性"、"巧妙"等 AI 常用评价词？删掉
+- [ ] 有没有空泛的效果描述？替换为具体数据或技术指标
+- [ ] 技术方案部分是否有纯原理或纯功能表述？补充实现细节
+- [ ] 每个技术效果是否都能追溯到具体的技术手段？建立因果链
+- [ ] 术语是否统一？同一事物是否存在多种叫法？
+- [ ] 英文缩写是否都有中文解释？
+
+### 4.5 完整段落 Before/After 示例
+
+**Before（AI 味道浓）**：
+
+> 本发明创造性地提出了一种高效的票据签收处理方法。该方法显著提升了系统的处理能力，巧妙地解决了传统方案中存在的性能瓶颈问题。通过采用先进的批量处理技术，本发明确保了系统在高并发场景下的鲁棒性，实现了革命性的性能突破。
+
+**After（工程师风格）**：
+
+> 本方案针对票据签收环节的并发处理问题，采用了请求合并+批量校验的方式。具体做法是：将200ms时间窗口内到达的签收请求合并为一个批次，对同一承兑人的票据共享额度查询结果，避免重复调用外部征信接口。实测在300笔/秒的并发压力下，单笔平均处理耗时从4.2s降到了380ms，数据库查询次数减少约65%。这种方式会引入最多200ms的额外等待，但在票据业务场景下（用户对秒级延迟不敏感）是可接受的。
+
+---
+
+## 第五阶段：生成 Word 文档
+
+交底书输出为 .docx 格式。**必须先阅读 docx skill 获取 docx-js 最新的使用指南和注意事项**（路径通常在同级 skills 目录下的 `docx/SKILL.md`）。docx skill 中包含了完整的文档创建、验证流程和关键规则，务必遵循。
+
+> **格式权威参考**：本节给出的字体、字号、行距、颜色、首行缩进、对齐方式全部来自客户提供的《技术交底书模板.doc》。若客户另外给出模板文件，应以客户模板为准，并按相同方法（unpack → 读 styles.xml + document.xml）提取规范后覆盖此处默认值。
+>
+> 详细格式速查表见 `references/docx-format-spec.md`。
+> 已封装的转换实现见 `scripts/md2docx.js`（推荐直接调用，无需重复编写）。
+
+### 5.1 页面与基本参数
+
+| 项目 | 取值 | 备注 |
+| --- | --- | --- |
+| 纸张 | A4 | 宽 11906 × 高 16838 DXA |
+| 上下页边距 | 2.54cm（1440 DXA） | |
+| 左右页边距 | 3.17cm（1800 DXA） | 即模板默认值 |
+| 页码 | 底部居中，9pt | 用 `PageNumber.CURRENT` |
+| 默认颜色 | 黑色 `#000000` | 蓝色 `#0000FF` 仅用于占位提示语，正式内容一律用黑色 |
+
+### 5.2 四类段落样式（**严格执行**）
+
+字号单位说明：docx-js 的 `size` 字段使用半磅，10.5pt = 21，18pt = 36，9pt = 18。
+
+| 段落类型 | 触发条件 | 东亚字体 | 西文字体 | 字号 | 字形 | 对齐 | 行距 | 首行缩进 |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| 大标题 | 仅文档首行的「技术交底书」 | 楷体_GB2312 | Times New Roman | 18pt（sz=36） | 加粗 | 居中 | 固定 21pt（line=420 exact） | 无 |
+| 头部字段 | `**交底书名称：**…` `**本专利发明人：**…` `**技术问题联系人：**…` `**联系人电话：**…` `**E-MAIL：**…` 五行 | 仿宋_GB2312 | Times New Roman | 10.5pt（sz=21） | 加粗 | 左对齐 | 1.5x（line=360 auto） | 无 |
+| 章节标题 | Markdown `#` / `##` / `###` / `####` | 楷体_GB2312 | Times New Roman | 10.5pt（sz=21） | 加粗 | 左对齐 | 固定 21pt（line=420 exact） | 无 |
+| 正文 | 其余段落、列表、表格内文字 | 宋体 | Times New Roman | 10.5pt（sz=21） | 常规 | 两端对齐（both） | 1.5x（line=360 auto） | 2 个汉字（firstLine=420 twips） |
+| 行内代码 / 代码块 | `` `code` `` / ``` ``` ``` | 宋体（兜底） | Consolas | 10pt（sz=20） | 常规 | 左对齐 | 1.25x（line=300 auto） | 无；底色 `#F5F5F5` |
+| 表格表头 | 表格首行 | 宋体 | Times New Roman | 10.5pt | 加粗 | 居中 | 1.25x | — |
+| 表格单元格 | 表格其它行 | 宋体 | Times New Roman | 10.5pt | 常规 | 左对齐 | 1.25x | — |
+| 附图 | 独立成行的 `![alt](path)` | — | — | 等比缩放至内容宽度 540px / 高度上限 720px | — | 居中 | 1.5x | — |
+| 图注 | 紧跟附图，沿用 alt 文字 | 宋体 | Times New Roman | 10pt（sz=20） | 斜体 | 居中 | 1.25x | — |
+
+### 5.3 docx-js API 关键写法
+
+docx-js 中 `font` 字段必须显式区分四个槽位，否则东亚字体会被覆写：
+
+```js
+// ❌ 错误：name 会被同时填到 eastAsia，把中文字体清掉
+new TextRun({ text: "中文 English", font: { name: "Times New Roman", eastAsia: "宋体" } });
+
+// ✅ 正确：分别声明 ascii / hAnsi / cs / eastAsia
+new TextRun({
+  text: "中文 English",
+  font: { ascii: "Times New Roman", hAnsi: "Times New Roman", cs: "Times New Roman", eastAsia: "宋体" },
+  size: 21,
+  color: "000000",
+});
+```
+
+颜色字段必须传 6 位十六进制不带 `#`：
+
+```js
+new TextRun({ ..., color: "000000" }); // 全文统一黑色；蓝色 "0000FF" 仅用于占位提示
+```
+
+### 5.4 附图嵌入（**强制：必须真正嵌入图片，不可用文本描述代替**）
+
+代理人审阅交底书时需要直接看到附图。生成 docx 时，md 中的 `![alt](path)` 必须被解析为真实图片嵌入到对应位置，**严禁**保留 `[附图1 - 四遍扫描整体流程](media/doc1_fig1.png)` 这类纯文本形式。
+
+#### 5.4.1 Markdown 写法
+
+附图必须 **独立成行**：
+
+```markdown
+![附图1 - 四遍扫描整体流程](media/doc1_fig1.png)
+```
+
+不要把附图与正文混排在同一段；非独立行的 `![]()` 不会触发图片嵌入。
+
+#### 5.4.2 文件组织
+
+- 每篇交底书 md 的同目录下建立 `media/` 子目录，把附图统一放在里面
+- 命名建议：`doc{交底书序号}_fig{图序}.png`，如 `media/doc1_fig1.png`、`media/doc2_fig3.png`
+- 路径解析以 md 文件所在目录为基准，支持相对路径或绝对路径
+
+#### 5.4.3 嵌入规则（已在 `scripts/md2docx.js` 中实现）
+
+| 项 | 取值 |
+| --- | --- |
+| 支持格式 | png / jpg / jpeg / gif / bmp / svg |
+| 真实像素读取 | png：解析 IHDR 块；其它：按 4:3 兜底 |
+| 目标宽度 | 540 px（≈A4 内容区宽 8306 DXA 留少量边距） |
+| 高度上限 | 720 px；超限时按高度反算宽度 |
+| 缩放方式 | 等比，绝不拉伸 / 绝不裁剪 |
+| 图片段落 | 居中，1.5x 行距，段前 120 / 段后 40 twips |
+| 图注 | 自动用 `alt` 文本生成；居中宋体 10pt 斜体；alt 为空时不输出 |
+| 容错 | 图片不存在时插入红色 `[图片缺失] alt (src)`，不中断转换 |
+
+#### 5.4.4 docx-js 关键写法
+
+```js
+new ImageRun({
+  type: "png",                                // 必填
+  data: fs.readFileSync(absPath),
+  transformation: { width: 540, height: 360 },
+  altText: { title: alt, description: alt, name: path.basename(absPath) }, // 三字段全填
+});
+```
+
+`scripts/md2docx.js` 已封装路径解析、IHDR 读取、等比缩放、图注、容错；直接调用脚本即可，无需手写 ImageRun。
+
+### 5.5 生成流程
+
+推荐路径（无需重复造轮子）：
+
+1. 阅读 docx skill（`docx/SKILL.md`），掌握 docx-js 基本规则与 `scripts/office/validate.py` 的调用方式
+2. `npm install docx`（项目级或工作区）
+3. 把 md 与 `media/` 子目录放好；md 中通过 `![alt](media/xxx.png)` 引用附图
+4. 直接调用本技能自带的 `scripts/md2docx.js`：
+   ```bash
+   node patent-disclosure-optimized/scripts/md2docx.js \
+     专利交底书_<发明名称简写>_<YYYYMMDD>.md \
+     专利交底书_<发明名称简写>_<YYYYMMDD>.docx
+   ```
+   脚本会按 5.2 / 5.4 节规范自动处理：大标题、五个头部字段、章节标题、正文、表格、列表、代码块、**附图嵌入与图注**。
+5. 用 `docx/scripts/office/validate.py` 校验生成文件
+6. 解包抽样核对（**附图与字体颜色都要查**）：
+   ```bash
+   python scripts/office/unpack.py 输出.docx tmp/
+   grep -oE 'w:eastAsia="[^"]+"' tmp/word/document.xml | sort | uniq -c
+   grep -oE 'w:color w:val="[A-F0-9]+"' tmp/word/document.xml | sort | uniq -c
+   ls tmp/word/media/ | wc -l   # 内嵌图片数应等于 md 中独立 ![]() 行数
+   ```
+   期望：
+   - 楷体_GB2312（标题）≥ 章节数；仿宋_GB2312 = 5（五个头部字段）；其余 = 宋体
+   - 颜色仅 `000000`（除非保留蓝色占位语）
+   - **`tmp/word/media/` 下图片数 = md 中独立 `![](...)` 行数**
+7. 将最终文件保存到用户的工作目录
+
+### 5.6 文档命名
+
+`专利交底书_<发明名称简写>_<日期YYYYMMDD>.docx`
+
+### 5.7 客户给了不同模板的情况
+
+若客户提供新模板（如《技术交底书模板.doc》），按以下流程更新格式：
+
+1. 用 `soffice.py --convert-to docx` 把 .doc 转为 .docx
+2. `python scripts/office/unpack.py 模板.docx tmpl/` 解包
+3. 读 `tmpl/word/styles.xml`（默认 rFonts、字号、行距）与 `tmpl/word/document.xml`（实际样例段落的 rPr）
+4. 重点提取：默认字体（rFontsDefault）、行距（spacing.line + lineRule）、首行缩进（ind.firstLineChars / firstLine）、各类标题字体与颜色、占位提示语颜色（如 `0000FF`）
+5. 把新参数覆盖到 `scripts/md2docx.js` 顶部的常量（FONT_BODY_EAST / FONT_HEADING_EAST / FONT_TITLE_EAST / FONT_HEADER_FIELD_EAST / SIZE_BODY / SIZE_TITLE / BODY_LINE_SPACING / HEADING_LINE_SPACING / BODY_FIRST_LINE_INDENT），同时在本节表格里记录变更
+
+---
+
+## 工作流程总结
+
+```
+用户提交项目材料（代码仓库 + 文档）
+      |
+[阶段1] 扫描结构 → 读文档 → 分析核心代码 → （可选）现有技术调研 → 形成项目认知
+      → 输出：项目技术概况备忘
+      |
+[阶段2] 阅读 mining-principles.md → 三要素判定法筛选 → 排除否定情形 → 输出候选清单
+      → 输出：候选专利点列表（含优先级）
+      |
+      ⏸️  暂停：等用户确认写哪些点 + 收集发明人信息
+      |
+[阶段3] 阅读 disclosure-template.md → 按模板6章节结构逐章撰写
+      → 输出：交底书文本初稿
+      |
+[阶段4] 逐段去 AI 味道检查 → 自检清单过一遍
+      → 输出：工程师风格的终稿
+      |
+[阶段5] 阅读 docx skill → 生成 .docx → 校验 → 交付
+      → 输出：专利交底书_XXX_日期.docx
+```

package/patent-disclosure-optimized/references/disclosure-template.md

@@ -0,0 +1,84 @@
+**技术交底书**
+
+**交底书名称：**
+
+**本专利发明人：刘二杨**
+
+**技术问题联系人: 刘二杨**
+
+**联系人电话：** 13473186668
+
+**E-MAIL：** [liueryang@yljr.com]{.underline}
+
+**该发明所属技术领域：**
+
+**术语解释：**(请将您认为代理人可能不理解的术语进行解释)
+
+**1、详细介绍技术背景,并描述已有的与本发明最相近似的实现方案**
+
+> （背景技术及现有技术方案）
+
+**2、现有技术的缺点是什么？针对这些缺点，说明本发明的目的。**
+
+> （请客观评价，现有技术的缺点是针对于本发明的优点来说的，本发明不能解决的缺点不必写；基于本发明能解决的问题写出发明的目的。
+>
+> 2.1
+> 如果找不出对比技术方案及其缺点，可用反推法，根据本发明的优点来找现有技术对应的缺点；
+
+2.2 本发明不能解决的缺点，不需提供；
+
+2.3 缺点可以是成本高、效率低、不环保、误码率高、反应速度慢等类似问题。）
+
+> **3、本发明技术方案的详细阐述，应该结合附图进行说明（附图可以是流程图、原理框图、电路图、时序图等）**
+>
+> （所有附图都应该有详细的文字描述，同时附图中的关键词或方框图中的注释都尽量用中文；方法专利都应该提供一个流程图，并提供相关的系统装置）。
+>
+> 3.1 基本原理（从原理、概括的层次说明本发明是如何解决上述技术问题的？）
+>
+> 3.2
+> 详细的技术方案*（*专利必须是一个技术方案，应该阐述发明目的通过什么技术方案来实现的，不能只有原理，也不能只做功能介绍.
+> ）
+
+*例如，对于您开发完成的产品而言，包括哪些模块（部件），各个模块（部件）之间是如何相关连接和相互工作的？各个模块（部件）分别起什么作用，完成什么功能？*
+
+*对于您需要保护的结构而言，哪个部件、哪种连接是您的创新，具体部件、连接的结构细部描述、在产品中所起的关键作用。对于您需要保护的工艺或制作方法而言，需要哪些步骤，如何控制工艺参数的设置。对于您希望保护的方法而言，需要哪些流程步骤？请详细说明，需要采用数据流的角度说明流程步骤。*
+
+**4、与第1部分所述的现有技术相比，本发明有何优点**
+
+> *4.1
+> 结合技术方案来描述，做到有理有据，即用推理或因果关系的方式推理说明；*
+>
+> *4.2 可以对应第2部分的发明目的来描述。*
+
+**5、本发明的关键点和欲保护点是什么？**
+
+> （本部分是提炼出技术方案的关键创新点，列出1、2、3\...，以提醒代理人注意，便于专利代理人撰写权利要求书）
+>
+> *5.1简单点明；*
+>
+> *5.2 具体可以对应第4部分能给本发明带来有益效果（优点）的关键技术点。*
+
+**6、针对第3部分的技术方案，是否还有别的替代方案同样能完成发明目的？**
+
+> *6.1
+> 如果有，请尽量写明，内容的提供可以扩大专利的保护范围，防止他人绕过本技术去实现同样的发明目的；*
+>
+> *6.2
+> 所述替代可以是部分结构、器件、方法步骤的替代，也可以是完整的技术方案。*
+
+**注意：**
+
+1\.
+代理人并不是技术专家，交底书要使代理人能看懂，**尤其是第3点本发明技术方案**，一定要写的全面、清楚。
+
+2.英文缩写有中文译文，避免使用英文单词，最好在术语解释部分给出。
+
+3.全文对同一事物的叫法应统一，避免出现一种东西多种叫法。
+
+4.认为需要保密的地方可在交底书中注明，对代理人不必保密。
+
+5.专利法规定：
+
+1)  专利必须是一个技术方案，应该阐述发明目的是通过什么技术方案来实现的，不能只有原理，也不能只做功能介绍；
+
+2)  专利必须充分公开，以本领域技术人员不需付出创造性劳动即可实现为准。

package/patent-disclosure-optimized/references/docx-format-spec.md

@@ -0,0 +1,183 @@
+# 专利交底书 .docx 输出格式规范
+
+本文档是 `SKILL.md` 第五阶段格式规范的详细附录，来源于客户提供的《技术交底书模板.doc》。规范用于驱动 `scripts/md2docx.js` 生成符合代理人审阅习惯的 .docx 文档。
+
+## 1. 页面参数
+
+| 项 | 取值 |
+| --- | --- |
+| 纸张 | A4（宽 11906 DXA × 高 16838 DXA） |
+| 上下页边距 | 1440 DXA（≈2.54 cm） |
+| 左右页边距 | 1800 DXA（≈3.17 cm） |
+| 页码 | 底部居中，9pt（sz=18），字体随正文 |
+| 行号、装订线 | 不启用 |
+
+## 2. 字体清单
+
+| 角色 | 东亚字体（eastAsia） | 西文字体（ascii / hAnsi / cs） | 用途 |
+| --- | --- | --- | --- |
+| 正文 | 宋体 | Times New Roman | 段落、表格单元格、列表项 |
+| 章节标题 | 楷体_GB2312 | Times New Roman | `#` / `##` / `###` / `####` |
+| 大标题 | 楷体_GB2312 | Times New Roman | 文档首行「技术交底书」 |
+| 头部字段 | 仿宋_GB2312 | Times New Roman | 交底书名称 / 发明人 / 联系人 / 电话 / E-MAIL |
+| 代码 | 宋体（兜底） | Consolas | 行内 `` ` `` 与 ``` ``` |
+
+> 字体名按模板原文写为 `宋体`、`楷体_GB2312`、`仿宋_GB2312`。Mac/Linux 缺字时可在 fontTable.xml 中追加 fallback，本规范不强制。
+
+## 3. 字号
+
+| 角色 | 字号 | docx-js `size`（半磅） | 行内字符 size |
+| --- | --- | --- | --- |
+| 大标题 | 18pt（二号） | 36 | — |
+| 正文 / 标题 / 头部字段 | 10.5pt（五号） | 21 | — |
+| 代码 | 10pt | 20 | — |
+| 页码 | 9pt | 18 | — |
+
+> 章节标题与正文同字号，仅"字体 + 加粗"区分；不要把章节标题做大字号，与模板不符。
+
+## 4. 段落参数
+
+| 段落 | 行距 | 对齐 | 首行缩进 | 段前 / 段后 |
+| --- | --- | --- | --- | --- |
+| 大标题 | line=420 exact | center | 无 | 240 / 240 |
+| 头部字段 | line=360 auto（1.5x） | left | 无 | 0 / 0 |
+| 章节标题 H1 | line=420 exact | left | 无 | 240 / 120 |
+| 章节标题 H2 | line=420 exact | left | 无 | 160 / 80 |
+| 章节标题 H3 | line=420 exact | left | 无 | 140 / 60 |
+| 章节标题 H4 | line=420 exact | left | 无 | 120 / 60 |
+| 正文 | line=360 auto（1.5x） | both（两端对齐） | 420 twips（2 字） | 0 / 0 |
+| 列表项 | line=360 auto | both | 720 hanging 360 | 0 / 0 |
+| 代码块行 | line=300 auto | left | 无 | 0 / 0；底色 `#F5F5F5` |
+
+行距单位说明：在 docx-js 里 `spacing.line` 单位为二十分之一磅；`lineRule: "exact"` 表示固定行高，`"auto"` 表示倍数（240 = 1x，360 = 1.5x，420 = 21pt 固定）。
+
+## 5. 颜色
+
+| 角色 | RGB |
+| --- | --- |
+| 正文 / 标题 / 头部 / 表格 / 列表 / 代码 | `#000000`（黑） |
+| 占位提示语（如「（请客观评价…）」） | `#0000FF`（模板蓝），仅出现在保留模板占位的场合 |
+| 表格表头底色 | `#E7E6E6` |
+| 代码块底色 | `#F5F5F5` |
+
+> 正式交付的交底书中不应出现模板蓝；若文档中出现蓝色文字，说明仍残留模板占位语，需替换为真实内容。
+
+## 6. 附图嵌入规范
+
+代理人审阅交底书时需要直接看到附图，**不能**接受 `[![附图1 - 四遍扫描整体流程](media/doc1_fig1.png)]` 这类文本描述形式。生成 docx 时必须把图片真正嵌入到对应位置。
+
+### 6.1 Markdown 写法
+
+附图必须 **独立成行**：
+
+```markdown
+![附图1 - 四遍扫描整体流程](media/doc1_fig1.png)
+```
+
+不要把附图与正文混排在同一段；非独立行的 `![]()` 不会触发图片嵌入，仍按文本处理。
+
+### 6.2 文件组织
+
+- 推荐每篇交底书 md 的同目录下建立 `media/` 子目录，把附图放在里面
+- 命名建议：`doc{交底书序号}_fig{图序}.png`，例如 `media/doc1_fig1.png`、`media/doc1_fig2.png`
+- 路径解析以 md 文件所在目录为基准；只支持相对路径或绝对路径
+
+### 6.3 嵌入与缩放规则
+
+| 项 | 取值 |
+| --- | --- |
+| 支持格式 | png / jpg / jpeg / gif / bmp / svg |
+| 真实像素读取 | png：解析 IHDR 块拿真实宽高；其它格式：按 4:3 兜底 |
+| 目标宽度 | 540 px（≈内容区宽度 8306 DXA，留少量边距） |
+| 高度上限 | 720 px |
+| 缩放 | 等比；高度超限时按高度反算宽度，绝不裁剪、绝不拉伸 |
+| 图片段落对齐 | 居中 |
+| 图片段落行距 | 1.5x（line=360 auto）；段前 120 / 段后 40 twips |
+
+### 6.4 图注
+
+`![alt](path)` 中的 `alt` 文字会自动生成图注段落紧跟在图片下方：
+
+- 字体：宋体（东亚）+ Times New Roman（西文）
+- 字号：10pt（sz=20）
+- 字形：斜体
+- 对齐：居中
+- 行距：1.25x（line=300 auto），段后 120 twips
+
+`alt` 为空时不输出图注段落。
+
+### 6.5 容错
+
+- 图片路径不存在：在文档中插入红色 `[图片缺失] alt (src)` 文本，**不**抛错中断转换
+- 非 png 图片读取尺寸失败：按 4:3 兜底
+- 跨平台路径分隔符：始终用 `path.resolve` 统一为绝对路径再读
+
+### 6.6 docx-js API 关键写法
+
+`ImageRun` 必须传 `type` 参数，且 `altText` 三字段全填：
+
+```js
+new ImageRun({
+  type: "png",
+  data: fs.readFileSync(absPath),
+  transformation: { width: 540, height: 360 },
+  altText: { title: "附图1", description: "附图1", name: "doc1_fig1.png" },
+});
+```
+
+`scripts/md2docx.js` 已封装以上全部逻辑，调用脚本即可，无需手写 ImageRun。
+
+## 7. 表格规范
+
+- 宽度模式：`WidthType.DXA`（不要用百分比）
+- 表格总宽 = 列宽之和 = 内容区宽度（A4 默认 8306 DXA）
+- 单元格四周边框：`BorderStyle.SINGLE`，size=4，color=`808080`
+- 单元格 padding：`{ top: 80, bottom: 80, left: 120, right: 120 }`
+- 表头：底色 `#E7E6E6`，居中加粗
+- 单元格段落行距：1.25x（line=300 auto）
+
+## 8. 头部字段识别规则
+
+满足以下任一正则的段落会被识别为"头部字段"，自动套用仿宋_GB2312 加粗：
+
+```text
+^\s*\*\*交底书名称[：:].*\*\*
+^\s*\*\*本专利发明人[：:].*\*\*
+^\s*\*\*技术问题联系人[：:].*\*\*
+^\s*\*\*联系人电话[：:].*\*\*
+^\s*\*\*E-?MAIL[：:].*\*\*
+```
+
+为避免相邻头部字段被合并为单段，tokenizer 在遇到 `**xxx：**` 形式的行时不与上下行合并。
+
+## 9. 自检（生成后）
+
+生成 docx 后，建议执行：
+
+```bash
+python scripts/office/unpack.py 专利交底书_X_20260318.docx tmp/
+grep -oE 'w:eastAsia="[^"]+"' tmp/word/document.xml | sort | uniq -c
+grep -oE 'w:color w:val="[A-F0-9]+"' tmp/word/document.xml | sort | uniq -c
+ls tmp/word/media/ 2>/dev/null | wc -l   # 内嵌图片数
+```
+
+期望输出：
+
+- `仿宋_GB2312` 恰好出现 **5** 次（五个头部字段）
+- `楷体_GB2312` 出现次数 ≥ 章节标题数
+- 其余东亚字体均为 `宋体`
+- `w:color` 仅出现 `000000`（除非显式保留蓝色占位语）
+- 内嵌图片数 = md 中独立行 `![alt](path)` 的个数（即 md 中 `grep -cE '^\s*!\[' *.md`）
+
+任一项不满足，需检查 md 源文档结构与 `scripts/md2docx.js` 的常量配置。
+
+## 10. 客户换模板的更新步骤
+
+1. 转换为 .docx：`soffice --headless --convert-to docx 新模板.doc`
+2. 解包：`python scripts/office/unpack.py 新模板.docx tmpl/`
+3. 在 `tmpl/word/styles.xml` 中读取：
+   - `<w:docDefaults>` → 默认 rFonts / sz（决定正文默认值）
+   - `Heading1` / `Heading2` 等内置标题样式 → 章节标题字体、字号、行距
+4. 在 `tmpl/word/document.xml` 中抽样几段实际文本，确认实际使用的 rPr 是否覆盖了 styles 默认值
+5. 将差异写入本规范 § 2~7 表格，同时同步修改 `scripts/md2docx.js` 顶部常量
+6. 重跑 § 9 自检