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：输入解析

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

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 新方案对比。

阶段 3：创新点识别

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

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

向用户确认创新点范围（一次提问，多选）：

• 列出识别出的所有创新点
• 标注推荐的核心创新
• 让用户选择专利文档的覆盖范围

阶段 4：专利文档生成

文档结构（严格遵循）：

# <专利名称>

## 发明人
（待填写）

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

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

## 具体实施例
### 代码说明
#### 步骤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

文件结构：

# 专利上下文信息

## 基本信息
- **专利名称**：{专利名称}
- **创建日期**：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 文档：

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. 如存在差异，记录差异并在回复中说明

代码一致性验证：

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

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

步骤 3：撰写回复文档

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

回复原则：

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

回复文档结构：

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

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

---

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

### 审查意见

> {审查员原话}

### 回复

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

---

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

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

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

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

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

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

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

编写要求：

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

自带文件

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

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