Patent Writer

Patent Writer — 中国发明专利技术交底书撰写

适用范围

本 skill 不绑定任何特定公司或团队，可用于任何中国发明专利技术交底书的撰写。建议在使用前根据自己团队情况，把以下两个外部依赖填好：

• 本团队已有专利清单（可选）：用于 Step 3 去重，避免重复申请。形式不限——可以是本地 Markdown、内部 wiki、Notion 数据库、Google Doc 等。在 Step 3C 把它的读取方式告诉 Claude 即可（例如 cat ~/path/to/team-patents.md）。
• 本公司专利提交系统（可选）：用于 Step 7 生成"提案系统填写参考"时贴合贵司表单字段。把贵司提案系统的字段名（提案名称 / 关键词 / 核心创新点 / 技术领域 / 发明人比例 / 产出地等）告诉 Claude，它会按字段输出。

检索工具配置

> Token 不写死在本文件中。每位用户第一次使用前，请按 USAGE.md 注册自己的 token 并写入 ~/.config/patent-writer/secrets.env，本 skill 在 Step 3 检索前会自动加载。

Token 加载逻辑：

import os
from pathlib import Path

def load_secrets():
    env_path = Path.home() / '.config/patent-writer/secrets.env'
    if env_path.exists():
        for line in env_path.read_text().splitlines():
            line = line.strip()
            if line and not line.startswith('#') and '=' in line:
                k, v = line.split('=', 1)
                os.environ.setdefault(k.strip(), v.strip().strip('"').strip("'"))

load_secrets()
DEEPXIV_TOKEN = os.environ.get('DEEPXIV_TOKEN', '')
SERPAPI_KEY   = os.environ.get('SERPAPI_KEY', '')

assert DEEPXIV_TOKEN and SERPAPI_KEY, \
    '请先在 ~/.config/patent-writer/secrets.env 配置 DEEPXIV_TOKEN 与 SERPAPI_KEY，参考 USAGE.md'

• 论文（deepxiv_sdk）：注册地址 https://data.rag.ac.cn/register

``python from deepxiv_sdk import Reader reader = Reader(token=DEEPXIV_TOKEN) ``

• 专利（SerpAPI Google Patents）：注册地址 https://serpapi.com/users/sign_up（每月 250 次免费额度）
• 直接 urllib.request.urlopen(url, timeout=20)
• 参数 num 必须 ≥10
• 中文检索加 country=CN，国际加 country=WO/US
• 回退方案：若上述工具均失败，可手动用商用专利数据库（如 PatSnap / 智慧芽 / Google Patents 网页版）补充检索后，把关键发现告诉 Claude

工作目录与中间产物（断点续跑必备）

每个专利都建立独立工作区，所有中间产物以 JSON/Markdown 落盘，便于回退、审查、跨会话续接：

~/Desktop/zhuanli//
├── 技术交底书-.docx        # 最终产物
├── 提案填写参考.txt                  # 最终产物
└── .workspace/                       # 中间产物（团队成员接手时直接读取）
    ├── 01_idea.md                    # Step 1 整理后的 idea 摘要
    ├── 02_triplet_v1.json            # Step 2 初步三要素（强 Schema）
    ├── 03_research/
    │   ├── papers.json               # deepxiv 检索结果
    │   ├── patents.json              # SerpAPI 检索结果
    │   └── team_patents.json         # 本团队已有专利去重结果（可选）
    ├── 03_triplet_v2.json            # Step 3.5 修正后的三要素
    ├── 03_patentability.json         # Step 3.8 可专利性判断
    ├── 04_outline.json               # Step 4 大纲与权利要求框架
    ├── 04_title_candidates.json      # Step 4 发明名称 3 选 1
    ├── 05_content.json               # Step 5 各章节合并后的 content（即 generate_docx.py 入参）
    ├── 06_review_score.json          # Step 6 打分明细与扣分项
    └── 06_iter_log.md                # 每轮回退/重试的失败原因日志

回退时只重写对应文件，其他文件不动——例如 Step 6 打分发现"技术方案缺参数"，只回到 Step 5 ③重写实施方式部分并更新 05_content.json，不必重新跑 Step 1-4。

接手原则：第一件事是 cat .workspace/06_iter_log.md 看历史决策，再 cat .workspace/03_triplet_v2.json 看当前确定的三要素，避免推翻已经评审过的内容。

---

历史驳回规律（核心避坑）

