代码仓库转专利交付

概述

本技能面向“代码已经开发完成，但需要把技术实现高效转交给专利代理师”的场景。核心目标不是简单改写代码说明，而是把代码仓库中的真实实现方式整理成适合专利申请协作的结构化产物，并在证据充足时继续形成接近可申报版的中国发明专利初稿。

当前推荐主模式是：

代码仓库 + 人工总结的候选专利方案
        ↓
创建 archive 归档目录
        ↓
项目结构盘点 + 方案/模块映射
        ↓
代码证据提取 + 技术特征抽象
        ↓
技术交底书
        ↓
L2.5 权利要求布局卡 + 权利要求-代码证据矩阵
        ↓
中国发明专利初稿 + 初稿自检表

在此基础上，预留两个扩展方向：

从代码仓库自动挖掘可申请专利的技术方案
从已确认方案继续生成接近可申报版的中国发明专利初稿

本技能当前默认法域是中国发明专利。初稿结构和摘要要求以国家知识产权局《专利审查指南》中与“说明书、权利要求书、摘要撰写”直接相关的部分为基线，并补充计算机程序相关发明保护主题的公开解读：

如需快速进入起草，不要先通读整份 PDF；应先读：

references/patent-drafting-quick-reference.md
再按需下钻 references/patent-drafting-spec.md

第一部分：适用场景与定位

当前主场景

用户已经有一个可读取的代码项目，并且已经初步整理出若干拟申请专利的技术方案。技能需要：

读取代码仓库并识别相关模块
将候选技术方案映射到代码中的具体实现
标注哪些技术特征已有直接代码证据，哪些仍需研发补充
输出适合研发人员和专利代理师协作的技术交底书

扩展场景 A：代码到可专利方案挖掘

如果用户尚未整理专利方案，可由 AI 基于代码仓库主动总结：

哪些实现具有“解决具体技术问题”的特征
哪些方案适合拆分为多个申请点
哪些内容只是业务规则或常规工程实现，不建议申请

扩展场景 B：代码到发明专利初稿

如果用户希望继续推进到申请文件层，技能应默认采用两步写作链路：

先生成《权利要求布局卡》与《权利要求-代码证据矩阵》
再据此生成完整初稿与《发明专利初稿自检表》

初稿层应覆盖：

说明书部分：发明名称、技术领域、背景技术、发明内容、附图说明、具体实施方式
权利要求书草稿
说明书摘要
摘要附图建议
请求书待填字段清单
待代理师 / 研发确认事项

当前模板范围： 本技能当前保留五类核心模板：

发明专利技术交底书模板
权利要求布局模板
权利要求-代码证据矩阵模板
发明专利初稿模板
发明专利初稿自检模板

同时，将“项目分析规范”“代码抽取规范”“发明专利起草规范”从主文档中拆出，放入 references/；将交付模板放入 templates/，以明确区分“输出骨架”和“执行规范”。

第二部分：输入方式与最小输入集

启动提问

在正式进入代码阅读前，应优先向用户确认以下问题：

是否已有人工整理的候选专利申请清单或技术方案清单
如果有，该清单中哪些方案优先级最高
本次任务的主题是什么（用于 archive/ 归档目录命名）
是否有 PRD、产品方案、需求说明或其他能解释项目目标的文档
目标输出层级是什么（技术交底书 / 权利要求布局卡 / 发明专利初稿）
如果目标是初稿，是否需要直接输出完整初稿（默认仍先生成布局卡和证据矩阵）
是否有客户或代理师指定的交底书模板、初稿模板或特定写法要求
如果没有候选清单，是否有希望优先关注的业务方向；若没有，则默认由 AI 先自动挖掘候选方案清单

这一步是本技能的入口闸门，不能跳过。

入口分流规则

情况 A：用户已有候选专利申请清单

直接进入“定向检索模式”：

按候选方案逐项建立代码映射
围绕已知方向做针对性搜索和证据提取
输出代码证据映射、技术交底书
如用户需要起草层，则继续输出《权利要求布局卡》与《权利要求-代码证据矩阵》
在上述中间产物完成后，再输出《发明专利初稿》和《发明专利初稿自检表》

情况 B：用户没有候选专利申请清单

