---
slug: "patent-writer"
source_type: "skill_md"
source_url: "https://cdn.jsdelivr.net/gh/ry-xiaopanghu/patent-writer@main/SKILL.md"
repo: "https://github.com/ry-xiaopanghu/patent-writer"
source_file: "SKILL.md"
branch: "main"
---
---
name: patent-writer
description: 撰写中国发明专利技术交底书，生成 .docx 文件到 ~/Desktop/zhuanli/ 目录。当用户说"写专利"、"帮我申请专利"、"这个能不能申请专利"、"给我写一篇技术交底书"、"patent"、"专利idea"、"有个想法能不能申请专利"时必须触发。适用于 AI/算法/软件/通信/控制等多种技术方向。执行完整 7 步流程，最终输出技术交底书 .docx 和提案系统填写参考。遇到专利相关请求务必调用本 skill，不要自行撰写。
---

# Patent Writer — 中国发明专利技术交底书撰写

## 适用范围

本 skill 不绑定任何特定公司或团队，可用于任何中国发明专利技术交底书的撰写。建议在使用前根据自己团队情况，把以下两个外部依赖填好：

- **本团队已有专利清单**（可选）：用于 Step 3 去重，避免重复申请。形式不限——可以是本地 Markdown、内部 wiki、Notion 数据库、Google Doc 等。在 Step 3C 把它的读取方式告诉 Claude 即可（例如 `cat ~/path/to/team-patents.md`）。
- **本公司专利提交系统**（可选）：用于 Step 7 生成"提案系统填写参考"时贴合贵司表单字段。把贵司提案系统的字段名（提案名称 / 关键词 / 核心创新点 / 技术领域 / 发明人比例 / 产出地等）告诉 Claude，它会按字段输出。

## 检索工具配置

> Token **不写死在本文件中**。每位用户第一次使用前，请按 USAGE.md 注册自己的 token 并写入 `~/.config/patent-writer/secrets.env`，本 skill 在 Step 3 检索前会自动加载。

**Token 加载逻辑**：

```python
import os
from pathlib import Path

def load_secrets():
    env_path = Path.home() / '.config/patent-writer/secrets.env'
    if env_path.exists():
        for line in env_path.read_text().splitlines():
            line = line.strip()
            if line and not line.startswith('#') and '=' in line:
                k, v = line.split('=', 1)
                os.environ.setdefault(k.strip(), v.strip().strip('"').strip("'"))

load_secrets()
DEEPXIV_TOKEN = os.environ.get('DEEPXIV_TOKEN', '')
SERPAPI_KEY   = os.environ.get('SERPAPI_KEY', '')

assert DEEPXIV_TOKEN and SERPAPI_KEY, \
    '请先在 ~/.config/patent-writer/secrets.env 配置 DEEPXIV_TOKEN 与 SERPAPI_KEY，参考 USAGE.md'
```

- **论文（deepxiv_sdk）**：注册地址 https://data.rag.ac.cn/register
  ```python
  from deepxiv_sdk import Reader
  reader = Reader(token=DEEPXIV_TOKEN)
  ```
- **专利（SerpAPI Google Patents）**：注册地址 https://serpapi.com/users/sign_up（每月 250 次免费额度）
  - 直接 `urllib.request.urlopen(url, timeout=20)`
  - 参数 `num` 必须 ≥10
  - 中文检索加 `country=CN`，国际加 `country=WO`/`US`
- **回退方案**：若上述工具均失败，可手动用商用专利数据库（如 PatSnap / 智慧芽 / Google Patents 网页版）补充检索后，把关键发现告诉 Claude

## 工作目录与中间产物（断点续跑必备）

每个专利都建立独立工作区，所有中间产物以 JSON/Markdown 落盘，便于回退、审查、跨会话续接：