| 类型 | 特征 | 驳回依据 | |------|------|----------| | ❌ 商业方法 | 纯运营策略、用户激励、业务流程，无技术手段 | 专利法第2条第2款 | | ❌ 纯算法改进 | 实质是数学模型优化，不解决特定技术问题，效果是算法本身改进 | 专利法第2条第2款+第22条 | | ✅ 可专利 | 具体技术手段 + 特定技术领域的技术问题 + 技术效果（非通用算法改进） | — |

---

完整工作流程

Step 1：整理 Idea

收集用户提供的所有输入：

• 文字描述的 idea
• 代码目录（读取关键文件理解实现，不在交底书中引用代码）
• 内部 wiki / 设计文档（如果用户提供 URL，可用相应工具读取）
• 其他背景材料

输出一段结构化摘要：

【技术背景】：当前系统/场景是什么
【核心做法】：这个 idea 的主要技术动作
【初步区别点】：与通常做法有何不同（此时只是猜测，Step 3后会修正）

如果用户没有提供 idea，基于代码目录或团队已知方向，提供 3-5 个可申请专利的方向建议供用户选择，再进入 Step 2。

---

Step 2：初步三要素分析 + 技术化翻译

提炼三要素草稿，同时将业务语言翻译为技术语言（这是 AI/算法类专利的核心难点）：

三要素框架（PPT三问）： > Q1：现有技术存在什么具体技术问题？ > Q2：本提案采用了什么技术手段？（分步骤） > Q3：实现了什么技术效果？

技术化翻译规则（AI/算法类必须执行）：

| 业务表达（❌错误） | 技术化表达（✅正确） | |-------------------|---------------------| | 提升模型准确率 | 降低低光照场景下视觉缺陷检测的误检率 | | 改进算法效果 | 在工业管道泄漏检测系统中，通过多频段声纹特征融合机制过滤环境噪声干扰 | | 更智能的推荐 | 基于用户运动轨迹的可穿戴设备能耗模式自适应切换方法 | | 优化大模型输出 | 构建分层验证管道，对 LLM 生成的 JSON Patch 指令执行路径守卫+Schema 约束四级串行校验 |

输出格式（强 JSON Schema，落盘到 .workspace/02_triplet_v1.json）：

{
  "technical_problem": "具体技术缺陷的精确描述，非业务问题",
  "technical_solution": "技术手段总览（一句话）",
  "technical_effect": "可量化或可描述的技术改善",
  "core_inventive_concept": "用一句话概括本方案最不可替代的发明构思（这是审查员看的）",
  "key_components": [
    {"name": "组件A精确名称", "function": "组件A在方案中承担的具体功能"},
    {"name": "组件B精确名称", "function": "组件B在方案中承担的具体功能"}
  ],
  "method_steps": [
    {"id": "S1", "name": "步骤一精确名称", "description": "步骤一在做什么", "is_key": true},
    {"id": "S2", "name": "步骤二精确名称", "description": "步骤二在做什么", "is_key": false}
  ]
}

为什么必须用 JSON Schema 而非自由文本：key_components 和 method_steps 里的 name 字段是全文术语锚点——Step 4 的权利要求、Step 5 的实施方式、Step 6 的术语一致性校验都引用这同一份字段。这能根治"独权写'拦截器'、实施方式写'代理层'"这种术语漂移（专利工程师退稿的最高频原因之一）。

展示 JSON 给用户确认（特别是 key_components 的命名），确认后写入 .workspace/02_triplet_v1.json，进入 Step 3。

---

Step 3：检索现有技术

3A. 论文检索（deepxiv_sdk）：

pip install deepxiv-sdk -q 2>/dev/null

from deepxiv_sdk import Reader
reader = Reader(token=DEEPXIV_TOKEN)  # 已由本节顶部 load_secrets() 加载
results = reader.search(
    query="",
    size=5,
    source="arxiv",
    categories=["cs.DB", "cs.AI", "cs.IR"]
)
# 对每篇相关论文获取摘要
for r in results['result']:
    brief = reader.brief(r['arxiv_id'])

3B. 专利检索（优先 MCP，回退 SerpAPI）：

> 检索声明（写入提示词，避免抄袭）：本 step 检索现有专利仅用于学习写作风格、了解术语习惯、识别真正的差异点——严禁将检索到的权利要求文本、技术方案描述直接复制到本发明的交底书中。每次检索后，必须明确写出"本方案与检索到的方案 X 的差异点是 Y"。

优先方式：MCP 工具（如果已配置 mcp__google-patents-mcp 或 mcp__exa）：