进入“候选方案挖掘模式”，但不应直接生成技术交底书或专利初稿。应先：

先自动读取代码仓库并做项目边界与依赖画像
生成《候选可专利方案清单》
对每个候选方案给出简要依据、优先级建议和不确定点
明确提示用户先进行人工筛选、合并、拆分或排序
形成《人工筛选确认记录》
在人工筛选完成后，回到“定向检索模式”，再继续做代码映射、技术交底书、权利要求布局或专利初稿

只有在用户完成筛选并确认方向后，才进入后续的定向代码检索、交底书生成、权利要求布局或专利初稿生成。

方式一：对话输入

用户直接在对话中提供：

代码片段或关键实现说明
候选专利方案清单
创新点说明
业务场景描述
希望输出到哪一层（交底书 / 权利要求布局卡 / 专利初稿）

方式二：文件输入

用户提供代码文件或项目目录，技能将：

优先读取 README、PRD/需求说明、架构文档等高层材料
盘点代码结构、入口、核心模块和关键数据流
将候选方案与模块、接口、类、函数、配置进行映射
提取技术特征与实现证据
先生成交底书与权利要求布局材料，再生成专利初稿

支持的文件类型：

源代码文件（.py, .js, .java, .go, .rs 等）
项目目录（自动扫描关键文件）
技术文档（.md, .txt, .docx）
PRD、产品方案、需求说明文档
架构设计文档、接口文档、测试文档（如有）

第三部分：用户提供材料优先读取与模板筛选

用户提供材料优先读取

正常情况下，本技能依赖的是用户在当前任务中提供的代码仓库、候选方案清单、PRD/需求说明、沟通纪要和交底书模板，而不是 skill 目录内部预置的客户材料。

如果 skill 目录内恰好放有某个具体项目的材料，应将其视为参考样例或开发测试素材，而不是本技能的常规内置输入来源。

执行时不要跳过用户提供的材料直接读代码，应先把这些资料视为“客户侧先验输入”，再进入代码仓库分析。

建议优先级如下：

客户已总结的拟申请方案清单
PRD、产品方案、需求说明
客户或技术人员的沟通纪要、录音转写
客户或代理师提供的 Word 版技术交底书模板
客户或代理师提供的初稿模板、权利要求布局习惯、既有申请样式
补充商务材料（费用、国家布局、交付要求等）
代码仓库本身

这些文件的价值分别是：

方案清单：确定候选发明点，避免 AI 自行偏题
PRD / 需求说明：帮助理解项目目标、关键场景和产品约束，避免只看代码实现而忽略设计意图
沟通纪要：补充技术问题、商业目标和申请优先级
Word 模板：决定最终交付章节顺序和表达口径

模板筛选规则

本技能当前主要面向软件、算法、Agent 系统相关方案，模板规则如下：

若用户提供了 Word 版 技术交底书模板.docx 或同类模板文件，优先按该模板章节输出技术交底书
若用户没有提供技术交底书模板，则使用 templates/invention-patent-disclosure-template.md
若用户要求形成权利要求布局，则使用：
- templates/invention-patent-claim-layout-template.md
- templates/invention-patent-claim-evidence-matrix-template.md
若用户要求形成中国发明专利申请文件初稿，则使用：
- templates/invention-patent-draft-template.md
- templates/invention-patent-draft-self-check-template.md
项目分析与代码抽取的详细要求，分别参照：
- references/project-analysis-spec.md
- references/code-extraction-spec.md
- references/patent-drafting-spec.md

换言之，当前业务模式下不再保留多种专利类型模板，但会保留五类核心交付模板，以及三份支撑执行质量的规范文件。

搜索顺序

在实际执行时，建议按以下顺序推进：

先读用户提供的候选清单、PRD/需求说明、沟通纪要和模板，确定项目目标与客户预期
再读代码仓库中的 README、架构文档和目录说明，建立项目的高层理解
再做项目边界与依赖画像，明确哪些是自研、哪些是第三方
再进入代码仓库做模块映射和证据提取
先按客户模板或内置交底书模板生成技术交底书
再按起草规范生成权利要求布局卡、证据矩阵和初稿

详细规范