```
~/Desktop/zhuanli/<发明名称>/
├── 技术交底书-<发明名称>.docx        # 最终产物
├── 提案填写参考.txt                  # 最终产物
└── .workspace/                       # 中间产物（团队成员接手时直接读取）
    ├── 01_idea.md                    # Step 1 整理后的 idea 摘要
    ├── 02_triplet_v1.json            # Step 2 初步三要素（强 Schema）
    ├── 03_research/
    │   ├── papers.json               # deepxiv 检索结果
    │   ├── patents.json              # SerpAPI 检索结果
    │   └── team_patents.json         # 本团队已有专利去重结果（可选）
    ├── 03_triplet_v2.json            # Step 3.5 修正后的三要素
    ├── 03_patentability.json         # Step 3.8 可专利性判断
    ├── 04_outline.json               # Step 4 大纲与权利要求框架
    ├── 04_title_candidates.json      # Step 4 发明名称 3 选 1
    ├── 05_content.json               # Step 5 各章节合并后的 content（即 generate_docx.py 入参）
    ├── 06_review_score.json          # Step 6 打分明细与扣分项
    └── 06_iter_log.md                # 每轮回退/重试的失败原因日志
```

**回退时只重写对应文件，其他文件不动**——例如 Step 6 打分发现"技术方案缺参数"，只回到 Step 5 ③重写实施方式部分并更新 `05_content.json`，不必重新跑 Step 1-4。

**接手原则**：第一件事是 `cat .workspace/06_iter_log.md` 看历史决策，再 `cat .workspace/03_triplet_v2.json` 看当前确定的三要素，避免推翻已经评审过的内容。

---

## 历史驳回规律（核心避坑）

| 类型 | 特征 | 驳回依据 |
|------|------|----------|
| ❌ 商业方法 | 纯运营策略、用户激励、业务流程，无技术手段 | 专利法第2条第2款 |
| ❌ 纯算法改进 | 实质是数学模型优化，不解决特定技术问题，效果是算法本身改进 | 专利法第2条第2款+第22条 |
| ✅ 可专利 | 具体技术手段 + 特定技术领域的技术问题 + 技术效果（非通用算法改进） | — |

---

## 完整工作流程

### Step 1：整理 Idea

收集用户提供的所有输入：
- 文字描述的 idea
- 代码目录（读取关键文件理解实现，**不在交底书中引用代码**）
- 内部 wiki / 设计文档（如果用户提供 URL，可用相应工具读取）
- 其他背景材料

输出一段结构化摘要：
```
【技术背景】：当前系统/场景是什么
【核心做法】：这个 idea 的主要技术动作
【初步区别点】：与通常做法有何不同（此时只是猜测，Step 3后会修正）
```

如果用户没有提供 idea，基于代码目录或团队已知方向，提供 3-5 个可申请专利的方向建议供用户选择，再进入 Step 2。

---

### Step 2：初步三要素分析 + 技术化翻译

提炼三要素草稿，**同时将业务语言翻译为技术语言**（这是 AI/算法类专利的核心难点）：

**三要素框架（PPT三问）：**
> Q1：现有技术存在什么具体技术问题？
> Q2：本提案采用了什么技术手段？（分步骤）
> Q3：实现了什么技术效果？

**技术化翻译规则（AI/算法类必须执行）：**

| 业务表达（❌错误） | 技术化表达（✅正确） |
|-------------------|---------------------|
| 提升模型准确率 | 降低低光照场景下视觉缺陷检测的误检率 |
| 改进算法效果 | 在工业管道泄漏检测系统中，通过多频段声纹特征融合机制过滤环境噪声干扰 |
| 更智能的推荐 | 基于用户运动轨迹的可穿戴设备能耗模式自适应切换方法 |
| 优化大模型输出 | 构建分层验证管道，对 LLM 生成的 JSON Patch 指令执行路径守卫+Schema 约束四级串行校验 |

**输出格式（强 JSON Schema，落盘到 `.workspace/02_triplet_v1.json`）：**

```json
{
  "technical_problem": "具体技术缺陷的精确描述，非业务问题",
  "technical_solution": "技术手段总览（一句话）",
  "technical_effect": "可量化或可描述的技术改善",
  "core_inventive_concept": "用一句话概括本方案最不可替代的发明构思（这是审查员看的）",
  "key_components": [
    {"name": "组件A精确名称", "function": "组件A在方案中承担的具体功能"},
    {"name": "组件B精确名称", "function": "组件B在方案中承担的具体功能"}
  ],
  "method_steps": [
    {"id": "S1", "name": "步骤一精确名称", "description": "步骤一在做什么", "is_key": true},
    {"id": "S2", "name": "步骤二精确名称", "description": "步骤二在做什么", "is_key": false}
  ]
}
```

