Code2patent

代码仓库转专利交付

定位

本技能用于把已经开发完成的代码项目整理成专利代理师可继续起草和判断的材料。核心目标不是把代码翻译成专利语言，而是把真实实现、技术问题、技术方案、技术效果和证据位置整理成可追溯的发明专利底稿。

默认法域为中国发明专利，主要适用于软件、算法、Agent 系统、调度优化、状态表示、鉴权、记忆、上下文编排和文件系统等以代码实现为主的方案。

推荐主链路：

用户材料 + 代码仓库
        ↓
输入成熟度判断 + archive 归档目录
        ↓
项目边界与依赖画像
        ↓
方案-代码证据映射
        ↓
算法/软件类说明书式技术交底书
        ↓
权利要求布局卡 + 权利要求-证据矩阵
        ↓
发明专利初稿 + 初稿自检表

启动闸门

开始读取代码前，先确认：

1. 是否已有候选专利方案清单。 2. 候选清单是仅有名称，还是已有技术问题、核心实现、技术效果和代码范围。 3. 本次目标是技术交底书、权利要求布局卡、发明专利初稿，还是候选方案挖掘。 4. 是否有 PRD、需求说明、会议纪要、客户交底书模板、既有申请样式或代理师格式要求。 5. 本次归档主题是什么，用于创建 archive/YYYY-MM-DD-主题/。

专利名称不是技术方案。 如果用户只给标题或一句话方向，不要直接写交底书或初稿。

输入成熟度分流

未经人工确认的 T0/T1 或自动挖掘结果，只能作为候选方向，不得写成客户已确认的技术方案。

材料优先级

执行时先读用户提供材料，再读代码。建议顺序：

1. 候选专利方案清单或标题清单 2. PRD、产品方案、需求说明 3. 沟通纪要、录音转写、客户补充说明 4. 技术交底书模板、既有申请文件、代理师格式要求 5. 代码仓库 README、架构文档、目录说明 6. 源代码、配置、测试、部署和运行时文件

如果用户提供模板或样本，先抽取章节结构、步骤编号、附图习惯和技术效果写法，再生成交付物。若未提供模板，按 references/algorithm-software-disclosure-format.md 和内置模板执行。

必读规范

只在需要时读取对应文件，避免把所有 reference 一次性装入上下文。

本文件只保留入口、分流、路由和强规则；细节规则以后优先维护在 references/。

模板路由

templates/ 是可直接填充的交付骨架；references/ 是执行规则和判断标准。不要把二者合并。

核心强规则

1. 先判断输入成熟度，再读代码细节。 2. 用户提供的方案、模板和样本优先于 AI 自行推断。 3. 没有人工确认的候选方向，不直接进入交底书或专利初稿。 4. 先做项目边界与依赖画像，避免把第三方库、模型平台或框架默认能力写成申请人的创新。 5. 代码证据映射和技术交底书正文必须分层。 6. 交底书正文默认采用算法/软件类说明书式结构，不写成代码盘点报告。 7. 文件路径、函数名、字段名、测试文件和内部事件名默认进入证据映射或附录；正文只保留必要证据摘要。 8. 发明内容优先整理为技术问题、总体方案、步骤 S1...Sn、进一步限定和技术效果。 9. 具体实施方式用示例场景展开输入、模型/状态、步骤、参数、输出和替代实现。 10. 代码架构必须理解，但最终正文应转译为技术对象、关系、状态、动作、时序和输出，不展示技术选型或模块清单。 11. 05-技术交底书、05A-权利要求布局卡、05B-权利要求-证据矩阵、06-发明专利初稿 中的 S1...Sn 步骤编号应保持一致。 12. 目标是初稿时，默认先生成布局卡和证据矩阵，再生成完整初稿。 13. A 级证据可进入独立权利要求骨架；B 级证据优先进入从属权利要求或优选实施例；C 级证据只能进入待确认事项或替代实施例。 14. 摘要默认控制在 300 字内，不使用商业性宣传语言。 15. 正式申请文件仍需专利代理师审核。 16. 涉及评分、排序、阈值、向量或图结构的方案，正文公式须先设符号表、维度用下标、符号唯一且跨节同形，体例见 references/algorithm-software-disclosure-format.md"公式与符号体例"。 17. 同一 archive 主题下的产物修订不覆盖原件，按时间戳另存并在 08-修订记录.md 留痕；方案级修订不得回到 T0/T1 重新挖掘。

输出层级

标准执行顺序

按目标层级裁剪执行，不必每次输出全部文件。

1. 预读用户材料，确认目标层级和模板要求。 2. 创建 archive/YYYY-MM-DD-主题/。 3. 判断输入成熟度：T0/T1 先澄清，无清单先挖掘。 4. 读取项目 README、PRD、架构和依赖文件，形成边界画像。 5. 围绕已确认方案读取代码，提取证据并分级。 6. 将工程实现转译为 S1...Sn、技术特征、技术效果和替代实施方式。 7. 生成交底书，正文采用说明书式结构，证据后置。 8. 如需申请文件层，生成布局卡和证据矩阵。 9. 如需完整初稿，生成发明专利初稿和自检表。 10. 输出待研发、代理师或申请主体确认的问题。

推荐交付文件

archive/YYYY-MM-DD-主题/
├── 00-输入材料摘要.md
├── 01-专利名称反向澄清卡-待确认.md
├── 01A-人工确认记录.md
├── 02-项目边界与依赖画像.md
├── 03-项目技术方案画像.md
├── 04-方案代码证据映射-<方案名>.md
├── 05-技术交底书-<方案名>.md
├── 05A-权利要求布局卡-<方案名>.md
├── 05B-权利要求-证据矩阵-<方案名>.md
├── 06-发明专利初稿-<方案名>.md
├── 06A-发明专利初稿自检表-<方案名>.md
├── 07-研发补充问题清单.md
└── 08-修订记录.md（迭代时生成，非每次必产）

若当前是候选方案挖掘模式，先输出 03-候选可专利方案清单-待人工筛选.md 和 04-优先申请建议.md，待用户确认后再进入定向检索。

迭代与版本留痕

同一 archive/YYYY-MM-DD-主题/ 目录下的产物修订，遵循以下规则：

1. 不覆盖原件：对已有产物做修订时，按“主产物名 + 时间戳后缀”另存为新文件，例如 05-技术交底书-<方案名>-250622-1430.md。同目录多版本即版本历史，不再开子目录。 2. 维护 08-修订记录.md：追加式记录每次修订，至少包含修订意图、受影响的产物文件、S1...Sn 是否变化和时间戳。首次修订时创建，后续只追加。 3. 门禁——不回退到重新挖掘：方案级增量修订只在已确认方案上更新证据、步骤或表达；不得回到 T0/T1 重新做候选挖掘或名称澄清。若用户要换方案或重新挖掘，应开新的 archive/YYYY-MM-DD-主题/ 目录，不与原方案混档。 4. 步骤链同步：若修订导致 S1...Sn 变化，交底书、权利要求布局卡、权利要求-证据矩阵和发明专利初稿须同步更新，并在 08-修订记录.md 登记受影响文件。

交底书默认结构

软件、算法和 Agent 系统方案的技术交底书默认使用以下顺序：

1. 方案基本信息 2. 技术领域 3. 背景技术 4. 发明内容 5. 附图说明 6. 具体实施方式 7. 技术效果 8. 替代实施方式 9. 代码证据摘要与附录索引 10. 待研发 / 代理师确认事项

如果正文中连续出现多个代码路径、函数名或字段名，应回退重写，将其移入 04-方案代码证据映射-<方案名>.md 或证据附录。

输入/输出

输入

• 必需：代码文件或项目目录、技术描述、创新点说明、候选专利方案，至少具备其中两类；若只有专利名称，按 L0 处理。
• 可选：PRD、需求说明、会议纪要、技术领域、应用场景、附图偏好、输出层级、申请主体信息、发明人候选、优先权信息、客户模板。

输出

• 专利名称反向澄清卡
• 候选可专利方案清单
• 项目边界与依赖画像
• 方案代码证据映射表
• 算法/软件类说明书式技术交底书
• 权利要求布局卡
• 权利要求-证据矩阵
• 发明专利初稿
• 发明专利初稿自检表
• 待确认事项清单

Changelog

All notable changes to this skill will be documented in this file.

[1.6.0] - 2026-06-22

新增

• 在 references/algorithm-software-disclosure-format.md 新增“公式与符号体例”章节，沉淀符号表先行、维度用下标、符号唯一、公式分隔符统一和跨节同形五条规则，并给出评分/调度场景的正反例对照
• 在 SKILL.md 新增“迭代与版本留痕”小节，明确同一 archive 主题下的产物修订按时间戳另存、维护 08-修订记录.md、方案级修订不得回到 T0/T1 重新挖掘

改进

• SKILL.md 核心强规则补入第 16 条（公式与符号体例）和第 17 条（archive 迭代留痕）
• 交底书模板和初稿模板在“示例跑通过程”处补入公式体例指引，指回 references/algorithm-software-disclosure-format.md
• references 路由表为 algorithm-software-disclosure-format.md 补入“+ 公式与符号体例”

文档完善

• 同步更新 TASKS.md 和 DECISIONS.md，记录本次公式体例与迭代留痕补强

[1.5.3] - 2026-05-28

改进

• 补强“理解项目架构但不展示模块清单”的规则：代码架构必须先被理解，再转译为技术对象、对象关系、状态表示、动作更新、时序推进和输出结果
• 在 algorithm-software-disclosure-format.md 中补入参考样稿抽取出的“权利要求与说明书镜像关系”，要求摘要、独立权利要求、发明内容和具体实施方式围绕同一组 S1...Sn 步骤展开
• 在项目画像、代码抽取、交底书模板和初稿模板中增加“架构转译”要求，避免把框架、服务、数据库、接口或技术选型清单当作正文主线
• 强化具体实施方式写法：要求选择典型场景或样例输入，将 S1...Sn 从输入、状态、参数、判断、更新到输出完整跑通

文档完善

• 同步更新 README.md、TASKS.md 和 DECISIONS.md，记录本次从算法/调度类样稿进一步抽取出的架构转译规则
• 中性化历史记录中的外部样稿来源表述，避免保留客户来源痕迹

[1.5.2] - 2026-05-28

改进

• 统一 references/ 口径：默认将软件项目视为算法/软件类发明，抽取结果优先服务于权利要求布局和具体实施方式
• 将 project-analysis-spec.md 的“项目代码技术盘点”口径调整为“项目技术方案画像”，避免按工程目录或模块层级组织正文
• 将 code-extraction-spec.md 调整为 S1...Sn 方法步骤、F1...Fn 技术特征、E1...En 证据编号的抽取方式
• 将“权利要求-代码证据矩阵”对外表述收口为“权利要求-证据矩阵”，强调权利要求特征为主线、代码模块仅作证据位置

