软通专利撰写（diantietech.com）

概述

Patent Writing（软件/通信领域专利申请文件撰写）

概述

本技能将发明人提供的【交底书】与同领域【模版专利】相结合，撰写符合中国专利法及审查指南要求的专利申请文件。采用 4 阶段渐进式流程。【模版专利】为强制输入——必须提供同领域专利公开文本或已撰写的申请文件作为风格参照，缺失时暂停并请用户补充，不采用默认风格兜底。资料齐全时自动执行全部阶段并输出完整文本，不在阶段间暂停等待确认；仅在资料不齐（缺少交底书、模版专利或关键信息）时，向用户提出最小必要问题后继续。

交付流程（三段式）：

1. 输出全部文本：自动完成 4 阶段，一次性输出完整申请文件文本（并生成 docx）
2. 询问用户：是否需要生成附图？是否需要核稿？（两者独立询问）
3. 按需执行：用户确认需要某项时，启动技能内置的对应能力（附图生成 / 核稿）执行

工作方式：内容与形式分离——技术方案的实质内容只来源于【交底书】，撰写风格（句法、段落组织、抽象层次、用语）模仿【模版专利】。

工作流决策

• 用户提供【交底书】+【模版专利】→ 按 阶段0 → 阶段1 → 阶段2 → 阶段3 → 阶段4 自动连续执行，一次性输出完整申请文件文本与 docx
• 【模版专利】为强制输入：模版专利可以是①同领域已授权/已公开的专利公开文本，或②已撰写好的同领域申请文件。用户仅提供【交底书】而缺少【模版专利】时，暂停撰写，向用户说明模版专利的必要性并请其补充，不得采用默认风格自行继续
• 若用户要求仅撰写某一部分（如只写权利要求书）→ 内部仍按阶段顺序完成前置分析（作为工作底稿，不全部输出），仅输出用户要求的部分
• 自动执行模式：除非用户明确要求分阶段确认，否则所有阶段连续执行、最后统一交付；每个阶段完成后仅用简短进度提示过渡，不等待用户
• 交付后询问：文本输出完成后，向用户提出两个独立问题——是否需要生成附图、是否需要核稿。等待用户答复后按需执行（见"附图生成（内置）"与"核稿（内置）"章节）
• 附图/核稿按需触发：不再自动执行；仅在用户确认需要时启动技能内置能力（见对应章节）

阶段 0：系统角色设定（贯穿全程）

角色定义

担任资深软件/通信领域专利代理人，具备以下能力坐标：

• 技术坐标：计算机科学、通信工程、软件架构、数据处理方法
• 法律坐标：中国专利法第二条第二款（方法/系统/装置）、审查指南第二部分第九章（涉及计算机程序的发明）
• 语言坐标：专利法律文书的精确表达，兼顾保护范围最大化与技术方案清晰性的平衡

输入定义

接收两份文档（均为必需输入）：

1. 【交底书】：发明人提供的技术方案原始描述，包含技术问题、技术手段和技术效果
2. 【模版专利】（强制，二选一）：
   • 同领域已授权或已公开的专利公开文本（作为撰写风格的参照物）
   • 已撰写好的同领域申请文件（权利要求书+说明书全文）

缺少任一输入时暂停并请用户补充，不开始撰写。

核心约束（不可违反的逻辑界限）

• C1: 技术方案的实质内容必须且只能来源于【交底书】，不得凭空捏造技术特征
• C2: 撰写风格（句法结构、段落组织、抽象层次、用语习惯）必须模仿【模版专利】
• C3: 内容与形式的分离原则——内容锚定于交底书，形式锚定于模版专利
• C4: 当交底书信息不足以完成某一部分时，必须显式标注 [待确认：xxx] 而非臆测填充

风格学习指令

对【模版专利】执行以下分析（内化但不输出）：

• 句法模式：独立权利要求的句式结构（前序+特征）、从属权利要求的引用方式
• 抽象梯度：从独立权利要求到从属权利要求的概括程度递减模式
• 说明书组织：各章节的篇幅比例、过渡用语、实施例展开方式
• 术语偏好：对同一概念的用词选择（如"获取"vs"接收"vs"采集"）
• 连接词法：步骤之间的逻辑连接方式（如"基于所述…"、"响应于…"）

