本指南提供写作与审查方法。涉及具体申请法域、法定期限或法律效力时，核对当前主管机关资料，并标注来源；未完成检索时不作确定性结论。

# 专利申请文件审查清单

对已完成的专利申请文件进行系统化质量检查。审查结果按三个严重等级分类，帮助快速定位和优先处理关键问题。

---

## 问题严重等级

| 等级 | 含义 | 处理优先级 |
|---|---|---|
| **致命** | 直接导致驳回或权利范围严重缺陷，提交前必须修正 | 立即修正 |
| **重要** | 可能导致审查意见或减弱保护效果，强烈建议修正 | 优先修正 |
| **改进** | 不影响授权但可以提升文件质量，视时间精力决定 | 有余力时修正 |

审查时对发现的每个问题标注等级，修改时按"致命 → 重要 → 改进"的顺序处理。

---

## 一、权利要求书审查

### 1.1 清楚性检查

权利要求是否清楚地限定了保护范围？

| 检查项 | 等级 | 说明 |
|---|---|---|
| 有无模糊限定词 | 致命 | 检查是否含有"大约""基本上""适当地""近似"等词，除非给出了明确的判断标准 |
| 有无主观评价词 | 致命 | 检查是否含有"高效""优质""良好""最佳""足够"等无客观标准的词 |
| 有无相对性用语 | 重要 | 检查是否含有"较大""较小""较高""较低"等没有比较基准的词 |
| 技术特征是否具体 | 重要 | 每个技术特征是否有明确的技术含义，而非功能性的空泛描述 |
| 主题名称是否恰当 | 改进 | 主题名称是否准确反映了权利要求保护的技术方案 |

**模糊用语速查表**（以下词语在权利要求中出现时需要警惕）：

> 大约、约、基本上、实质上、大致、近似、适当、合适、适宜、足够、必要时、可选地、优选、优选地、较好、较佳、等等、诸如、例如、高效、优秀、先进、良好、显著、明显

### 1.2 先行词一致性检查

"所述"引用是否都能找到先行词？

| 检查项 | 等级 | 说明 |
|---|---|---|
| 每个"所述XX"是否有先行词 | 致命 | 逐条检查：每个"所述"后面的术语，是否在前面的权利要求中用"一种/一个"引入过 |
| 术语是否全文一致 | 致命 | 同一技术特征在不同权利要求中名称是否完全一致，不能一处写"处理模块"另一处写"处理单元" |
| 首次引入是否用"一种/一个" | 重要 | 每个技术特征的首次出现是否使用了正确的引入格式 |

**检查方法**：对每条权利要求，提取所有"所述XX"的引用，在该条权利要求及其引用链上逐一查找对应的引入。

### 1.3 权利要求结构检查

权利要求体系的结构是否合理？

| 检查项 | 等级 | 说明 |
|---|---|---|
| 独权是否只含必要技术特征 | 重要 | 独权中有没有可以移到从权中的非必要特征？独权特征过多导致保护范围过窄 |
| 从权引用关系是否正确 | 致命 | 从权引用的编号是否指向正确的权利要求？引用链是否逻辑自洽？ |
| 从权是否每条只限定一个维度 | 重要 | 一条从权中是否同时限定了两个不相关的特征？ |
| 多引权利要求是否被再次多引 | 致命 | 多引的从权不能再被多引 |
| 方法权利要求与装置权利要求是否对应 | 重要 | 方法步骤与装置模块是否一一对应？ |
| 权利要求总数是否合理 | 改进 | 通常10-25条为宜 |

### 1.4 保护范围检查

| 检查项 | 等级 | 说明 |
|---|---|---|
| 独权保护范围是否足够宽 | 重要 | 有没有不必要的限定缩小了保护范围？ |
| 从权是否覆盖了主要变体 | 重要 | 核心技术特征的替代实现方式是否有从权覆盖？ |
| 是否有多种类型的权利要求 | 改进 | 是否同时包含方法和装置权利要求？软件类是否包含存储介质权利要求？ |

---

## 二、说明书审查

### 2.1 充分公开检查

