# Patent

> Use when writing patent documents from code — comparing old/new code to identify innovations, generating complete patent documents (Markdown + Word). Also handles patent review replies (审查意见回复). Trigger on keywords like "patent", "专利", "写专利", "专利文档", "审查意见", "受理".

- Skill: `jeandoom/patent` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add jeandoom/patent`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jeandoom/patent/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: Jeandoom (https://skillmd.com/u/jeandoom)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/jeandoom/patent

---


# Patent Document Generator

对比代码差异 → 识别创新点 → 生成完整专利文档（Markdown + Word）。
处理审查意见 → 验证专利与代码一致性 → 生成精简回复文档。

## 触发条件

用户提到以下任一关键词时使用本 skill：
- "专利", "写专利", "专利文档", "patent"
- "创新点", "专利申请", "分析项目", "找创新点", "发现创新", "分析"
- "审查意见", "受理", "回复审查"
- "筛选创新点", "推荐专利候选", "创新管理"
- 对比代码差异并要求生成技术文档

---

## 执行流程

### 阶段 0A：创新发现

**触发条件**：用户说"分析 xxx 项目"、"找创新点"、"发现创新"、"分析项目"等。

**流程**：

1. **确认目标项目**：从 `projects/` 下选择，或用户指定路径
2. **获取 commit 历史**：读取目标项目最近 2 周的 commit（`git log --since="2 weeks ago" --oneline`）
3. **读取核心源码**：基于 commit 涉及的文件，使用 Glob + Read 读取完整内容
4. **识别技术创新点**，按以下标准评估：
   - `innovation_level`: `core`（架构级变化）/ `supporting`（配套方案）/ `incremental`（实现细节）
   - `patent_value`: `high` / `medium` / `low`
5. **获取代码参与人**：对关键文件运行 `git blame --line-porcelain`，提取作者信息
6. **生成创新点文件**：为每个创新点创建 `innovations/{项目名}/{slug}.md`
   - frontmatter 记录元数据（name, title, project, source_commit, status, innovation_level, patent_value, blame_participants, related_files, patent_doc）
   - 正文包含：背景与问题、创新描述、核心代码片段、与其他创新点的关系
7. **更新项目索引**：创建或更新 `innovations/{项目名}/_index.md`（记录项目信息、最近分析 commit、创新点总数）
8. **更新流水线**：在 `records/_pipeline.md` 的"待筛选"区域追加新发现的创新点
9. **向用户展示**：列出所有发现的创新点及其价值评估，让用户确认

### 阶段 0B：创新筛选

**触发条件**：用户说"筛选创新点"、"推荐专利候选"、"创新管理"等。

**流程**：

1. 读取 `innovations/` 下所有创新点文件的 frontmatter
2. 按 `patent_value`（high > medium > low）和 `innovation_level`（core > supporting > incremental）排序
3. 展示推荐列表，标注 `high+core` 的创新点为"推荐专利候选"
4. 用户选择后，将选中创新点的 `status` 更新为 `shortlisted`
5. 更新 `records/_pipeline.md`：将选中项从"待筛选"移至"已入围"

---

### 阶段 1：输入解析

确认用户提供的输入类型：

```dot
digraph input_type {
  "用户输入" [shape=box];
  "两种代码目录？" [shape=diamond];
  "Git对比？" [shape=diamond];
  "新功能代码？" [shape=diamond];
  "双目录对比" [shape=box];
  "Git diff对比" [shape=box];
  "单组代码分析" [shape=box];

  "用户输入" -> "两种代码目录？";
  "两种代码目录？" -> "双目录对比" [label="是"];
  "两种代码目录？" -> "Git对比？";
  "Git对比？" -> "Git diff对比" [label="是"];
  "Git对比？" -> "新功能代码？";
  "新功能代码？" -> "单组代码分析" [label="是"];
}
```

**三种输入场景**：
1. **双目录对比**：用户指定 `old_dir` + `new_dir`（如 `@app/graphs/smart_filler/` vs `@app/graphs/smart_filler_v2/`）
2. **Git 对比**：用户指定 git ref（分支/commit）+ 可选文件范围（如 `patent` 分支 vs `master` 分支）
3. **新功能**：用户指定单组文件/目录，无旧代码对比

**同时确认**：
- 参考专利目录（如已有专利文档，保持术语和风格一致）
- Word 模板路径（默认使用本 skill 自带的 `模板/` 目录下第一个 `.docx` 文件）
- 专利文档格式规范见本 skill 自带的 `专利文档格式.md`
- **如果用户选择了 shortlisted 创新点**：自动从 `innovations/` 读取关联文件和代码作为输入

### 阶段 2：代码阅读与对比

**读取规则**：
1. 使用 Glob 列出目录下所有源码文件（排除 `__init__.py`、`*.pyc`）
2. 使用 Read 读取每个文件的完整内容
3. 对比场景：同时读取新旧两组代码

**结构化提取维度**（逐文件分析）：

| 维度 | 分析内容 |
|------|---------|
| **架构模式** | 状态机 vs Agent 循环 vs 管道，节点/工具定义方式 |
| **流程控制** | 确定性路由 vs LLM 驱动规划，条件判断逻辑 |
| **状态管理** | 字段数量、Reducer 策略、合并机制 |
| **数据处理** | 字段配置、拆分/合并、验证流程 |
| **错误处理** | 错误码、重试机制、回退策略 |
| **扩展性** | 新增功能的代码改动量，配置 vs 硬编码 |

**输出**：生成差异分析矩阵（表格形式），包含每个维度的旧方案 vs 新方案对比。

### 阶段 3：创新点识别

从差异矩阵中识别技术创新点，按以下标准评估：

```
创新点评估框架：
├── 核心创新（1-2个）
│   ├── 架构级变化（非简单重构）
│   ├── 解决了旧方案的固有缺陷
│   └── 可独立申请专利
├── 支撑机制（2-4个）
│   ├── 支撑核心创新的配套技术方案
│   └── 可作为从属权利要求
└── 实现细节（可选）
    ├── 具体的数据结构/算法优化
    └── 用于丰富实施例