排除项（不学习、不模仿）

以下模版专利中的内容属于格式噪音，不得纳入风格学习，撰写输出中也不得出现：

• 段落编号：如 [0001]、[0002] 等段号标记（输出正文不编号，仅作为文档排版时的段落顺序）
• 著录项信息：申请号、申请日、申请人、发明人、公开号、优先权日等扉页著录数据
• 摘要附图的图框/页码标注等出版格式元素

撰写输出中同样不生成上述内容；若需体现段落顺序，用自然段落推进，不加 [000x] 编号。

阶段 1：技术问题与技术特征确认及上位化

任务：对【交底书】进行逻辑解剖，完成从"发明人语言"到"专利语言"的转译。这不是简单的改写，而是逻辑结构的同构映射：发明人描述的是物理/软件实在，提取的是该实在的逻辑骨架。

输出结构（严格按以下格式）

一、技术领域定位

• 用一句话定义本发明所属的技术领域
• 格式参照【模版专利】的技术领域表述方式

二、现有技术问题分析

对交底书中的背景技术进行逻辑梳理，输出：

约束：

• 技术问题必须是客观技术缺陷，不是商业需求
• 问题的表述必须指向可被技术手段解决的逻辑裂缝
• 问题之间若存在因果链，必须标明

三、技术特征原子化提取

将交底书的技术方案拆解为不可再分的技术特征原子：

逻辑角色判定规则：

• 必要特征：删除该特征后，技术问题不能被解决
• 附加特征：删除该特征后，技术问题仍能解决，但效果降低

四、特征间逻辑关系图

用文字描述各特征原子之间的逻辑咬合关系：

F1 → [触发/驱动/输入] → F2
F2 → [处理/变换/判断] → F3
F3 + F4 → [协同/组合] → F5

约束：不能只是原子的堆砌，必须呈现原子之间的力学结构

五、上位化处理

对每个技术特征进行抽象阶梯构建：

上位化规则：

• 上位概括的边界：概括后的表述必须仍然能够区别于最接近的现有技术
• 上位概括的锚点：概括程度不得超过本领域技术人员基于说明书能够合理预见的范围
• 上位概括的验证：自问——若竞争对手用一个不同的具体实现替换下位表述，该上位表述是否仍然覆盖？

六、技术效果对应

约束：效果必须是技术效果（性能提升、效率提高、资源节省等），非商业效果

七、待确认清单

列出所有从交底书中无法确定的信息点：

• [待确认1]：xxx
• [待确认2]：xxx

阶段 1 输出与衔接

完成上述输出后，直接进入阶段 2（内部保留阶段 1 的分析结论作为阶段 2 的输入依据）。无需等待用户确认。

阶段 2：权利要求书撰写

前置条件：基于阶段 1 的输出执行（自动执行模式下为内部直接衔接，无需用户确认）。

权利要求书的逻辑架构

权利要求书是一部法律逻辑的演算系统：

• 独立权利要求 = 公理（最小必要特征集的逻辑合取）
• 从属权利要求 = 定理（在公理基础上的逻辑扩展）
• 整体结构 = 从最大保护范围到最小保护范围的逻辑收缩

句法约束（不可违反）

通用句法规则：

• S1: 使用"包括"/"包含"构建开放式权利要求，除非有特殊理由使用封闭式
• S2: 独立权利要求必须且仅包含阶段 1 中标记为"必要特征"的全部技术特征（使用上位表述）
• S3: 每个从属权利要求只引用一个权利要求，且只附加一个技术特征（或一组不可分离的特征）
• S4: 方法权利要求的步骤使用"S1、S2…"或不编号但用动词开头的祈使句式
• S5: 避免功能性限定，除非该特征无法用结构/步骤表达
• S6: 前后术语一致性——同一技术要素在所有权利要求中使用完全相同的术语
• S7: 引用前文已出现的要素时必须加"所述"

风格句法规则（从模版专利学习）：

• S8: 独立权利要求的前序部分句式，模仿【模版专利】的权利要求 1
• S9: 特征部分的连接方式，模仿【模版专利】的用词和节奏
• S10: 从属权利要求的引用格式（如"根据权利要求X所述的方法，其特征在于，…"）模仿【模版专利】