• 调用方式由 runtime 决定，免去手填 SerpAPI Key
• 失败时回退到下方 SerpAPI 方式

回退方式：SerpAPI Google Patents（urllib 直调）：

import urllib.request, urllib.parse, json

# SERPAPI_KEY 已由本节顶部 load_secrets() 加载

def search_patents(query, num=10, country=''):
    params = {'engine': 'google_patents', 'q': query, 'api_key': SERPAPI_KEY, 'num': num}
    if country:
        params['country'] = country
    url = f'https://serpapi.com/search?{urllib.parse.urlencode(params)}'
    req = urllib.request.Request(url, headers={'User-Agent': 'Mozilla/5.0'})
    with urllib.request.urlopen(req, timeout=25) as resp:
        return json.loads(resp.read())

# 至少检索 4 组关键词：英文核心 + 中文核心 + 同义词扩展 + 上下位概念
# 中文关键词加 country='CN'，英文加 country='WO' 或 'US'

检索策略要求：

• 至少 4 组不同关键词（中英文各 2 组），每组返回 10 条
• 重点提取：publication_number、title、snippet 三字段
• 对最相关的 3-5 篇做差异点对比（不能只列标题）

回退方案：若 SerpAPI 不可用，可使用商用专利数据库（PatSnap / 智慧芽 / Google Patents 网页版）手动检索后告诉 Claude 关键发现。

3C. 读取本团队已有专利（可选，避免重复）：

如果你团队维护了已有专利清单（任意形式：本地文件、内部 wiki、Notion、Google Doc 等），把读取方式告诉 Claude，例如：

cat ~/path/to/team-patents.md
# 或
# 

提取已有专利的名称和核心创新点，与当前 idea 比对去重。如果没有清单可读，跳过此步即可。

输出：

• 相关论文列表（标题+摘要+与本方案的差异）
• 相关专利列表（名称+摘要+区别点）
• 团队已有专利中是否有重叠（若提供）

---

Step 3.5：修正三要素

基于检索结果，更新 Step 2 的三要素：

• 技术问题：结合检索到的现有方案，明确"现有方案做到了X，但在Y场景下仍存在Z缺陷"
• 区别点：从检索结果中找出本方案真正的差异特征
• 技术效果：对照已有方案，量化或具体化效果

---

Step 3.8：可专利性判断

基于修正后的三要素 + 检索结果，综合判断：

判断矩阵：

| 判断项 | 标准 | 通过/不通过 | |--------|------|-------------| | 保护客体 | 非商业方法、非纯算法数学改进 | — | | 技术性 | 有具体技术手段，与特定技术系统绑定 | — | | 新颖性 | 与检索专利/论文相比有实质区别特征 | — | | 创造性 | 区别点非本领域显而易见的适应性调整 | — |

结论三选一：

• ✅ 可申请 → 继续 Step 4
• ⚠️ 风险较高（60-80分） → 说明具体风险点 + 给出调整方向，询问用户是否继续
• ❌ 建议不申请 → 说明具体原因（商业方法/纯算法改进/与现有专利高度重合），直接终止，建议作为商业秘密保护

---

Step 4：生成发明名称 + 大纲 + 权利要求框架

4.0 发明名称 3 选 1（先做）

基于 Step 3.5 修正后的三要素，生成 3 个候选发明名称让用户挑选：

命名规则（这些是审查指南明确禁止/不推荐的写法）：

• ❌ 含 "智能/优化/改进/创新" 等空洞修饰词
• ❌ 含产品型号、品牌名（如某操作系统/某品牌型号）
• ❌ 含 "基于人工智能的..."（太宽泛，等于没写）
• ❌ 长度超过 25 个汉字
• ✅ 推荐句式：一种的，如 "一种基于多视角图像融合的电池表面缺陷检测方法"
• ✅ 包含本方案最不可替代的发明构思（可从 Step 2 的 core_inventive_concept 字段提取）

输出 3 个候选 + 各自的取舍说明，让用户挑一个，落盘到 .workspace/04_title_candidates.json。

4.1 权利要求框架

先写权利要求框架（权利要求决定保护范围，说明书为权利要求服务）：

两段式权利要求格式（中国专利标准格式）

每条权利要求由前序部分（已知技术领域+共性特征）+ "其特征在于" + 特征部分（本发明的区别技术特征）组成。