```

**向用户确认创新点范围**（一次提问，多选）：
- 列出识别出的所有创新点
- 标注推荐的核心创新
- 让用户选择专利文档的覆盖范围

### 阶段 4：专利文档生成

**文档结构**（严格遵循）：

```markdown
# <专利名称>

## 发明人
（待填写）

## 背景技术方案及缺陷
### 现有方案
### 主要缺陷

## 本发明解决的技术问题
### 主要目的
### 基本构思

## 具体实施例
### 代码说明
#### 步骤1：...
#### 步骤N：...
### 实例说明

## 本发明取得的有益效果
### 主要优点

## 附图说明
```

**写作规则**：

1. **背景技术**：描述 2-3 种现有方案（含老版本方案），每种方案 3-5 句。缺陷必须是对应本发明能解决的。
2. **基本构思**：先用 1 段话概述核心创新，再用"为支撑上述核心机制"引出配套方案。每个技术要点用 `**加粗**` 标注名称。
3. **代码说明**：每个步骤包含"说明段落 + 代码片段"。代码直接引用源码文件中的实际实现，不编造伪代码。说明段落必须解释该步骤的设计意图和与旧方案的差异。
4. **实例说明**：用具体场景（如"差旅预申请"）展示完整的用户-系统交互流程，包含每轮对话的系统后台处理逻辑和最终回复。
5. **有益效果**：每个优点包含"与旧方案的对比"和"量化或定性提升描述"。
6. **附图说明**：使用 PlantUML 描述，选择 2-3 张最具表现力的图（架构图、流程图优先）。PlantUML 中所有文字使用中文。

### 阶段 5：保存专利上下文文件

在专利文档同一目录下创建 `context.md` 文件，记录专利相关的代码上下文信息，用于后续审查回复时快速定位和分析。

**输出路径**：`patents/{yyyy-MM}/{专利名}/`，其中 `yyyy-MM` 取当前年月（如 `2026-06`）。

**文件命名**：`context.md`

**文件结构**：

```markdown
# 专利上下文信息