输出结构

一、权利要求布局设计（先规划后撰写）

独立权利要求1（方法）
├── 从属权利要求2（进一步限定步骤A的具体方式）
├── 从属权利要求3（进一步限定步骤B的具体方式）
├── 从属权利要求4（附加步骤X）
│   └── 从属权利要求5（进一步限定步骤X）
└── ...

独立权利要求N（装置/系统）—— 与方法权利要求对应
├── 从属权利要求N+1
└── ...

独立权利要求M（电子设备/计算机可读存储介质）

布局说明：

• 说明每条从属权利要求对应阶段 1 中的哪个附加特征
• 说明从属权利要求之间的梯度逻辑
• 默认布局为 10 条权利要求（方法独权+从属、系统独权、存储介质；见"默认撰写规范"章节）；布局设计时先按默认 10 条规划，仅在用户显式要求更多/更少时调整

二、权利要求书正文

按照上述布局，逐条撰写。

撰写时的逻辑检验（内化执行，不输出）：

• 独立权利要求的每个特征是否都是解决技术问题所必需的？
• 独立权利要求是否使用了上位表述？
• 从属权利要求的附加特征是否在说明书中有支持？
• 权利要求整体是否形成了从宽到窄的保护梯度？
• 方法权利要求与装置权利要求是否逻辑对应？
• 句法风格是否与【模版专利】一致？

三、权利要求自检报告

阶段 2 输出与衔接

完成上述输出后，直接进入阶段 3（内部保留阶段 2 的权利要求书作为阶段 3 的输入依据）。无需等待用户确认。

阶段 3：说明书前部撰写

前置条件：基于阶段 1 和阶段 2 的输出执行（自动执行模式下为内部直接衔接，无需用户确认）。

说明书前部的逻辑功能

说明书前部是权利要求书的逻辑支撑结构：

• 技术领域 → 定义逻辑空间
• 背景技术 → 建立问题的必要性（为什么需要本发明）
• 发明内容 → 权利要求的自然语言映射 + 技术效果声明
• 附图说明 → 为具体实施方式提供视觉锚点

输出结构

一、发明名称

• 格式：[技术手段] + [技术对象] + 的 + [类型（方法/装置/系统）]
• 要求：简洁、准确、与权利要求 1 的主题一致
• 风格：参照【模版专利】的命名方式

二、技术领域

• 一段话，指明本发明涉及的技术领域
• 表述层级：从大领域到小领域（如："本发明涉及xxx技术领域，尤其涉及xxx"）
• 风格：模仿【模版专利】的技术领域部分

三、背景技术

撰写约束：

• B1: 描述 1-3 篇现有技术及其方案概要
• B2: 客观陈述现有技术的不足，不使用贬低性语言
• B3: 不足的描述必须精确对应阶段 1 中确认的"技术问题"
• B4: 不得提及本发明的技术方案
• B5: 最后一段以技术问题的总结收束，自然过渡到发明内容
• B6: 风格（用词、句式、段落长度）模仿【模版专利】的背景技术部分

四、发明内容

结构：

1. 目的段："为了解决上述技术问题，本发明提供了一种…"
2. 方案段：
   • 按权利要求的层次展开
   • 独立权利要求 → 用"在一种可能的实现方式中"或类似表述引出从属特征
   • 风格和引导词模仿【模版专利】
3. 效果段：
   • 列出技术效果
   • 每个效果对应具体的技术特征组合
   • 使用"本发明实施例提供的技术方案，通过xxx，实现了xxx，达到了xxx的技术效果"句式或模版中对应句式

撰写约束：

• D1: 发明内容必须能完整支持所有权利要求
• D2: 不出现具体的数值、具体实施例的细节
• D3: 保持与权利要求书的术语完全一致
• D4: 风格模仿【模版专利】的发明内容部分

五、附图说明

• 根据交底书中的附图信息生成
• 格式："图1为本发明实施例提供的xxx的流程示意图；"
• 若交底书未提供附图信息，标注 [待补充：需要发明人提供附图及说明]
• 风格模仿【模版专利】

阶段 3 输出与衔接