**为什么必须用 JSON Schema 而非自由文本**：`key_components` 和 `method_steps` 里的 `name` 字段是**全文术语锚点**——Step 4 的权利要求、Step 5 的实施方式、Step 6 的术语一致性校验都引用这同一份字段。这能根治"独权写'拦截器'、实施方式写'代理层'"这种术语漂移（专利工程师退稿的最高频原因之一）。

展示 JSON 给用户确认（特别是 `key_components` 的命名），确认后写入 `.workspace/02_triplet_v1.json`，进入 Step 3。

---

### Step 3：检索现有技术

**3A. 论文检索（deepxiv_sdk）：**
```bash
pip install deepxiv-sdk -q 2>/dev/null
```
```python
from deepxiv_sdk import Reader
reader = Reader(token=DEEPXIV_TOKEN)  # 已由本节顶部 load_secrets() 加载
results = reader.search(
    query="<从Step2提取的技术关键词，英文>",
    size=5,
    source="arxiv",
    categories=["cs.DB", "cs.AI", "cs.IR"]
)
# 对每篇相关论文获取摘要
for r in results['result']:
    brief = reader.brief(r['arxiv_id'])
```

**3B. 专利检索（优先 MCP，回退 SerpAPI）：**

> **检索声明（写入提示词，避免抄袭）**：本 step 检索现有专利**仅用于学习写作风格、了解术语习惯、识别真正的差异点**——严禁将检索到的权利要求文本、技术方案描述直接复制到本发明的交底书中。每次检索后，必须明确写出"本方案与检索到的方案 X 的差异点是 Y"。

**优先方式：MCP 工具**（如果已配置 `mcp__google-patents-mcp` 或 `mcp__exa`）：
- 调用方式由 runtime 决定，免去手填 SerpAPI Key
- 失败时回退到下方 SerpAPI 方式

**回退方式：SerpAPI Google Patents（urllib 直调）：**

```python
import urllib.request, urllib.parse, json

# SERPAPI_KEY 已由本节顶部 load_secrets() 加载

def search_patents(query, num=10, country=''):
    params = {'engine': 'google_patents', 'q': query, 'api_key': SERPAPI_KEY, 'num': num}
    if country:
        params['country'] = country
    url = f'https://serpapi.com/search?{urllib.parse.urlencode(params)}'
    req = urllib.request.Request(url, headers={'User-Agent': 'Mozilla/5.0'})
    with urllib.request.urlopen(req, timeout=25) as resp:
        return json.loads(resp.read())

# 至少检索 4 组关键词：英文核心 + 中文核心 + 同义词扩展 + 上下位概念
# 中文关键词加 country='CN'，英文加 country='WO' 或 'US'
```

**检索策略要求：**
- 至少 4 组不同关键词（中英文各 2 组），每组返回 10 条
- 重点提取：publication_number、title、snippet 三字段
- 对最相关的 3-5 篇做差异点对比（不能只列标题）

**回退方案**：若 SerpAPI 不可用，可使用商用专利数据库（PatSnap / 智慧芽 / Google Patents 网页版）手动检索后告诉 Claude 关键发现。

**3C. 读取本团队已有专利（可选，避免重复）：**

如果你团队维护了已有专利清单（任意形式：本地文件、内部 wiki、Notion、Google Doc 等），把读取方式告诉 Claude，例如：

```bash
cat ~/path/to/team-patents.md
# 或
# <用你公司的内部 wiki CLI 工具读取>
```

提取已有专利的名称和核心创新点，与当前 idea 比对去重。如果没有清单可读，跳过此步即可。

**输出：**
- 相关论文列表（标题+摘要+与本方案的差异）
- 相关专利列表（名称+摘要+区别点）
- 团队已有专利中是否有重叠（若提供）

---

### Step 3.5：修正三要素

基于检索结果，更新 Step 2 的三要素：
- **技术问题**：结合检索到的现有方案，明确"现有方案做到了X，但在Y场景下仍存在Z缺陷"
- **区别点**：从检索结果中找出本方案真正的差异特征
- **技术效果**：对照已有方案，量化或具体化效果

---

### Step 3.8：可专利性判断

基于修正后的三要素 + 检索结果，综合判断：

**判断矩阵：**

| 判断项 | 标准 | 通过/不通过 |
|--------|------|-------------|
| 保护客体 | 非商业方法、非纯算法数学改进 | — |
| 技术性 | 有具体技术手段，与特定技术系统绑定 | — |
| 新颖性 | 与检索专利/论文相比有实质区别特征 | — |
| 创造性 | 区别点非本领域显而易见的适应性调整 | — |