“先宏观后局部”的项目分析要求，统一参见：

references/project-analysis-spec.md
references/code-extraction-spec.md
references/patent-drafting-quick-reference.md
references/patent-drafting-spec.md

SKILL.md 只保留主流程和选择规则，具体的分析顺序、依赖判断、证据分级和产出要求，全部在上述三个规范文件中维护。

第四部分：标准工作流程

标准主流程

1. 输入材料预读
2. 任务边界确认
3. 创建 archive 输出目录
4. 项目边界与依赖画像
5. 代码仓库盘点
6. 候选方案映射
7. 代码证据提取
8. 专利语言抽象
9. 技术交底书生成
10. L2.5 权利要求布局卡生成
11. L2.5 权利要求-代码证据矩阵生成
12. L3 发明专利初稿生成
13. L3 发明专利初稿自检

步骤 1：输入材料预读

优先读取用户在当前任务中提供的材料，回答：

用户是否已经给出候选专利申请清单
用户是否提供了 PRD、产品方案或需求说明
客户目前拟申请哪几个发明点
哪个方案优先级最高
客户是否已经明确要求发明专利
最终交付是否需要贴合特定 Word 模板
是否已经有会议纪要、录音转写或技术交底口述材料

步骤 2：任务边界确认

优先确认以下事项：

当前目标是“技术交底书”“权利要求布局卡”还是“发明专利初稿”
如果目标是初稿，是否需要仅产出布局卡，还是继续扩展为完整初稿
是否已有人工整理的候选专利方案
如果没有候选方案，当前任务是否只做到“候选方案清单 + 人工筛选建议”
在候选方案完成人工筛选后，是否立即回到定向检索模式继续生成交底书、权利要求布局或初稿
一个方案是否拆成多个申请点
是否只处理已在代码中实现的内容
是否允许写入“可选实施例/未来演进方向”
当前默认法域是否维持“中国发明专利”

强规则： 如果当前还没有人工确认过的候选方案清单，默认只做到“候选方案挖掘 + 待人工筛选”，不直接输出技术交底书或专利初稿。

步骤 3：创建 archive 输出目录

所有中间产物和最终产物，都应默认写入 skill 内部的 archive/ 目录。

目录命名规则：

archive/YYYY-MM-DD-主题/
主题应尽量简短，能标识本次项目或本次方案方向
如主题中包含 /、\、: 等不适合作为目录名的字符，应先替换或删除
如果同一天同主题已存在目录，可在末尾追加 -02、-03 以区分

示例：

archive/2026-03-18-智能体调度专利挖掘/
archive/2026-03-18-代码记忆系统交底书/

步骤 4：项目边界与依赖画像

这一阶段不是读某个函数，而是先看整个项目的技术边界。至少要识别：

当前仓库哪些目录是自研代码
是否存在 monorepo/workspace、私有共享包、git submodule
哪些能力来自第三方库、云服务、模型 API、向量库、中间件
真正的创新是在“库本身”，还是在“本项目对库的组织、调用、调度、回退、注入、缓存、鉴权方式”

原则： 第三方库本身的内部机制不能直接写成申请人的技术方案；但如果创新在于本项目如何组合和使用这些能力，则该组合机制可以成为重点申请对象。

步骤 5：代码仓库盘点

先建立项目级理解，不要一上来就写交底书。至少要回答：

项目是单体应用、微服务、SDK、Agent 系统还是算法仓库
入口文件、核心服务、数据层、调度层、模型层、接口层分别在哪里
哪些模块直接对应候选技术方案
哪些配置、缓存、向量库、消息队列、权限控制、编排机制与技术方案相关

建议先输出：

《项目边界与依赖画像》
《项目代码技术盘点》

步骤 6：候选方案映射

如果用户已给出候选专利方案，则对每个方案分别建立映射：

方案名称
目标技术问题
对应模块/目录/文件
关键类、函数、接口、任务流
直接证据与间接证据
仍需研发确认的问题

原则：一个候选方案对应一份独立映射，不要把多个发明点混在一份交底书里。

步骤 7：代码证据提取

从代码或文档中提取以下内容：

核心处理流程
模块之间的调用关系
关键数据结构与状态流转
输入、输出、约束条件
与现有技术差异最大的机制
可支持有益效果的实现依据