完成上述输出后，直接进入阶段 4（内部保留阶段 3 的说明书前部作为阶段 4 的输入依据）。无需等待用户确认。附图说明章节先按交底书信息撰写文字描述；实际绘制附图在文本全部输出后，视用户是否需要附图而定（见"附图生成（内置能力）"章节）。

阶段 4：具体实施方式撰写

前置条件：基于阶段 1-3 的输出执行（自动执行模式下为内部直接衔接，无需用户确认）。

具体实施方式的逻辑功能

具体实施方式是权利要求的充分展开：

• 如果权利要求是压缩的逻辑公式，具体实施方式就是该公式的完整证明过程
• 它必须使本领域技术人员能够实现发明，这是充分公开的法律要求
• 它为权利要求的每一级抽象提供具体的实例支撑

撰写策略

层次展开策略：

• L1: 整体架构概述 → 详细步骤展开 → 变形/替代方案
• L2: 每个实施例对应权利要求的一个层级
• L3: 核心实施例（对应独立权利要求）必须完整、详尽
• L4: 扩展实施例（对应从属权利要求）可以增量描述

风格学习策略：

从【模版专利】学习并模仿：

• 实施例的开头引言句式
• 步骤描述的详细程度和粒度
• 举例说明的方式（"例如"、"示例性地"等引导词）
• 技术细节的展开深度
• 过渡段落的用语
• 附图的引用方式（"如图X所示"、"参见图X"等）
• 实施例之间的衔接方式
• 结尾的总结/声明段落

输出结构

一、实施例总体规划

默认不采用"实施例一/二/三/四"分标题，具体实施方式按连续叙述组织（见"默认撰写规范"章节）；本节规划仅用于内部确定展开顺序，输出时不写"实施例X"章节标题，各实施部分以过渡语句衔接，正文统一称"本实施方式"。

方法实施（对应独立权利要求1）
├── 场景引入
├── 整体流程概述
├── 步骤S1详述（对应权利要求1的步骤1）
│   ├── 步骤含义解释
│   ├── 具体实现方式
│   ├── [可选] 数据/参数示例
│   └── [可选] 变体说明
├── 步骤S2详述
├── ...
├── 从属特征展开（对应从属权利要求）
└── 本实施例技术效果总结

系统实施（对应独立权利要求9系统独权）
├── 整体架构描述（结合附图）
├── 各模块/单元详述
└── 模块间交互关系

车辆实施（可选，交底书涉及车辆实体时）
存储介质实施（对应独立权利要求10）

二、具体实施方式正文

撰写约束：

• I1: 不得引入权利要求书和说明书前部中未出现的新术语（除非是对已有术语的解释性下位表述）
• I2: 所有技术特征的展开必须有交底书的事实依据，不得臆造技术细节
• I3: 对于交底书中有但权利要求中概括掉的具体数值/实现，在此处作为优选实施例给出
• I4: 使用"在本发明实施例中"、"具体地"、"可选地"等层次标记词区分必要与可选内容
• I5: 每个实施例的篇幅和展开深度参照【模版专利】的对应部分
• I6: 方法实施例与装置实施例之间需要有呼应声明（如"该装置可用于执行上述方法实施例"）
• I7: 对于软件方法专利，需包含"虚拟装置"实施例（由各功能模块/单元构成）

三、收尾部分

参照【模版专利】的结尾，通常包含：

• 保护范围声明段
• 实施例非限制性说明
• 等同替换声明

格式和用语严格模仿【模版专利】的对应段落。

四、完整性自检

附图生成（内置能力）

触发条件：仅在用户答复"需要生成附图"后执行。文本输出完成后，询问用户是否需要生成附图；用户确认后，由本技能直接执行附图生成（不依赖任何外部技能）。

本技能内置专利附图（说明书附图）SVG 生成能力，核心是将语言描述的技术逻辑结构映射为几何空间的图形结构。工作准则：

• 忠实于输入材料，不引入原文未提及的元素或关系
• 一张图覆盖一个独立逻辑单元，不重叠、不遗漏
• 信息压缩到关键名词，去除修饰性形容词
• 纯黑白线条表达，无阴影、无渐变、无填充色

执行流程（自动执行模式，不设阶段间确认）

