发明专利起草规范
本规范用于把
code2patent的交底书输出继续扩展为接近可申报版的中国发明专利起草材料。 适用于软件、算法、Agent 系统及其他以代码实现为主的技术方案。 本规范只收口到《专利审查指南》中与“说明书、权利要求书、摘要撰写”直接相关的内容，以及计算机程序相关发明保护主题的官方解读。
一、目标
起草阶段应至少回答以下问题：
- 本方案真正要解决的技术问题是什么
- 哪些技术特征属于解决该技术问题的必要技术特征
- 哪些特征适合进入独立权利要求，哪些只适合进入从属权利要求或实施例
- 说明书是否足以支撑权利要求并满足充分公开
- 算法/软件类方案是否已经形成步骤 S1...Sn，并在交底书、布局卡、证据矩阵和初稿中保持一致
- 摘要、附图建议、请求书字段是否已经整理到位
二、官方基线
起草结构和硬约束默认参考以下公开资料：
- 国家知识产权局：《专利审查指南》官方 PDF
- 第二部分第二章“说明书和权利要求书”是本 skill 的主起草依据。
- 说明书摘要部分明确：摘要应写明名称、所属技术领域、所要解决的技术问题、技术方案要点和主要用途；摘要文字部分不得超过 300 个字，且不得使用商业性宣传用语。
- 独立权利要求撰写部分明确：前序部分写主题名称和与最接近现有技术共有的必要技术特征，特征部分写区别技术特征，二者合起来限定全部必要技术特征。
- 从属权利要求撰写部分明确：从属权利要求包括引用部分和限定部分，限定部分写附加技术特征。
- 说明书具体实施方式部分明确：当独立权利要求保护范围较宽时，应给出足以支持该概括范围的实施例；区别技术特征和从属权利要求附加技术特征应当充分描述。
- 国家知识产权局：《专利审查指南》（2023）修改解读（四）
- 涉及计算机程序的发明专利申请，权利要求可以写成方法权利要求，也可以写成产品权利要求，例如实现该方法的装置、计算机可读存储介质或者计算机程序产品。
- 本次解读明确了计算机程序产品也属于产品权利要求，为软件类方案提供了更完整的保护主题。
起草时重点吸收的官方要求
- 说明书和权利要求书要相互支撑，权利要求不能脱离说明书公开内容单独漂移。
- 权利要求应清楚、简要，且只写技术特征，不写不必要的原因、理由或宣传表述。
- 独立权利要求只保留必要技术特征，从属权利要求再写附加技术特征。
- 计算机程序相关方案既可以走方法口径，也可以走产品口径，但无论采用哪种口径，都必须反映完整技术方案，而不能只写抽象功能和效果。
三、默认起草策略
1. 两步写作
只要目标是发明专利初稿，默认先完成：
05A-权利要求布局卡-<方案名>.md05B-权利要求-证据矩阵-<方案名>.md
之后才允许生成完整初稿。
对于算法/软件类方案，布局卡和证据矩阵应以步骤 S1...Sn 为主线，保持与技术交底书和初稿中的步骤编号一致。
2. 默认交付目标
- 法域默认：中国发明专利
- 交付目标默认：接近可申报版
- 交付口径默认：方法 + 系统 / 装置 + 计算机可读存储介质 + 计算机程序产品四类保护主题草案
注意： 平行保护主题是为了便于代理师比较和整合，不等于正式提交时必须原样保留全部独立权利要求。
3. 证据驱动规则
- A 级证据：可进入独立权利要求骨架
- B 级证据：优先进入从属权利要求、优选实施例，并注明“基于实现归纳”
- C 级证据：只进入待确认事项或替代实施例，不得写成既有实现
四、权利要求起草方法
1. 先锁定核心发明构思
在写权利要求前，先用一句话说清楚：
- 解决了什么技术问题
- 通过什么核心技术手段解决
- 取得了什么技术效果
如果一句话说不清，就说明候选方案仍然过宽、过散或混入了多个发明点。
2. 独立权利要求只保留必要技术特征
独立权利要求应只保留解决技术问题所必需的技术特征，不要把以下内容默认塞入主独权：
- 只属于优选实现的参数范围
- 可替换的工程实现细节
- 仅用于性能优化但不是必要前提的缓存、回退、告警、日志特征
- 尚无直接代码证据的设想性特征
3. 从属权利要求按层级挂接
从属权利要求建议分三层：
- 核心增强层：进一步限定关键处理步骤、关键交互关系、关键数据结构
- 优选参数层：阈值、时机、触发条件、排序策略、调度优先级
- 工程细节层：缓存、回退、鉴权、异常处理、日志记录、补偿机制
4. 计算机程序相关发明保护主题的映射方式
方法口径
优先描述：
- 输入对象
- 处理步骤
- 判断 / 调度 / 更新逻辑
- 输出结果
系统 / 装置口径
将方法中的关键步骤映射为单元、组件或执行器，但不要机械改写为“用于……的模块”列表，也不要照搬代码目录中的实现模块名称。系统 / 装置口径必须体现各单元之间的配合关系、数据交互关系和对方法步骤 S1...Sn 的支撑。
计算机可读存储介质口径
以“存储有程序，程序被处理器执行时实现上述方法”为基础，但应确保其支撑的方法口径已经写稳。
计算机程序产品口径
当方案确有必要强调软件产品分发、部署、下载或程序本身的实现形态时，可写成计算机程序产品权利要求。但仍然要回到完整技术方案，不能只写“某程序实现某功能”这类抽象功能描述。
五、说明书起草方法
1. 章节顺序
说明书默认采用以下顺序：
- 发明名称
- 技术领域
- 背景技术
- 发明内容
- 附图说明
- 具体实施方式
1A. 算法/软件类说明书式结构
软件、算法、Agent 系统和代码实现类方案，说明书正文应优先按照 references/algorithm-software-disclosure-format.md 的结构展开：
- 技术领域：写清具体技术方向
- 背景技术：写现有实现和技术问题
- 发明内容：写技术问题、总体方案、步骤 S1...Sn、进一步限定和技术效果
- 附图说明：至少建议整体流程图或系统框图
- 具体实施方式：用示例场景展开输入、模型/状态、步骤、参数、输出和替代实现
代码路径、函数名、字段名和测试文件只作为证据摘要或附录索引，不应成为说明书正文主线。 若说明书主体呈现为“前端模块、服务模块、接口模块、配置模块”的工程分层，应回退重写为算法步骤、状态/数据流、单元协同和实施例。
2. 背景技术
- 只写与本方案最相关的现有实现路径
- 直接引出本方案要解决的问题
- 避免写成泛泛的行业介绍
3. 发明内容
应清楚对应三件事：
- 要解决的技术问题
- 为解决该问题采用的技术方案
- 相对于现有技术取得的有益效果
算法/软件类方案的发明内容还应明确步骤 S1...Sn。每个步骤应描述技术动作、处理对象和输出结果，不写成本地函数调用。
4. 具体实施方式
具体实施方式应能支撑权利要求，并至少包含：
- 一套基础实施流程
- 一组优选实施方式
- 一组不脱离发明构思的替代实施方式
不要在具体实施方式中引入与权利要求完全无关的新核心概念，否则容易导致术语漂移。
六、摘要与请求书
1. 摘要
摘要应当：
- 写清名称、技术领域、技术问题、技术方案要点、主要用途
- 默认控制在 300 字内
- 不使用商业性宣传语言
2. 请求书待填字段
code2patent 首版不自动生成正式请求书表格，但应整理以下字段：
- 发明名称
- 申请人名称 / 姓名
- 申请人地址和邮编
- 发明人姓名
- 代理机构与代理师信息
- 优先权信息
- 申请文件清单
- 附加文件清单
- 其他需要补充的法定事项
七、起草完成后的自检
完成初稿后，至少检查：
- 术语是否在权利要求和说明书中前后一致
- 独立权利要求是否只包含必要技术特征
- 从属权利要求是否形成清晰层级
- 说明书是否支撑每一个关键权利要求特征
- 摘要是否符合长度和表达要求
- 算法/软件类方案的 S1...Sn 是否在交底书、布局卡、证据矩阵和初稿中一致
- 计算机程序相关方案是否区分了方法口径与产品口径，且没有把抽象功能直接当作技术方案
- 是否已将项目架构转译为技术对象、关系、状态、动作、时序和输出，而不是模块或技术选型清单
- 是否误把第三方固有能力或 C 级证据写成申请人的既有实现
- 是否显式列出待代理师 / 研发确认事项