技术优化

• 调整布局卡、证据矩阵、初稿和自检模板中的表头与文件引用，减少“模块清单式”填写诱导

[1.5.1] - 2026-05-28

改进

• 将 SKILL.md 从 771 行压缩为约 200 行的入口与路由文档，减少与 references/ 中执行规范的重复
• 明确 templates/ 只保存可填充交付骨架，references/ 只保存执行规则和判断标准，继续保留两者分层
• 保留 T0/T1 输入闸门、说明书式交底书、S1...Sn 步骤链、A/B/C 证据分级和两步起草链路等核心规则

技术优化

• 删除本地生成的空白记忆文件和 .DS_Store，减少技能目录杂项

[1.5.0] - 2026-05-28

新增

• 新增 references/algorithm-software-disclosure-format.md，沉淀从参考材料抽取出的算法/软件类说明书式交底书格式

改进

• 将默认技术交底书模板重构为“方案基本信息 → 技术领域 → 背景技术 → 发明内容 → 附图说明 → 具体实施方式 → 技术效果 → 替代实施方式 → 代码证据摘要与附录索引 → 待确认事项”
• 同步重写权利要求布局模板、权利要求-代码证据矩阵模板、发明专利初稿模板和初稿自检模板，使全链路围绕步骤 S1...Sn 保持一致
• 在 SKILL.md 中新增“参考模板 / 说明书格式抽取”步骤，要求先分析用户提供的模板、样本或代理师格式要求，再生成交底书或初稿
• 更新 references/patent-drafting-quick-reference.md 和 references/patent-drafting-spec.md，补入算法/软件类说明书式起草规则
• 更新 references/code-extraction-spec.md，要求从代码证据中整理可贯穿交底书、布局卡、证据矩阵和初稿的步骤链

文档完善

• 同步更新 README.md、TASKS.md 和 DECISIONS.md，记录本次基于外部参考样稿形成的全链路调整

[1.4.4] - 2026-05-28

改进

• 将技术交底书默认表达进一步收紧为“说明书式正文 + 独立证据映射/附录”，避免在正文主体中堆叠代码来源、重点模块、函数名和路径表
• 更新 SKILL.md 的 L2 技术交底书规则，新增正文禁止项和“技术问题 → 总体构思 → 实施步骤 → 关键机制 → 技术效果”的生成顺序
• 重写 templates/invention-patent-disclosure-template.md 的主体结构，将代码证据摘要移动到后置附录位置，并新增证据状态摘要、实施步骤和表达自检要求
• 更新 references/code-extraction-spec.md，增加正文筛选阈值和输出拆分规则

文档完善

• 同步更新 README.md、TASKS.md 和 DECISIONS.md，记录基于外部交底样稿与方案清单复盘形成的交底书表达调整

[1.4.3] - 2026-05-27

新增

• 新增 templates/patent-title-clarification-card-template.md，用于处理仅有专利名称、标题或一句话方向的弱输入场景
• 在 SKILL.md 中新增 L0 名称反向澄清层，要求先确认客户意图和最小技术闭环，再进入交底书或初稿

改进

• 明确区分“代码证据映射”和“技术交底书正文”：代码路径、函数、字段、状态和测试证据保留在证据表或附录中，交底书正文优先表达技术问题、方案构思、实施方式和技术效果
• 重写 templates/invention-patent-disclosure-template.md 的表达规则，避免把交底书写成代码盘点报告
• 更新 references/code-extraction-spec.md，增加从代码证据到交底书表达的转译规则

文档完善

• 同步更新 README.md、TASKS.md 和 DECISIONS.md，记录本次基于外部交底样稿复盘形成的流程调整

[1.4.2] - 2026-04-06

新增

• 新增 references/patent-drafting-quick-reference.md，将《专利审查指南》撰写部分和计算机程序发明保护主题压缩成 agent 可直接执行的短版速查卡

改进

• 在 SKILL.md 中补充默认阅读顺序：起草层优先读速查卡，再按需下钻完整起草规范
• 进一步降低 code2patent 进入初稿阶段的认知负担，使 agent 更容易稳定执行“证据映射 → 布局卡 → 初稿 → 自检”的链路
• 同步更新 README.md、TASKS.md 和 DECISIONS.md 记录本次优化

文档完善

• 2026-04-22：按独立仓库 README 新规范重写首页，突出代码证据映射、交底书、权利要求布局和专利初稿的交付链路，并补充安装方式、使用边界、核心设计、关键文件、Legal Skills 关联项目导流、作者联系入口和微信二维码

[1.4.1] - 2026-04-05

改进

• 收口 code2patent 的官方起草依据：不再把《专利法实施细则》或通用申请事项说明作为主依据，改为以《专利审查指南》第二部分第二章“说明书和权利要求书”为主
• 调整 references/patent-drafting-spec.md，把说明书、权利要求书、摘要的起草要求重新压缩到《专利审查指南》的撰写规则上
• 强化计算机程序相关发明的保护主题提示，在起草规范和模板中明确纳入“计算机程序产品”这一产品权利要求主题
• 更新 SKILL.md、初稿模板、布局模板和自检模板，使“方法 / 装置 / 存储介质 / 程序产品”四类口径更一致
• 同步更新 README.md、TASKS.md 和 DECISIONS.md 记录本次收口调整

[1.4.0] - 2026-04-05

新增

• 新增 references/patent-drafting-spec.md，沉淀中国发明专利初稿的结构基线、权利要求写法、充分公开要求和自检规则
• 新增 templates/invention-patent-claim-layout-template.md，用于先搭建权利要求布局卡
• 新增 templates/invention-patent-claim-evidence-matrix-template.md，用于把权利要求特征逐项回勾到代码证据
• 新增 templates/invention-patent-draft-self-check-template.md，用于对初稿进行结构、证据和术语一致性检查

改进

• 将 code2patent 的起草链路升级为 L1 代码证据映射 → L2 技术交底书 → L2.5 权利要求布局 → L3 发明专利初稿
• 在 SKILL.md 中固化“布局卡 → 证据矩阵 → 初稿 → 自检表”的两步写作规则
• 重写发明专利初稿模板，使其覆盖说明书、三套平行保护主题草稿、摘要、请求书待填字段清单和待确认事项
• 更新技术交底书模板，增加“权利要求布局准备”章节，明确 A / B / C 级证据进入不同起草位置
• 更新 references/code-extraction-spec.md，将 A / B / C 级证据与独立权利要求、从属权利要求和实施例的写法对应起来
• 将 README.md 中 code2patent 的版本和能力说明同步到本次增强

技术优化

• 默认法域收口为中国发明专利，并在 SKILL.md 中补充官方起草基线
• 默认起草目标收口为“接近可申报版”，但继续保留“待代理师 / 研发确认事项”作为强制输出
• 默认平行准备方法、系统 / 装置、计算机可读存储介质三套保护主题草稿，方便代理师择优整合

[1.3.5] - 2026-03-18

改进

• 将技能当前名称统一收口为 code2patent
• 更新 SKILL.md frontmatter 中的 name 字段
• 同步整理技能级文档中的当前名称和目录表述，避免继续混用旧名称

[1.3.4] - 2026-03-18

改进

• 在 SKILL.md 中将 PRD、产品方案、需求说明加入启动提问和输入优先级
• 调整材料优先级和搜索顺序，明确在深挖代码前先读用户提供的 PRD 和代码仓库中的 README
• 明确无候选清单时的后续步骤：先自动生成候选方案清单，再经人工筛选后回到定向检索模式
• 更新 references/project-analysis-spec.md，提升 README 和 PRD 的前置阅读优先级

[1.3.3] - 2026-03-18

新增

• 新增 archive/ 目录，用于统一沉淀技能运行产生的中间产物和最终产物

改进

• 调整启动提问：若用户没有候选专利方案清单，则默认由 Agent 先自动生成候选方案清单
• 在 SKILL.md 中加入归档规则，明确所有产物统一写入 archive/YYYY-MM-DD-主题/
• 调整标准工作流程，新增“创建 archive 输出目录”步骤
• 调整推荐交付文件路径，使候选清单、技术交底书和专利初稿都默认落在归档目录中

[1.3.2] - 2026-03-17

改进

• 在 SKILL.md 中增加“启动提问”机制，要求先确认用户是否已有候选专利申请清单
• 明确入口分流：有清单时走定向检索；无清单时先做候选方案挖掘
• 增加强规则：未经过人工筛选确认的候选方案，不直接进入技术交底书或专利初稿生成
• 调整“可专利方案挖掘模式”的推荐交付文件，增加“待人工筛选”和“人工筛选确认记录”节点

[1.3.1] - 2026-03-17

新增

• 新增 templates/ 目录，用于集中存放交付模板

改进

• 将技术交底书模板迁移至 templates/invention-patent-disclosure-template.md
• 将发明专利初稿模板迁移至 templates/invention-patent-draft-template.md
• 将技术交底书模板重写为面向研发与代理师协作的“交底书结构”，不再与专利初稿结构混同
• 将 references/ 收口为规范目录，仅保留项目分析规范和代码抽取规范
• 调整 SKILL.md，明确 templates/ 与 references/ 的职责区分

[1.3.0] - 2026-03-17

新增

• 恢复 references/02-invention-patent-draft-template.md，重新提供独立的发明专利初稿模板
• 新增 references/03-project-analysis-spec.md，沉淀“先宏观后局部”的项目分析规范
• 新增 references/04-code-extraction-spec.md，沉淀候选方案映射与代码证据提取规范

改进

• 调整 references/01-invention-patent-disclosure-template.md，使其回归为纯粹的发明专利技术交底书模板
• 调整 SKILL.md，明确两条核心交付场景：技术交底书、发明专利初稿
• 将项目分析与代码抽取的细节从 SKILL.md 主文档中解耦到独立 reference 文件

技术优化

• references/ 目录从“单模板”收口模式调整为“2 个模板 + 2 个规范文件”的结构
• 主文档聚焦流程、选择规则和协作边界，降低后续维护成本

[1.2.1] - 2026-03-17

改进

• 重排唯一保留的发明专利模板，使其按中国发明专利常见结构组织
• 将模板结构统一为“说明书部分 + 权利要求书草稿 + 说明书摘要 + 摘要附图建议”
• 调整 SKILL.md 中对“发明专利初稿”的定义，避免与技术交底书结构混用

[1.2.0] - 2026-03-17

改进

• 收口 references/ 目录，只保留一个内置的发明专利技术交底书模板
• 删除标准专利、实用新型、代码证据映射、可专利方案挖掘、发明专利初稿、项目边界画像等参考模板文件
• 调整 SKILL.md，明确其他产物按流程直接生成，不再分别维护参考模板

技术优化