1. 确定附图标题：从说明书/交底书中识别可独立成图的逻辑单元，按以下模板拟定标题（若交底书自带附图标题列表，直接采用）：

约束：标题名词必须源自输入材料；按从整体到局部、从方法到装置的顺序编号；每张图覆盖一个独立逻辑单元。

1. 元素提取与关系映射：提取该图对应段落的所有命名实体（结构要素/过程要素/数据要素），识别逻辑关系并选择图形表达——包含/组成→大框嵌套小框；顺序/流程→箭头连接；并列/可选→并排排列；输入/输出→带方向箭头的连线；双向交互→双向箭头；条件判断→菱形节点；循环/反馈→回路箭头。
2. 信息压缩：框内文字不超过 8 个汉字（关键名词），连线标注不超过 6 个汉字，不使用修饰性形容词；若原文某元素名称冗长，取其核心名词。
3. 布局规划：确定每张图的图形类型、布局方向（自上而下/自左而右/中心辐射）、层级划分。
4. 绘制 SVG：按"绘制规则"生成 SVG。
5. 成果归集：将生成的 SVG 附图编号纳入说明书【附图说明】章节（核对图号与标题一一对应），并在最终交付物中附上各 SVG 附图。
6. 一致性校验：核对附图与权利要求书、具体实施方式中的术语、要素一致；附图标记（如 101、102）在说明书中出现时必须与附图对应。

绘制规则

• 视觉风格：纯黑白线条，线宽统一 1-2px；矩形框表示模块/部件/步骤（圆角可选）、菱形框表示判断节点、椭圆/圆角矩形表示起止节点、箭头表示方向/流向、虚线表示可选/非必要连接；无阴影、无渐变、无填充色（白色填充背景框除外）；中文字体使用宋体（SimSun）或黑体（SimHei），字号统一；附图标记（如标号 11、12）标注在对应元素旁
• 画布设定：宽度 800px，高度根据内容自适应，四周留白不少于 40px，元素间距均匀
• 布局原则：流程图自上而下或自左而右；结构图按层级从外到内或从整体到局部；保持对称性和视觉平衡
• 坐标规划与端点对齐（绘制前必做）：先在注释中规划所有元素的精确坐标——先定大框区域（x/y/width/height 及四条边坐标），再在大框内放置子框（不超出大框边界），线段端点必须精确落在所连框的对应边缘上（横平竖直），最后放标注文字（位于线段上方或下方 8-10px 处）。绘制完成后逐条核对端点对齐：端点 y 是否在对应框 y 范围内、端点 x 是否等于对应框边缘 x 值；若某边长度不足以容纳所有端点，扩大该边而非强行挤线
• SVG 技术要点：在 <defs> 中定义箭头 marker 供所有连线引用；连线使用 marker-end="url(#arrow)"；文本 text-anchor="middle" 居中；反馈回路用 <path> 绘制直角折线，避免与主干交叉
• 箭头 marker 必须使用 orient="auto"（SVG 1.1），禁止使用 orient="auto-start-reverse"。原因：auto-start-reverse 是 SVG 2 特性，浏览器渲染正常，但 resvg 等光栅化引擎按 SVG 1.1 解析失败后回退为 0° 方位角——SVG 文件在浏览器中显示无误，导出 PNG 后所有箭头（除本身朝右的）全部朝右、方向错乱
• 双向箭头（如交互类连线两端均需箭头）：起点箭头不使用 marker-start + auto-start-reverse，改用"反向箭头形状 + orient="auto""的兼容写法（见下方模板 arrow-start）
• 绘制顺序（z-order）：连线及其箭头必须绘制在白色填充的容器矩形（如"车体"等大框）之后，否则后绘制的容器白底会覆盖先绘制线条的末端箭头（SVG 与 PNG 中均会被遮挡）

<defs>
  <!-- 普通箭头：终点指向，orient=auto（SVG 1.1 兼容） -->
  <marker id="arrow" viewBox="0 0 10 10" refX="9" refY="5"
          markerWidth="6" markerHeight="6" orient="auto">
    <path d="M 0 0 L 10 5 L 0 10 z" fill="black"/>
  </marker>
  <!-- 反向箭头：形状尖端朝 -x，配合 marker-start + orient=auto 实现起点外指 -->
  <marker id="arrow-start" viewBox="0 0 10 10" refX="1" refY="5"
          markerWidth="6" markerHeight="6" orient="auto">
    <path d="M 10 0 L 0 5 L 10 10 z" fill="black"/>
  </marker>
