Code2patent

---
name: code2patent
homepage: https://github.com/cat-xierluo/legal-skills
author: 杨卫薪律师（微信ywxlaw）
version: "1.6.0"
license: CC-BY-NC
description: 从已开发代码项目中提取技术实现证据，围绕候选专利方案生成算法/软件类说明书式技术交底书，并以“权利要求布局卡 → 发明专利初稿”两步法继续生成接近可申报版的中国发明专利起草材料。触发场景包括：读取代码仓库后撰写技术交底书、将人工总结的专利方案映射到具体实现、从代码中挖掘可专利技术方案、为专利代理师准备权利要求布局和发明专利初稿。
---

# 代码仓库转专利交付

## 定位

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

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

推荐主链路：

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

## 启动闸门

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

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

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

## 输入成熟度分流

| 等级 | 输入状态 | 默认动作 |
|------|----------|----------|
| T0 名称清单 | 只有专利名称、标题或一句话方向 | 输出《专利名称反向澄清卡》，等待用户确认 |
| T1 方向清单 | 有名称和业务方向，但缺少技术问题、实现路径或效果 | 先补齐候选解释、代码证据方向和待确认问题 |
| T2 技术方案清单 | 已有技术问题、核心实现、目标效果和初步模块范围 | 进入定向检索，生成代码证据映射和交底书 |
| T3 证据型方案清单 | 已有技术方案、代码路径、关键流程和证据等级 | 复核证据后继续生成交底书、布局卡或初稿 |
| 无清单 | 用户希望从代码中挖掘专利点 | 先输出候选可专利方案清单，人工筛选后再起草 |

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

## 材料优先级

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

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

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

## 必读规范

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

| 需要处理的问题 | 读取文件 |
|----------------|----------|
| 算法/软件类交底书结构、S1...Sn、代码证据后置规则、公式与符号体例 | `references/algorithm-software-disclosure-format.md` |
| 项目技术方案画像、依赖边界、自研与第三方能力区分 | `references/project-analysis-spec.md` |
| S/F/E 抽取、A/B/C 分级、从代码到专利表达的转译 | `references/code-extraction-spec.md` |
| 快速进入布局卡、初稿和自检写作 | `references/patent-drafting-quick-reference.md` |
| 需要完整起草依据、权利要求层级和摘要规则 | `references/patent-drafting-spec.md` |

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

## 模板路由

| 目标产物 | 模板 |
|----------|------|
| 专利名称反向澄清卡 | `templates/patent-title-clarification-card-template.md` |
| 算法/软件类发明专利技术交底书 | `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` |

`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 重新挖掘。

## 输出层级

| 层级 | 适用场景 | 主要产物 |
|------|----------|----------|
| L0 名称反向澄清 | 用户仅提供专利名称、标题或一句话方向 | 专利名称反向澄清卡 + 人工确认记录 |
| L1 代码证据映射 | 已有候选方案，需判断是否落在代码实现上 | 方案-代码证据映射表 |
| L2 技术交底书 | 当前最推荐主产物 | 算法/软件类说明书式技术交底书 + 必要证据附录 |
| L2.5 权利要求布局 | 需要推进到申请文件层但先稳住 claim tree | 权利要求布局卡 + 权利要求-证据矩阵 |
| L3 发明专利初稿 | 需要代理撰写前的完整初稿 | 说明书初稿 + 权利要求草稿 + 摘要 + 自检表 |
| L4 可专利方案挖掘 | 用户尚未总结候选方案 | 候选方案清单 + 优先级建议 + 人工筛选记录 |

## 标准执行顺序

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

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

## 推荐交付文件

```text
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、需求说明、会议纪要、技术领域、应用场景、附图偏好、输出层级、申请主体信息、发明人候选、优先权信息、客户模板。

### 输出

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