**结论三选一：**
- ✅ **可申请** → 继续 Step 4
- ⚠️ **风险较高（60-80分）** → 说明具体风险点 + 给出调整方向，询问用户是否继续
- ❌ **建议不申请** → 说明具体原因（商业方法/纯算法改进/与现有专利高度重合），**直接终止**，建议作为商业秘密保护

---

### Step 4：生成发明名称 + 大纲 + 权利要求框架

#### 4.0 发明名称 3 选 1（先做）

基于 Step 3.5 修正后的三要素，生成 **3 个候选发明名称**让用户挑选：

**命名规则（这些是审查指南明确禁止/不推荐的写法）：**
- ❌ 含 "智能/优化/改进/创新" 等空洞修饰词
- ❌ 含产品型号、品牌名（如某操作系统/某品牌型号）
- ❌ 含 "基于人工智能的..."（太宽泛，等于没写）
- ❌ 长度超过 25 个汉字
- ✅ 推荐句式：`一种<动作动词><对象>的<方法/系统/装置>`，如 "一种基于多视角图像融合的电池表面缺陷检测方法"
- ✅ 包含本方案最不可替代的发明构思（可从 Step 2 的 `core_inventive_concept` 字段提取）

**输出 3 个候选 + 各自的取舍说明，让用户挑一个**，落盘到 `.workspace/04_title_candidates.json`。

#### 4.1 权利要求框架

**先写权利要求框架**（权利要求决定保护范围，说明书为权利要求服务）：

#### 两段式权利要求格式（中国专利标准格式）

每条权利要求由**前序部分**（已知技术领域+共性特征）+ "**其特征在于**" + **特征部分**（本发明的区别技术特征）组成。

```
权利要求 1（独立权利要求 - 方法类）：
  一种[发明名称]，应用于[特定技术领域/系统]，其特征在于，包括：
  S1：[第一个核心步骤，含必要参数]；
  S2：[第二个核心步骤]；
  S3：[第三个核心步骤]；
  ...
  其中，[关键技术特征的进一步限定]。

权利要求 2-N（从属权利要求，逐层细化）：
  根据权利要求 1 所述的方法，其特征在于，[在权利要求1基础上的进一步限定]。

权利要求 N+1（独立权利要求 - 系统/装置类）：
  一种[发明名称]系统，其特征在于，包括：
  [模块1]，用于...；
  [模块2]，用于...；
  ...

权利要求 N+2（独立权利要求 - 计算机可读存储介质，软件类必加）：
  一种计算机可读存储介质，其上存储有计算机程序，其特征在于，
  所述计算机程序被处理器执行时实现权利要求1-N任一项所述的方法。

权利要求 N+3（电子设备，软件类建议加）：
  一种电子设备，包括存储器和处理器，其特征在于，[...]。
```

#### 权利要求 Few-Shot 正例（严格按此句式与标点）

> **1.** 一种数据处理方法，**其特征在于**，包括：
> 获取待处理数据；
> 根据**所述**待处理数据的类型，确定目标处理模型；
> 调用**所述**目标处理模型对**所述**待处理数据进行处理，**得到**处理结果。
>
> **2. 根据权利要求 1 所述的方法**，其特征在于，**所述根据所述待处理数据的类型，确定目标处理模型**，包括：
> 提取**所述**待处理数据的统计特征；
> 将**所述**统计特征输入预训练的分类模型，**得到**所述目标处理模型的标识。
>
> **3. 根据权利要求 1 或 2 所述的方法**，其特征在于，**所述目标处理模型**为基于 Transformer 架构的神经网络模型，**所述** Transformer 架构包括 N 层编码器和 N 层解码器，N 为大于等于 1 的整数。
>
> **4.** 一种数据处理装置，**其特征在于**，包括：
> 获取模块，用于获取待处理数据；
> 确定模块，用于根据**所述**待处理数据的类型，确定目标处理模型；
> 处理模块，用于调用**所述**目标处理模型对**所述**待处理数据进行处理，**得到**处理结果。