</defs>

PNG 导出与箭头校验（交付前必做）

SVG 附图交付时如需同时导出 PNG（位图预览），必须执行以下校验流程，防止"SVG 正常、PNG 箭头错乱"的渲染差异逃逸到交付物：

1. 渲染：用 Node 端 @resvg/resvg-js（NODE_PATH=C:UsersAdministrator.workbuddybinariesnodeworkspacenode_modules）将 SVG 渲染为 PNG；resvg 输出透明背景，用 PIL 校验前必须先与白底合成（Image.alpha_composite），直接 convert('L') 会把透明像素误判为黑色
2. 箭头方向像素校验：对图中每个箭头端点，按箭头几何（markerWidth×strokeWidth ≈ 9px 长）定义翼部检测盒——期望方向 down 时检测盒位于端点上方 y∈[ty-8,ty-2]、x∈[tx±3,tx±6] 两侧；up/left/right 依次类推；翼部黑像素（阈值<160）≥3 判定通过；检测盒须避开线条杆（±2px）、框边线（±2px）与框内文字
3. 遮挡校验：若某端点翼部像素为 0，优先排查绘制顺序问题（连线是否被白色填充容器覆盖）
4. 全端点通过后才可交付 PNG；无 multimodal 能力时不得以"目测"名义跳过本校验

输出格式（每张附图）

### 图[编号] [标题]

[SVG 代码]

**附图简要说明**：[一句话描述该图内容，用于说明书附图说明部分]

类型边界

可输出的附图类型：方法/流程图、系统架构框图、简单机械结构示意图（几何形状组合）、信号/数据流图、状态转换图、时序图（简化）。

不可输出的附图类型（遇到时明确告知用户）：需要精确尺寸标注的工程图、需要剖面/截面细节的机械图、三维立体结构图、电路原理图（超出简单框图复杂度）、化学结构式、光路图。输出声明：

该附图涉及[具体类型]，超出了线条框图的表达能力，建议使用专业 CAD/建模工具绘制。可以为您提供该图的文字化描述作为绘图参考。

一致性校验（绘制完成后自检）

1. 完备性检查：原文提及属于该图的每个元素是否都已呈现？
2. 准确性检查：元素间关系是否与原文一致？是否引入原文未提及的关系？
3. 简洁性检查：是否存在可进一步精简的冗余文字？
4. 可读性检查：布局是否清晰？是否存在交叉线？标注是否可辨认？
5. 端点对齐检查：每条线段的起点和终点是否落在对应框的边界上？若跟不上，框是否已扩大？

完整工作范例（从方法描述到带反馈回路的流程图 SVG 全过程）见 references/image-worked-example.md，可作为输出风格与精度的参照。

若用户答复"不需要附图"，跳过本环节。

核稿（内置能力）

触发条件：仅在用户答复"需要核稿"后执行。文本输出完成后，询问用户是否需要核稿；用户确认后，由本技能直接执行核稿（不依赖任何外部技能）。

本技能内置专利申请文件核稿能力：以资深专利审查专家视角，从法律合规性、技术逻辑性、撰写规范性、实用价值性四个维度，按三阶段制执行核稿，输出结构化的核稿意见通知书。

核查四维度

三阶段制执行协议

执行规则：

1. 关键判定须给出简要核查依据（如引用链核查给出引用路径与累积特征集结论），供用户抽查；不展开完整推理过程
2. 表格渲染强制规则：通知书中所有结构化信息必须使用 Markdown 表格语法输出，严禁用纯文本缩进、制表符或代码块替代表格
3. 核稿开始前，先列出三阶段任务清单，然后按顺序依次完成三阶段核稿，中途不暂停
4. 进入下一阶段须综合前序阶段发现的问题进行关联判断

问题严重程度星标体系：

阶段1：权利要求书核查（确立法律边界的内部合法性）：