• 模板策略从“多模板并存”简化为“客户模板优先，内置唯一模板兜底”
• 将 skill 的内置范围进一步聚焦到“代码项目 → 发明专利技术交底书”主场景

[1.1.0] - 2026-03-17

新增

• 新增“代码证据映射”交付层，支持将候选专利方案映射到代码仓库中的具体实现
• 新增 references/04-code-evidence-mapping-template.md，用于沉淀方案、模块、代码证据和技术效果之间的对应关系
• 新增 references/05-patent-opportunity-mining-template.md，用于从代码仓库主动挖掘可专利技术方案
• 新增 references/06-invention-patent-draft-template.md，用于在交底书基础上继续生成发明专利初稿
• 新增 references/07-project-boundary-dependency-profile-template.md，用于在进入代码细节前先完成项目边界与依赖画像

改进

• 重写 SKILL.md，将技能定位从“通用交底书生成”升级为“代码仓库到专利交付”的流程型技能
• 明确当前主模式为“代码仓库 + 人工候选方案 → 代码证据提取 → 技术交底书”
• 明确后续两个扩展方向：自动总结可申请专利方案、直接生成发明专利初稿
• 引入 A/B/C 三级证据分级规则，区分直接实现、归纳实现与待确认内容
• 新增“用户提供材料优先读取”规则，要求优先读取客户方案清单、沟通纪要和用户提供的 Word 模板
• 新增“项目边界与依赖画像”要求，先识别自研代码、关联仓库和第三方依赖，再进入方案抽取
• 明确软件、算法、Agent 系统场景默认优先走发明专利模板，实用新型仅作例外分支
• 固化“先宏观后局部”的搜索方式，要求先查看依赖文件、部署文件、说明文档和运行时配置，再下钻业务代码

技术优化

• 增加项目代码盘点、候选方案映射、研发补充问题清单等协作节点
• 增加与 repo-research、patent-analysis、patent-download 等技能的协作说明

待办事项

• 为常见技术栈补充专项代码阅读指引
• 增加真实代码项目示例，验证完整交付链路

[1.0.0] - 2026-03-17

新增

• 初始版本发布
• 支持两种输入方式：

1. 对话输入（代码片段、技术描述、创新点说明） 2. 文件输入（支持 .py/.js/.java/.go/.rs 等代码文件）

• 支持两种输出格式：

1. 标准专利格式（发明/实用新型） 2. 灵活技术文档格式

• 完整工作流程：需求确认 → 信息提取 → 技术分析 → 方案撰写 → 输出交付
• 专利技术交底书结构详解
• 代码到专利语言转化指南
• 提供三种模板：
• references/01-patent-disclosure-template.md - 标准专利技术交底书模板
• references/02-invention-patent-template.md - 发明专利交底书模板
• references/03-utility-model-template.md - 实用新型交底书模板
• 与 md2word、legal-doc-writing、patent-analysis 技能的配合说明

code2patent

把已经开发完成的代码仓库，整理成专利代理师能继续起草和判断的交付材料：代码证据映射、算法/软件类说明书式技术交底书、权利要求布局卡，以及接近可申报版的中国发明专利初稿。

它解决的不是“把代码翻译成专利语言”，而是先把真实实现、技术效果和证据位置说清楚，再进入专利起草。

适合谁用

• 已有产品或代码项目，准备挖掘软件、算法、Agent 系统等技术方案的创业团队
• 需要把研发实现转交给专利代理师的技术负责人或知识产权负责人
• 希望先形成交底书、证据矩阵和权利要求布局，再决定是否正式申报的律师或代理师

典型场景

用户：这是我们的代码仓库和三个候选专利点，请帮我整理成技术交底书，并标出每个技术特征对应的代码证据。
AI：我会先读 PRD、README 和候选清单，再盘点自研代码与第三方依赖边界。
    输出会包含方案-代码证据映射、技术交底书、权利要求布局卡和待研发确认事项。

如果用户还没有候选专利点，skill 会先进入“候选方案挖掘”模式，输出待人工筛选的候选清单；未经人工确认，不直接生成交底书或专利初稿。

如果用户只提供几个专利名称或标题，skill 会先进入“名称反向澄清”模式，帮助把标题还原成可确认的技术问题、方案构思、代码证据方向和技术效果；未经确认，不直接把代码命中的内容写成交底书。

它能产出什么

• 专利名称反向澄清卡和人工确认记录
• 代码仓库边界与依赖画像
• 候选专利方案清单和优先级建议
• 围绕 S1...Sn 步骤、F1...Fn 技术特征和 E1...En 证据编号的映射表
• 算法/软件类说明书式发明专利技术交底书
• 围绕步骤 S1...Sn 的权利要求布局卡与权利要求-证据矩阵
• 中国发明专利初稿，包括五段式说明书、权利要求书草稿、摘要和自检表
• 待研发、代理师或申请主体补充确认的问题清单

当前覆盖范围

• 默认法域：中国发明专利
• 主要对象：已开发代码项目、软件系统、算法流程、Agent / AI 应用系统
• 默认写作链路：代码证据映射 -> 算法/软件类说明书式技术交底书 -> 权利要求布局 -> 专利初稿 -> 自检
• 主要依据：《专利审查指南》中与说明书、权利要求书、摘要撰写直接相关的规则，并结合计算机程序相关发明的保护主题要求

安装方式

1. 打开本仓库的 GitHub Releases。 2. 下载最新版本的 skill 压缩包。 3. 解压后将 code2patent/ 文件夹放入你的 skill 目录。 4. 在支持 SKILL.md 的 Agent / Claude 环境中启用该 skill。

本 skill 不要求额外 Python 依赖。实际使用时，应让 Agent 能读取目标代码仓库、PRD、候选方案清单和客户模板。

可以怎么用

• “请读取这个代码仓库，围绕我列出的 3 个候选专利点生成技术交底书”
• “我还没有专利点，请先从代码里挖掘可能适合申请的技术方案”
• “请在交底书基础上继续生成权利要求布局卡和代码证据矩阵”
• “请输出一版中国发明专利初稿，并列出需要代理师确认的问题”

使用边界

这个 skill 适合：

• 从真实代码实现中抽取可追溯的技术证据
• 帮研发、企业知识产权人员和专利代理师建立协作底稿
• 在证据充分时起草接近可申报版的中国发明专利初稿

这个 skill 不适合：

• 替代专利代理师完成最终申请文件定稿
• 在没有代码、PRD、方案说明或技术效果信息时直接编造创新点
• 对专利授权前景、稳定性、侵权风险作最终法律判断
• 处理非中国法域的专利申请文件，除非另行提供当地规则和模板

核心设计

证据优先

每个技术特征都尽量回勾到代码文件、函数、配置、数据结构或调用链。证据不足的内容会标注为“待确认”，避免把未实现内容写进申请材料。

交底书去代码化

代码证据映射是内部核验材料，技术交底书正文则面向专利代理师理解发明方向。正文优先表达技术问题、方案构思、实施方式、可替代方案和技术效果，文件路径、函数名和字段名默认放入证据附录。

架构转译

理解项目架构是必要前提，但正文不展示框架、服务、数据库、接口或技术选型清单。架构事实会被转译为技术对象、对象关系、状态表示、动作更新、时序推进和输出结果，再进入权利要求布局、发明内容和具体实施方式。

说明书式表达

技术交底书主体默认按“技术领域、背景技术、发明内容、附图说明、具体实施方式”组织；发明内容内部用 S1...Sn 展开技术步骤，不把本地代码路径、重点模块表或函数清单放在正文核心位置。

两步起草

不直接从交底书跳到完整专利初稿，而是先生成权利要求布局卡和证据矩阵，保持 S1...Sn 步骤链一致，再扩展为说明书、权利要求书草稿和摘要。这样更方便代理师调整保护范围。

人工筛选闸门

自动挖掘候选方案时，先让人筛选、合并、拆分或排序；确认方向后才进入定向检索和起草，降低跑偏风险。

关键文件

• SKILL.md：执行入口、分流规则和文件路由
• references/algorithm-software-disclosure-format.md：算法/软件类说明书式交底书格式规范
• references/project-analysis-spec.md：项目技术方案画像与依赖边界规范
• references/code-extraction-spec.md：S/F/E 代码证据抽取和证据分级规则
• references/patent-drafting-quick-reference.md：发明专利起草速查卡
• templates/patent-title-clarification-card-template.md：专利名称反向澄清卡模板
• templates/：交底书、权利要求布局、证据矩阵、初稿和自检模板

许可证

本作品采用 CC BY-NC 4.0 许可证。商用授权联系方式以 LICENSE.txt 为准。

关于作者 / 咨询与交流

杨卫薪律师（微信 ywxlaw）

如需就代码挖掘专利点、技术交底书、发明专利初稿、企业内部落地或商用授权进一步沟通，欢迎添加微信（请注明来意）。

<div align="center"> <img src="https://raw.githubusercontent.com/cat-xierluo/legal-skills/main/wechat-qr.jpg" width="200" alt="微信二维码"/> <p><em>微信：ywxlaw</em></p> </div>

关联项目

本仓库是 Legal Skills 的子项目。如果需要合同、商标、专利、OPC、小微企业合规、文档处理等更多法律类开源 Skill，可以关注主仓库。

相关项目：

• patent-analysis：专利文件分析、侵权比对、FTO 和规避设计
• contract-copilot：合同审查、起草和 Word 修订批注
• opc-legal-counsel：一人公司、AI 创业团队和小微企业法律顾问

算法与软件类发明交底书格式规范

本规范沉淀自参考材料中的技术交底书模板、算法/调度方法类样本和官方说明书/权利要求书模板。

适用于软件、算法、Agent 系统、调度优化、状态表示、特征提取、上下文编排、鉴权、记忆和文件系统等以代码实现为主的发明方案。

一、核心结论

算法与软件类技术交底书应当更接近“说明书前置稿”，而不是“代码实现盘点”。

默认正文主线为：

方案基本信息
技术领域
背景技术
发明内容
附图说明
具体实施方式
技术效果
替代实施方式
代码证据摘要与附录索引
待研发 / 代理师确认事项

其中“代码证据摘要与附录索引”用于保留可追溯性，但不应进入正文核心位置。

二、技术交底书模板抽取

参考材料中的通用技术交底书模板实际只要求四类核心信息：

1. 背景：要解决什么问题；现有方案是什么；现有方案有什么缺点；为什么需要新的方案。 2. 发明要点：核心想法是什么；采用本方案有什么优势；实现原理是什么。 3. 详细描述：用文字、框图、流程图描述方案如何工作、如何实现；说明书应具体，并尽量提供多个实施例。 4. 替代实现：针对详细描述部分，是否存在其他方式实现同样发明目的。

在 code2patent 中，这四类信息应映射为：

三、算法类说明书结构