**关键句式约束（中文专利权利要求的硬性规则）：**
- 第一次出现的对象用 "一种 / 一个"，再次提及统一改为 "**所述**"（绝不能用 "该/此/这个"）
- 步骤之间用 **"；"** 分隔，最后一步用 **"。"**
- 从属权利要求开头必须是 "**根据权利要求 N 所述的方法/系统/装置**"，不能省略
- 引用上层时可以并列引用："根据权利要求 1 **或** 2 所述..."、"根据权利要求 1 **至** 5 中**任一项**所述..."
- 系统/装置类的模块描述统一用 "**XX 模块**，用于 ...；" 句式

#### 权利要求质量要求

- **独立权利要求 1**：保护范围最宽——只写"必不可少"的核心技术特征，不要把可选的细节写进去。判断标准：去掉任一特征后方案仍能实现 → 该特征不应进独权
- **从属权利要求 5-7 条**：从不同维度细化（如：参数范围、变体场景、可选模块、性能优化），每条单点限定，作为退守阵地
- **不同类型独权之间**：方法权利要求 + 系统/装置权利要求 + 介质权利要求，软件类专利至少包含这三类
- **避免**：用功能性限定堆砌（"用于实现 XX 的模块"是空洞的，要写"基于 XX 算法对 YY 进行 ZZ 操作的模块"）

**策略说明**：权利要求要有层次——独立权利要求写"最宽可守住的范围"，从属权利要求逐层细化作为兜底。若独立权利要求被审查员驳回，从属权利要求可作为退守阵地。

**大纲展示给用户确认，确认后进入 Step 5。**

---

### Step 5：并行撰写各章节 + 流程图

以下章节**并行生成**（权利要求已在Step4完成框架）：

#### 字数与详细度硬性要求

| 章节 | 字数下限 | 必备元素 |
|------|----------|----------|
| 背景技术 | ≥ 800 字 | 至少引用 2 篇相关现有方案，明确指出 2-3 个具体技术缺陷 |
| 发明内容（含三要素） | ≥ 1500 字 | 技术问题/方案/效果一一对应，方案分步骤+参数 |
| 具体实施方式 | ≥ 5000 字 | 至少 1 个详细实施例（推荐 2 个），每步骤含参数阈值 |
| 权利要求书 | ≥ 600 字 | 独权×2-3 + 从属×8-12，方法/系统/介质三类齐全 |
| 摘要 | ≤ 150 字 | 领域+问题+方案要点+效果 |

**说明书全篇总字数下限 ≥ 8000 字**（不含权利要求书和摘要）。低于此阈值的交底书在专利工程师那一关大概率被打回。

#### 章节清单：

**① 背景技术**
- 描述现有技术方案（引用检索到的专利/论文）
- 明确指出 2-3 个具体技术缺陷（与本方案的区别点对应）
- 避免将本方案内容混入背景技术

**② 发明内容**
三部分：
- 技术问题：本发明要解决的技术问题
- 技术方案：分步骤详细描述（含参数阈值/范围/单位）
- 技术效果：每条**严格按"声明 → 关联特征 → 对比现有技术"三段式**写：

  > 示例（✅ 合格）：
  > "本方案在 200~400 lux 低光照条件下将电池表面划痕的漏检率降低至 0.5% 以下（**声明**），
  > 这是因为步骤一通过偏振光片对反光进行抑制、步骤三采用多帧时序融合提升弱信号可分性（**关联特征**），
  > 而现有单帧 CNN 检测方案在该光照范围下漏检率普遍高于 8%（**对比现有技术**）。"

  > 反例（❌ 空话，必须改写）：
  > "本方案显著提升了检测系统的可靠性。"
  > "本方案让缺陷识别更智能、更精准。"
  > "本方案达到了更好的用户体验。"

**为什么强制三段式**：审查员驳回创造性时最常说的话是"未指明效果与技术特征的对应关系"。三段式直接命中创造性论证，强迫每个效果都能挂回到具体的方案步骤上。

**AI/模型类专项要求（深度学习/生成式模型方向必须检查）：**
- [ ] 训练过程和推理过程分开描述
- [ ] 提供模型架构，说明与通用模型/Transformer 标准架构的区别
- [ ] 训练数据特征：类型、规模、是否需要标注
- [ ] 所有公式中每个参数的含义
- [ ] 算法步骤中的关键参数阈值和范围

**③ 具体实施方式（采用 4 步扩写法，单次"写到 5000 字"经常灌水）**

把"≥5000 字"分解为 4 个串行动作，每步完成后**自报字数**，不达标继续扩写：