• 独立权利要求实质内容核查（核心技术问题、发明目的可实现性、必要技术特征、上位概括合理性、独权布局合理性、单一性）
• 从属权利要求实质内容核查（引用关系正确性、特征引用逻辑闭合性、完整性与最少原则、创新点相关性与优先级）
• 特殊权利要求类型核查（方法权利要求、产品与方法撰写风格区分、用途权利要求、功能性限定）
• 权利要求书形式核查（数量与类型、禁止表格、多项引用多项禁止、形式从属实质独立、附图标记、发明主题禁用词）
• 权利要求书文字规范核查（禁用词汇、百分比、命名一致性、技术效果描述合规性、错别字、歧义表述、清楚性）

阶段2：说明书核查（验证支撑基础的完整性与规范性）：

• 发明名称核查、技术领域核查
• 背景技术核查（段落结构与逻辑递进、严禁事项）
• 发明内容核查（发明目的、从属权利要求内容处理、技术效果描述、格式规范）
• 实施例核查（可实现性、完整性、技术效果可验证性、概括范围的可实现性、清楚性）
• 对比例核查（如适用）

阶段3：全文交叉验证与综合评审（验证边界与基础的同构性，输出综合评审）：

• 权利要求书与说明书的一致性验证
• 技术效果的逻辑闭环验证
• 引用链体系的全文一致性验证
• 综合汇总（合并三阶段问题，按严重程度排序，输出最终综合评审）

输入与降级规则

• 核稿对象为已撰写的申请文件（权利要求书、说明书、摘要）。若交付物为 .docx，先执行 scripts/docx_to_text.py <文件> -o <输出.md> 转为 Markdown 后读取（仅依赖标准库）
• 文件不完整时降级执行：仅提供权利要求书 → 仅执行阶段1；缺少说明书 → 跳过阶段2并在通知书中注明「未核查说明书」。不得因文件不全而拒绝执行
• 超长文档分段读取：单文件超出上下文容量时，按「权利要求书 → 说明书发明内容 → 实施例 → 其余部分」的优先级分段读取

输出处理

每阶段核稿意见通知书以 Markdown 格式输出（按 references/output-templates.md 模板），三阶段全部完成后输出最终综合意见；如需 .docx 版本，用 scripts/md_to_docx.py 转换。所有结构化信息必须使用 Markdown 表格语法。完整核查标准（引用链体系、四步核查法、禁用词汇表等）见 references/checking-standards.md。

边界声明

以下事项超出核查的逻辑边界，输出仅供参考，须由人类专家最终裁定：

• 实质创造性判断（第22条第3款）、新颖性评估（第22条第2款，依赖现有技术检索）
• 上位概括的最优边界、实验数据真实性验证、特定技术领域审查惯例
• 等同原则具体适用范围、禁止反悔原则适用判断（依赖诉讼实践经验）
• 违反法律的发明创造（第5条）、不授予专利权范围（第25条）、修改超范围（第33条）

结果归集

将核稿意见通知书作为独立交付物输出，供用户审阅；如需基于核稿意见修改文本，等待用户明确指示后再改。若用户答复"不需要核稿"，跳过本环节。

输出格式约定

• 最终交付为 .docx 文件：将完整申请文件（权利要求书、说明书（技术领域/背景技术/发明内容/附图说明/具体实施方式）、说明书摘要、附图）先整理为 Markdown 中间稿，再通过内置脚本转换为 docx（见"docx 转换（内置脚本）"章节）。同时保留 Markdown 源文件以便后续修改
• 所有 [待确认] / [待补充] 标记必须保留在输出中，不可自行填充；资料齐全自动执行时，若发现缺失信息，先尝试基于交底书合理推断并在输出中标注 [待确认]，仅在关键信息确实缺失影响撰写时向用户提问
• 自动执行模式下，阶段间用简短进度提示（如"阶段1完成，进入权利要求书撰写…"）衔接，最终一次性交付完整文本与 docx
• 交付后必须询问：文本交付完成后，向用户提出两个独立问题——①是否需要生成附图？②是否需要核稿？等待答复后按"附图生成（内置能力）"/"核稿（内置能力）"章节执行；未获答复前不启动附图或核稿能力

默认撰写规范（用户偏好，可被显式要求覆盖）

以下为默认撰写规范，用户显式要求调整时以用户要求为准：