步骤 8：专利语言抽象

将工程实现转换为专利语言时，应遵循：

不直接照抄函数名、变量名、表名
保留真正有创造性的处理机制
区分“技术问题”“技术方案”“技术效果”
将局部代码细节上升为方法步骤、系统模块、装置单元或存储介质表述

步骤 9：技术交底书生成

交底书需要服务于“公司技术人员 + 外部专利代理师”的协作，因此除了标准章节，还应显式标注：

哪些内容已在代码中直接实现
哪些内容是结合多处实现归纳出来的
哪些内容目前代码中未体现，需要研发确认
哪些内容可作为替代实施例或优选实施例
当前采用的是哪一份交底书模板（客户模板 / 内置交底书模板）

步骤 10：生成《权利要求布局卡》

如果用户要求继续推进到申请文件层，则必须先输出《权利要求布局卡》，并参照 templates/invention-patent-claim-layout-template.md。

布局卡至少应包含：

方案名称、技术问题、核心发明构思
A/B/C 级技术特征清单
主口径建议
方法、系统 / 装置、计算机可读存储介质、计算机程序产品四类平行保护主题的独立权利要求骨架
从属权利要求分层挂接建议：
- 核心增强特征
- 优选参数 / 条件
- 缓存 / 回退 / 鉴权 / 调度 / 异常处理细节
风险提示与待确认问题

默认规则：

默认同时准备“方法 + 系统 / 装置 + 计算机可读存储介质 + 计算机程序产品”四类平行布局口径，供代理师择优整合
独立权利要求骨架只能吸收 A 级证据对应的必要技术特征
B 级证据默认优先写入从属权利要求或优选实施例，并标注“基于实现归纳”
C 级证据只能写入待确认事项或替代实施例，不能写成既有实现

步骤 11：生成《权利要求-代码证据矩阵》

在布局卡完成后，应继续输出《权利要求-代码证据矩阵》，并参照 templates/invention-patent-claim-evidence-matrix-template.md。

矩阵至少要回答：

每项拟写入权利要求的技术特征对应哪些代码模块、调用链、配置项或数据流
该特征证据等级是什么（A / B / C）
该特征宜进入主独立权利要求、平行保护主题、从属权利要求还是实施例
是否存在第三方依赖归属风险、公开不充分风险或术语不一致风险

步骤 12：生成《发明专利初稿》

只有在布局卡和证据矩阵完成后，才进入完整初稿，并参照 templates/invention-patent-draft-template.md 与 references/patent-drafting-spec.md：

说明书部分：发明名称、技术领域、背景技术、发明内容、附图说明、具体实施方式
权利要求书草稿
说明书摘要
摘要附图建议
请求书待填字段清单

初稿生成时应遵循：

说明书章节顺序、术语口径和摘要要求按《专利审查指南》第二部分第二章“说明书和权利要求书”的写法组织
初稿默认为“接近可申报版”，但仍必须保留“待研发确认 / 待代理师修订”清单
涉及计算机程序的方案，默认允许输出方法权利要求以及产品权利要求草稿；产品权利要求应优先按装置、计算机可读存储介质、计算机程序产品三类保护主题进行布局
不做正式请求书表格自动填写，只做待填字段清单

步骤 13：生成《发明专利初稿自检表》

初稿完成后，应再输出《发明专利初稿自检表》，并参照 templates/invention-patent-draft-self-check-template.md。

自检至少覆盖：

术语是否统一
独立权利要求是否包含必要技术特征
从属权利要求是否形成清晰层级
说明书是否支撑权利要求
摘要是否控制在 300 字内
是否误把第三方固有能力或 C 级特征写成申请人既有实现
是否显式列出待确认项和高风险点

第五部分：代码证据提取规则

代码证据提取仍然遵循 A/B/C 三级证据分级，但详细规则不再在主文档重复展开，统一参见：

references/code-extraction-spec.md

在执行层面，至少要做到：

一个候选方案对应一份独立证据映射
每条技术特征都要回到具体模块、调用链、数据流或配置项
无直接证据的内容不得写成既有实现
无法明确归属的第三方能力不得直接写成申请人的核心创新
A 级证据特征才可进入独立权利要求骨架
B 级证据特征默认进入从属权利要求或说明书优选实施例，并标注来源性质
C 级证据特征只能进入“待确认事项”或“替代实施例”