| 阶段 | 内容动作 | 字数下限 |
|------|----------|----------|
| 第 1 步 初稿 | 整体方法骨架，按步骤编号 S101/S102/...（与权利要求 S1/S2/... 对应），每步骤一段，含输入/输出/动作 | ≥ 2500 字 |
| 第 2 步 段落扩展 | 每个步骤段补：算法细节、数据结构、参数取值范围、异常处理、与现有方案的区别 | 每段 ≥ 800 字，全篇 ≥ 4000 字 |
| 第 3 步 多实施例 | 至少 2 个实施例：基础版（核心场景）+ 变体版（扩展场景或特殊优化） | 全篇 ≥ 5500 字 |
| 第 4 步 技术深化 | 补伪代码、参数表、性能数据、硬件依赖描述、与训练数据规模相关的具体数字 | 全篇 ≥ 6500 字 |

**为什么分 4 步而非一次性堆字数**：实测一次性"写到 5000 字"的输出有 30-40% 是空话（"如本领域技术人员所知..."、"在某些实施例中..."等套话）。分阶段每步都有具体动作目标，灌水率显著下降。**字数不是目的，"动作完成度"才是**——若第 4 步没有任何参数表/伪代码而 5000 字已达标，仍判定为不合格。

**与权利要求的术语一致性硬约束**：实施方式中的"步骤名称"和"组件名称"必须与 Step 2 的 `key_components`/`method_steps` 字段完全一致。例如权利要求 1 写的是"偏振光抑制模块"，实施方式不能换成"反光过滤层"或"图像预处理器"。

**④ 权利要求书（细化Step4框架，严格遵循两段式格式）**
- 独立权利要求 1（方法类）× 1：前序部分 + "其特征在于" + 步骤化特征部分
- 从属权利要求 × 5-7（逐层细化，每条引用上层权利要求）
- 独立权利要求（系统/装置类）× 1：与方法权利要求一一对应的模块结构
- 从属权利要求 × 2-3
- 独立权利要求（计算机可读存储介质）× 1（软件类必加）
- 独立权利要求（电子设备）× 1（建议加）

**校验项**：
- 独权 1 的特征是否能去掉任何一项后方案仍能成立？若能 → 该项不应进独权（保护范围太窄）
- 从属权利要求是否每条都"加了一个新限定"而非重复独权内容？
- 系统类独权与方法类独权的步骤是否一一对应？

**⑤ 摘要**
- 150字以内
- 包含：技术领域 + 技术问题 + 技术方案要点 + 技术效果

**⑥ 流程图（Mermaid，自动渲染并嵌入 docx）**

`generate_docx.py` 通过 `mermaid.ink` 在线 API 自动把 Mermaid 渲染为 PNG 嵌入文档（无需本地安装 mmdc）。为避免渲染失败，**Mermaid 代码必须遵守以下禁止事项**：

| 禁止 | 原因 |
|------|------|
| ❌ 节点标签里写 LaTeX 公式（如 `$F=ma$`） | 渲染器不识别，整张图渲染失败 |
| ❌ 使用 `style/linkStyle/classDef` 自定义样式 | 增加渲染失败概率，且 docx 嵌入不需要美化 |
| ❌ 在节点内换行用 `\n` | 应使用 HTML 标签 `<br>` |
| ❌ 节点标签含特殊字符（如 `()` `,` `:` `"`）但未用双引号包裹 | 解析报错。规则：**所有节点标签都用双引号包裹** |
| ❌ 中文节点 ID（如 `用户 --> 系统`） | 应英文 ID + 中文 label：`U["用户"] --> S["系统"]` |
| ❌ 在 Mermaid 里写 ` % ` 注释 | 部分版本不支持，删掉即可 |
| ❌ 单图节点数 > 30 | 渲染时间长且嵌入 docx 后字号过小不可读，应拆成多张子图 |

**推荐句式**：
```
flowchart TD
    A["输入图像"] --> B["预处理模块"]
    B --> C{"光照是否充分?"}
    C -->|是| D["单帧 CNN 检测"]
    C -->|否| E["多帧融合 + 偏振抑制"]
    D --> F["缺陷定位与分类"]
    E --> F
    F --> G["输出检测结果"]
```