权利要求 1（独立权利要求 - 方法类）：
  一种[发明名称]，应用于[特定技术领域/系统]，其特征在于，包括：
  S1：[第一个核心步骤，含必要参数]；
  S2：[第二个核心步骤]；
  S3：[第三个核心步骤]；
  ...
  其中，[关键技术特征的进一步限定]。

权利要求 2-N（从属权利要求，逐层细化）：
  根据权利要求 1 所述的方法，其特征在于，[在权利要求1基础上的进一步限定]。

权利要求 N+1（独立权利要求 - 系统/装置类）：
  一种[发明名称]系统，其特征在于，包括：
  [模块1]，用于...；
  [模块2]，用于...；
  ...

权利要求 N+2（独立权利要求 - 计算机可读存储介质，软件类必加）：
  一种计算机可读存储介质，其上存储有计算机程序，其特征在于，
  所述计算机程序被处理器执行时实现权利要求1-N任一项所述的方法。

权利要求 N+3（电子设备，软件类建议加）：
  一种电子设备，包括存储器和处理器，其特征在于，[...]。

权利要求 Few-Shot 正例（严格按此句式与标点）

> 1. 一种数据处理方法，其特征在于，包括： > 获取待处理数据； > 根据所述待处理数据的类型，确定目标处理模型； > 调用所述目标处理模型对所述待处理数据进行处理，得到处理结果。 > > 2. 根据权利要求 1 所述的方法，其特征在于，所述根据所述待处理数据的类型，确定目标处理模型，包括： > 提取所述待处理数据的统计特征； > 将所述统计特征输入预训练的分类模型，得到所述目标处理模型的标识。 > > 3. 根据权利要求 1 或 2 所述的方法，其特征在于，所述目标处理模型为基于 Transformer 架构的神经网络模型，所述 Transformer 架构包括 N 层编码器和 N 层解码器，N 为大于等于 1 的整数。 > > 4. 一种数据处理装置，其特征在于，包括： > 获取模块，用于获取待处理数据； > 确定模块，用于根据所述待处理数据的类型，确定目标处理模型； > 处理模块，用于调用所述目标处理模型对所述待处理数据进行处理，得到处理结果。

关键句式约束（中文专利权利要求的硬性规则）：

• 第一次出现的对象用 "一种 / 一个"，再次提及统一改为 "所述"（绝不能用 "该/此/这个"）
• 步骤之间用 "；" 分隔，最后一步用 "。"
• 从属权利要求开头必须是 "根据权利要求 N 所述的方法/系统/装置"，不能省略
• 引用上层时可以并列引用："根据权利要求 1 或 2 所述..."、"根据权利要求 1 至 5 中任一项所述..."
• 系统/装置类的模块描述统一用 "XX 模块，用于 ...；" 句式

权利要求质量要求

• 独立权利要求 1：保护范围最宽——只写"必不可少"的核心技术特征，不要把可选的细节写进去。判断标准：去掉任一特征后方案仍能实现 → 该特征不应进独权
• 从属权利要求 5-7 条：从不同维度细化（如：参数范围、变体场景、可选模块、性能优化），每条单点限定，作为退守阵地
• 不同类型独权之间：方法权利要求 + 系统/装置权利要求 + 介质权利要求，软件类专利至少包含这三类
• 避免：用功能性限定堆砌（"用于实现 XX 的模块"是空洞的，要写"基于 XX 算法对 YY 进行 ZZ 操作的模块"）

策略说明：权利要求要有层次——独立权利要求写"最宽可守住的范围"，从属权利要求逐层细化作为兜底。若独立权利要求被审查员驳回，从属权利要求可作为退守阵地。

大纲展示给用户确认，确认后进入 Step 5。

---

Step 5：并行撰写各章节 + 流程图

以下章节并行生成（权利要求已在Step4完成框架）：

字数与详细度硬性要求

| 章节 | 字数下限 | 必备元素 | |------|----------|----------| | 背景技术 | ≥ 800 字 | 至少引用 2 篇相关现有方案，明确指出 2-3 个具体技术缺陷 | | 发明内容（含三要素） | ≥ 1500 字 | 技术问题/方案/效果一一对应，方案分步骤+参数 | | 具体实施方式 | ≥ 5000 字 | 至少 1 个详细实施例（推荐 2 个），每步骤含参数阈值 | | 权利要求书 | ≥ 600 字 | 独权×2-3 + 从属×8-12，方法/系统/介质三类齐全 | | 摘要 | ≤ 150 字 | 领域+问题+方案要点+效果 |

说明书全篇总字数下限 ≥ 8000 字（不含权利要求书和摘要）。低于此阈值的交底书在专利工程师那一关大概率被打回。

