@zeyue0329/xiaoma-cli 1.0.48 → 1.0.66

package/src/xpm/skills/xiaoma-patent-mining/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 自检

package/src/xpm/skills/xiaoma-patent-mining/references/mining-principles.md

@@ -0,0 +1,168 @@
+# 专利申请自检与奖励机制
+
+## 一、专利挖掘核心前提：判定合格技术方案
+
+合格的专利技术方案需同时满足**解决具体技术问题、采用技术手段、实现技术效果**三大核心要求，区别于单纯原理、功能描述，是专利申请的基础判定标准。
+
+### （一）解决具体的技术问题
+
+**核心要求**：**技术问题必须是技术应用场景下的具体缺陷**，而非泛化的业务需求或抽象目标，需明确指向
+"哪个技术环节存在何种缺陷、导致了哪些不良后果"。
+
+1.  **否定情形**
+
+-   **泛化需求 /
+    业务诉求：**仅描述抽象目标或业务价值，未定位到具体技术环节与技术缺陷。
+
+    ·示例
+    1："让系统运行更快"（未说明是哪个模块、哪种场景下慢，慢到什么程度，由什么技术原因导致）。
+
+    ·示例
+    2："提升资金流转效率，方便用户办理业务"。属于业务目标，未指出是数据校验、接口调用还是存储环节的技术瓶颈。
+
+-   **非技术类问题**：属于管理、商业、运营或用户体验层面的诉求，与技术实现无关。
+
+    ·示例："需要设计新的会员积分规则，提升用户复购率"。本质是商业运营策略，未涉及任何技术缺陷或技术实现问题。
+
+-   **模糊描述**：未明确技术缺陷的具体表现、影响范围或触发条件。
+
+    ·示例："系统存在稳定性问题"。未说明是内存泄漏、并发冲突还是网络抖动导致的不稳定。
+
+2.  **肯定情形**
+
+    精准指向技术环节痛点，明确：
+
+    **现有技术的具体缺陷**（如结构、算法、流程、参数等方面的不足）；
+
+    **缺陷引发的不良技术后果**（如延迟高、精度低、能耗大、数据不安全等）；
+
+    **问题的应用场景与约束**（如无法满足实时性、高并发、高可靠等业务需求）。
+
+    ·示例
+    1："现有技术中，供应链数据传输需要经过多次中心化校验，导致响应延迟高（平均
+    500ms 以上），且存在数据篡改风险，无法满足毫秒级实时交易需求。"
+
+    ·示例 2："现有供应链金融 API
+    编排依赖人工拖拽配置，未利用历史调用日志数据，导致工作流设计周期长达数天，且生成的调用链路易出现延迟超标（平均延迟超
+    300ms）、错误率高（历史失败率达
+    8%）的问题，无法满足微服务架构下快速迭代与高可靠运行的业务需求。"
+
+### （二）采用技术手段
+
+**核心要求**：必须依托**自然规律**（物理、化学、计算机等技术原理），通过**技术模块**（如传感器、处理器、算法模块、硬件组件等）或**技术步骤**（如数据采集、信号处理、信息传输、自动控制等）实现，最终体现为**系统结构、技术
+/
+算法流程、参数设计、模块连接关系**等可落地的技术实现形式，而非单纯的业务规则或人为约定。
+
+1.  **否定情形**
+
+-   **采用非技术手段**：依赖商业营销、管理规则、人为约定等解决问题，未利用自然规律。
+
+    ·例如：
+    "通过增加优惠力度来吸引客户，从而解决坏账率高的问题"（本质是商业策略，未采用技术手段）。
+
+-   **简单组合 /
+    配置现有技术**：仅对成熟工具、框架或组件进行常规拼接、参数调整，未形成新的技术逻辑或改进。
+
+    ·例如："通过对前端开发、编译等组合工具的简单配置，实现页面快速构建"（仅为工具的常规使用，未产生新的技术贡献）。
+
+-   **纯智力 /
+    管理规则**：依赖人的主观判断、流程约定或逻辑推演，未结合硬件 /
+    物理实体。
+
+    ·例如："设计一套新的员工绩效考核规则，提升团队效率"（属于智力活动，纯管理方法，非技术手段）。
+
+2.  **肯定情形**
+
+    **依托技术层面的结构 / 方法 /
+    流程解决问题，利用自然规律实现技术目标。**
+
+    ·示例
+    1：采用异步物化视图技术（技术方法）构建供应链金融实时数仓，设计增量数据同步与物化视图自动刷新流程（技术步骤），结合分布式存储与计算架构（技术结构），优化融资放款明细数据的存储与查询逻辑，实现低延迟、低成本的
+    T+0 级别实时数据计算。
+
+    ·示例
+    2：通过将原始API调用日志重构为蕴含拓扑与性能特征的有向异质图，利用图卷积神经网络执行迭代式链接预测自动生成概率最高的API调用链路，并基于复合损失函数同步优化拓扑准确性、延迟与错误率，以实现微服务工作流的自动化编排与性能最优化"（结合了图数据结构构建、深度学习推理与多目标优化算法，属于典型技术手段）。
+
+    ·示例
+    3："通过构建行业大模型与幻觉对照大模型的双模型架构（技术架构），利用词元粒度的对比学习算法（技术方法）对两个模型的输出概率分布进行实时差分计算与修正，以抑制大语言模型生成过程中的事实性幻觉"。
+
+### （三）实现技术效果
+
+**核心要求**：**达成技术层面可量化、可验证的收益**，如响应速度更快、计算成本更低、检测精度更高、系统运行更稳定、资源占用更少、能耗更低等，**且技术效果需与所采用的技术手段一一对应，是技术手段直接引发的技术属性提升，**而非商业、品牌或社会层面的间接影响。
+
+1.  **否定情形**
+
+    仅实现非技术效果，如商业收益、品牌影响力、社会价值等，**未体现技术指标的改善，且与技术手段无直接因果关系。**
+
+    ·示例
+    1："实施本方案后，企业品牌知名度大幅提升，合作伙伴数量增加"（属于品牌与商业效果，与技术手段无直接关联）。
+
+    ·示例 2："本方案上线后，用户活跃度提升
+    30%，营收增长显著"（属于业务运营效果，未体现系统性能、精度等技术维度的变化）。
+
+    ·示例
+    3："该设计更美观，提升了用户体验"（属于视觉与主观体验效果，不属于可量化的技术效果）。
+
+2.  **肯定情形**：
+
+    **技术手段直接带来可量化、可复现的技术指标改善**，能客观反映系统在性能、精度、稳定性、资源占用等维度的提升。
+
+    ·示例 1：采用多层级向量索引构建 +
+    乘积量化技术，针对客服场景微调预训练模型并实现粗精检索分离后，检索时间复杂度从
+    O (n) 降至 O (log n)，检索速度提升 10-50
+    倍，百万级图像库平均检索延迟≤100ms；存储空间占用减少
+    60-80%，支持千万级图像库扩展；检索精度损失＜5%，在保证高精度的同时满足客服场景实时检索需求，系统可扩展性与稳定性大幅提升。（来源：《多层级向量索引构建方法、客服场景图像检索方法及电子设备》-中企链信（北京）科技有限公司）
+
+    ·示例 2："采用融合架构的保理业务风险分级接入模型，结合领域微调的
+    BERT/GPT
+    大模型与跨模态注意力机制实现多源异构数据融合分析后，企业保理业务接入评估周期从传统数周压缩至数小时，效率提升
+    90% 以上；风险等级预测准确率达 92%
+    以上，实现免实测的全维度风险评估"。（来源：《一种保理业务分级接入方法及装置》-中企云链股份有限公司）
+
+### （四）技术方案快速判定公式
+
+按以下三步完整描述你的方案，若能清晰、具体地填完所有空白，即可判定为可专利化的技术方案；若某一步模糊或无法落地，则需进一步细化完善。
+
+1.  **因为（技术问题）**：现有方案在 XX
+    具体技术环节/模块上有XX技术缺陷，导致 XX
+    不良技术后果，无法满足XX场景约束/业务需求；
+
+2.  **所以（技术手段）**：我提出了用 XX 结构 / 方法 /
+    流程/算法，通过XX可落地的技术动作/算法步骤/参数设计等技术手段对上述缺陷进行改进；
+
+3.  **结果（技术效果）**：因此， XX 技术性能 / 效率 /
+    稳定性等得到了显著提升，具体表现为XX技术指标改善，满足XX目标场景/业务需求。
+
+## 二、专利申请常见规避问题
+
+专利申请文件不得仅包含原理表述或功能介绍，必须形成完整、可落地、可重复实现的技术方案，需明确技术改进点、实现步骤与逻辑关联，具体对比示例如下：
+
+  ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+  表述类型     错误示例                               问题说明                                                                                           合格技术方案描述
+  ------------ -------------------------------------- -------------------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+  纯原理表述   本方案通过 LSTM                        仅提及技术概念，**未介绍方案中具体的改进点、结构设计、参数配置或场景适配方式**，无法体现技术贡献   "本方案构建了一种改进的深度学习模型：输入层对企业行为序列与多维特征进行标准化处理；LSTM层针对资金流周期特性设计了自适应门控结构；注意力层专门对供应链中的'需求信号时段'进行加权聚焦；最终输出层生成需求概率与时机建议。"\
+               时序模型和注意力机制进行融资需求预测                                                                                                      *(注：需介绍模型具体的输入输出定义、结构改进点及数学形式。此处为简化示例)*
+
+  纯功能表述   本方案系统能够自动识别用户身份         仅描述实现的功能，**未提供具体技术实现手段、模块交互逻辑或判断规则**                               "系统通过摄像头采集人脸图像，利用CNN神经网络提取128维特征向量，将其与本地加密数据库中的基准特征进行欧氏距离比对，当距离小于阈值T时输出匹配成功信号。"\
+                                                                                                                                                         *(注：需展开具体的数据采集、预处理、特征提取及阈值判断逻辑。此处为简化示例)。*
+  ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+
+**纯原理表述**：只讲 "用了什么技术"，不讲
+"怎么改、怎么用、为什么这么用"，无法体现创造性，极易被驳回。
+
+**纯功能表述**：只讲 "能实现什么效果"，不讲 "用什么结构 / 步骤 /
+算法实现"，属于典型的 "功能限定" 写法，不符合专利撰写规范。
+
+## 三、不可申请专利的情形
+
+1.  **纯代码/纯公式：**
+
+    **单独的计算机代码、数学公式、算法原理不能申请专利**。
+
+    对策：代码请申请计算机软件著作权。
+
+2.  **算法/软件专利化路径：**
+
+    **软件转化为专利**：若需申请专利，必须将代码逻辑转化为标准化的技术语言。
+
+    **算法转化为专利**：算法必须结合具体的应用场景（如图像处理、融资需求预测、金融风控等）和硬件实体（如处理器、传感器、存储器、数据库等），形成一套完整的"数据处理方法"或"系统架构"。