第六部分：输出层级与交付清单

输出层级

层级	适用场景	主要产物
L1 代码证据映射	用户已有候选专利方案，先判断是否落在代码实现上	方案-代码证据映射表
L2 技术交底书	当前最推荐主产物	标准技术交底书
L2.5 权利要求布局	用户希望进一步推进到申请文件层，但需要先稳住 claim tree	权利要求布局卡 + 权利要求-代码证据矩阵
L3 发明专利初稿	用户希望进一步推进代理撰写前的初稿	布局卡 + 证据矩阵 + 说明书初稿 + 权利要求草稿 + 摘要 + 自检表
L4 可专利方案挖掘	用户尚未总结候选方案，或希望额外寻找新申请点	候选技术方案清单 + 优先级建议

归档要求

无论是候选方案清单、技术交底书还是发明专利初稿，都应自包含地保存在本 skill 内部的 archive/ 目录中，便于按项目和日期回溯。

默认原则：

一次任务对应一个归档目录
同一归档目录下同时保存输入摘要、中间分析和最终产物
目录名优先体现日期和主题，保证不同项目可以直观看出差异

第七部分：参考模板与规范

当前目录按职责分成两组：

`templates/`

`references/`

其中：

templates/ 用于最终交付或中间交付的模板
references/ 用于项目分析、代码抽取和起草执行规范

第八部分：与研发和代理师的协作要点

面向研发人员

需要特别追问或确认：

该方案对应的最小实现闭环是什么
是否已有线上或测试环境运行
有哪些参数、阈值、策略是关键创新点
哪些内容只是设想，尚未进入代码
是否存在可替换实现或优选实现

面向专利代理师

建议在交付时同步提供：

候选方案清单
项目边界与依赖画像
代码证据映射表
技术交底书
权利要求布局卡
权利要求-代码证据矩阵
发明专利初稿自检表
待确认问题清单

这样可以减少“代理师只看到概念、不知道代码里真正做了什么”的沟通损耗。

第九部分：注意事项

证据优先：不要把没有代码依据的设想写成既有实现
一个发明点一份交底书：避免把多个创造性方案混写
保密意识：专利申请前需注意保密，避免过早公开技术方案
新颖性与创造性：交底书只是内部材料，不等于一定具备授权前景，必要时应先做专利检索
充分公开：技术交底书应足以让代理师和技术人员继续展开撰写与补充
两步写作默认开启：只要目标是初稿，默认先出“权利要求布局卡 + 证据矩阵”，再出完整初稿
专业审查：权利要求和正式申请文本仍需专利代理师审核
效果克制：没有实验数据或线上指标支持的效果，不要随意量化夸大
软件专利默认发明专利：算法、流程、调度、记忆、鉴权、编排等方案，默认按发明专利组织材料
先分清自研与外部依赖：不要把第三方库、模型平台或中间件的固有能力误写为申请人的创新点
优先贴合客户模板：若用户提供了 Word 版交底书模板，应优先按其章节组织输出；如无客户模板，则选用内置交底书模板或初稿模板
摘要限制：说明书摘要默认控制在 300 字内，且不使用商业性宣传语言
请求书仅做字段清单：首版只列待填字段，不自动生成正式官表
计算机程序相关方案默认并行准备多种保护主题：默认准备方法、系统 / 装置、计算机可读存储介质、计算机程序产品等保护主题草稿，但最终提交策略由代理师结合单一性和审查策略决定

输入/输出

输入

必需：代码文件/项目目录、技术描述、创新点说明、候选专利方案（至少具备其中两类，最好同时具备代码和候选方案）
可选：技术领域、应用场景、附图偏好、输出层级偏好、目标法域、申请主体信息、发明人候选、优先权信息、客户模板

输出

方案代码证据映射表
专利技术交底书
权利要求布局卡
权利要求-代码证据矩阵
可专利方案清单（可选）
发明专利初稿（可选）
发明专利初稿自检表（可选）
研发补充问题清单（可选）

code2patent