章节清单：

① 背景技术

• 描述现有技术方案（引用检索到的专利/论文）
• 明确指出 2-3 个具体技术缺陷（与本方案的区别点对应）
• 避免将本方案内容混入背景技术

② 发明内容 三部分：

• 技术问题：本发明要解决的技术问题
• 技术方案：分步骤详细描述（含参数阈值/范围/单位）
• 技术效果：每条严格按"声明 → 关联特征 → 对比现有技术"三段式写：

> 示例（✅ 合格）： > "本方案在 200~400 lux 低光照条件下将电池表面划痕的漏检率降低至 0.5% 以下（声明）， > 这是因为步骤一通过偏振光片对反光进行抑制、步骤三采用多帧时序融合提升弱信号可分性（关联特征）， > 而现有单帧 CNN 检测方案在该光照范围下漏检率普遍高于 8%（对比现有技术）。"

> 反例（❌ 空话，必须改写）： > "本方案显著提升了检测系统的可靠性。" > "本方案让缺陷识别更智能、更精准。" > "本方案达到了更好的用户体验。"

为什么强制三段式：审查员驳回创造性时最常说的话是"未指明效果与技术特征的对应关系"。三段式直接命中创造性论证，强迫每个效果都能挂回到具体的方案步骤上。

AI/模型类专项要求（深度学习/生成式模型方向必须检查）：

• [ ] 训练过程和推理过程分开描述
• [ ] 提供模型架构，说明与通用模型/Transformer 标准架构的区别
• [ ] 训练数据特征：类型、规模、是否需要标注
• [ ] 所有公式中每个参数的含义
• [ ] 算法步骤中的关键参数阈值和范围

③ 具体实施方式（采用 4 步扩写法，单次"写到 5000 字"经常灌水）

把"≥5000 字"分解为 4 个串行动作，每步完成后自报字数，不达标继续扩写：

| 阶段 | 内容动作 | 字数下限 | |------|----------|----------| | 第 1 步 初稿 | 整体方法骨架，按步骤编号 S101/S102/...（与权利要求 S1/S2/... 对应），每步骤一段，含输入/输出/动作 | ≥ 2500 字 | | 第 2 步 段落扩展 | 每个步骤段补：算法细节、数据结构、参数取值范围、异常处理、与现有方案的区别 | 每段 ≥ 800 字，全篇 ≥ 4000 字 | | 第 3 步 多实施例 | 至少 2 个实施例：基础版（核心场景）+ 变体版（扩展场景或特殊优化） | 全篇 ≥ 5500 字 | | 第 4 步 技术深化 | 补伪代码、参数表、性能数据、硬件依赖描述、与训练数据规模相关的具体数字 | 全篇 ≥ 6500 字 |

为什么分 4 步而非一次性堆字数：实测一次性"写到 5000 字"的输出有 30-40% 是空话（"如本领域技术人员所知..."、"在某些实施例中..."等套话）。分阶段每步都有具体动作目标，灌水率显著下降。字数不是目的，"动作完成度"才是——若第 4 步没有任何参数表/伪代码而 5000 字已达标，仍判定为不合格。

与权利要求的术语一致性硬约束：实施方式中的"步骤名称"和"组件名称"必须与 Step 2 的 key_components/method_steps 字段完全一致。例如权利要求 1 写的是"偏振光抑制模块"，实施方式不能换成"反光过滤层"或"图像预处理器"。

④ 权利要求书（细化Step4框架，严格遵循两段式格式）

• 独立权利要求 1（方法类）× 1：前序部分 + "其特征在于" + 步骤化特征部分
• 从属权利要求 × 5-7（逐层细化，每条引用上层权利要求）
• 独立权利要求（系统/装置类）× 1：与方法权利要求一一对应的模块结构
• 从属权利要求 × 2-3
• 独立权利要求（计算机可读存储介质）× 1（软件类必加）
• 独立权利要求（电子设备）× 1（建议加）

校验项：

• 独权 1 的特征是否能去掉任何一项后方案仍能成立？若能 → 该项不应进独权（保护范围太窄）
• 从属权利要求是否每条都"加了一个新限定"而非重复独权内容？
• 系统类独权与方法类独权的步骤是否一一对应？

⑤ 摘要

• 150字以内
• 包含：技术领域 + 技术问题 + 技术方案要点 + 技术效果

⑥ 流程图（Mermaid，自动渲染并嵌入 docx）