**多图建议**：除了"总体方法流程图"外，至少再生成 2-4 张细节图——应用场景图、关键步骤时序图、模块结构图、端到端调用链路示例图。这些落入 content JSON 的 `extra_diagrams` 字段（已在 `generate_docx.py` 中支持自动渲染并居中嵌入）。

---

### Step 6：审查打分

**打分表（满分100）：**

| 维度 | 分值 | 检查点 |
|------|------|--------|
| 可专利性 | 20 | 非商业方法；技术手段而非纯数学改进 |
| 三要素完整性 | 20 | 问题→方案→效果逻辑链完整、三者一一对应；技术效果按"声明→关联特征→对比"三段式 |
| 技术方案详细度 | 20 | 有参数阈值/范围/单位；算法步骤完整；公式参数有含义说明；具体实施方式 ≥ 5000 字且含 ≥2 个实施例与伪代码/参数表 |
| 与现有技术区别 | 15 | 区别点明确；背景技术与发明内容不混写；引用了真实检索到的现有方案 |
| 权利要求质量 | 10 | 独权保护范围合理（不过宽不过窄）；从属权利要求有层次；用了"所述"句式与"；"分隔 |
| **术语一致性** | **5** | **独权模块名、从属权利要求、实施方式、Step 2 `key_components` 中的命名是否完全一致（无"拦截器/代理层/中间件"漂移）** |
| AI/模型类专项 | 10 | 训练/推理分开；架构差异说明；参数含义完整 |

**阈值：≥ 80分通过，进入Step 7**

**回退映射（< 80分时）：**

| 扣分原因 | 回到哪步 |
|----------|----------|
| 可专利性不足（商业方法/纯算法） | 回 Step 2，重新技术化翻译三要素 |
| 与现有专利重合度高 | 回 Step 3，扩大检索范围后重新判断区别点 |
| 技术方案缺参数/阈值/公式说明 | 回 Step 5②，补充发明内容和具体实施方式 |
| 权利要求保护范围不合理 | 仅重写 Step 5④ 权利要求 |
| 说明书与权利要求不一致 | 回 Step 5，对齐各章节与权利要求 |
| 背景技术与发明内容杂糅 | 回 Step 5①②，重写背景技术 |
| 字数不达标（说明书<8000字、实施方式<5000字） | 回 Step 5③，扩充实施例细节 |

#### 重试机制

每个回退步骤**最多重试 3 次**：
- 第 1 次：按上表回到对应步骤，重新生成
- 第 2 次：分析为何上一次仍未通过，调整策略后重试
- 第 3 次：若仍不达标，将打分结果与具体扣分项明确告知用户，由用户决定是放弃、强行通过、还是手动补充

**重试不要无脑循环**：每次重试前必须先分析失败原因（如：字数不够 vs. 技术细节不够 vs. 权利要求保护范围错位），针对性地修改上一步的输出，而非简单重新生成。

---

### Step 7：合并生成文档

创建输出目录并生成文件：
```bash
mkdir -p ~/Desktop/zhuanli/<发明名称>
```

调用生成脚本：
```bash
python3 ~/.claude/skills/patent-writer/scripts/generate_docx.py \
  --output "~/Desktop/zhuanli/<发明名称>/技术交底书-<发明名称>.docx" \
  --content '/tmp/patent_content.json'
```

**同时生成提案系统填写参考**（用于在贵公司专利提案系统填表时参考）：
```
~/Desktop/zhuanli/<发明名称>/提案填写参考.txt

内容：
提案名称：一种XXX方法
关键词（2-4个）：XXX、XXX、XXX
核心创新点文字说明：[100-200字，精炼版技术方案]
技术领域分类：[建议的分类]
产品分类：[建议的产品类型]
```

> 不同公司的提案系统字段不同。请把贵公司提案系统的字段名告诉 Claude，它会按字段输出。

---

## 附：15 分钟校稿清单（输出在文档末尾）

```
□ 流程图中参数名称是否前后一致？
□ 控制/算法类：关键参数阈值和范围是否都写了？
□ 涉及公式：每个参数的含义是否都解释了？
□ 现有技术的缺陷与本方案的效果是否一一对应？
□ 背景技术中是否有本方案内容混入？
□ 非中文技术名词是否有中文注释（如 Transformer、Attention）？
□ 独立权利要求是否为最宽保护范围，且能与现有技术区分？
□ 提案系统的必填字段（提案名称/关键词/核心创新点/发明人比例等）是否填写完整？
```
