从 Idea 到技术交底书：用 Skill 构建专利自动撰写工作流

专利全自动撰写是很多科研团队和研发工程师关注的能力但真正操作过专利申请流程的人都知道从一句 idea 到一份能交给专利代理人或知识产权部门的技术交底书中间有大量结构化信息需要整理。技术问题是什么、现有方案为什么不行、你的方案由哪些技术特征组成、对比现有方案能产生什么效果这些内容缺一不可。如果只是复制一段通用提示词让大模型“写一篇发明专利”生成结果往往又空又散甚至会出现虚构的技术参数。用 Skill 的方式把专利撰写的提示词、模板、输入数据结构和校验脚本一起封装起来才能得到一个可复用、可验证、可排查的自动化工作流。这篇博客会以“专利撰写 Skill”为载体从概念、环境准备、实现、验证、排错到生产化建议完整走一遍从 idea 快速生成技术交底书初稿的流程。适用读者包括科研人员、算法工程师、产品经理和准备系统化提升研发效率的团队。读完你能掌握一套可复现的 Skill 工程结构并能在自己的模型 API 基础上跑通最小闭环。1. 先理解“专利自动撰写 Skill”到底解决什么问题1.1 专利文档不是“写作文”而是技术信息与法律语言的结构化组合专利申请文件通常包含技术交底书、说明书、权利要求书和摘要等多个部分。大多数研发人员最早接触的是技术交底书它是发明人向专利代理人描述技术方案的内部文档。一份合格的交底书至少要回答几个问题背景技术是什么、要解决的技术问题是什么、现有方案存在哪些不足、你的技术方案由哪些步骤或模块组成、与现有方案相比有什么有益效果。这里的核心难点不是“写”而是把散落在脑子里的想法、实验记录、会议讨论变成有固定逻辑顺序的技术信息。大模型擅长把杂乱输入整理成连贯文本但如果输入本身就缺少关键字段它就只能靠“编”来补齐。所以自动撰写工作的第一步是把自由文本转换成结构化输入。1.2 “全自动”的边界从 idea 到初稿而不是从零到授权“专利全自动撰写”这个说法容易让人产生误解。真正的专利申请需要满足新颖性、创造性、实用性等法律要求还要经过形式审查和实质审查。AI 可以高效生成技术交底书、说明书初稿、权利要求书草稿但它不能替代专利代理人做检索分析、权利边界设计、审查意见答复。哪怕完全自动化也需要发明人复核技术细节代理人复核法律表达。实际项目中可以自动化的部分包括技术问题归纳、现有方案整理、技术特征拆分、实施例生成、有益效果描述。这些工作重复性高、模板性强适合用大模型批量处理。涉及法律判断的部分比如“权利要求保护范围是否合理”“这项技术是否构成对现有技术的改进”必须保留人工决策环节。把边界画清楚Skill 才能设计得实用。1.3 Skill 的本质把可复用的工作流封装给大模型Skill 是大模型 Agent 场景下的一种能力封装方式。一个 Skill 通常由一个描述文件、若干脚本和模板资源组成。描述文件告诉模型“这个技能用于什么场景、什么时候调用、如何调用”脚本负责执行具体的输入解析、数据处理、文件读取模板负责提供结构化的提示词。相比直接在对话里粘贴一段长提示词Skill 的优势在于可复用、可版本管理、可组合。以常见 Agent Skill 机制为例目录里会有一个类似SKILL.md的主文件其中写了技能用途和调用方式再由scripts目录里的 Python 脚本做实际处理。模型在对话中识别到用户需要生成专利初稿时会读取 Skill 说明按脚本和模板执行。这套机制非常适合专利撰写因为专利文档的结构是高度固定的但每次输入的项目背景、技术方案不同。注意Skill 不是魔法。如果输入数据缺乏技术细节模型只能生成泛泛而谈的框架。真正决定输出质量的是输入结构化程度和模板里的约束。2. 从零搭一个专利撰写 Skill 的工作台2.1 环境与依赖学习环境下只需要一台能运行 Python 的电脑以及一个可访问的大模型 API。为了便于复现这里使用 Python 3.10 以上版本配合openai、python-dotenv、pydantic等常用包。openai用于调用模型接口python-dotenv用于管理密钥和配置pydantic用于校验输入 JSON。在项目目录下创建requirements.txtopenai1.30.0 python-dotenv1.0.0 pydantic2.0.0 pdfplumber0.11.0安装依赖pip install -r requirements.txt如果已有虚拟环境先激活再安装。如果只是快速验证也可以直接用pip install openai python-dotenv pydantic pdfplumber。依赖包用途学习环境建议openai调用大模型 API直接使用最新稳定版python-dotenv读取.env配置本地开发必备pydantic校验输入数据结构保证 JSON 字段完整pdfplumber解析论文 PDF 文本做论文转专利时需要2.2 Skill 目录结构一个可维护的专利撰写 Skill 应该把“提示词、脚本、示例、输出”分开放置。参考目录结构如下patent-skill/ ├── SKILL.md ├── scripts/ │ ├── generate_idea_draft.py │ ├── extract_paper.py │ └── validate_draft.py ├── templates/ │ └── patent_prompt.md ├── examples/ │ ├── idea.json │ └── paper_input.txt └── output/SKILL.md描述整个技能的功能、适用场景和执行流程。templates/patent_prompt.md是生成专利初稿的核心提示词模板。scripts/generate_idea_draft.py负责读取 idea 输入并调用模型。scripts/extract_paper.py从论文文本中抽取关键信息。scripts/validate_draft.py对生成结果做结构检查。examples存放示例输入output存放生成结果。这种结构的好处是模型只需要读取SKILL.md就能知道何时调用脚本人只需要修改模板和脚本就能更新整个技能版本管理时也能清晰看到每个文件的变化。2.3 配置模型访问在项目根目录创建.env文件OPENAI_API_KEYyour_api_key_here MODEL_NAMEgpt-4o-mini BASE_URLhttps://api.openai.com/v1如果不使用 OpenAI也可以把BASE_URL改成其他兼容接口的地址。实际项目中密钥不要提交到 Git 仓库.env应该加入.gitignore。在脚本里统一读取配置import os from dotenv import load_dotenv load_dotenv() API_KEY os.getenv(OPENAI_API_KEY) MODEL_NAME os.getenv(MODEL_NAME, gpt-4o-mini) BASE_URL os.getenv(BASE_URL, https://api.openai.com/v1)调用模型前先确认密钥是否已设置避免运行时出现AuthenticationError才发现问题。3. 核心实现把“一句话 idea”变成“技术交底书”3.1 输入数据结构设计自动生成专利初稿的前提是输入结构化。下面是一个最小化的idea.json示例覆盖了技术交底书的核心字段{ title: 一种基于低功耗蓝牙的智能门锁身份验证方法, background: 现有智能门锁通常采用 Wi-Fi 连接手机进行远程控制门锁需要持续联网耗电量大。, problem: 当前方案在门锁电池供电场景下功耗过高且 Wi-Fi 连接不稳定导致开锁响应延迟明显。, existing_solutions: [ 传统密码锁需要输入密码适合临时访问但无法远程管理。, Wi-Fi 智能锁支持远程控制但功耗高对路由器依赖强。 ], technical_solution: 门锁通过低功耗蓝牙模块与家庭网关建立连接网关收到手机端的开锁指令后通过蓝牙将其转发给门锁门锁根据动态密钥和时间戳验证指令合法性完成开锁并上报状态。, benefit: 门锁在待机时不需要保持 Wi-Fi 连接仅在有操作时启动蓝牙通信整体功耗低于现有 Wi-Fi 方案同时通过动态密钥提升身份验证安全性。 }这个 JSON 必须由用户或上游系统填好。实际项目中字段可以更多比如“具体实施例”“实验数据”“关键参数”“附图说明”。字段越多生成内容越具体。关键原则是不要让模型替用户发明技术方案。3.2 模板让 LLM 按专利交底书的逻辑生成内容创建templates/patent_prompt.md内容如下你是一名专利撰写助手。根据以下结构化信息生成一份完整的技术交底书初稿输出为 Markdown。 要求 1. 背景技术部分要说明当前技术领域和现有方案并指出现有方案的不足。 2. 发明内容部分要至少包含“技术问题”“技术方案”“有益效果”三小节。 3. 技术方案中的每个重要步骤或模块都要有明确的技术特征不要写抽象的意图。 4. 有益效果要与技术特征对应不能凭空添加效果。 5. 不要直接复制输入中的句子而是用专利技术语言重新组织。 6. 如果信息不足用“待补充”标注不要编造参数。 输入 JSON {{idea_json}} 输出结构 # 技术交底书{{title}} ## 一、背景技术 ## 二、发明内容 ### 技术问题 ### 技术方案 ### 有益效果 ## 三、具体实施方式 ## 四、附图说明如无写“待补充”这里使用{{idea_json}}作为占位符实际代码中会把 JSON 字符串注入进去。模板的关键不是让模型自由写作而是锁定章节结构和内容约束。特别是“不要编造参数”这一条能显著减少幻觉。3.3 实现代码组装请求与解析输出创建scripts/generate_idea_draft.pyimport os import json import argparse from openai import OpenAI from dotenv import load_dotenv load_dotenv() client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(BASE_URL, https://api.openai.com/v1), ) MODEL_NAME os.getenv(MODEL_NAME, gpt-4o-mini) def load_prompt() - str: with open(templates/patent_prompt.md, r, encodingutf-8) as f: return f.read() def read_idea(path: str) - dict: with open(path, r, encodingutf-8) as f: return json.load(f) def generate_draft(idea: dict) - str: prompt_template load_prompt() prompt prompt_template.replace({{idea_json}}, json.dumps(idea, ensure_asciiFalse, indent2)) response client.chat.completions.create( modelMODEL_NAME, messages[ {role: system, content: 你是一个严谨的专利撰写助手。输出中文 Markdown。}, {role: user, content: prompt}, ], temperature0.3, max_tokens4000, ) return response.choices[0].message.content def main(): parser argparse.ArgumentParser(descriptionGenerate patent draft from idea JSON) parser.add_argument(--input, defaultexamples/idea.json) parser.add_argument(--output, defaultoutput/idea_draft.md) args parser.parse_args() idea read_idea(args.input) draft generate_draft(idea) os.makedirs(output, exist_okTrue) with open(args.output, w, encodingutf-8) as f: f.write(draft) print(f[OK] Draft saved to {args.output}) if __name__ __main__: main()这段代码的核心是把模板和输入 JSON 组装成最终 prompt然后调用模型。temperature0.3是为了减少随机性让输出保持稳定。max_tokens4000控制长度避免单次请求超限。实际项目里可以根据模型上下文长度调整。3.4 运行与预期输出在项目根目录执行python scripts/generate_idea_draft.py --input examples/idea.json --output output/idea_draft.md正常情况下控制台会输出保存地址output/idea_draft.md文件会生成类似下面的结构# 技术交底书一种基于低功耗蓝牙的智能门锁身份验证方法 ## 一、背景技术 现有智能门锁多依赖 Wi-Fi 与移动终端通信。门锁需保持网络连接导致待机功耗偏高同时 Wi-Fi 信号受墙体与网关位置影响开锁指令容易出现延迟或丢失。 ## 二、发明内容 ### 技术问题 提供一种基于低功耗蓝牙的身份验证方法以降低门锁待机功耗并提高开锁指令传输的可靠性。 ### 技术方案 门锁内置蓝牙模块。蓝牙模块在待机状态下处于低功耗监听模式。家庭网关收到手机端加密开锁指令后将指令通过蓝牙转发至门锁。门锁解析指令中的动态密钥与时间戳校验一致后执行开锁。 ### 有益效果 门锁无需持续保持 Wi-Fi 连接待机功耗降低蓝牙通信由本地网关触发减少因 Wi-Fi 网络不稳定导致的延迟动态密钥机制降低指令被重放攻击的风险。 ## 三、具体实施方式 正文生成内容通常包含详细步骤 ## 四、附图说明 待补充如果输出中大量出现“待补充”说明输入 JSON 信息不足需要补全技术细节而不是调整 prompt 让其强行生成。注意生成结果只是初稿。如果方案里包含具体参数、材料、算法步骤必须由发明人确认后才能进入下一步。4. 从论文到专利初稿更贴近科研场景的增强方案4.1 论文和专利的视角差异很多科研人员手里有论文初稿想快速输出专利交底书。论文和专利看似描述同一个技术但视角差异很大。论文强调发现和验证过程专利强调技术方案和保护范围论文可以写“实验证明了”专利通常写“所述方法包括”论文注重数据对比专利注重权利要求的技术特征。维度论文写法专利写法核心目标证明现象和结果描述技术方案和边界关键要素实验、数据、分析步骤、模块、参数、连接关系语言风格学术解释技术特征 功能性表述公开程度充分公开以实现复现充分公开并防止绕开保护范围数据使用大量实验数据实施例可简化但需要支撑因此不能简单把论文正文复制给模型生成专利。需要先抽取论文中的技术方案部分再按专利模板改写。4.2 抽取论文核心段落作为输入这里提供一个简化版论文抽取脚本它接收纯文本文件按章节标题拆出摘要、引言、方法、实验等部分。实际项目中如果输入是 PDF可以先用pdfplumber提取文本。scripts/extract_paper.pyimport re import argparse def extract_sections(text: str) - dict: sections {} current_title header lines text.splitlines() for line in lines: stripped line.strip() if re.match(r^(摘要|引言|方法|实验|结论|Abstract|Introduction|Method|Experiment|Conclusion), stripped): current_title stripped sections[current_title] [] else: sections.setdefault(current_title, []).append(stripped) return {k: \n.join(v).strip() for k, v in sections.items()} def main(): parser argparse.ArgumentParser(descriptionExtract sections from paper text) parser.add_argument(--input, defaultexamples/paper_input.txt) parser.add_argument(--output, defaultoutput/paper_sections.json) args parser.parse_args() with open(args.input, r, encodingutf-8) as f: text f.read() sections extract_sections(text) with open(args.output, w, encodingutf-8) as f: json.dump(sections, f, ensure_asciiFalse, indent2) print(f[OK] Sections saved to {args.output})实际使用时可以先用该脚本把论文章节拆开然后由人或模型从“方法”和“实验”部分提取专利输入字段。整个链路是论文文本 - 章节抽取 - 字段提取 - 生成交底书初稿。4.3 生成时如何避免直接照抄论文专利文档要求“清楚、完整地公开”但直接复制论文原文可能出现两个问题一是论文中可能包含他人素材或未公开数据直接复制会带入版权风险二是论文语言偏学术与专利的表述方式不匹配。所以在模板中要显式加入“用你的话重写技术方案禁止连续复制原文”的约束。更稳妥的做法是把论文段落交给模型前先让模型做一次“转述”请根据以下论文内容提炼出技术领域、要解决的技术问题、技术方案和有益效果并用中性客观的技术语言概括。不要保留原文中的第一人称和主观判断。这一步生成的结构化摘要再作为idea.json的输入。这样既降低了照抄概率又保证了专利撰写流程的一致性。5. 验证产出质量的四个检查点5.1 章节完整性检查生成完成后先做结构检查。写一个validate_draft.py验证 Markdown 文件是否包含预期章节import re import argparse def validate_draft(path: str): with open(path, r, encodingutf-8) as f: text f.read() required_sections [ 背景技术, 技术问题, 技术方案, 有益效果, 具体实施方式, ] missing [s for s in required_sections if s not in text] if missing: print([WARN] Missing sections:, missing) else: print([INFO] All required sections present.) heading_count len(re.findall(r^#{1,3} , text, flagsre.MULTILINE)) print(f[INFO] Total headings: {heading_count}) return len(missing) 0 if __name__ __main__: parser argparse.ArgumentParser() parser.add_argument(--draft, defaultoutput/idea_draft.md) args parser.parse_args() validate_draft(args.draft)这个脚本的价值在于把“是否生成完整”从人眼判断变成命令判断。在自动化流水线里如果检查失败可以标记为“需要重新生成”。5.2 技术特征是否具体单纯有章节还不够还要看每个技术方案里是否有可执行的技术特征。常见的空洞描述包括“通过智能算法进行优化”“采用先进技术处理数据”这些没有给出具体步骤。检查方式有两种一种是用规则检查关键词比如是否包含“模块”“步骤”“接口”“参数”“阈值”等实现性词汇另一种是让大模型对生成结果做二次评价提示它“找出技术方案中无法被本领域技术人员实施的句子”。实际项目中推荐先做规则检查再做人工复核。5.3 输出格式规范专利交底书最终要交给专利代理人格式混乱会增加沟通成本。检查点包括标题层级是否正确、代码块是否完整、编号是否连续、是否存在空段落、是否包含占位符“待补充”但未标记。对于“待补充”出现的位置要重点确认是输入信息缺失还是模型故意留空。可以增加一个简单脚本统计待补充出现次数超过阈值就提示需要补全输入。5.4 人工复核清单算法检查只能覆盖结构问题技术内容的准确性必须由人确认。建议交底书初稿完成后发明人按下面的清单逐项复核检查项通过标准技术问题与背景技术对应不存在夸大或编造技术方案每个步骤或模块能在实际环境中落地技术特征包含具体参数、结构、流程或算法逻辑有益效果能与技术特征对应不写模糊收益实施例能指导本领域技术人员实现该方案术语一致性全文对同一模块或方法的称呼一致信息缺口所有“待补充”位置都已经填写或解释原因这个清单应该放进SKILL.md让模型在生成完成后自动提醒用户执行人工复核。6. 常见问题排查与避坑指南6.1 生成内容出现不存在的技术效果现象模型输出“本方案使响应速度提升 300%”但输入里没有任何实验数据或测试结果。原因模型在生成文本时倾向于补全看似合理的效果尤其在 prompt 中缺少“禁止编造”约束时。检查方式搜索输出中的数字、百分比、绝对化副词与输入字段比对。处理方式在模板中加“对于没有数据支撑的效果使用‘相比现有方案可能存在……’或直接写‘待实验验证’”。如果输入中缺少效果描述先让用户补全不进入生成流程。6.2 一句话 idea 生成的内容空洞现象输入只有“我想做一个智能门锁”生成的背景技术和技术方案写得像产品宣传语。原因输入字段中background、technical_solution为空或过于简短模型只能靠常识填充。处理方式宁愿先要求用户填完核心字段也不要强行生成。可以写一个前置检查脚本必填字段为空时直接报错。6.3 输出被截断导致章节不全现象生成结果停在“具体实施方式”一半没有结束。原因max_tokens设置过小或模型一次输出超过上下文限制。处理方式适当调大max_tokens如果仍不够可以拆分生成先生成背景技术和发明内容再生成具体实施方式。两段分别调用模型最后合并。6.4 修改 prompt 后结果不稳定现象相同输入两次生成结果差异很大章节顺序不一致。原因temperature偏高或 prompt 中缺少明确的输出顺序约束。处理方式将temperature降到 0 到 0.3 之间并在模板中固定 Markdown 标题顺序。如果业务允许可以使用json_object格式让模型先输出结构化 JSON再转成 Markdown。6.5 保密数据和敏感信息风险现象直接把未公开的研发数据、公司内部的技术方案发送给云端模型 API可能带来数据泄露隐患。原因专利申请本身有保密要求在授权公开前核心技术方案不应随意外传。处理方式内部部署模型或使用支持私有化部署的模型接口在发送给外部 API 前脱敏涉及核心秘方、底层算法时使用占位符替代真实参数。这是生产环境最重要的一条底线。注意不要把带保密标识的文档直接粘贴给外部模型尤其是涉及商业机密和国防安全的技术领域。稳妥做法是先做字段脱敏模型只处理抽象技术逻辑。7. 从学习环境到生产环境还需要补什么7.1 稳定性与成本控制学习环境跑通后要进入生产环境还需要考虑调用频率、超时、重试、失败告警。建议用任务队列管理生成任务单条生成超时后重试一次如果第二次仍失败则进入人工队列。成本方面要统计每次生成的 token 消耗根据输入长度和输出长度估算费用。模板中的冗余文字越多token 成本越高需定期优化 prompt。7.2 检索增强避免撞车和重复专利最怕重复。自动生成初稿后至少做一次初步检索确认没有相同技术方案。可以接入专利检索 API也可以用向量检索对已有专利文本做相似度匹配。注意自动检索只能作为初审参考最终的新颖性和创造性判断仍需专业代理人。7.3 权限、审计与人工闭环生产环境需要记录谁发起了生成、输入了什么数据、模型输出了什么、人工修改了什么。建议增加审计日志表保留完整版本历史。同时设置“人工确认”状态位未确认的草稿不能进入下一流程。这个“人机闭环”是整个系统的核心它既保证效率又守住质量底线。7.4 可复用检查清单最后整理一份可直接用于项目的清单建议保存在团队文档中输入数据是否包含题目、背景、问题、现有方案、技术方案、有益效果六类字段。prompt 模板是否包含“禁止编造参数”“信息不足用待补充”约束。模型参数是否设置为低 temperature、可控 max_tokens。生成结果是否通过章节完整性脚本检查。“待补充”出现次数是否小于阈值。是否完成人工技术复核。是否完成专利初步检索。是否对输入数据做了脱敏。是否记录生成日志和人工修改记录。是否在最终提交前由专利代理人审核。这套 Skill 的核心价值不是让你把“一键生成”当成万能工具而是把专利撰写中重复、结构化的部分交给模型把技术判断、法律判断和保密审查留给专业人工。真正能落地的自动化永远是在清晰边界内的高效协作。建议先从最小闭环开始准备一个真实的 idea填好 JSON跑通生成与校验再逐步加入论文抽取、检索和审计能力。