generate_docx.py 通过 mermaid.ink 在线 API 自动把 Mermaid 渲染为 PNG 嵌入文档（无需本地安装 mmdc）。为避免渲染失败，Mermaid 代码必须遵守以下禁止事项：

| 禁止 | 原因 | |------|------| | ❌ 节点标签里写 LaTeX 公式（如 $F=ma$） | 渲染器不识别，整张图渲染失败 | | ❌ 使用 style/linkStyle/classDef 自定义样式 | 增加渲染失败概率，且 docx 嵌入不需要美化 | | ❌ 在节点内换行用 \n | 应使用 HTML 标签 ` | | ❌ 节点标签含特殊字符（如 () , : "）但未用双引号包裹 | 解析报错。规则：**所有节点标签都用双引号包裹** | | ❌ 中文节点 ID（如 用户 --> 系统） | 应英文 ID + 中文 label：U["用户"] --> S["系统"] | | ❌ 在 Mermaid 里写 % ` 注释 | 部分版本不支持，删掉即可 | | ❌ 单图节点数 > 30 | 渲染时间长且嵌入 docx 后字号过小不可读，应拆成多张子图 |

推荐句式：

flowchart TD
    A["输入图像"] --> B["预处理模块"]
    B --> C{"光照是否充分?"}
    C -->|是| D["单帧 CNN 检测"]
    C -->|否| E["多帧融合 + 偏振抑制"]
    D --> F["缺陷定位与分类"]
    E --> F
    F --> G["输出检测结果"]

多图建议：除了"总体方法流程图"外，至少再生成 2-4 张细节图——应用场景图、关键步骤时序图、模块结构图、端到端调用链路示例图。这些落入 content JSON 的 extra_diagrams 字段（已在 generate_docx.py 中支持自动渲染并居中嵌入）。

---

Step 6：审查打分

打分表（满分100）：

| 维度 | 分值 | 检查点 | |------|------|--------| | 可专利性 | 20 | 非商业方法；技术手段而非纯数学改进 | | 三要素完整性 | 20 | 问题→方案→效果逻辑链完整、三者一一对应；技术效果按"声明→关联特征→对比"三段式 | | 技术方案详细度 | 20 | 有参数阈值/范围/单位；算法步骤完整；公式参数有含义说明；具体实施方式 ≥ 5000 字且含 ≥2 个实施例与伪代码/参数表 | | 与现有技术区别 | 15 | 区别点明确；背景技术与发明内容不混写；引用了真实检索到的现有方案 | | 权利要求质量 | 10 | 独权保护范围合理（不过宽不过窄）；从属权利要求有层次；用了"所述"句式与"；"分隔 | | 术语一致性 | 5 | 独权模块名、从属权利要求、实施方式、Step 2 key_components 中的命名是否完全一致（无"拦截器/代理层/中间件"漂移） | | AI/模型类专项 | 10 | 训练/推理分开；架构差异说明；参数含义完整 |

阈值：≥ 80分通过，进入Step 7

**回退映射（

调用生成脚本：
```bash
python3 ~/.claude/skills/patent-writer/scripts/generate_docx.py \
  --output "~/Desktop/zhuanli//技术交底书-.docx" \
  --content '/tmp/patent_content.json'

同时生成提案系统填写参考（用于在贵公司专利提案系统填表时参考）：

~/Desktop/zhuanli//提案填写参考.txt

内容：
提案名称：一种XXX方法
关键词（2-4个）：XXX、XXX、XXX
核心创新点文字说明：[100-200字，精炼版技术方案]
技术领域分类：[建议的分类]
产品分类：[建议的产品类型]

> 不同公司的提案系统字段不同。请把贵公司提案系统的字段名告诉 Claude，它会按字段输出。

---

附：15 分钟校稿清单（输出在文档末尾）

□ 流程图中参数名称是否前后一致？
□ 控制/算法类：关键参数阈值和范围是否都写了？
□ 涉及公式：每个参数的含义是否都解释了？
□ 现有技术的缺陷与本方案的效果是否一一对应？
□ 背景技术中是否有本方案内容混入？
□ 非中文技术名词是否有中文注释（如 Transformer、Attention）？
□ 独立权利要求是否为最宽保护范围，且能与现有技术区分？
□ 提案系统的必填字段（提案名称/关键词/核心创新点/发明人比例等）是否填写完整？

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: ry-xiaopanghu
• Source: ry-xiaopanghu/patent-writer
• License: MIT

Install and usage instructions live in the source repository linked above.