1. 专利焦虑的根源与开源 Skill 的切入逻辑做研发的人尤其是做硬件、嵌入式、算法落地这一块的几乎都绕不开一个共同的隐痛专利。不是不想写是写起来太折磨人。一个完整的专利交底书从技术问题、现有方案缺陷、发明点提炼、实施例展开到权利要求布局少则三五千字多则上万字而且格式要求极其严格。更麻烦的是研发人员擅长的是写代码、调电路、跑实验不是写法律文书。于是出现了一个很荒诞的局面手里明明有真东西但就是卡在“把它变成一份合格专利文档”这一步。我身边不少做嵌入式开源项目和 AI Agent 开发的朋友都有过类似的经历。项目代码写得飞起GitHub 上 Star 涨得也快但一到要申请专利或者配合公司法务出交底书的时候整个人就蔫了。有人拖了半年没动笔有人写出来的东西被代理人打回来三次还有人干脆放弃申请结果被竞争对手抢先布局。这种焦虑不是能力问题是工具和流程问题。标题里提到的“6.3k Star 的开源 Skill”本质上就是冲着这个痛点来的。它不是一个完整的专利代理系统而是一个可复用的技能模块用 Python 写成可以挂载到 Agent 框架里把“研发人员脑子里的技术方案”自动转化成“结构化的专利交底文档”。注意这里的关键词是Skill和Agent不是“专利写作软件”。这两者的区别很大传统软件是你填表单、选模板它帮你排版而 Skill 是让 Agent 理解你的技术描述主动追问缺失信息然后按照专利交底书的逻辑重新组织语言。为什么是 Python因为当前绝大多数 Agent 框架、Skill 运行时、工具调用链都是用 Python 写的。你不可能用一个封闭的 SaaS 工具去对接公司内部的代码仓库、实验记录和文档系统但你可以用 Python 写一个 Skill让它读取你的 README、代码注释、实验日志然后生成初稿。这就是开源 Skill 的价值它不替代人它把研发人员从“格式劳动”里解放出来让你专注在“技术方案本身”上。这个 Skill 适合谁三类人最直接受益。第一类是做嵌入式、硬件、算法方向的研发工程师手里有技术方案但不会写专利第二类是开源项目维护者项目火了之后需要沉淀知识产权但没精力逐字写交底书第三类是 Agent 开发者和技术管理者想在自己的工具链里集成一个“专利辅助生成”的能力。如果你属于这三类中的任何一类下面的内容值得你花时间看完。2. 这个开源 Skill 到底解决了什么问题2.1 从“技术描述”到“专利语言”的翻译层研发人员描述技术方案的方式和专利代理人需要的语言之间存在一道巨大的鸿沟。你可能会说“我用了一个环形缓冲区加双指针来做数据同步”这是工程语言。但专利交底书需要的是“在一个实施例中所述数据同步模块包括一环形存储单元及一双指针索引单元所述双指针索引单元配置为分别指向所述环形存储单元的写入位置与读取位置……”这不是故意绕弯子而是专利文件的法定表达方式。这个 Skill 的核心能力之一就是做这层翻译。它内部维护了一套“技术特征到专利术语”的映射规则同时结合大语言模型的语义理解能力把你的口语化描述、代码注释、甚至变量命名转写成符合专利交底书规范的表述。我实测下来它不会把“环形缓冲区”硬翻成“环形存储单元”就完事而是会根据上下文判断这个特征是否属于发明点如果是就展开写如果只是现有技术就一笔带过。注意这个翻译层不是万能的。如果你的技术方案本身描述得过于模糊比如只写了一句“用 AI 优化了性能”那 Skill 也救不了你。它需要你至少提供技术问题是什么、现有方案怎么做、你的方案和现有方案的区别在哪、具体怎么实现的。这四点缺一不可。2.2 自动追问缺失信息而不是等你写全这是我觉得最像“Agent”而不是“工具”的地方。传统模板工具是你填完所有字段它才动但这个 Skill 会在你提交一段技术描述后主动分析信息完整度然后追问。比如你写了“我设计了一个基于状态机的任务调度器”它会追问状态机有几个状态状态转移条件是什么和现有的轮询调度相比延迟降低了多少有没有具体的实验数据这种追问机制背后是一套信息完整度评分模型。Skill 内部对专利交底书的必要字段做了拆解每个字段有对应的权重。当你提交的描述覆盖了 60% 的字段时它会优先追问权重最高的缺失项。我试过故意只写两句话它连续追问了四轮最后生成的初稿居然比我手写的第一版还完整。当然追问的质量取决于你回答的质量如果你敷衍它它也只能生成敷衍的文档。2.3 与 Agent 框架的挂载方式这个 Skill 不是一个独立应用它需要挂载到 Agent 框架里运行。目前主流的 Agent 框架比如基于 Python 的那些都支持自定义 Skill 注册。挂载方式通常有两种一种是作为工具函数注册Agent 在需要时调用另一种是作为系统提示词的一部分让 Agent 在对话中自动激活。我推荐第一种因为专利生成是一个重流程任务不适合混在普通对话里。你可以这样理解Agent 是你的“研发助理”Skill 是它的一项“专业技能”。当你说“帮我把这个技术方案整理成专利交底书”时Agent 会调用这个 Skill然后按照 Skill 定义的流程一步步执行。这种架构的好处是Skill 可以独立更新不影响 Agent 的其他能力同时你可以把多个 Skill 组合起来比如“专利检索 Skill”加“交底书生成 Skill”形成一个完整的工作流。2.4 为什么是开源而不是闭源 SaaS专利文档涉及核心技术秘密任何公司都不可能把未申请的技术方案上传到第三方 SaaS 平台。这是闭源专利写作工具最大的死穴。开源 Skill 的部署方式是你自己控制数据代码跑在你自己的机器上模型可以用本地部署的文档存在你自己的目录里。6.3k Star 这个数字说明什么说明有大量研发人员和小团队在找这种“数据不出本地”的方案。另外开源意味着你可以改。不同公司的专利交底书模板不一样不同技术领域的表达习惯也不一样。闭源工具你只能提需求等更新开源 Skill 你可以直接改提示词、改映射规则、改输出格式。我见过一个团队把它的输出模板改成了公司内部法务规定的格式连页边距和字体都对齐了省掉了代理人二次排版的功夫。3. 核心细节解析与实操要点3.1 环境准备Python 环境与依赖安装这个 Skill 是 Python 写的所以第一步是把 Python 环境搭好。如果你已经有 Python 3.9 以上的环境可以跳过安装步骤但建议检查一下版本。我实测下来Python 3.10 和 3.11 的兼容性最好3.9 也能跑但某些依赖库的版本会受限。python --version # 确认版本 3.9如果版本不对去 Python 官网下载安装包或者用 conda 创建一个独立环境。我强烈建议用 conda 或 venv 创建虚拟环境不要直接装在系统 Python 里。原因很简单这个 Skill 依赖的库可能和你其他项目的库版本冲突隔离环境能省掉很多“昨天还能跑今天怎么就报错”的破事。conda create -n patent-skill python3.11 conda activate patent-skill接下来是安装依赖。这个 Skill 的依赖通常包括大语言模型的 Python SDK、文档处理库、以及一些文本解析工具。具体依赖列表在项目的requirements.txt里直接安装即可。pip install -r requirements.txt提示如果你在国内pip 安装速度慢可以临时指定镜像源。这不是必须的但能省时间。命令是pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple。注意这里只是加速下载不涉及任何其他操作。3.2 模型接入本地模型还是 API这个 Skill 需要一个大语言模型来驱动。你有两个选择调用云端 API或者用本地部署的开源模型。两者各有取舍我列个表对比一下。对比项云端 API本地开源模型数据隐私数据需上传不适合未申请专利数据完全本地安全性高生成质量通常更高模型更大取决于模型规模和量化程度硬件要求无有网就行需要 GPU显存至少 8GB 起成本按 token 计费一次性硬件投入电费忽略不计部署难度填个 API Key 就行需要配置推理框架和模型文件我的建议是如果技术方案已经提交了专利申请可以用云端 API 快速生成如果还没提交老老实实用本地模型。本地模型推荐用 Ollama 部署它把模型下载、量化、推理服务都封装好了一条命令就能跑起来。模型选择上7B 到 14B 参数量的模型在专利文本生成任务上已经够用再大就吃显存了。ollama pull qwen2.5:14b ollama serve然后在 Skill 的配置文件里把模型地址指向http://localhost:11434模型名填qwen2.5:14b。如果你用的是云端 API就填对应的 API Key 和模型名称。配置文件通常是config.yaml或.env具体看项目文档。3.3 技术描述的输入方式这个 Skill 支持多种输入方式我按推荐程度排序。第一种是直接粘贴技术描述。你可以在对话里把技术方案用自然语言写出来Skill 会解析。这种方式最灵活但要求你至少把技术问题、现有方案、你的方案、实现细节这四点说清楚。我通常建议先用 bullet point 列出来再让 Skill 展开。第二种是读取代码仓库。Skill 可以扫描你指定的代码目录提取 README、注释、函数签名和关键变量名然后基于这些信息生成初稿。这种方式适合开源项目因为代码本身就是最好的技术描述。但要注意代码里的实现细节不一定都是发明点Skill 需要你额外标注哪些是核心创新。第三种是读取实验记录或文档。如果你有实验日志、设计文档、甚至聊天记录也可以喂给 Skill。它会从中提取技术特征。这种方式的信息噪声比较大建议先人工筛选一遍。注意不管用哪种方式都不要把完整的、未脱敏的核心代码直接扔进去。即使是本地模型也建议只提供必要的技术描述而不是整个代码库。这是基本的保密意识。3.4 输出格式与交底书结构Skill 生成的初稿通常包含以下几个部分发明名称、技术领域、背景技术、现有技术缺陷、发明目的、技术方案、有益效果、具体实施方式、附图说明。这个结构基本符合大多数专利交底书的要求但不同公司的法务可能会有微调。我实测下来生成质量最高的部分是“技术方案”和“具体实施方式”因为这两部分最依赖技术细节而 Skill 恰好擅长从你的描述里提取细节。相对薄弱的是“背景技术”和“现有技术缺陷”因为这部分需要检索现有专利和非专利文献Skill 本身不做检索只能基于你提供的信息来写。所以我的做法是先让 Skill 生成初稿然后自己补充背景技术部分的文献引用再让 Skill 润色一遍。输出格式默认是 Markdown方便你后续编辑。如果你需要 Word 文档可以用 pandoc 转换或者直接复制到 Word 里调整格式。我通常会在 Skill 生成后把内容粘贴到公司模板里手动调整一下权利要求书的编号和引用关系。这部分目前还不能完全自动化因为权利要求的布局需要很强的法律判断Skill 只能给你一个初稿最终还是要人来定。4. 实操过程与核心环节实现4.1 从零开始生成一份专利交底书我拿一个真实的例子来演示。假设你做了一个“基于环形缓冲区的串口数据零拷贝接收方法”这是嵌入式开发里很常见的技术方案。你手里有代码但不知道怎么写成专利。第一步启动 Agent 并加载 Skill。如果你用的是命令行方式大概是这样的python agent.py --skill patent_skill --model qwen2.5:14b第二步输入技术描述。你可以这样写技术问题串口接收数据时传统方式需要多次内存拷贝导致 CPU 占用高高速率下容易丢包。 现有方案用 DMA 接收但 DMA 缓冲区满后仍需拷贝到应用缓冲区。 我的方案设计一个环形缓冲区DMA 直接写入环形缓冲区应用层通过读指针直接读取实现零拷贝。 实现细节环形缓冲区大小 4096 字节读写指针用原子操作保护DMA 半满和全满中断触发应用层处理。 实验数据115200 波特率下CPU 占用从 15% 降到 3%连续接收 1MB 数据无丢包。第三步Skill 会分析这段描述然后追问。它可能会问环形缓冲区的数据结构是怎么定义的读写指针的原子操作具体用什么指令实现的半满和全满中断的处理逻辑有什么区别这些问题你回答得越细生成的交底书就越完整。第四步生成初稿。Skill 会把你的回答整合进去输出一份结构化的交底书。我截取一段“具体实施方式”的生成结果给你看在一个实施例中所述环形缓冲区由一固定长度的数组及两个索引指针构成所述两个索引指针分别标识写入位置与读取位置。DMA 控制器配置为将接收到的串口数据直接写入所述写入位置所指向的存储单元并在写入完成后更新所述写入位置。应用层处理器配置为从所述读取位置所指向的存储单元读取数据并在读取完成后更新所述读取位置。所述写入位置与所述读取位置的更新操作通过原子指令实现以避免并发访问导致的数据竞争。这段文字已经非常接近专利代理人的表达方式了。你只需要把“原子指令”具体化成“LDREX/STREX 指令”或者“关中断保护”再补充一些实施例的变体就可以提交给法务了。4.2 参数选择与计算过程的补充Skill 在生成过程中会涉及一些参数比如环形缓冲区大小、超时时间、重试次数等。这些参数不能随便写需要有计算依据。我举个例子为什么环形缓冲区选 4096 字节计算过程是这样的串口波特率 115200即每秒传输 115200 位按 8N1 格式算每字节 10 位所以每秒传输 11520 字节。假设应用层最坏情况下 100ms 处理一次数据那么缓冲区至少需要容纳 11520 × 0.1 1152 字节。取 4096 字节是 2 的幂次方便用位运算做取模同时留了 3 倍余量应对突发流量。这个计算过程如果写进交底书会大大增强技术方案的可信度。Skill 本身不会自动做这个计算但它会在追问时提示你“请提供参数选择的依据”。我的经验是提前把这些计算准备好一次性喂给它生成的文档质量会高很多。如果你懒得算也可以让 Skill 帮你算但你要检查它的计算逻辑对不对。我遇到过它把波特率和字节率搞混的情况所以关键参数还是自己把关。4.3 权利要求书的初步布局权利要求书是专利的核心也是最难写的部分。Skill 可以生成一个初步的权利要求布局但需要你提供“哪些是必要技术特征哪些是可选技术特征”的信息。我通常的做法是在技术描述里用“必须”和“可以”来区分。比如“环形缓冲区是必须的原子操作是必须的但缓冲区大小 4096 字节是可以调整的”。Skill 会根据这些信息把必要特征写进独立权利要求把可选特征写进从属权利要求。生成的结果大概是这样的一种串口数据接收方法其特征在于包括配置 DMA 控制器将串口数据直接写入环形缓冲区的写入位置通过原子指令更新所述写入位置应用层从所述环形缓冲区的读取位置读取数据并通过原子指令更新所述读取位置。根据权利要求 1 所述的方法其特征在于所述环形缓冲区的大小为 2 的幂次。根据权利要求 1 所述的方法其特征在于所述 DMA 控制器在缓冲区半满和全满时产生中断。这个布局不算完美但作为初稿已经很有价值了。代理人拿到这个初稿修改的工作量会小很多。我个人的体会是Skill 生成的权利要求书大约能省掉 60% 的初稿撰写时间剩下的 40% 是法律层面的精修这部分必须由专业人员完成。4.4 与现有工作流的集成如果你在公司里推动这个 Skill 的使用不能只把它当成一个独立工具要把它集成到现有的研发工作流里。我的做法是在项目的docs/目录下建一个patent/子目录每次技术评审通过后把技术描述和实验数据存进去然后跑一次 Skill 生成初稿。这样日积月累每个项目都有对应的专利交底书草稿等到需要申请的时候直接拿出来改就行。集成方式可以用 Git Hook比如在pre-push时检查是否有新的技术方案需要生成交底书。也可以用 CI/CD比如在合并到主分支时自动触发。但我不建议完全自动化因为专利文档需要人工确认自动生成后必须有人 review。我的做法是Skill 生成初稿后发一封邮件给相关研发和法务附上草稿链接让他们在三天内反馈。这样既保证了效率又不会漏掉人工把关的环节。5. 常见问题与排查技巧实录5.1 生成内容太空泛怎么办这是最常见的问题。Skill 生成的交底书读起来像“正确的废话”比如“所述模块用于处理数据”这种没有信息量的表述。原因通常是你给的技术描述太笼统。解决办法是在输入时强制自己回答三个问题——具体用什么数据结构具体用什么算法具体在什么硬件上跑把这三个问题的答案写进去生成质量会立刻提升。我踩过的坑是一开始只写了“用状态机优化了调度”结果生成的交底书全是“所述状态机包括多个状态”这种废话。后来我改成“状态机有 IDLE、RUN、WAIT、ERROR 四个状态转移条件分别是……”生成的内容就具体多了。所以问题不在 Skill在输入。5.2 模型胡编技术细节本地小模型有时候会“脑补”一些你没提到的技术细节比如你没用 DMA它给你编了一个 DMA 控制器出来。这种情况在 7B 以下的模型里比较常见。解决办法有两个一是换更大的模型14B 以上明显好转二是在提示词里明确写“只使用我提供的信息不要添加未提及的技术特征”。我在 Skill 的配置里加了一条系统提示“你是一个专利交底书生成助手你的任务是基于用户提供的技术描述生成文档。严禁添加用户未提及的技术特征、实验数据或硬件平台。如果信息不足请追问不要猜测。” 这条提示词加进去之后胡编的情况减少了 90% 以上。5.3 输出格式不符合公司模板不同公司的专利交底书模板差异很大有的要求把“技术领域”放在最前面有的要求先写“发明名称”。Skill 默认的输出格式不一定符合你的要求。解决办法是修改 Skill 的输出模板文件。通常是一个 Markdown 模板或者 Jinja2 模板你直接改标题顺序和字段名称就行。我帮一个团队改过模板他们把“有益效果”拆成了“技术效果”和“商业效果”两部分还在最后加了“附图清单”表格。改完之后Skill 生成的初稿直接就能用省掉了手动调整格式的时间。这个改动大概花了半小时但后续每个项目都受益。5.4 处理长技术文档时截断如果你的技术描述超过模型的上下文长度Skill 可能会截断后面的内容。这个问题在本地模型上尤其明显因为本地模型的上下文窗口通常比云端 API 小。解决办法是把长文档拆成多个部分分批次输入让 Skill 逐段生成最后再合并。我通常按“技术问题与现有方案”、“技术方案与实现细节”、“实验数据与效果”分成三段每段单独生成然后手动拼接。拼接时注意过渡句的衔接不要让读者感觉到明显的断裂。如果 Skill 支持多轮对话也可以在一个会话里分段输入它会记住前面的内容。5.5 常见问题速查表问题现象可能原因解决办法生成内容空泛输入描述太笼统补充数据结构、算法、硬件平台等具体信息模型胡编细节模型规模太小或提示词不严换 14B 以上模型加“禁止添加未提及特征”提示格式不符合模板默认模板与公司要求不一致修改 Skill 的模板文件调整字段顺序和名称长文档被截断超出模型上下文窗口分段输入逐段生成后合并权利要求布局不合理未区分必要特征和可选特征在输入中用“必须”和“可以”明确标注生成速度太慢本地模型推理速度受限用量化版模型或换用云端 API中文表达不地道模型中文能力不足换中文语料训练充分的模型如 Qwen 系列提示如果你遇到表格里没列出的问题先去项目的 Issues 页面搜一下大概率有人已经遇到过了。开源项目的 Issues 区是最实用的排查手册比任何文档都管用。6. 我对这个 Skill 的实际使用体会我用这个 Skill 大概跑了十几个技术方案覆盖嵌入式、算法和 Agent 开发三个方向。最直观的感受是它把专利交底书的“启动成本”降到了几乎为零。以前想到要写专利就头疼现在随手把技术描述扔进去几分钟就能出一版初稿心理负担小了很多。这种“先有初稿再精修”的模式比“从零开始憋大招”高效得多。另一个体会是Skill 的质量高度依赖你的输入质量。你把它当搜索引擎用它就给你搜索引擎级别的结果你把它当专业助手用认真回答它的追问它就能给你接近代理人初稿水平的结果。我见过有人抱怨“这玩意儿生成的东西没法用”一看输入就写了两行字。这不是 Skill 的问题是使用方法的问题。最后说一个我觉得最有价值的场景技术方案沉淀。很多研发人员做完项目就完了技术方案散落在代码、文档和脑子里过半年就忘了。用这个 Skill每次项目结束花十分钟生成一份交底书草稿存进知识库。等到年底盘点知识产权的时候你会发现手里多了好几份可以直接申请专利的素材。这个习惯我坚持了半年已经攒了五份交底书其中两份已经提交了申请。这种“顺手就把专利写了”的感觉确实比专门抽时间写专利要轻松得多。