算法、软件和调度方法类样本通常采用以下说明书结构：

1. 技术领域

• 用一句话写明所属领域和具体方向。
• 示例方向：车间调度、智能体运行时、动态上下文组装、会话鉴权、文件系统隔离、记忆召回等。

2. 背景技术

• 先写现有系统或现有技术路线。
• 再写复杂场景下的约束、瓶颈或不足。
• 最后自然引出“如何解决某个具体技术问题”。

3. 发明内容

• 先写本发明为解决什么问题提出什么方法。
• 再给出总体步骤 S1...Sn。
• 再给出进一步限定，例如关键状态、特征向量、约束、模型、计算方式、更新方式。
• 最后写技术效果。

4. 附图说明

• 至少建议流程图或系统框图。
• 算法类方案优先建议：整体流程图、数据/状态流图、模型结构图、时序图、效果对比图。

5. 具体实施方式

• 用一个可理解的示例场景展开。
• 逐步说明输入、初始化、核心计算、判断/更新、输出。
• 对关键步骤补充参数、状态、数据结构、触发条件、边界条件和替代实现。

四、架构与实现方式的转译规则

代码项目的架构必须理解，但不应按工程模块原样展示。参考样稿中的“异构图模型”“两阶段进化策略”“多情景下界计算框架”等写法，本质上是在描述技术对象、关系、状态、动作和时序，而不是描述用了哪些代码模块。

将代码架构转译为说明书语言时，按以下顺序抽取：

1. 技术对象

• 系统处理的对象是什么，例如会话、任务、工序、机器、AGV、文件视图、候选解、上下文片段。

2. 对象关系

• 对象之间如何连接、约束或协同，例如节点-边关系、前后序关系、权限链、候选关系、父子任务关系。

3. 状态表示

• 哪些状态、特征、向量、集合、队列、档案或索引用于表达当前运行状态。

4. 动作与更新

• 系统如何选择动作、执行校验、更新状态、推进时间、回写结果或触发下一轮处理。

5. 层级与协同

• 如存在多阶段、多层决策、多单元协同，应写成“第一阶段/第二阶段”“区域选择层/算子选择层”“感知层/决策层/执行层”等机制协同。

6. 输出与效果

• 输出什么结果，以及该结果如何支撑技术效果。

正文中可以说明“架构”或“框架”，但必须落到上述抽象技术机制。不要写成“前端模块、后端模块、数据库模块、某框架、某服务”等技术选型列表。

五、权利要求与说明书的镜像关系

参考样稿通常采用同一组步骤贯穿摘要、独立权利要求、发明内容和具体实施方式：

1. 摘要

• 用 1 段压缩写明技术领域、技术问题、核心步骤和主要效果。

2. 独立权利要求

• 写完整方法步骤 S1...Sn，只保留解决技术问题必不可少的步骤。

3. 从属权利要求 / 进一步限定

• 按步骤逐项展开关键对象、状态表示、参数、约束、计算方式、更新方式和替代条件。

4. 发明内容

• 先给总体构思，再列 S1...Sn，再写进一步限定和技术效果。

5. 具体实施方式

• 用同一组 S1...Sn，在具体示例中把输入、初始化、状态更新、计算、判断、输出完整跑一遍。

因此，code2patent 不应为交底书、布局卡、证据矩阵和初稿分别创造不同的步骤链。步骤编号、技术对象名称和技术效果口径应保持一致。

六、发明内容写法

发明内容内部固定按以下顺序组织：

1. 要解决的技术问题

• 不写泛泛业务目标。
• 要能对应背景技术中的不足。

2. 总体技术方案

• 用 1-2 段概括“通过什么技术手段解决什么问题”。
• 软件/算法方案应写成方法、系统或运行时机制，而不是“某模块实现某功能”。

3. 方法步骤 S1...Sn

• S1 通常写输入、初始化、对象识别或模型构建。
• 中间步骤写核心计算、筛选、调度、更新、校验、映射、召回、注入等。
• 最后一步写输出、执行、回写、拒绝、告警、优化结果或上下文更新。

4. 进一步限定

• 对关键步骤补充节点、边、状态、特征、阈值、优先级、约束、权重、缓存、回退或鉴权。
• 这部分通常是从属权利要求和具体实施方式的来源。

5. 技术效果

• 每条效果应能回到一个或多个技术步骤。
• 没有实验数据时，不写量化提升。
• 可按“方法层面”和“应用层面”拆分：方法层面写建模、计算、状态更新、特征提取、搜索效率；应用层面写系统响应、资源利用、调度质量、风险控制等。

七、具体实施方式写法

具体实施方式应满足“代理师能继续扩展为说明书”的要求，至少包含：

1. 示例场景

• 例如某个智能体会话、某个任务板、某类调度系统、某个多对象交互场景。

2. 输入对象

• 会话信息、用户身份、工作案例、任务目标、图结构、候选视图、调度工件、资源状态等。

3. 模型或状态表示

• 命名空间、异构图、状态机、特征向量、权限链、记忆强度、候选集合等。

4. 步骤展开

• 按 S1...Sn 展开，不写成本地函数调用链。
• 可说明每一步的判断条件、更新方式和输出结果。

5. 参数与边界条件

• 阈值、权重、排序条件、触发条件、终止条件、权限范围、降级策略。

6. 输出与效果

• 输出文件视图、上下文、认证状态、调度结果、候选解、风险结论、审查动作等。

7. 优选与替代实施

• 不同数据结构、不同模型、不同触发条件、不同部署方式、不同安全策略。

8. 示例跑通

• 样稿通常会给一个具体算例、输入数据、参数或场景，并按 S1...Sn 展示系统如何执行。
• 对代码项目，也应选择一个典型用户会话、任务流、文件操作、调度请求或上下文构建过程，把步骤完整跑通。

9. 公式、规则或伪代码

• 如涉及评分、排序、阈值、向量、图结构、时间推进或资源约束，可用公式、规则表或伪代码说明。
• 这些内容属于实现方式，不等于本地代码函数。

八、代码证据放置规则

代码证据是内部核验材料，不是正文主线。

默认拆分为：

1. 04-方案代码证据映射-<方案名>.md

• 可列路径、函数、字段、接口、事件、测试、配置、调用链。

2. 05-技术交底书-<方案名>.md

• 正文只保留证据状态摘要和附录索引。
• 不在正文核心章节放“代码来源”“重点模块”“代码实现对应关系”。

3. 05B-权利要求-证据矩阵-<方案名>.md

• 用于把权利要求特征逐项回勾到证据。

正文中只有在代码细节能说明必要技术特征、区别点、技术效果或充分公开时，才可摘要提及。

九、公式与符号体例

软件、算法和调度类方案常涉及评分、排序、阈值、向量、图结构和时间推进等可形式化内容。当正文出现公式或形式化符号时，按下述体例执行，避免交底书、布局卡、证据矩阵、初稿和具体实施例之间出现符号不一致、维度标签被误读、同一字母多义等问题。这些是算法类专利代理师审稿时的高频返工点。

1. 符号表先行

正文首次出现公式前，先集中列出符号表。建议按以下顺序分组：

1. 任务或对象下标：如第 i 个任务、第 j 个候选、第 k 轮迭代。 2. 节点、资源或环境下标：如节点 n、资源类型 r、时段 t。 3. 标量、向量与矩阵：明确区分标量、向量和矩阵。

每项符号至少包含：符号、含义、下标含义、量纲或取值范围。示例：

2. 维度与下标

多维属性用下标表达，不用上标。上标只保留给幂次、转置等运算，避免维度标签被误读为指数。

• ✓：$b_{i,\mathrm{cpu}}$（任务 i 的 CPU 维需求）
• ✗：$b_i^{\mathrm{cpu}}$（上标易被读作 $b_i$ 的 cpu 次幂）

多个维度并列时按下标序列书写，如 $b_{i,\mathrm{cpu},t}$。

3. 符号唯一性

同一字母不得在同一方案中兼表两种含义。任务侧与节点侧应使用不同字母族，避免同一个 $b$ 同时表示"任务需求"和"节点供给"。

• ✓：任务需求用 $b$，节点供给用 $g$，用 $b_i \leq g_n$ 表达"任务需求不超过节点供给"。
• ✗：任务需求和节点供给都写 $b$，靠上下文区分。

4. 公式分隔符统一

全文公式分隔符各选定一种，不混用：

• 行内公式：$...$ 或 \(...\) 二选一。
• 块级公式：$$...$$ 或 \[...\] 二选一。

同一份交底书或初稿内不一致会干扰代理师转排和后续排版。

5. 跨节同形

同一组符号和公式在以下位置必须逐字一致：

1. 符号表（本节第 1 点） 2. 发明内容中首次出现的定义式 3. 具体实施方式中展开的计算式 4. 参数表中的"符号"列 5. S1...Sn 步骤描述中引用的符号

若具体实施方式需要引入新符号，应回填到符号表，不就地另起命名。交底书、布局卡、证据矩阵和初稿之间共享同一组符号，不为不同产物各自命名。

6. 公式与代码证据的关系

公式用于表达技术机制，不等于本地代码函数。代码中的实现细节（变量名、循环结构、临时变量）默认进入证据映射或附录，不进入公式正文。若某公式对应明确代码证据，可在证据矩阵中登记，但正文公式保持说明书语言。

7. 正反例对照

以"任务-节点匹配评分"为例：

十、下笔前检查

生成交底书、布局卡或初稿前，先检查：

1. 是否已先读取用户提供的清单、模板、PRD、沟通纪要或参考样本。 2. 是否能用一句话说明技术问题、核心技术手段和技术效果。 3. 是否已经把代码证据与说明书式正文拆开。 4. 是否已经把核心步骤整理成 S1...Sn。 5. 是否明确哪些特征进入独立权利要求，哪些只进入从属权利要求或实施例。 6. 是否存在把第三方库、模型平台或框架默认能力写成申请人创新的风险。 7. 是否已将项目架构转译为技术对象、关系、状态、动作、时序和输出，而不是模块清单。 8. 是否能用一个具体实施例把 S1...Sn 跑通。 9. 若正文涉及公式或形式化符号，是否已按"公式与符号体例"设符号表、维度用下标、符号唯一且跨节同形。

代码证据抽取规范

本规范用于将候选专利方案映射到代码中的真实实现，并形成可供研发人员和专利代理师协作的证据材料。

抽取结果应服务于权利要求布局和具体实施方式，不应把模块、接口、函数或配置清单作为技术交底书正文。

一、目标

代码抽取阶段应尽量回答：

1. 技术方案在代码中是否已经实现 2. 可拆成哪些方法步骤 S1...Sn、技术特征 F1...Fn 和实施例要素 3. 哪些技术特征有直接代码证据，哪些只是归纳实现 4. 每个步骤或特征由哪些证据 E1...En 支撑 5. 哪些内容仍需研发补充，不能直接写成既有实现 6. 哪些证据只适合放入内部证据映射，哪些可以转译为交底书正文、从属权利要求或具体实施方式

