cslawyer1985 Patent Doc Writer（发明专利说明书生成器）
概述
根据用户提供的技术方案描述，按照中国国家知识产权局（CNIPA）的标准格式，生成一份完整的发明专利说明书文档。覆盖软件/电子/通信/物联网等领域的方法及系统类专利。
触发条件
- 用户说"写专利"、"生成专利说明书"、"帮我写发明专利"、"专利文档"
- 用户提供了一个技术方案，要求转化为专利申请文件
- 用户说"把这个方案写成专利"、"这个技术能不能申请专利"
前置条件
- 用户能够描述清楚技术方案的核心内容（解决什么问题、怎么解决、效果如何）
- 最好有技术方案文档、需求文档或讨论记录作为输入
操作步骤
Step 1 — 收集技术方案信息
向用户确认以下要素（如果用户已提供则跳过）：
| 要素 | 说明 | 示例 |
|---|---|---|
| 发明名称 | 简洁、准确的技术名称 | "基于意图判断的二维码自动识别方法及系统" |
| 技术领域 | 属于哪个技术领域 | "医疗物联网技术领域" |
| 解决的问题 | 现有技术有什么缺陷 | "二维码设备绑定流程繁琐、易误触发" |
| 核心方案 | 怎么解决的（方法步骤） | "后台采集视频流→检测二维码→意图判断→自动连接" |
| 系统模块 | 系统包括哪些模块 | "状态监测模块、摄像头驱动模块、检测模块..." |
| 有益效果 | 相比现有技术的优势 | "零交互、低成本、隐私安全、防误触" |
| 现有技术 | 可选：已有的相关专利号 | "CN108027738A、CN117669622A" |
Step 2 — 生成说明书各部分
按照以下标准结构依次生成，每部分都有明确的写作规范：
2.1 说明书摘要（300字以内）
写作要点：
- 第一句：技术领域 + 发明名称
- 第二句：方法包括哪些步骤（用分号隔开）
- 第三句：解决了什么问题
- 第四句：有益效果（效率、成本、安全等）
- 指定摘要附图（选最能体现发明思路的图）
2.2 技术领域（1-2句）
格式：
本发明属于【技术领域】技术领域，具体地，涉及一种【发明名称】。
2.3 背景技术（3-5段）
写作结构：
- 应用场景描述：描述技术应用的场景和需求
- 现有技术方案1：描述目前怎么做（至少2种方案）
- 现有技术方案2：另一种方案及其缺点
- 现有技术文献引用：引用2-3篇相关专利文献，说明其不足
- 问题总结：用"因此，目前需要..."引出技术问题
文献引用格式：
专利申请文献《【文献标题】》（【专利号】）公开了【技术方案概要】，但其【不足之处】，难以解决【具体问题】。
2.4 发明内容
包含三个部分：
（1）发明目的
针对现有技术中的缺陷，本发明的目的是提供一种【发明名称】。
（2）技术方案
方法权利要求（独立权利要求 + 从属权利要求）：
根据本发明提供的一种【方法名称】，应用于【应用场景】，包括：
【步骤A】；
【步骤B】；
【步骤C】；
【步骤D】。
【关键约束，如"上述过程均在本地执行"】。
从属权利要求用"优选地"引导：
优选地，【进一步限定的技术特征】。
系统权利要求（与方法对应）：
根据本发明提供的一种【系统名称】，应用于【应用场景】，包括：
【模块A】，【功能描述】；
【模块B】，【功能描述】；
...
（3）有益效果
与现有技术相比，本发明具有如下的有益效果：
1、【效果1】：【具体说明】。
2、【效果2】：【具体说明】。
3、【效果3】：【具体说明】。
4、【效果4】：【具体说明】。
2.5 附图说明
通过阅读参照以下附图对非限制性实施例所作的详细描述，本发明的其他特征、目的和优点将会变得更明显：
图1为【图1描述】；
图2为【图2描述】；
图3为【图3描述】。
2.6 具体实施方式（核心部分，最长）
写作结构：
- 引入段：结合附图介绍实施例
下面结合具体实施例对本发明进行详细说明。以下实施例将有助于本领域的技术人员进一步理解本发明，但不以任何形式限制本发明。
场景描述：以具体场景为例描述（如"以图2为例，该终端设备具体为..."）
系统模块说明：逐一介绍各模块的硬件/软件实现
方法流程详述：用 S101、S102... 编号步骤，每步包含：
- 步骤标题
- 具体操作描述
- 技术参数（如帧率、分辨率、阈值等具体数值）
- 优选实施方式（用"在更多的优选例中"引导）
硬件实现说明（末尾标准段落）：
本领域技术人员知道，除了以纯计算机可读程序代码方式实现本发明提供的系统及其各个装置、模块、单元以外，完全可以通过将方法步骤进行逻辑编程来使得本发明提供的系统及其各个装置、模块、单元以逻辑门、开关、专用集成电路、可编程逻辑控制器以及嵌入式微控制器等的形式来实现相同功能。
- 结尾标准段落：
以上对本发明的具体实施例进行了描述。需要理解的是，本发明并不局限于上述特定实施方式，本领域技术人员可以在权利要求的范围内做出各种变化或修改，这并不影响本发明的实质内容。在不冲突的情况下，本申请的实施例和实施例中的特征可以任意相互组合。
2.7 权利要求书
方法独立权利要求（权利要求1）：
1、一种【方法名称】，应用于【应用场景】，其特征在于，包括：
【步骤A】；
【步骤B】；
【步骤C】；
【步骤D】；
【关键约束】。
方法从属权利要求（2-5）：每条用"根据权利要求X所述的...，其特征在于"引导，进一步限定某个技术特征。
系统独立权利要求（权利要求6）：
6、一种【系统名称】，应用于【应用场景】，其特征在于，包括：
【模块A】，【功能描述】；
【模块B】，【功能描述】；
...
系统从属权利要求（7-10）：与方法从属对应，用模块语言描述。
Step 3 — 生成 Word 文档
将完整的专利说明书生成为 .docx 格式，使用 python-docx 库：
- 标题：黑体，小三号，居中
- 章节标题：黑体，四号
- 正文：宋体，小四号，行距1.5
- 权利要求编号：阿拉伯数字
- 步骤编号：S101、S102...
文件命名：{DK编号}--{公司名}--{发明名称}--发明（软件）--{日期}.docx
Step 4 — 交付与检查
- 使用
present_files展示生成的文档 - 提供一份检查清单供用户核对：
| 检查项 | 要求 |
|---|---|
| 摘要字数 | ≤300字 |
| 权利要求数 | 方法5条 + 系统5条 = 10条 |
| 独立权利要求 | 方法1条 + 系统1条 |
| 从属权利要求 | 每条引用正确的在前权利要求 |
| 有益效果 | ≥3条，与发明内容对应 |
| 具体实施方式步骤 | ≥5步，每步有具体参数 |
| 现有技术文献 | ≥2篇专利文献引用 |
| 附图说明 | ≥3张图 |
| 标准段落 | 引入段 + 硬件实现段 + 结尾段齐全 |
注意事项
- 方法与系统对应：系统权利要求的模块必须与方法权利要求的步骤一一对应
- 从属权利要求引用：只能引用在前的权利要求（如权3可以引权1，不能引权4）
- "其特征在于"：每条权利要求的特征部分必须用此引导语
- 具体参数：具体实施方式中必须给出具体数值（如帧率15fps、分辨率320×240、阈值500ms等），不能只说"预设值"
- 优选实施方式：用"优选地"或"在更多的优选例中"引导，不能作为独立权利要求
- 不使用绝对化用语：避免"最好"、"最优"等表述，用"优选地"、"在一实施例中"
- 技术术语统一：全文中同一概念用同一术语，不要混用
- 软件专利特别要求：如果涉及软件发明，需在具体实施方式中说明"本领域技术人员知道..."的标准段落
- 隐私/安全：如果方案涉及数据处理，需强调本地处理、不上传云端等安全措施
- 文献引用格式：专利号格式为 CN + 数字 + A/B/U
常见问题
| 问题 | 解决方案 |
|---|---|
| 用户只给了简单描述，细节不足 | 按 Step 1 的要素逐项追问，给出示例帮助理解 |
| 不确定能不能申请专利 | 判断三要素：新颖性、创造性、实用性；有具体技术方案即可 |
| 方法和系统写不对应 | 先写方法权利要求，再逐条翻译成模块语言 |
| 权利要求太少 | 从独立权利要求的每个步骤/模块中拆分出从属权利要求 |
| 具体实施方式太空 | 补充具体参数、数值、场景描述、优选实施方式 |
版本历史
- v1.0 (2026-07-12) — 初始版本：基于真实发明专利（DK106373）结构分析，包含完整的七步生成流程、标准段落模板、检查清单