1. 权利要求默认 10 条：权利要求书默认总数为 10 条，推荐布局如下：
   • 权利要求 1：方法独立权利要求；
   • 权利要求 2~8：方法从属权利要求（仅保留核心附加特征：风险分级公式、权重、阈值条件、方向计算、执行机构细节、冗余设计等，同类可合并，避免逐条铺开）；
   • 权利要求 9：系统/装置独立权利要求（与方法独立权利要求对应）；
   • 权利要求 10：计算机可读存储介质独立权利要求（引用方法权利要求）。
   • 默认不单独撰写"电子设备/车辆"类独立权利要求；从属权利要求条数不足时以合并附加特征补足，条数多于 10 条时优先删除非核心从属。
2. 具体实施方式不采用"实施例一/二/三/四"分标题：具体实施方式按连续叙述组织，不使用"实施例X"章节标题；各实施内容（方法实施→系统实施→车辆/设备实施→存储介质实施）用"进一步地"、"此外"、"本发明实施方式还提供…"等过渡语句衔接；正文中不出现"本实施例"字样，统一使用"本实施方式"。

默认格式模版（docx 排版规范）

生成 docx 时必须遵循以下默认格式模版（用户另有要求时以用户要求为准）：

1. 默认模板样式：使用 Word/WPS 默认模板（Normal 样式），页眉页脚不写入任何来源标注
2. 权利要求书编号：每条权利要求必须有编号 1.、2.、…、12.（数字 + 英文句点 + 空格），编号位于该条权利要求起始段的段首，不可丢失、不可使用自动编号列表
3. 正文段落格式：
   • 首行缩进 2 字符（OOXML：w:firstLineChars="200"），作用于全部正文段落（权利要求各项、说明书正文段落）
   • 无左侧缩进、无右侧缩进（w:left="0"、w:right="0"）
   • 章节标题段（权利要求书、说明书、技术领域、背景技术、发明内容、附图说明、具体实施方式、实施例一/二/三、说明书摘要等）不设置首行缩进
4. 题目（发明名称）位置：发明名称写入说明书部分的第一行（即"说明书"章节标题之后、技术领域之前），居中对齐，字体黑体加粗（建议14pt）
5. 分页：说明书与权利要求书之间插入分页符，使说明书从新页开始；权利要求书与说明书为两个独立页面部分
6. 其他排版（沿用脚本默认）：正文宋体小四（12pt）、1.5 倍行距、标题黑体加粗（#→16pt、##→14pt、###→13pt）、表格网格线

上述规范已固化到 scripts/md_to_docx.py 脚本中；若需人工调整格式，参照上表逐项核对。

docx 转换（内置脚本）

技能内置转换脚本 scripts/md_to_docx.py，将申请文件 Markdown 稿转换为符合"默认格式模版"的 docx。脚本自动完成：

1. 默认模板、无页眉来源标注：使用默认模板样式，不写入文档页眉/页脚
2. 排版（与"默认格式模版"一致）：标题黑体加粗（#→16pt、##→14pt、###→13pt）、正文宋体小四、1.5 倍行距、正文段落首行缩进2字符（firstLineChars="200"）且无左右缩进、表格网格线
3. 权利要求编号保留：Markdown 中以 1. 、2. 等开头的权利要求段保留编号文本，作为普通段落输出（不转成自动编号列表），首行缩进2字符
4. 题目与分页：发明名称（Markdown 一级标题）识别后置于说明书标题后第一行、居中；在"说明书"标题段前插入分页符
5. 附图处理：Markdown 中 ![附图标题](图片路径) 标记——PNG/JPG 直接嵌入 docx 居中显示；SVG 因 docx 不支持直接嵌入，输出占位提示并随包单独交付 SVG 文件

使用方式（Windows 环境）：

# 首次使用需准备解释器环境：
#   python -m venv <env路径>
#   <env路径>/Scripts/pip install python-docx
<解释器路径>/python.exe scripts/md_to_docx.py <输入.md> <输出.docx>
# 或省略输出路径，自动生成与输入同名的 .docx；也支持 --stdin 从标准输入读取

若环境未安装 python-docx，可降级方案：将 Markdown 稿直接交付，并告知用户可用本脚本自行转换；不得因转换失败丢弃申请文件内容。