二、抽取顺序

建议按以下顺序展开：

1. 以候选方案为单位建立映射，不要混写多个发明点 2. 先用一句话锁定技术问题、核心技术手段和技术效果 3. 再将核心处理流程整理为步骤 S1...Sn 4. 为每个步骤提炼技术特征 F1...Fn 和具体实施方式要素 5. 将项目架构事实转译为技术对象、对象关系、状态表示、动作更新和输出结果 6. 最后回到代码中定位证据 E1...En，记录路径、函数、字段、接口、配置和测试 7. 将证据整理成内部证据映射表 8. 把可申请的机制转译为说明书式交底书语言，不把证据表直接当成交底书正文

三、证据分级

起草层使用规则

1. A 级证据特征可进入独立权利要求骨架 2. B 级证据特征优先进入从属权利要求、优选实施例或“基于实现归纳”的说明 3. C 级证据特征只能进入“待研发确认”“替代实施例”或风险提示，不能写成既有实现

交底书层使用规则

1. 交底书正文只吸收能说明“技术问题、方案构思、实施方式、技术效果”的证据 2. 文件路径、函数名、字段名、测试路径和内部事件名默认放入证据摘要或附录 3. 如果一个段落主要由代码路径组成，应改写为处理步骤、技术特征、数据/状态流转或具体实施方式 4. 代码证据充分不等于交底书合格；仍需说明该实现为什么构成一个可申请的技术方案 5. 交底书主体默认不设置“代码来源”“重点模块”“代码实现对应关系”等工程盘点章节 6. 只有当代码细节能帮助代理师理解必要技术特征、区别点或充分公开时，才可在正文中摘要提及

四、每条技术特征必须回答的问题

1. 该特征对应的技术问题是什么 2. 该特征对应哪个步骤 S1...Sn 或从属限定 3. 该特征在权利要求中应写成必要特征、附加特征还是实施例要素 4. 与常规实现相比，差异点在哪里 5. 是否足以支撑技术效果 6. 是否需要研发补充参数、阈值、条件或边界说明 7. 哪些代码证据 E1...En 支撑该特征 8. 在交底书正文中应表达为哪一种机制、步骤、状态流、数据流或单元协同 9. 哪些模块、类、函数、接口或配置仅作为证据位置，不进入正文主线 10. 哪些工程细节应只留在证据附录中

推荐内部编号：

• S1...Sn：方法步骤
• F1...Fn：拟进入权利要求或实施例的技术特征
• E1...En：代码、配置、文档或测试证据
• A1...An：架构事实到专利表达的转译项

正文优先写 S 和 F，证据表再列 E。不要反过来用 E 的文件路径和函数名组织正文。 架构信息优先写成 A 的转译结论，例如“运行时文件视图生成机制”“会话状态更新机制”“多层搜索策略”，不要写成原始模块名。

五、从代码证据到交底书的转译规则

1. 不要直接写成代码盘点

以下表达不适合作为交底书正文：

• “某文件实现了某函数”
• “某接口调用某服务”
• “某字段取值为某状态”
• “某测试文件覆盖某流程”
• “重点模块包括 A、B、C”
• “代码来源为某本地绝对路径”

这些内容应进入证据映射表或代码证据附录。

2. 转成发明叙事

应把工程事实转成专利代理师可理解的表达：

3. 保留必要证据

交底书正文可以保留少量证据摘要，例如：

• “代码证据显示，该机制已覆盖创建校验、状态回写和出站事件三个环节”
• “具体证据详见《方案代码证据映射》中的 A1-A5”

但不应在正文中连续堆叠多个路径或函数名。

4. 正文筛选阈值

将某个工程细节写入交底书正文前，先问四个问题：

1. 它是否对应拟保护的必要技术特征 2. 它是否解释了本方案相对现有方式的区别 3. 它是否支撑某个技术效果 4. 它是否有助于代理师理解可替代实施方式或充分公开

四个问题均无法回答时，该细节只能放入证据映射表或附录。

5. 输出拆分规则

04-方案代码证据映射-<方案名>.md 可以保留路径、函数、字段、接口、事件和测试。

05-技术交底书-<方案名>.md 应默认采用算法/软件类说明书式结构：技术领域、背景技术、发明内容、附图说明、具体实施方式、技术效果、替代实施方式、证据附录。

05A / 05B / 06 中的步骤编号应沿用 05-技术交底书 中的 S1...Sn，不得重新发明一套步骤链。

六、引用要求

• 优先引用代码仓库中的相对路径
• 对关键实现注明模块、类、函数、接口、配置项或任务流名称，但只作为证据位置
• 不大量粘贴代码，重点写清楚“代码做了什么”
• 没有找到依据时明确写“未在当前代码中定位到直接证据”

七、不宜直接写成专利特征的内容

• 纯业务规则、运营策略、文案逻辑
• 通用 CRUD 流程
• 仅是开发框架默认能力
• 完全来自第三方库或平台的固有机制
• 无法对应具体技术效果的常规工程做法

八、标准产出

建议形成以下文档：

1. 04-方案代码证据映射-<方案名>.md 2. 05-技术交底书-<方案名>.md 3. 05A-权利要求布局卡-<方案名>.md 4. 05B-权利要求-证据矩阵-<方案名>.md 5. 06-发明专利初稿-<方案名>.md 6. 06A-发明专利初稿自检表-<方案名>.md 7. 07-研发补充问题清单.md

其中 04-方案代码证据映射-<方案名>.md 为核心前置产物，但它不是技术交底书正文。

04 的推荐表头为：步骤编号、技术特征、权利要求/实施例位置、证据编号、证据位置、证据等级、待确认事项。不要以“模块名称、模块功能、对应文件”为主表头。

发明专利起草速查卡

给 agent 用的短版规则卡。

只保留最容易写偏、但最影响 code2patent 输出质量的规则。

一、先看什么

进入起草层时，默认按这个顺序：

1. 04-方案代码证据映射-<方案名>.md 2. 05-技术交底书-<方案名>.md 3. references/algorithm-software-disclosure-format.md 4. 本速查卡 5. references/patent-drafting-spec.md 6. 再动笔写 05A / 05B / 06 / 06A

二、10 条硬规则

1. 算法/软件类交底书按说明书式结构写

• 默认主线是：技术领域、背景技术、发明内容、附图说明、具体实施方式。
• 发明内容内部要包含技术问题、总体方案、步骤 S1...Sn、进一步限定和技术效果。
• 具体实施方式要用示例场景展开输入、状态/数据表示、步骤、参数和输出。
• 对软件项目，默认按算法/软件类发明处理；不要退回到“系统模块说明书”。

2. 交底书不是代码盘点

• 代码证据映射可以列文件、函数、字段和状态。
• 技术交底书正文应讲技术问题、方案构思、实施步骤、具体实施方式和技术效果。
• 如果正文连续堆叠代码路径，应先转译为步骤 S1...Sn、技术特征、数据/状态流转、单元协同或证据附录。
• 如果输出主体变成“模块 A、模块 B、模块 C”，应回退重写为权利要求候选特征和具体实施方式。

3. 权利要求必须有说明书支撑

• 权利要求不能脱离说明书公开内容单独漂移。
• 如果说明书没写清，权利要求就不要先写大。

4. 独立权利要求只写必要技术特征

• 只保留“为解决技术问题所必需”的特征。
• 参数、优选条件、缓存、回退、异常处理等，通常先放从属权利要求或实施例。

5. 从属权利要求只写附加技术特征

• 不要重复独立权利要求已经写过的全部内容。
• 默认按三层挂接：步骤细化、参数/条件、实施细节。

6. 先稳 claim tree，再写完整初稿

• 先写 05A-权利要求布局卡
• 再写 05B-权利要求-证据矩阵
• 最后写 06-发明专利初稿

不要跳过 L2.5 直接硬写初稿。

7. 摘要只做压缩，不做营销

• 写名称、技术领域、技术问题、技术方案要点、主要用途。
• 控制在 300 字内。
• 不写宣传性表达，不写夸张效果。

8. 计算机程序相关发明要区分方法口径和产品口径

• 方法口径：写处理步骤。
• 产品口径：可按装置、计算机可读存储介质、计算机程序产品布局。
• 不要只写“某程序实现某功能”这种抽象功能描述。

9. A / B / C 级证据进入位置不同

• A 级：可进入独立权利要求骨架。
• B 级：优先进入从属权利要求或优选实施例，并标“基于实现归纳”。
• C 级：只能进待确认事项或替代实施例。

10. 第三方能力不直接写成申请人创新

• 模型、SDK、中间件、向量库、云服务的固有能力，不直接主张。
• 只主张本项目对其的组织、调度、适配、回退、缓存、状态管理等自研机制。

三、计算机程序相关发明的默认保护主题

默认先并行准备四类草稿，供代理师择优整合：

1. 方法 2. 系统 / 装置 3. 计算机可读存储介质 4. 计算机程序产品

注意：这里是内部布局草稿，不等于正式申请文件必须全部同时保留。

四、下笔前自问 9 个问题

1. 这份方案真正解决的技术问题是什么？ 2. 交底书是否已经按算法/软件类说明书式结构组织？ 3. S1...Sn 是否覆盖完整技术闭环，并在交底书、布局卡、证据矩阵和初稿中保持一致？ 4. 交底书正文是否仍然像代码证据表？ 5. 主独立权利要求里有没有混入“非必要特征”？ 6. 是否把 B / C 级证据写实了？ 7. 是否把第三方固有能力误写成了申请人创新？ 8. 是否已把项目架构转译为技术对象、关系、状态、动作、时序和输出？ 9. 是否把实现模块清单误当成了技术方案主线？

五、最常见的 5 个错误

1. 把代码证据映射直接改名为技术交底书，正文过度技术化。 2. 交底书没有技术领域、背景技术、发明内容、附图说明、具体实施方式这条主线。 3. 交底书、布局卡、证据矩阵和初稿中的步骤编号不一致。 4. 把工程优化细节全塞进独立权利要求，导致主权利要求过窄。 5. 把第三方平台能力直接当成申请人的核心创新。

发明专利起草规范

本规范用于把 code2patent 的交底书输出继续扩展为接近可申报版的中国发明专利起草材料。

适用于软件、算法、Agent 系统及其他以代码实现为主的技术方案。

本规范只收口到《专利审查指南》中与“说明书、权利要求书、摘要撰写”直接相关的内容，以及计算机程序相关发明保护主题的官方解读。

一、目标

起草阶段应至少回答以下问题：