| 检查项 | 等级 | 说明 |
|---|---|---|
| 权利要求中的每个特征是否都有描述 | 致命 | 逐条比对：权利要求中的每个技术特征，在说明书中是否都有对应的详细描述？ |
| 关键步骤是否有具体实现方式 | 致命 | 有没有"黑箱"——只说了做什么，没说怎么做？ |
| 关键参数是否给出 | 重要 | 涉及阈值、比例、范围等参数时，有没有给出具体值或选择依据？ |
| 本领域技术人员能否实现 | 重要 | 整体判断：读完说明书后，一个有经验的工程师能否不做创造性劳动就实现发明？ |

### 2.2 支持性检查

| 检查项 | 等级 | 说明 |
|---|---|---|
| 独权的方案在"发明内容"中是否有概述 | 重要 | "发明内容"部分的技术方案描述是否覆盖了独权的核心内容 |
| 从权的附加特征在实施例中是否有体现 | 重要 | 每条从权的附加特征是否在至少一个实施例中有详细描述 |
| 上位概念是否有下位支撑 | 重要 | 独权中使用了上位概念（如"分类模型"）时，说明书中是否给出了具体的下位实例（如"SVM、随机森林、神经网络"） |

### 2.3 结构完整性检查

| 检查项 | 等级 | 说明 |
|---|---|---|
| 五大部分是否齐全 | 致命 | 技术领域、背景技术、发明内容、附图说明、具体实施方式 |
| 技术问题→方案→效果逻辑链是否完整 | 重要 | 背景技术中的不足 → 发明内容中的方案 → 技术效果，三者是否环环相扣 |
| 附图说明与实施方式中的引用是否一致 | 重要 | 附图说明中列出的每幅图，在具体实施方式中是否都有引用？反过来也要检查 |

### 2.4 术语一致性检查

| 检查项 | 等级 | 说明 |
|---|---|---|
| 说明书与权利要求书术语是否一致 | 致命 | 同一技术特征在两份文件中是否使用完全相同的术语 |
| 说明书内部术语是否一致 | 重要 | 同一概念在说明书不同部分是否使用了同一名称 |
| 附图标记是否一致 | 改进 | 同一组件的附图标记在全文中是否统一 |

---

## 三、摘要审查

| 检查项 | 等级 | 说明 |
|---|---|---|
| 字数是否合规 | 重要 | 通常控制在300字以内 |
| 是否涵盖三要素 | 重要 | 技术问题（或技术领域）+ 技术方案要点 + 主要用途或效果 |
| 是否独立可读 | 改进 | 不依赖说明书，单独阅读摘要能否理解发明概要 |
| 是否含有不当内容 | 改进 | 摘要中不应有商业宣传性语言 |

---

## 四、形式审查

| 检查项 | 等级 | 说明 |
|---|---|---|
| 权利要求编号是否连续 | 致命 | 从1开始连续编号，不跳号 |
| 从权引用编号是否存在 | 致命 | 引用的权利要求编号指向的条目是否真实存在 |
| 附图编号是否连续 | 重要 | 图1、图2、图3...不跳号 |
| 说明书各部分标题是否规范 | 改进 | 使用标准的部分标题名称 |

---

## 审查输出格式

审查完成后，按以下格式输出审查报告：

```
## 审查报告

### 致命问题（X项）
1. [位置] 问题描述 → 建议修改方案
2. ...

### 重要问题（X项）
1. [位置] 问题描述 → 建议修改方案
2. ...

### 改进建议（X项）
1. [位置] 问题描述 → 建议修改方案
2. ...

### 总体评价
[对文件整体质量的简要评价，以及建议的修改优先级]
```

其中"位置"标注为：权利要求X / 说明书-技术领域 / 说明书-背景技术 / 说明书-发明内容 / 说明书-具体实施方式 / 摘要 等。

如果用户要求，在给出审查报告后可以直接输出修改后的完整文件。

如果用户提供了 DOCX，先读取结构，再用 `scripts/edit_document.py` 回填。需要修订标记的文本替换添加 `--track-changes --author <作者>`；操作结构、已有修订限制和校验流程见 `references/word-operations.md`。