判断实施例够不够，用一条规则就够：拿权利要求书逐条对照说明书，每个技术特征都能在实施例里找到具体实现。找不到的那条权利要求就没有支撑，审查时会被要求删除或者修改。
为什么实施例比权利要求更关键
专利法第二十六条第四款要求权利要求以说明书为依据。这条要求在审查里出现频率极高：独立权利要求概括的范围超出了实施例能支撑的程度，就会被指出概括过宽。这时候能做的修改只有往回收，而收多少取决于实施例写到了哪里。
三种情况分别要写几个
| 方案类型 | 实施例数量 | 关键点 |
|---|---|---|
| 单一结构改进 | 一个主实施例，加两三个替代方案 | 替代方案要写清换了什么、效果差别 |
| 参数或范围类 | 至少覆盖范围两端和中间点 | 每个取值都要有对应的效果说明 |
| 方法类 | 一个完整流程，加变体步骤 | 判断条件和分支要写出来 |
实施例里必须有的内容
- 具体结构或具体步骤，不要用「可以采用已知方式」这类表述带过。
- 参数的具体取值，以及与取值对应的效果。范围类方案尤其重要。
- 替代方案的可行性说明。写了「也可以采用螺纹连接」就要说清为什么可行。
- 与附图标记的对应关系，每个提到的部件都要能在图上找到。
写实施例的操作顺序
- 先把独立权利要求的特征逐个列出来，做成一张对照表。
- 为每个特征写一段具体实现，能给出数值的给数值，能给结构的给结构。
- 再回头看从属权利要求的每一条，逐条找落点。找不到落点的，要么补实施例，要么删掉这条从属权利要求。
- 最后检查替代方案。没有替代方案的，独立权利要求里的上位概念就会显得缺乏支撑。
一个常见的写法错误
把实施例写成了产品说明书：先介绍应用场景，再写市场优势，最后一段才提结构。这种写法的问题是，具体实施方式部分被压缩得只剩两三句，从属权利要求全部悬空。正确的顺序是从结构写起，场景和优势属于背景技术，可以写但不要占篇幅。
常见问题
实施例越多越好吗
不是。数量服务于覆盖，重复的实施例没有意义，反而可能引入前后矛盾，被审查员指出不清楚。
只写一个实施例可以吗
可以，但独立权利要求就不能写得太上位，否则会被认为得不到支持。单一实施例适合结构非常具体的方案。
实施例里的数据必须是实测的吗
必须是真实可复现的。编造的数据一旦在后续程序中被质疑，会影响整份申请的可信度。
可以写「效果显著提升」代替数据吗
不建议。没有量化依据的效果主张说服力很弱，涉及创造性论证时几乎用不上。
实施例能后期补充吗
不能。修改不得超出原说明书和权利要求书记载的范围，申请日之后补的内容不能用来支撑原始权利要求。
逐条对照权利要求和实施例这件事，用 专利Pro 可以先把技术特征表拉出来，再逐项确认说明书有没有落点，比通读一遍更可靠。
具体要求以提交时国家知识产权局的最新规定为准。