1. 本方案真正要解决的技术问题是什么 2. 哪些技术特征属于解决该技术问题的必要技术特征 3. 哪些特征适合进入独立权利要求，哪些只适合进入从属权利要求或实施例 4. 说明书是否足以支撑权利要求并满足充分公开 5. 算法/软件类方案是否已经形成步骤 S1...Sn，并在交底书、布局卡、证据矩阵和初稿中保持一致 6. 摘要、附图建议、请求书字段是否已经整理到位

二、官方基线

起草结构和硬约束默认参考以下公开资料：

1. 国家知识产权局：《专利审查指南》官方 PDF

• 第二部分第二章“说明书和权利要求书”是本 skill 的主起草依据。
• 说明书摘要部分明确：摘要应写明名称、所属技术领域、所要解决的技术问题、技术方案要点和主要用途；摘要文字部分不得超过 300 个字，且不得使用商业性宣传用语。
• 独立权利要求撰写部分明确：前序部分写主题名称和与最接近现有技术共有的必要技术特征，特征部分写区别技术特征，二者合起来限定全部必要技术特征。
• 从属权利要求撰写部分明确：从属权利要求包括引用部分和限定部分，限定部分写附加技术特征。
• 说明书具体实施方式部分明确：当独立权利要求保护范围较宽时，应给出足以支持该概括范围的实施例；区别技术特征和从属权利要求附加技术特征应当充分描述。

2. 国家知识产权局：《专利审查指南》（2023）修改解读（四）

• 涉及计算机程序的发明专利申请，权利要求可以写成方法权利要求，也可以写成产品权利要求，例如实现该方法的装置、计算机可读存储介质或者计算机程序产品。
• 本次解读明确了计算机程序产品也属于产品权利要求，为软件类方案提供了更完整的保护主题。

起草时重点吸收的官方要求

1. 说明书和权利要求书要相互支撑，权利要求不能脱离说明书公开内容单独漂移。 2. 权利要求应清楚、简要，且只写技术特征，不写不必要的原因、理由或宣传表述。 3. 独立权利要求只保留必要技术特征，从属权利要求再写附加技术特征。 4. 计算机程序相关方案既可以走方法口径，也可以走产品口径，但无论采用哪种口径，都必须反映完整技术方案，而不能只写抽象功能和效果。

三、默认起草策略

1. 两步写作

只要目标是发明专利初稿，默认先完成：

1. 05A-权利要求布局卡-<方案名>.md 2. 05B-权利要求-证据矩阵-<方案名>.md

之后才允许生成完整初稿。

对于算法/软件类方案，布局卡和证据矩阵应以步骤 S1...Sn 为主线，保持与技术交底书和初稿中的步骤编号一致。

2. 默认交付目标

• 法域默认：中国发明专利
• 交付目标默认：接近可申报版
• 交付口径默认：方法 + 系统 / 装置 + 计算机可读存储介质 + 计算机程序产品四类保护主题草案

注意： 平行保护主题是为了便于代理师比较和整合，不等于正式提交时必须原样保留全部独立权利要求。

3. 证据驱动规则

• A 级证据：可进入独立权利要求骨架
• B 级证据：优先进入从属权利要求、优选实施例，并注明“基于实现归纳”
• C 级证据：只进入待确认事项或替代实施例，不得写成既有实现

四、权利要求起草方法

1. 先锁定核心发明构思

在写权利要求前，先用一句话说清楚：

• 解决了什么技术问题
• 通过什么核心技术手段解决
• 取得了什么技术效果

如果一句话说不清，就说明候选方案仍然过宽、过散或混入了多个发明点。

2. 独立权利要求只保留必要技术特征

独立权利要求应只保留解决技术问题所必需的技术特征，不要把以下内容默认塞入主独权：

• 只属于优选实现的参数范围
• 可替换的工程实现细节
• 仅用于性能优化但不是必要前提的缓存、回退、告警、日志特征
• 尚无直接代码证据的设想性特征

3. 从属权利要求按层级挂接

从属权利要求建议分三层：

1. 核心增强层：进一步限定关键处理步骤、关键交互关系、关键数据结构 2. 优选参数层：阈值、时机、触发条件、排序策略、调度优先级 3. 工程细节层：缓存、回退、鉴权、异常处理、日志记录、补偿机制

4. 计算机程序相关发明保护主题的映射方式

方法口径

优先描述：

• 输入对象
• 处理步骤
• 判断 / 调度 / 更新逻辑
• 输出结果

系统 / 装置口径

将方法中的关键步骤映射为单元、组件或执行器，但不要机械改写为“用于……的模块”列表，也不要照搬代码目录中的实现模块名称。系统 / 装置口径必须体现各单元之间的配合关系、数据交互关系和对方法步骤 S1...Sn 的支撑。

计算机可读存储介质口径

以“存储有程序，程序被处理器执行时实现上述方法”为基础，但应确保其支撑的方法口径已经写稳。

计算机程序产品口径

当方案确有必要强调软件产品分发、部署、下载或程序本身的实现形态时，可写成计算机程序产品权利要求。但仍然要回到完整技术方案，不能只写“某程序实现某功能”这类抽象功能描述。

五、说明书起草方法

1. 章节顺序

说明书默认采用以下顺序：

1. 发明名称 2. 技术领域 3. 背景技术 4. 发明内容 5. 附图说明 6. 具体实施方式

1A. 算法/软件类说明书式结构

软件、算法、Agent 系统和代码实现类方案，说明书正文应优先按照 references/algorithm-software-disclosure-format.md 的结构展开：

1. 技术领域：写清具体技术方向 2. 背景技术：写现有实现和技术问题 3. 发明内容：写技术问题、总体方案、步骤 S1...Sn、进一步限定和技术效果 4. 附图说明：至少建议整体流程图或系统框图 5. 具体实施方式：用示例场景展开输入、模型/状态、步骤、参数、输出和替代实现

代码路径、函数名、字段名和测试文件只作为证据摘要或附录索引，不应成为说明书正文主线。 若说明书主体呈现为“前端模块、服务模块、接口模块、配置模块”的工程分层，应回退重写为算法步骤、状态/数据流、单元协同和实施例。

2. 背景技术

• 只写与本方案最相关的现有实现路径
• 直接引出本方案要解决的问题
• 避免写成泛泛的行业介绍

3. 发明内容

应清楚对应三件事：

1. 要解决的技术问题 2. 为解决该问题采用的技术方案 3. 相对于现有技术取得的有益效果

算法/软件类方案的发明内容还应明确步骤 S1...Sn。每个步骤应描述技术动作、处理对象和输出结果，不写成本地函数调用。

4. 具体实施方式

具体实施方式应能支撑权利要求，并至少包含：

• 一套基础实施流程
• 一组优选实施方式
• 一组不脱离发明构思的替代实施方式

不要在具体实施方式中引入与权利要求完全无关的新核心概念，否则容易导致术语漂移。

六、摘要与请求书

1. 摘要

摘要应当：

• 写清名称、技术领域、技术问题、技术方案要点、主要用途
• 默认控制在 300 字内
• 不使用商业性宣传语言

2. 请求书待填字段

code2patent 首版不自动生成正式请求书表格，但应整理以下字段：

1. 发明名称 2. 申请人名称 / 姓名 3. 申请人地址和邮编 4. 发明人姓名 5. 代理机构与代理师信息 6. 优先权信息 7. 申请文件清单 8. 附加文件清单 9. 其他需要补充的法定事项

七、起草完成后的自检

完成初稿后，至少检查：

1. 术语是否在权利要求和说明书中前后一致 2. 独立权利要求是否只包含必要技术特征 3. 从属权利要求是否形成清晰层级 4. 说明书是否支撑每一个关键权利要求特征 5. 摘要是否符合长度和表达要求 6. 算法/软件类方案的 S1...Sn 是否在交底书、布局卡、证据矩阵和初稿中一致 7. 计算机程序相关方案是否区分了方法口径与产品口径，且没有把抽象功能直接当作技术方案 8. 是否已将项目架构转译为技术对象、关系、状态、动作、时序和输出，而不是模块或技术选型清单 9. 是否误把第三方固有能力或 C 级证据写成申请人的既有实现 10. 是否显式列出待代理师 / 研发确认事项

项目技术方案画像规范

本规范用于在进入代码细节前，先建立项目边界、依赖结构、运行时形态和可申请技术机制的整体认识。

适用于“代码仓库转专利交付”的所有场景，无论最终产物是技术交底书还是发明专利初稿。

本规范不是模块清单模板；项目分析的结论应服务于权利要求布局和具体实施方式，而不是把代码目录改写成正文。

一、目标

完成项目分析阶段后，应至少回答以下问题：

1. 当前项目可能包含哪些可申请的软件/算法类技术机制 2. 是否存在 monorepo、workspace、共享包、submodule 或私有依赖 3. 哪些关键能力来自第三方库、云服务、模型平台或中间件 4. 创新点主要落在算法步骤、状态表示、数据流、调度逻辑、权限控制、上下文编排还是异常回退 5. 哪些目录和模块只是证据位置，不能成为交底书或权利要求的正文主线 6. 项目架构可以转译为哪些技术对象、对象关系、状态表示、动作更新和输出结果 7. 哪些能力不宜直接写成申请人的核心技术特征

二、分析顺序

建议按“先宏观、后局部”的顺序推进：

1. 先读用户提供的候选方案清单、PRD/需求说明、沟通纪要、技术描述、Word 模板 2. 再读代码仓库中的 README、架构文档、接口文档和目录说明 3. 再读项目边界和依赖文件 4. 再读部署与运行文件 5. 最后围绕已确认候选方案进入关键流程代码，抽取 S1...Sn 步骤、F1...Fn 技术特征和 E1...En 证据编号

三、优先查看的文件

1. 边界与依赖文件

这些文件用于判断能力归属和证据边界，不用于生成“重点模块清单”作为交底书正文。

• package.json
• pnpm-workspace.yaml
• turbo.json
• pyproject.toml
• requirements.txt
• go.mod
• Cargo.toml

2. 部署与运行文件

• Dockerfile
• docker-compose.yml
• .env.example
• 启动脚本
• CI 配置

3. 项目说明文件

• README.md
• PRD.md、产品方案、需求说明文档
• 架构文档
• 接口文档
• 目录说明

4. 运行时编排文件

重点观察运行时如何组织算法步骤、状态流、权限流、上下文流和异常回退，而不是仅列出配置文件名称。

• workflow 配置
• agent 配置
• prompt 配置
• 任务调度配置
• 缓存配置
• 消息队列配置
• 向量库配置

四、必须完成的判断

1. 边界判断

• 当前仓库哪些目录是主项目自研代码，仅作为证据边界
• 哪些目录是 workspace 包、共享包、submodule 或外挂仓库

2. 依赖判断

• 哪些能力来自第三方库、外部 SDK、模型平台、中间件或云服务
• 这些依赖在项目中承担什么角色