## 基本信息
- **专利名称**：{专利名称}
- **创建日期**：YYYY-MM-DD
- **专利文档**：{专利文档文件名}

## 项目信息
- **项目名称**：{项目名称}
- **项目位置**：{项目根目录绝对路径}

## 代码分支
- **基准分支**：{旧代码分支/commit，如 master, release-202501-1}
- **创新分支**：{新代码分支/commit，如 feature-AI-xxx, patent}

## 专利相关代码路径

以下文件和目录是本专利核心实现，审查回复时优先从此处定位代码：

| 文件路径 | 作用描述 | 对应专利步骤 |
|---------|---------|-------------|
| `app/graphs/ai_audit/audit_graph.py` | 审核工作流主图，包含路由分类器和工具增强节点 | 步骤4、步骤5 |
| `app/graphs/ai_audit/audit_utils.py` | 多模态附件信息提取实现 | 步骤3 |
| `app/graphs/common/middleware.py` | Agent中间件（迭代限制、错误处理） | 步骤4 |
| ... | ... | ... |

## 关键配置
- **模型配置**：{关键模型名称和用途}
- **常量定义**：{关键常量如 MAX_ITERATIONS 等}

## 备注
{其他需要记录的上下文信息，如特殊依赖、环境要求等}
```

**用途**：审查回复时，直接读取 `context.md` 可快速了解：
1. 专利对应的代码分支和版本
2. 核心实现文件的位置
3. 关键配置和常量
4. 无需重新扫描整个项目或询问用户分支信息

**生成后自动更新**：
1. 在 `records/` 下创建 `{专利名}/record.md`（如不存在）
2. 更新 `records/_pipeline.md`：将对应创新点移至"已完成 (patented)"
3. 更新关联的 `innovations/{项目名}/{slug}.md` 的 `patent_doc` 字段和 `status` 为 `patented`

### 阶段 6：Markdown → Word 转换

生成 Markdown 文件后，自动调用转换工具生成 Word 文档：

```bash
python -X utf8 <skill-dir>/tools/md2docx.py <input.md> [-t template.docx] [-o output.docx]
```

其中 `<skill-dir>` 是本 skill 的安装路径（即本 SKILL.md 所在目录）。

**前提**：
- `<skill-dir>/tools/md2docx.py` 脚本已随 skill 一起安装
- `python-docx` 已安装（`pip install python-docx`）
- Word 模板文件在 `<skill-dir>/模板/` 目录下
- Word 模板文件存在

**如果转换失败**：告知用户 Markdown 文件已生成，手动转换命令为上述命令。

---

## 常见错误与注意事项

1. **不要编造代码**：专利文档中的代码必须是源码文件中的实际实现，可原文引用或合理删减，但不编造。
2. **区分现有技术与本发明**：明确标注哪些是"现有方案"（旧代码/通用技术），哪些是"本发明创新"。
3. **不要把所有差异都写成创新**：重构、重命名、性能微调等不属于专利创新点。
4. **实例要完整**：至少展示 2-3 轮对话的完整交互流程，不要只写一轮。
5. **术语一致性**：与参考专利文档保持术语一致（如"Agent"不混用"智能体"）。

---

## 审查意见回复流程

当用户提供审查员/受理员的反馈意见时，执行以下流程生成回复文档。

### 步骤 1：读取上下文与专利文档

1. **读取上下文文件**：优先读取专利目录下的 `context.md`，获取项目信息、分支、代码路径等上下文
2. **读取专利文档**：完整阅读对应的专利 Markdown 文件，理解每个技术要点的描述
3. **定位实际代码**：根据 `context.md` 中记录的代码路径和专利文档引用的文件，读取对应的源码实现
4. **建立映射表**：记录专利文档中每个关键机制在代码中的实际位置和行为

**如果 `context.md` 不存在**：
- 询问用户项目路径和分支信息
- 根据专利文档中引用的文件路径手动定位代码
- 建议在回复完成后补充创建 `context.md`，便于后续审查

### 步骤 2：验证分支与代码一致性

**分支验证**（基于 `context.md` 中的分支信息）：

1. 确认当前代码库中对应分支是否存在：`git branch -r | grep {分支名}`
2. 对比专利分支与代码分支的关键文件是否一致：`git diff {patent分支} {代码分支} -- {关键文件路径}`
3. 如存在差异，记录差异并在回复中说明

**代码一致性验证**：

对审查意见中涉及的每个技术点，验证专利文档描述与代码实现是否一致：

| 检查项 | 检查方法 |
|--------|---------|
| 专利描述的功能是否真的在代码中实现 | 搜索关键词/函数名，Read 对应代码 |
| 专利描述的数据流是否与代码逻辑匹配 | 追踪变量传递路径 |
| 专利中的常量/枚举值是否与代码一致 | 对比具体值 |
| 专利描述的错误处理是否与代码行为一致 | 检查异常分支 |

**如果发现不一致**：先修改专利文档使其与代码一致，再基于修改后的专利文档撰写回复。这是关键原则——回复内容必须与专利文档对齐，审查员以专利文档为准。

### 步骤 3：撰写回复文档

**文件命名**：`回复-{专利名称}-{日期}.md`，保存在专利文档同一目录下。

**回复原则**：

1. **精简**：每个问题只包含"审查意见引用 + 回复内容"，不添加改进方案、建议等额外内容
2. **基于专利**：每条回复必须能在专利文档中找到直接依据，用"参见专利文档步骤X"引用
3. **切中要点**：直接回答审查员的问题，不展开不相关的技术细节
4. **附带实例**：提供 1 个异常状态处理实例，展示系统的自愈能力

**回复文档结构**：

```markdown
# 审查意见回复 — {专利名称}