3. 创新判断

• 创新是否发生在单个算法步骤内部
• 创新是否更主要体现在状态表示、特征计算、调度逻辑、缓存机制、上下文注入、鉴权、异常回退或数据流设计
• 创新是否可整理为权利要求中的步骤 S1...Sn 或特征 F1...Fn
• 项目架构是否可以表达为“对象-关系-状态-动作-输出”的技术机制链

4. 归属判断

• 哪些内容是第三方能力本身，不应直接写成申请人的创新
• 哪些内容是本项目对第三方能力的组织、改造和组合使用方式，可作为重点申请对象

五、依赖可读性标注

若部分依赖或关联仓库无法读取，必须显式标注状态：

• 已读取：当前已直接查看相关代码或配置
• 未读取但可推断：虽未直接查看，但可从调用方式、配置或文档合理推断
• 未读取且影响判断：当前无法读取，且会直接影响创新归属或实现判断

六、标准产出

建议至少形成以下文档：

1. 00-输入材料摘要.md 2. 01-项目边界与依赖画像.md 3. 03-项目技术方案画像.md

如当前只做初步预研，可至少先产出前两项。

03-项目技术方案画像.md 应优先按“技术问题、候选机制、S 步骤、F 特征、E 证据、待确认事项”组织。不要按 controller/service/component/package 等工程目录层级展开正文；这些信息只放在证据列或附录索引中。

建议在画像中增加一张“架构转译表”：

发明专利权利要求-证据矩阵模板

本模板用于把拟写入权利要求的技术特征逐项回勾到代码、配置、文档和实现链路证据。

对算法/软件类方案，矩阵应同时保持“步骤 S1...Sn”和“技术特征 F1...Fn”的对应关系。

表格主线是权利要求特征和实施步骤，代码模块只作为证据位置填写。

一、方案基本信息

1. 方案名称

[填写方案名称]

2. 对应布局卡

[填写 05A-权利要求布局卡-<方案名>.md 的文件名]

3. 对应交底书

[填写 05-技术交底书-<方案名>.md 的文件名]

二、步骤-证据矩阵

三、权利要求-证据矩阵

四、技术效果对应矩阵

五、第三方依赖边界检查

六、写作位置建议

1. 可进入独立权利要求的特征

• [A 级必要特征，对应 S1...Sn 中不可缺少的步骤]

2. 适合进入从属权利要求的特征

• [B 级或非必要但重要的增强特征]

3. 适合进入说明书具体实施方式的特征

• [优选实现、参数、边界条件、示例数据、运行条件]

4. 仅能进入待确认事项的特征

• [C 级特征]

算法与软件类发明专利权利要求布局模板

本模板用于在技术交底书基础上先搭建 claim tree，再进入完整初稿。

默认面向中国发明专利软件 / 算法 / Agent 系统场景。

方法权利要求优先按步骤 S1...Sn 布局，再映射到系统 / 装置、计算机可读存储介质和计算机程序产品。

一、方案基本信息

1. 方案名称

[填写拟申请方案名称]

2. 对应交底书

[填写 05-技术交底书-<方案名>.md 的文件名]

3. 默认法域

[通常填写：中国发明专利]

4. 主保护主题建议

[默认建议：方法；如系统结构更强，可说明是否改以系统 / 装置为主]

二、核心发明构思

1. 要解决的技术问题

[用 1 段写清楚，必须对应背景技术中的不足]

2. 核心技术手段

[用一句话概括“通过什么步骤、状态、数据结构、模型或调度机制解决什么问题”]

3. 核心技术效果

[只写已能由交底书、代码证据或材料支撑的效果]

三、方法步骤布局

四、技术特征分级清单

五、独立权利要求骨架

1. 方法独立权利要求骨架

一种[方法名称]，其特征在于，包括：

S1、[必要步骤 1]；

S2、[必要步骤 2]；

S3、[必要步骤 3]；

S4、[必要步骤 4]。

只写解决技术问题必不可少且有 A 级证据支撑的步骤。参数、优选触发条件、缓存、回退、异常处理等通常放入从属权利要求。

2. 系统 / 装置独立权利要求骨架

一种[系统 / 装置名称]，其特征在于，包括：

• [第一单元]，用于执行步骤 S1；
• [第二单元]，用于执行步骤 S2；
• [第三单元]，用于执行步骤 S3；
• [第四单元]，用于执行步骤 S4；
• 其中，各单元按照步骤 S1...Sn 的数据流、状态流或权限流协同工作。

3. 计算机可读存储介质独立权利要求骨架

一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如上述方法口径所述的方法。

4. 计算机程序产品独立权利要求骨架

一种计算机程序产品，其特征在于，包括计算机程序，所述计算机程序被处理器执行时实现如上述方法口径所述的方法。

六、从属权利要求分层

1. 步骤细化层

• [进一步限定 S1 的输入对象、初始化方式或识别规则]
• [进一步限定 S2 的模型、状态、数据结构、特征向量或命名空间]
• [进一步限定 S3 的判断、筛选、调度、映射、校验或召回方式]
• [进一步限定 S4 的输出、回写、更新、拒绝、告警或优化方式]

2. 参数与条件层

• [阈值、权重、排序、优先级、触发条件、终止条件]

3. 实施细节层

• [缓存]
• [回退]
• [鉴权]
• [异常处理]
• [日志 / 补偿 / 重试]
• [部署或运行时约束]

七、平行保护主题映射

八、不建议进入主独权的内容

• [仅为优选实现的特征]
• [只有 B 级或 C 级证据的特征]
• [与解决核心技术问题无直接关系的工程便利性特征]
• [第三方库、模型平台或框架默认能力]

九、待确认与风险

1. [哪些特征只有 B 级证据，需要研发确认后再决定是否写入从权] 2. [哪些特征存在第三方依赖归属风险] 3. [哪些特征目前只宜保留为替代实施例] 4. [代理师在正式提交前需要决定的口径取舍]

算法与软件类发明专利技术交底书模板

本模板用于软件、算法、Agent 系统和代码实现类方案的技术交底书整理。

默认写成“说明书前置稿”，而不是代码实现盘点。

代码路径、函数名、字段名、接口、测试文件和内部事件名默认进入独立证据映射或本文后置附录。

如需继续扩展为中国发明专利申请文件初稿，请改用 invention-patent-draft-template.md。

一、方案基本信息

1. 方案名称

[应体现技术方案主题，建议控制在 25 字以内]

2. 方案来源与确认状态

[说明方案来自客户确认、标题反向澄清、代码挖掘、PRD、会议纪要或参考模板；如原始标题经过调整，应写明调整原因]

3. 候选申请类型

[通常填写：发明专利]

4. 证据状态摘要

[用一句话概括证据状态，例如“A 级证据覆盖会话解析、命名空间生成、权限校验和运行时投影链路”。不要填写本地绝对路径或模块清单]

二、技术领域

[用 1 段说明所属技术领域和具体应用方向。软件/算法/Agent 场景应写到具体机制，例如智能体运行时、动态上下文组装、会话鉴权、调度优化、状态表示、特征提取等]

三、背景技术

1. 现有技术或现有实现方式

[客观描述与本方案最接近的现有系统形态、算法路线、软件架构或工程实现方式]

2. 现有方案存在的问题

[围绕本方案真实解决的问题列出 2-5 条不足。避免泛泛写业务痛点，应写技术约束、状态表达不足、资源耦合、上下文污染、权限边界、计算效率、调度质量等]

3. 本发明拟解决的技术问题

[用 1 段收口为一个核心技术问题；如存在多个问题，说明它们如何共同指向同一技术方案]

四、发明内容

1. 总体技术方案

[用 1-2 段概括“通过什么技术手段解决什么技术问题”。不要堆叠代码文件名，不写成模块清单]

2. 架构转译说明

[将项目架构转译为技术对象、对象关系、状态表示、动作更新和输出结果。不要写技术选型清单]

3. 方法步骤

[按 S1、S2、S3... 写清楚方案如何执行。每一步应描述技术动作、处理对象和输出结果，不写具体函数名]

• S1：[输入、初始化、对象识别、模型构建或状态解析]
• S2：[核心数据/状态/权限/上下文/特征的生成或更新]
• S3：[关键判断、筛选、调度、映射、召回、注入、校验或计算]
• S4：[执行、输出、回写、拒绝、告警、优化或上下文更新]
• S5：[如有，循环迭代、终止条件、结果输出或后处理]

4. 进一步限定

[对关键步骤补充可进入从属权利要求或实施例的内容，例如状态字段、特征向量、权重、阈值、触发条件、缓存、回退、鉴权、异常处理、排序策略、终止条件等]

5. 核心创新点

[列举 3-5 个真正值得申请的机制或流程区别点。每一点应表达为“技术机制/流程/状态/数据结构上的改进”，而不是“某文件实现了某函数”]

6. 有益效果

[逐条说明技术效果，并尽量对应前文步骤或机制。没有实验数据或线上指标时，不做量化夸大]

五、附图说明

[建议绘制哪些图，并说明每张图服务于哪一段方案表达]

1. 图 1：[整体流程图] 2. 图 2：[技术机制或单元协同框图] 3. 图 3：[数据流、状态流转、权限链、资源映射或模型结构图] 4. 图 4：[可选，效果对比、时序图或异常处理流程图]

六、具体实施方式

1. 示例场景

[用一个具体但不泄露客户敏感信息的场景说明本方案如何运行。例如某个智能体会话、任务板、身份验证、记忆召回或调度优化场景]

2. 输入对象与初始条件

[说明输入数据、对象、状态、权限、上下文、候选集合、资源约束、运行参数或环境条件]

3. 模型、状态或数据表示

[说明命名空间、状态机、异构图、特征向量、权限链、记忆强度、候选集合、任务目标、调度约束等核心表示方式]

4. 具体执行步骤

[按 S1...Sn 展开具体实施过程。每一步说明输入、处理逻辑、判断条件、输出或状态变化]

5. 参数、约束与边界条件

[说明阈值、权重、触发时机、终止条件、访问范围、失败条件、降级策略、缓存策略或异常处理]

6. 输出结果

[说明最终输出或执行结果，例如文件视图、上下文、身份状态、调度方案、候选解、审查结论、告警或回写记录]

7. 示例跑通过程

[选择一个具体场景或样例输入，按 S1...Sn 展示方案如何从输入运行到输出。可加入必要参数、规则表、公式或伪代码]

如涉及评分、排序、阈值、向量或图结构等可形式化内容，正文须先设符号表并保持跨节同形，体例见 references/algorithm-software-disclosure-format.md"公式与符号体例"。

七、技术效果

[将发明内容中的有益效果进一步对应到具体实施步骤。建议按“技术手段 -> 效果”的方式写]

八、替代实施方式

[列出在不脱离核心发明构思下的可替代实现，例如不同数据结构、不同模型、不同触发条件、不同部署方式、不同安全策略]

九、代码证据摘要与附录索引

本章只做证据摘要，不替代独立的 04-方案代码证据映射-<方案名>.md。

如果已经另行输出证据映射，本章只保留 3-6 条证据结论和映射文件索引。

1. 证据结论摘要

[说明哪些核心步骤已有直接代码支撑、哪些是结合多处实现归纳、哪些仍需确认]

2. 关键证据索引

3. 不写入正文的工程细节

[列出只适合作为证据附录的细节，例如内部字段名、临时变量、具体测试路径、框架样板代码]

十、待研发 / 代理师确认事项

1. [当前代码中尚未完全落实、需研发补充确认的内容] 2. [关键参数、阈值、约束条件或终止条件] 3. [是否有实验数据、测试结果或线上指标支撑技术效果] 4. [哪些特征适合进入独立权利要求，哪些更适合进入从属权利要求或实施例] 5. [哪些内容存在第三方依赖归属、公开不充分或术语不一致风险]

发明专利初稿自检模板

本模板用于在生成初稿后进行结构、证据和术语一致性检查。

对算法/软件类方案，应重点检查说明书五段式结构、步骤 S1...Sn、权利要求布局和代码证据之间是否一致。

一、基本信息

1. 方案名称

[填写方案名称]

2. 对应初稿文件

[填写 06-发明专利初稿-<方案名>.md 的文件名]

3. 对应布局与证据文件

[填写 05A-权利要求布局卡-<方案名>.md 和 05B-权利要求-证据矩阵-<方案名>.md]

二、说明书结构检查

三、步骤与技术效果检查

四、权利要求检查

五、说明书支撑检查

六、摘要与合规检查

七、待修订事项

1. [代理师需进一步收口或扩展的点] 2. [研发需补充参数、阈值、终止条件或实施细节] 3. [需要从代码证据映射中补强的技术特征] 4. [建议在正式申请前补做检索、对比或实验验证的点]

算法与软件类发明专利初稿模板

本模板用于在技术交底书、权利要求布局卡和权利要求-证据矩阵基础上，继续生成接近可申报版的中国发明专利初稿。

默认采用中国发明专利说明书五段式结构：技术领域、背景技术、发明内容、附图说明、具体实施方式。

默认起草口径：方法 + 系统 / 装置 + 计算机可读存储介质 + 计算机程序产品四类保护主题草稿，正式提交前仍需由专利代理师结合审查策略整合。

一、说明书

1. 发明名称

[应准确概括发明主题，通常控制在 25 字以内]

2. 技术领域

[说明所属技术领域及具体应用方向。算法/软件类方案应写到具体机制或应用场景]

3. 背景技术

3.1 现有技术概况

[客观描述常见实现路径、现有系统形态、算法路线或主流技术方案]

3.2 现有技术存在的问题

[逐项写明现有技术的缺陷或不足，并与后文要解决的技术问题对应]

3.3 本发明要解决的技术问题

[用一段话收口核心技术问题]

4. 发明内容

4.1 总体技术方案

[概括本发明通过什么方法、模型、状态表示、调度机制、权限机制、上下文机制或运行时机制解决上述问题]

4.2 架构转译

[将软件架构转译为技术对象、对象关系、状态表示、动作更新和输出结果。避免写成框架、服务、数据库、接口清单]

4.3 方法步骤

本发明提供一种[方法名称]，包括：

S1、[必要步骤 1]；

S2、[必要步骤 2]；

S3、[必要步骤 3]；

S4、[必要步骤 4]。

[如有更多必要步骤，继续编号；步骤编号必须与布局卡和证据矩阵保持一致]

4.4 进一步限定

[写入可支撑从属权利要求的关键限定，例如特征向量、状态更新、权限链、排序规则、阈值、缓存、回退、异常处理、终止条件等]

4.5 有益效果

[说明技术方案带来的技术效果，逐条对应具体步骤或机制；如无数据支持，不要随意量化]

5. 附图说明

1. 图 1：[整体流程图] 2. 图 2：[系统/装置结构框图] 3. 图 3：[状态流转图、数据流图、权限链图、资源映射图或模型结构图] 4. 图 4：[可选，效果对比图、时序图、异常处理图]

6. 具体实施方式

6.1 示例场景

[选择一个能完整覆盖 S1...Sn 的场景，不写成本地代码说明]

6.2 输入对象与初始条件

[说明输入数据、用户/会话/任务/资源/图结构/候选集合/运行参数等]

6.3 模型、状态或数据表示

[说明命名空间、状态机、异构图、特征向量、权限链、记忆强度、候选集合、上下文对象等]

6.4 基础实施例

[详细展开一套完整实施流程，按 S1...Sn 描述输入、处理、判断、更新和输出，确保支撑主独立权利要求]

6.5 示例跑通过程

[用一组示例输入、参数、状态或操作场景跑通 S1...Sn。必要时加入公式、规则表或伪代码]

如涉及评分、排序、阈值、向量或图结构等可形式化内容，正文须先设符号表并保持跨节同形，体例见 references/algorithm-software-disclosure-format.md"公式与符号体例"。

6.6 优选实施例

[说明参数优化、调度优化、缓存优化、回退机制、鉴权增强、异常处理、排序策略等优选方案；B 级证据优先放在本节或从属权利要求中]

6.7 替代实施例

[列出在不脱离核心发明构思下的替代实现；C 级证据只可在明确标注“待确认”的前提下保留在本节]

二、权利要求书草稿

默认输出四类平行保护主题草稿，供代理师择优整合。正式编号和最终保留范围由代理师决定。

1. 方法独立权利要求

1. 一种[方法名称]，其特征在于，包括：

S1、[步骤或特征 1]；

S2、[步骤或特征 2]；

S3、[步骤或特征 3]；

S4、[步骤或特征 4]。

2. 方法从属权利要求

2. 根据权利要求 1 所述的方法，其特征在于，[进一步限定步骤 S1 的输入对象、初始化条件或识别规则]。

3. 根据权利要求 1 所述的方法，其特征在于，[进一步限定步骤 S2 的模型、状态、数据结构或特征生成方式]。

4. 根据权利要求 1 所述的方法，其特征在于，[进一步限定步骤 S3 的判断、筛选、调度、映射、校验或召回方式]。

5. 根据权利要求 1 所述的方法，其特征在于，[进一步限定步骤 S4 的输出、回写、更新、拒绝、告警或优化方式]。

3. 系统 / 装置独立权利要求

6. 一种[系统 / 装置名称]，其特征在于，包括：

• [第一单元]，用于执行权利要求 1 中的步骤 S1；
• [第二单元]，用于执行权利要求 1 中的步骤 S2；
• [第三单元]，用于执行权利要求 1 中的步骤 S3；
• [第四单元]，用于执行权利要求 1 中的步骤 S4。

4. 计算机可读存储介质独立权利要求

7. 一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求 1-5 任一项所述的方法。

5. 计算机程序产品独立权利要求

8. 一种计算机程序产品，其特征在于，包括计算机程序，所述计算机程序被处理器执行时实现如权利要求 1-5 任一项所述的方法。

三、说明书摘要

[控制在 300 字内，概括名称、技术领域、技术问题、核心技术方案和主要技术效果，不使用商业性宣传语言]

四、摘要附图建议

[说明建议作为摘要附图的流程图或模块图，并说明原因]

五、请求书待填字段清单

1. 发明名称 2. 申请人名称 / 姓名 3. 申请人地址和邮编 4. 发明人姓名 5. 代理机构及代理师信息 6. 优先权信息 7. 申请文件清单 8. 附加文件清单 9. 其他需要补充的事项

六、待代理师 / 研发确认事项

1. [哪些步骤和技术特征已有直接代码证据] 2. [哪些特征属于归纳实现，需要研发进一步确认] 3. [哪些参数、阈值、边界条件、终止条件需要补充] 4. [哪些内容适合保留为主独立权利要求，哪些更适合退回从属权利要求] 5. [四类平行保护主题中，正式提交时建议优先保留的主题和删减策略] 6. [是否需要补充实验结果、测试数据或效果对比图]

专利名称反向澄清卡模板

本模板用于用户只提供专利名称、标题或一句话方向时。

目标是先把标题还原成可验证的技术方案候选，再由用户或研发确认。

未完成确认前，不应直接生成技术交底书、权利要求布局或专利初稿。

一、输入摘要

1. 原始标题

[填写客户提供的原始专利名称或一句话方向]

2. 客户已补充信息

[列出已有的业务场景、产品目标、PRD、沟通纪要或口头说明；未提供则写“未提及”]

3. 代码与文档来源

[填写本次可读取的代码仓库、PRD、README、架构文档、会议纪要等]

二、标题可能指向的技术解释

至少给出 1 个、最多给出 3 个候选解释。不要只因为代码里搜到某个关键词，就把第一个结果当成最终方案。

候选解释 A

• 可能的技术方案：
• 拟解决的技术问题：
• 最小技术闭环：
• 相关模块或证据线索：
• 与原始标题贴合度：高 / 中 / 低
• 偏题风险：
• 是否建议作为独立申请点：是 / 否 / 待确认

候选解释 B

• 可能的技术方案：
• 拟解决的技术问题：
• 最小技术闭环：
• 相关模块或证据线索：
• 与原始标题贴合度：高 / 中 / 低
• 偏题风险：
• 是否建议作为独立申请点：是 / 否 / 待确认

候选解释 C

• 可能的技术方案：
• 拟解决的技术问题：
• 最小技术闭环：
• 相关模块或证据线索：
• 与原始标题贴合度：高 / 中 / 低
• 偏题风险：
• 是否建议作为独立申请点：是 / 否 / 待确认

三、推荐确认版本

1. 建议方案名称

[把原始标题调整为更准确的技术方案名称；如果不建议调整，说明理由]

2. 推荐申请方向

[说明建议围绕哪一个候选解释继续做技术交底书]

3. 不建议纳入本方案的内容

[列出容易跑偏、证据不足或更适合拆成其他申请点的内容]

四、交底书表达方向

1. 背景问题应重点写什么

[写客户或行业中的实际技术问题，不写代码背景]

2. 技术方案应重点写什么

[写机制、流程、模块协同、状态变化、数据流、权限或调度逻辑]

3. 技术效果应重点写什么

[写可由方案直接支撑的效果；没有指标时不要量化夸大]

4. 代码证据应如何放置

[说明哪些内容进入正文，哪些内容只放证据附录]

五、待用户或研发确认问题

1. [该标题实际想保护哪个技术闭环？] 2. [是否接受建议方案名称？] 3. [哪些模块或实现必须纳入？] 4. [哪些内容不应纳入本申请？] 5. [是否已有技术效果、测试结果或线上反馈？]

六、确认记录