**回复日期：** YYYY-MM-DD

---

## 问题N：{审查员问题标题}

### 审查意见

> {审查员原话}

### 回复

{基于专利文档的精简回复，引用专利文档步骤编号}

---

## 补充：异常状态处理实例

{1个完整的异常场景，展示系统如何处理异常并自愈}
```

### 步骤 4：审查员常见关注点清单

以下是审查员通常关注的技术维度，撰写回复时主动覆盖：

| 关注维度 | 典型问题 | 回复要点 |
|---------|---------|---------|
| **循环/终止** | 循环次数上限、死循环风险 | 列出所有终止机制（计数器、框架限制、终止路径） |
| **LLM输出约束** | LLM输出与系统规则冲突时以谁为准 | 说明枚举校验、默认回退、系统兜底机制 |
| **动态性** | 静态配置能否应对动态变化 | 说明动态获取机制和会话内稳定性 |
| **错误纠错** | 关键节点输入错误时的纠错机制 | 说明校验→回退→循环自愈的多层保障 |
| **状态合并** | Reducer/合并策略的具体行为 | 列出完整合并规则表（替换/追加/删除）及设计理由 |
| **参数安全** | LLM能否覆盖系统注入的参数 | 说明参数分类（Schema声明 vs 运行时注入）和校验拦截 |

### 步骤 5：异常实例编写规则

异常实例需展示系统的多层自愈能力，典型场景链：

```
用户模糊输入 → LLM输出格式异常 → 校验拦截+自动回退
→ 工具执行返回业务错误 → 错误状态自动合并
→ 后续循环感知错误 → 调整决策 → 回复用户
```

**编写要求**：
- 展示至少 2 种不同类型的异常（如校验失败 + 业务错误）
- 每个步骤标注对应的专利文档机制名称
- 最终展示系统如何自愈并给出合理的用户回复
- 实例中的具体值（如枚举值、错误码）必须与代码实现一致

---

## 自带文件

本 skill 目录包含以下文件，安装后即可直接使用：

| 文件 | 用途 |
|---|---|
| `tools/md2docx.py` | Markdown → Word 转换脚本 |
| `模板/*.docx` | Word 文档模板（用于生成规范的专利文档） |
| `专利文档格式.md` | 专利文档格式规范参考 |

使用前请确保已安装依赖：`pip install python-docx`