我见过太多研发工程师代码写得漂亮一提到专利就头大。不是不想写是根本不知道从哪下手。挖专利点、写交底书、整理申请文件——这三件事听起来是专利代理人的活但真正干过的都知道最前面的功夫全在研发手里。所以当我看到GitHub上这个专门做专利的Skill项目而且Star冲到了10.0k的时候第一反应不是“又一个AI套壳”而是赶紧拉下来跑了一遍。先说结论这个开源的专利Skill本质上是把专利实务的整套SOP封装成了AI Agent能直接调用的“技能包”你只需要把一个技术方案丢给它它就能按步骤帮你挖创新点、生成交底书、整理出申请文件的初稿结构。全程免费本地运行数据也不出自己机器。这篇文我就把安装、用法、实测结果还有我个人踩过的坑全部写出来。1. 专利这行的真正痛点不在撰写在“翻译”1.1 研发与代理师之间的沟通断层专利申请这件事行业里默认是代理人的活但实际推进的时候卡点永远在研发这边。我见过太多方案研发自己觉得“很先进”但要他说清楚现有技术是什么、你的方案和现有技术差在哪、这个差异带来了什么效果——他就开始含糊其辞。这不是研发能力不行而是专利语境和工程语境是两套语言。工程师习惯说“我用了某某模块、跑了多少毫秒、降低了多少开销”代理人需要听到的是“相对于现有技术采用某种特定结构解决了某个技术问题产生了某种预料不到的技术效果”。前者是描述后者是论证。1.2 三块苦活到底苦在哪挖专利点难在“把隐性的创新显性化”。很多工程师觉得自己每天都在做重复劳动根本没创新但实际上他自己调了一周的Bug、绕过了一个架构陷阱、换了一种数据结构——这些全是潜在的专利点只是没人帮他系统梳理。写交底书难在“结构化表达”。交底书有固定套路但也有固定的雷区。背景技术不能写成产品介绍发明内容不能写成代码注释具体实施方式不能只说“用了某种算法”必须讲清楚参数范围、可选方案、技术效果的对应关系。没有模板新人根本写不来。整理申请文件难在“术语一致性和逻辑闭环”。摘要、权利要求书、说明书三者的表述必须严格对应权利要求书的每个词都要有说明书支持否则后续审查意见会一条条打回来。这三步每一环都消耗大量时间而且容错率极低。1.3 通用大模型为什么救不了专利撰写有人会说不是有ChatGPT吗让它写不就行了。我试过。通用模型写出来的东西有三个问题一是没有步骤感它不知道你目前处在“挖掘”还是“交底”还是“申请文件”阶段经常混着写二是对专利审查逻辑没有概念写出来像技术博客不像法律技术文件三是它不会主动追问关键信息——你给什么它写什么给少了它也能编编出来全是废话。这个专利Skill解决问题的思路完全不同它先把专利工作拆成固定流程然后在每个流程里塞入对应的方法论、提示词模板、规范检查表让AI按一个专业助理的标准路径来执行。这也正是“Skill”这个形态在最近半年快速流行的原因——它不只是提示词它是“提示词 知识库 工作流”的打包。2. 拆开这个10k星Skill它不是提示词是一套完整SOP2.1 Skill的底层形态一个目录加一个说明书目前主流的AI Agent平台都开始支持Skill机制无论是Claude这边的Agent Skills还是其他支持类似规范的工具。一个Skill的基本形态就是一个文件夹patent-skill/ ├── SKILL.md ├── prompts/ │ ├── mining.md │ ├── disclosure.md │ └── application.md ├── references/ │ ├── claim-structure.md │ ├── disclosure-template.md │ └── examination-guidelines.md └── examples/ ├── example-mining-output.md └── example-draft-output.mdSKILL.md是整个技能包的说明书里面写了这个Skill能做什么、调用条件是什么、输入输出格式是什么、内部有哪些子模块。AI Agent读到这个文件就知道“哦当用户让我写专利相关的东西时我应该按这套规则来”。prompts目录下是不同场景的提示词references是知识背景examples是输出示例。这个结构有一个非常大的好处普通人也能看懂整个流程而且可以自己改。你觉得它挖点的思路不够细直接改prompts/mining.md就行不需要懂代码。2.2 专利Skill的模块划分我拉下来看了一圈这个项目的模块划分很符合专利实务的真实节奏它不搞那种“一键生成专利”的噱头而是老老实实分了三条线模块输入输出对应实务环节专利挖掘技术方案描述、研发背景、实验数据候选创新点清单、可专利性初步判断研发内部挖掘交底书生成创新点清单、技术细节结构完整的交底书初稿研发→代理人交接申请文件整理交底书、审查意见、补充材料摘要、权利要求书、说明书初稿代理人撰写初稿这三个模块是串行关系挖掘的结果是交底书的输入交底书的质量直接决定申请文件的产出。打个比方它像一条小型流水线而不是一个万能生成器。这个设计我挺认可因为专利工作本身就是分阶段的每一阶段的稿件用途、读者、审查标准都不一样。2.3 为什么“检查表”比“自由发挥”重要这个项目里最值钱的东西可能不是那些prompt而是references里的一系列检查表。比如写权利要求书之前它会先过一遍是否包含必要技术特征缺少任何一个都无法解决技术问题是否使用了清楚、确定的术语有没有“大概”“可能”这类模糊词独权和从权的引用关系是否正确每个技术特征是否都能在说明书里找到对应描述这些条目全是专利代理师日常审核稿件时心里默念的点但普通人不知道。Skill把这一层隐性知识显性化了AI在生成内容的时候会主动对着检查表自检而不是“自由发挥”。这一点是它和普通prompt的核心差异——普通prompt要求AI写得“好”这个Skill要求AI写得“对”。3. 部署实操从GitHub克隆到第一个交底书产出3.1 环境准备与安装步骤先说明一下这个Skill依赖一个能加载Skill目录的AI Agent环境目前主流的Claude Code、Codex CLI等工具都支持。你需要做的就是把项目从GitHub克隆下来然后放到Agent指定的skills目录里。以Claude Code为例# 克隆项目到本地 git clone https://github.com/你的账号/patent-skill.git # 进入项目目录 cd patent-skill # 把Skill复制到Claude Code的skills目录 mkdir -p ~/.claude/skills cp -r patent-skill ~/.claude/skills/不同Agent的目录位置不一样但逻辑都差不多本质上是“把技能包放在Agent能扫到的地方”。放好之后重启一下Agent终端让它重新加载技能列表。这里说一个我踩过的坑很多人直接把整个仓库clone到了项目目录里然后在别的目录启动Agent导致Agent完全没扫到这个Skill。正确做法是先看Agent的文档确认skills目录的扫描路径再决定软链接还是复制过去。3.2 首次调用测试放好目录之后最简单的一句话测试是请使用专利Skill帮我对以下技术方案进行专利挖掘……如果Agent正确加载了Skill它通常会先回你一句类似“好的我会按照专利挖掘的标准流程来处理先补充几个信息”这样的反馈。这时候你就知道它已经进入Skill的工作流了而不是走通用对话。我第一次测试的时候Agent直接问我“这个技术方案相对于最接近的现有技术核心区别是什么有没有实验数据验证效果”我当时愣了一下——这个追问方式非常像代理人不像通用AI。这说明它已经在按专利实务逻辑运转。3.3 常用配置项说明这类Skill一般会在SKILL.md里留几个可调参数比如输出语言、面向的专利类型、是否启用严格检查模式。我看了一下这个项目的默认配置配置项默认值我建议的调整输出语言中文保持中文技术领域通用如果你们公司是机械/软件/化学建议在配置里写明检查模式标准第一稿用标准模式终稿前开严格模式自问自答开启保持开启这个功能会主动追问关键信息技术领域这个参数一定不要省。同样是一个“结构优化”的描述机械领域关注的是连接关系、材料力学软件领域关注的是模块划分、数据流化学领域关注的是配比范围、反应条件。你不告诉它领域它就只能按通用框架来写输出的质量会差一截。4. 专利挖掘模块把“这玩意有点新”变成可表述的技术方案4.1 输入什么才能挖出东西挖掘模块是整个Skill里我最喜欢的一部分因为它解决的是“我不知道自己有什么可以申请”的问题。它的输入不需要你写出专利语言只需要你用人话描述你的工作。我在实测的时候用的输入是这样的我们的设备里原本用风扇给主芯片散热风扇噪音大、功耗高。我改成了在芯片背面贴合一块均热板 再把均热板延伸到外壳边缘利用外壳整个面来散热。试过之后芯片温度降了12度风扇可以降速运行 噪音从45分贝降到了32分贝。这段话就是普通工程师写周报的口吻完全没有专利语言。Skill拿到之后它不会直接写而是先做信息拆解原技术方案风扇主动散热核心技术改动新增均热板贴合芯片背面延伸至外壳技术效果温度降低、噪音降低、功耗降低相对现有技术的区别散热路径从“局部强制风冷”改成了“面接触被动散热”这个拆解过程非常重要因为它把一段流水账变成了结构化的“问题—方案—效果”三元组。后面它还会进一步追问均热板的厚度、材质铜、铝、石墨、芯片到外壳的距离、均热板与外壳的连接方式是否有间隙。这些追问全是代理师会问的问题因为缺少这些细节权利要求书根本写不完整。4.2 可专利性判断的三个维度挖掘模块在生成候选创新点之后会对着三个维度做一轮自检。这三个维度我建议每个研发都刻在脑子里新颖性这个方案是不是现有技术里完全没有出现过的组合哪怕原来是风扇现在换成均热板外壳组合只要没人这么干过就有新颖性。创造性这个方案是不是“本领域技术人员容易想到的”如果只是把A材料换成B材料且在已知范围内创造性就弱如果改变了整个散热路径的物理逻辑创造性就比较稳。实用性能不能制造、能不能使用、能不能产生效果纯理论的东西不满足实用性。我实测的输出里它不止列了创新点还按这三个维度给了初步结论比如“该方案创造性可能体现在导热路径的重新设计建议优先检索均热板外壳一体化的现有技术”。4.3 挖掘过程中容易漏掉的素材用了几次之后我发现大部分工程师给的输入里都缺三类信息一是实验数据。很多人只说“效果好很多”但不说具体多少。温度降12度、噪音降13分贝这些数据在交底书里是“有益效果”部分的论据而在挖掘阶段数据还能反向辅助判断技术特征是否必要——如果去掉均热板温度就压不住均热板就是必要技术特征必须写进独权。二是失败经历。调试过程中遇到的坑恰恰是“预料不到的技术效果”的最佳证据。比如你试过用导热硅脂直接贴外壳效果不好后来改成均热板才解决——这条“弯路”本身就能证明均热板方案不是显而易见的。三是边界条件。你的方案在什么范围内有效超过某个厚度均热板效果不再提升低于某个温度反而有冷凝风险这些边界条件写清楚权利要求的保护范围才能画好。Skill的追问里会带这些角度但它只能问答得出来还是得靠你脑子里那些没写进周报的细节。5. 交底书生成标准结构下的工程化写作5.1 交底书的黄金结构交底书是研发和代理人之间的翻译文件它的受众是代理人但不能默认代理人懂你的技术。所以一份完整的交底书至少要覆盖六个部分章节内容要求常见错误发明名称体现技术领域技术方案类型写得太宽泛或太像产品名技术领域一句话说明属于哪个技术方向复制粘贴项目名背景技术现有技术的方案缺陷写成产品宣传或纯技术综述发明内容要解决的技术问题、技术方案、有益效果与背景技术没有逻辑呼应具体实施方式至少一个完整可实现的实施例只写抽象概念不给参数附图说明结构图/流程图的对应说明有图无标注或无图这个结构不是谁拍脑袋定的它对应的是后续申请文件里“说明书”五部分的雏形。交底书写得清楚代理师翻译成权利要求书的效率就高交底书写得含糊后续来回沟通的成本会翻倍。5.2 Skill如何写“背景技术”这是我观察下来它写得最好的一个部分因为通用AI最容易在背景技术上翻车——它们会把背景技术写成“现有技术综述”大段引用行业常识完全没聚焦到问题本身。这个Skill写背景技术的逻辑是先定位最接近的现有技术然后用两三句话描述它的核心方案再重点指出它的缺陷。而且缺陷必须和你的发明所解决的问题对应。比如上面散热方案的例子它会写“现有散热方案通常采用轴流风扇强制对流芯片热量通过散热鳍片与空气热交换排出。该方案存在如下缺陷风扇运转产生持续噪音主动散热需持续供电增加整机功耗在密闭或小型化设备中散热风道受限鳍片热交换效率大幅下降。”注意这段话的表述每一句都在为后文的发明内容铺路——噪音对应“降噪效果”功耗对应“降低功耗”风道受限对应“外壳侧面散热”。背景技术和发明内容之间必须是“挖坑—填坑”的关系而不是各写各的。5.3 发明内容与具体实施方式的分工很多新人搞不清楚发明内容和具体实施方式的区别以为把方案重复写两遍就行了。实际上两者分工完全不同发明内容部分要说“我的方案是什么、能解决什么问题、效果怎么样”它是概述用的语言要略微抽象为后续权利要求的保护范围留空间。尤其“技术方案”这一段经常是权利要求书的文字雏形到时候代理师会直接从这里抽出独权。具体实施方式部分要说“这个方案在真实产品里怎么做、参数是多少、有没有替代方案”它是展开要具体到本领域技术人员能够实现。Skill在处理这两部分时会刻意控制抽象和具体的比例发明内容里的“均热板”不会轻易限定材质和厚度但具体实施方式里会列出铜板、铝板、石墨片、均热板厚度范围0.3-2.0mm、贴合方式用导热胶或钎焊等。5.4 人工必须介入的三个位置我必须泼一盆冷水交底书生成这个环节AI能做的大约是60%的框架搭建和素材组织剩下40%必须人工补缺了这40%交底书会非常“像样但虚”。第一个必须人工补的是真实实验数据。Skill生成的有益效果部分是推测性的它可能写“有效降低芯片表面温度”但你必须把“12度”“32分贝”这些实测数字填进去才有说服力。第二个必须人工补的是替代方案和可变换的设计。同样实现面接触导热除了均热板还可以用热管均热板组合、还可以用相变材料填充间隙。你是实际做过的人你知道哪些替代方案真能成立AI不一定判断得准。第三个必须人工补的是“发明点在哪一层”。如果一个方案里既有硬件改动又有软件逻辑调整哪个是主创新点哪个是辅助创新点这个判断需要研发对项目投入的理解深度。AI能把两条线都列出来但分主次得你说了算因为单独申请和打包申请的策略完全不同。6. 申请文件整理摘要、权利要求书、说明书的分工与衔接6.1 申请文件与交底书的关系交底书写完之后Skill的第三个模块开始介入申请文件的整理。这里有一个容易误解的点申请文件不是交底书的“格式化重排”而是换一种法律技术语言来重新表达。交底书可以按研发习惯写想到哪写到哪申请文件必须按审查要求组织尤其是权利要求书它的每一句话都在划定法律保护范围。这个范围既不能太宽太宽会被现有技术打回来也不能太窄太窄了别人轻松规避。所以Skill在处理申请文件时第一步不是生成而是做一次“交底书信息完整度检查”列出缺项让用户补充然后再动笔。我在实测时发现它甚至会追问“均热板与外壳边缘的连接处是否有密封设计”这个问题直接关系到独权要不要写“密封结构”这个技术特征。6.2 权利要求书初稿的生成逻辑权利要求书是专利文件里最核心也最讲究的部分。Skill生成的独权逻辑我看了下基本是标准的“前序部分特征部分”结构一种电子设备散热结构其特征在于包括 ——壳体具有外壳表面 ——热源设置于所述壳体内 ——均热板贴合于所述热源背离所述壳体底壁的一侧并自该侧延伸至所述壳体的外壳边缘 其中所述均热板通过所述外壳边缘与外部环境进行热交换。这个写法符合基本要求把设备的基础组成部分放在前序把作出改进的技术特征放在“其特征在于”之后。但说实话第一稿的权利要求书通常需要人工大改因为保护范围的大小要靠经验拿捏。Skill能做的是保证你不犯结构性错误比如把非必要特征写进独权、引用关系混乱、术语不一致。这类错误如果是人工写代理师可能返工三遍用AI生成初稿至少第一遍就能把骨架搭对。6.3 说明书与摘要的整理要点说明书是权利要求的支撑审查意见里最常见的负面评价就是“权利要求得不到说明书支持”。Skill在处理说明书的时候会强制把权利要求书里的每个技术特征展开到具体实施方式中。例如权利要求写了“均热板延伸至外壳边缘”说明书里必须展开说明延伸的具体路径、长度比例、与外壳的连接方式、材料选择对导热效率的影响。这些细节在交底书里通常都有但散落在各处Skill的贡献是帮你把它们归位。摘要相对简单它是“技术问题技术方案技术效果”的三句话压缩包。这里也有个常见错误摘要写完忘了和权利要求书对应。Skill会做一致性检查保证摘要里出现的每个技术名词都在权利要求书里有定义不会出现摘要写“散热膜”而权利要求写“均热板”这种术语漂移。6.4 一种高效的“三步审校法”用Skill整理完申请文件初稿后我自己总结了一套三步审校法分享出来供参考第一步通读权利要求书只干一件事逐个技术特征比对现有技术问自己“这个特征是不是必要的去掉它行不行”。不能去掉的留在独权里可以去掉但能优化效果的放到从权里。我实测里第一次生成的独权有7个技术特征我砍掉了2个保护范围立刻大了不少。第二步拿权利要求书当索引翻说明书确保每个特征在说明书里都能找到对应展开。找不到就用补充实施方式的方式补进去不能删权利要求了事。第三步排序和术语统一。全文检查一遍术语表均热板、散热板、导热板不能混用。这一步是最耗时的但也是AI做不了的——术语的选择会影响后续侵权判定时的解释空间。7. 实测案例一个散热结构专利从输入到初稿的全程记录7.1 实测环境与输入内容为了写这篇文章我专门在自己的环境里完整跑了一遍流程。环境是Claude Code配合本地部署的专利Skill输入就是前面提到的那段散热方案描述。我没有做任何修饰完全模拟一个普通工程师的“周报语气”。7.2 各阶段输出的质量观察第一轮专利挖掘输出质量惊喜。它给了6个潜在创新点从“均热板外壳一体化散热结构”到“可变转速风扇控制逻辑联动”再到“贴合层材料与导热系数的优化选择”。其中有些角度我自己都没意识到——比如它指出“散热路径从局部风冷改为面接触被动散热”本身就是一种可申请的“散热方法”而不只是“散热结构”。这就是典型的将“产品专利”扩展出“方法专利”的思路很多研发意识不到这一层。第二轮交底书生成初稿可用度约七成。结构完全合规逻辑链清晰背景技术和发明内容衔接得好。需要我手动补的是真实测试数据、均热板厚度范围、以及一组对比实验单风扇 vs 风扇均热板 vs 纯均热板的具体数据表。第三轮申请文件整理权利要求书骨架可参考但保护范围需要调。它生成的权利要求偏具体把所有实施例里的参数都写进去了这是AI的普遍毛病——它倾向于“安全地写具体”而不是“有策略地写抽象”。所以我把独权里关于厚度、材质、连接方式全部删掉或者降级到从权才得到合理的保护范围。7.3 意外情况与修整过程过程里也出了一次问题第一版交底书里Skill把“均热板延伸到外壳边缘”理解成了“均热板外露在外壳表面”这会导致防水防尘的技术问题。我在修整时补了“均热板位于外壳内侧与外壳边缘区域导热接触不直接外露”的描述后续权利要求书才没有跑偏。这种细节误差说明一个道理Skill可以帮你把80%的框架搭好但最后20%的“技术事实准确性”只能靠懂技术的人把关。AI不理解你的产品真实长什么样它只会照着文本逻辑推而专利文件的致命伤恰恰是“逻辑无误但事实错误”。7.4 效率对比和适用建议从我实测的耗时来看用Skill辅助一个普通技术方案的专利申请前期工作大致是这样的节奏环节纯人工习惯耗时Skill辅助耗时专利挖掘思路梳理2-3天含拖延2小时出候选点交底书初稿2-4天半天含人工补数据申请文件初稿思路整理2-3天3小时出骨架代理师审校修改无法节省依然无法节省注意我不建议把这个时间差宣传成“AI替代代理人”。它的价值恰恰是让研发在进入代理人环节之前手里已经有一份像样的交底书原来可能要来回磨一个月的需求沟通压缩成一次高质量的信息传递。8. 这套Skill的边界在哪里以及我为什么不建议你“全自动”8.1 AI做得好的环节和做不了的环节经过这段时间的使用我倾向于把Skill的职责边界分成两个清单。它能做好的信息结构化、规范性审查、术语一致性、框架搭建、多角度思路补充、以及“用专利语言把你的技术描述重写一遍”。这些环节的共同点是“有明确规则、有标准格式、有大量历史样本”AI在规则清晰的领域确实高效。它做不了的创造性判断的最终决策、保护范围的策略权衡、真实实验数据的补充、技术事实的准确性验证、以及“这个专利到底值不值得申请”的商业判断。这些环节靠的是研发对技术的理解深度、代理师对审查实践的把握、以及企业对专利布局的战略考量AI目前没有能力也没有立场替你做这些决定。8.2 误用场景把它当“专利生成器”的人我在网上看到一些评论抱怨“用这个Skill生成的东西根本不能直接用”。我看了下他们的用法基本都是在输入框里丢一句话然后让AI直接生成全套申请文件接着拿这个去申报。这不是Skill的错是用法错了。专利文件是有法律后果的文件它不是你写博客错了删掉重来专利一旦申请提交修改范围受到严格限制前期草率后期寸步难行。还有个更隐性的风险如果一个企业内部多名研发都直接用AI生成交底书而不做个性化修改最后产出的技术方案描述很容易出现相似的表述模式。虽然专利审查不看你是不是AI写的但近似文本放在不同的申请里可能导致审查员认为技术方案没有明显区别影响审查结果。所以我一直强调AI生成初稿研发必须做实质性改写尤其是实施例和技术参数的描述。8.3 我建议的正确用法三明治工作流最后分享一下我个人目前的工作流管它叫“三明治”——人工、AI、人工三层夹着来。第一层人工把技术方案的关键信息整理清楚包括核心技术改动、实验数据、失败经历、边界条件。这层信息越丰富AI后续输出的质量越高。我给这个Skill喂料花的时间通常比它跑的时间还长但这段时间花得值。第二层AI让Skill依次跑挖掘、交底、申请文件三个模块每一轮都拿输出结果和我自己的思路做对照。它会提供我没想到的角度也会暴露我自己没想清楚的模糊点。第三层人工对AI产出的每一段涉及技术事实的内容进行逐句核对对权利要求书的保护范围做策略性调整对术语和全文逻辑做最终审校。然后再交给代理师去处理法律细节。这三个环节里AI是放大器和脚手架不是决策者。如果你想给自己的专利工作提效拿它来搭框架、查漏补缺、对齐规范是值得的如果你想省掉动脑子的环节直接拿AI文档去申请那我不太建议。专利这个东西最后在法律文件上签字的还是人签字的人就得对内容负责。
我见过太多研发工程师代码写得漂亮一提到专利就头大。不是不想写是根本不知道从哪下手。挖专利点、写交底书、整理申请文件——这三件事听起来是专利代理人的活但真正干过的都知道最前面的功夫全在研发手里。所以当我看到GitHub上这个专门做专利的Skill项目而且Star冲到了10.0k的时候第一反应不是“又一个AI套壳”而是赶紧拉下来跑了一遍。先说结论这个开源的专利Skill本质上是把专利实务的整套SOP封装成了AI Agent能直接调用的“技能包”你只需要把一个技术方案丢给它它就能按步骤帮你挖创新点、生成交底书、整理出申请文件的初稿结构。全程免费本地运行数据也不出自己机器。这篇文我就把安装、用法、实测结果还有我个人踩过的坑全部写出来。1. 专利这行的真正痛点不在撰写在“翻译”1.1 研发与代理师之间的沟通断层专利申请这件事行业里默认是代理人的活但实际推进的时候卡点永远在研发这边。我见过太多方案研发自己觉得“很先进”但要他说清楚现有技术是什么、你的方案和现有技术差在哪、这个差异带来了什么效果——他就开始含糊其辞。这不是研发能力不行而是专利语境和工程语境是两套语言。工程师习惯说“我用了某某模块、跑了多少毫秒、降低了多少开销”代理人需要听到的是“相对于现有技术采用某种特定结构解决了某个技术问题产生了某种预料不到的技术效果”。前者是描述后者是论证。1.2 三块苦活到底苦在哪挖专利点难在“把隐性的创新显性化”。很多工程师觉得自己每天都在做重复劳动根本没创新但实际上他自己调了一周的Bug、绕过了一个架构陷阱、换了一种数据结构——这些全是潜在的专利点只是没人帮他系统梳理。写交底书难在“结构化表达”。交底书有固定套路但也有固定的雷区。背景技术不能写成产品介绍发明内容不能写成代码注释具体实施方式不能只说“用了某种算法”必须讲清楚参数范围、可选方案、技术效果的对应关系。没有模板新人根本写不来。整理申请文件难在“术语一致性和逻辑闭环”。摘要、权利要求书、说明书三者的表述必须严格对应权利要求书的每个词都要有说明书支持否则后续审查意见会一条条打回来。这三步每一环都消耗大量时间而且容错率极低。1.3 通用大模型为什么救不了专利撰写有人会说不是有ChatGPT吗让它写不就行了。我试过。通用模型写出来的东西有三个问题一是没有步骤感它不知道你目前处在“挖掘”还是“交底”还是“申请文件”阶段经常混着写二是对专利审查逻辑没有概念写出来像技术博客不像法律技术文件三是它不会主动追问关键信息——你给什么它写什么给少了它也能编编出来全是废话。这个专利Skill解决问题的思路完全不同它先把专利工作拆成固定流程然后在每个流程里塞入对应的方法论、提示词模板、规范检查表让AI按一个专业助理的标准路径来执行。这也正是“Skill”这个形态在最近半年快速流行的原因——它不只是提示词它是“提示词 知识库 工作流”的打包。2. 拆开这个10k星Skill它不是提示词是一套完整SOP2.1 Skill的底层形态一个目录加一个说明书目前主流的AI Agent平台都开始支持Skill机制无论是Claude这边的Agent Skills还是其他支持类似规范的工具。一个Skill的基本形态就是一个文件夹patent-skill/ ├── SKILL.md ├── prompts/ │ ├── mining.md │ ├── disclosure.md │ └── application.md ├── references/ │ ├── claim-structure.md │ ├── disclosure-template.md │ └── examination-guidelines.md └── examples/ ├── example-mining-output.md └── example-draft-output.mdSKILL.md是整个技能包的说明书里面写了这个Skill能做什么、调用条件是什么、输入输出格式是什么、内部有哪些子模块。AI Agent读到这个文件就知道“哦当用户让我写专利相关的东西时我应该按这套规则来”。prompts目录下是不同场景的提示词references是知识背景examples是输出示例。这个结构有一个非常大的好处普通人也能看懂整个流程而且可以自己改。你觉得它挖点的思路不够细直接改prompts/mining.md就行不需要懂代码。2.2 专利Skill的模块划分我拉下来看了一圈这个项目的模块划分很符合专利实务的真实节奏它不搞那种“一键生成专利”的噱头而是老老实实分了三条线模块输入输出对应实务环节专利挖掘技术方案描述、研发背景、实验数据候选创新点清单、可专利性初步判断研发内部挖掘交底书生成创新点清单、技术细节结构完整的交底书初稿研发→代理人交接申请文件整理交底书、审查意见、补充材料摘要、权利要求书、说明书初稿代理人撰写初稿这三个模块是串行关系挖掘的结果是交底书的输入交底书的质量直接决定申请文件的产出。打个比方它像一条小型流水线而不是一个万能生成器。这个设计我挺认可因为专利工作本身就是分阶段的每一阶段的稿件用途、读者、审查标准都不一样。2.3 为什么“检查表”比“自由发挥”重要这个项目里最值钱的东西可能不是那些prompt而是references里的一系列检查表。比如写权利要求书之前它会先过一遍是否包含必要技术特征缺少任何一个都无法解决技术问题是否使用了清楚、确定的术语有没有“大概”“可能”这类模糊词独权和从权的引用关系是否正确每个技术特征是否都能在说明书里找到对应描述这些条目全是专利代理师日常审核稿件时心里默念的点但普通人不知道。Skill把这一层隐性知识显性化了AI在生成内容的时候会主动对着检查表自检而不是“自由发挥”。这一点是它和普通prompt的核心差异——普通prompt要求AI写得“好”这个Skill要求AI写得“对”。3. 部署实操从GitHub克隆到第一个交底书产出3.1 环境准备与安装步骤先说明一下这个Skill依赖一个能加载Skill目录的AI Agent环境目前主流的Claude Code、Codex CLI等工具都支持。你需要做的就是把项目从GitHub克隆下来然后放到Agent指定的skills目录里。以Claude Code为例# 克隆项目到本地 git clone https://github.com/你的账号/patent-skill.git # 进入项目目录 cd patent-skill # 把Skill复制到Claude Code的skills目录 mkdir -p ~/.claude/skills cp -r patent-skill ~/.claude/skills/不同Agent的目录位置不一样但逻辑都差不多本质上是“把技能包放在Agent能扫到的地方”。放好之后重启一下Agent终端让它重新加载技能列表。这里说一个我踩过的坑很多人直接把整个仓库clone到了项目目录里然后在别的目录启动Agent导致Agent完全没扫到这个Skill。正确做法是先看Agent的文档确认skills目录的扫描路径再决定软链接还是复制过去。3.2 首次调用测试放好目录之后最简单的一句话测试是请使用专利Skill帮我对以下技术方案进行专利挖掘……如果Agent正确加载了Skill它通常会先回你一句类似“好的我会按照专利挖掘的标准流程来处理先补充几个信息”这样的反馈。这时候你就知道它已经进入Skill的工作流了而不是走通用对话。我第一次测试的时候Agent直接问我“这个技术方案相对于最接近的现有技术核心区别是什么有没有实验数据验证效果”我当时愣了一下——这个追问方式非常像代理人不像通用AI。这说明它已经在按专利实务逻辑运转。3.3 常用配置项说明这类Skill一般会在SKILL.md里留几个可调参数比如输出语言、面向的专利类型、是否启用严格检查模式。我看了一下这个项目的默认配置配置项默认值我建议的调整输出语言中文保持中文技术领域通用如果你们公司是机械/软件/化学建议在配置里写明检查模式标准第一稿用标准模式终稿前开严格模式自问自答开启保持开启这个功能会主动追问关键信息技术领域这个参数一定不要省。同样是一个“结构优化”的描述机械领域关注的是连接关系、材料力学软件领域关注的是模块划分、数据流化学领域关注的是配比范围、反应条件。你不告诉它领域它就只能按通用框架来写输出的质量会差一截。4. 专利挖掘模块把“这玩意有点新”变成可表述的技术方案4.1 输入什么才能挖出东西挖掘模块是整个Skill里我最喜欢的一部分因为它解决的是“我不知道自己有什么可以申请”的问题。它的输入不需要你写出专利语言只需要你用人话描述你的工作。我在实测的时候用的输入是这样的我们的设备里原本用风扇给主芯片散热风扇噪音大、功耗高。我改成了在芯片背面贴合一块均热板 再把均热板延伸到外壳边缘利用外壳整个面来散热。试过之后芯片温度降了12度风扇可以降速运行 噪音从45分贝降到了32分贝。这段话就是普通工程师写周报的口吻完全没有专利语言。Skill拿到之后它不会直接写而是先做信息拆解原技术方案风扇主动散热核心技术改动新增均热板贴合芯片背面延伸至外壳技术效果温度降低、噪音降低、功耗降低相对现有技术的区别散热路径从“局部强制风冷”改成了“面接触被动散热”这个拆解过程非常重要因为它把一段流水账变成了结构化的“问题—方案—效果”三元组。后面它还会进一步追问均热板的厚度、材质铜、铝、石墨、芯片到外壳的距离、均热板与外壳的连接方式是否有间隙。这些追问全是代理师会问的问题因为缺少这些细节权利要求书根本写不完整。4.2 可专利性判断的三个维度挖掘模块在生成候选创新点之后会对着三个维度做一轮自检。这三个维度我建议每个研发都刻在脑子里新颖性这个方案是不是现有技术里完全没有出现过的组合哪怕原来是风扇现在换成均热板外壳组合只要没人这么干过就有新颖性。创造性这个方案是不是“本领域技术人员容易想到的”如果只是把A材料换成B材料且在已知范围内创造性就弱如果改变了整个散热路径的物理逻辑创造性就比较稳。实用性能不能制造、能不能使用、能不能产生效果纯理论的东西不满足实用性。我实测的输出里它不止列了创新点还按这三个维度给了初步结论比如“该方案创造性可能体现在导热路径的重新设计建议优先检索均热板外壳一体化的现有技术”。4.3 挖掘过程中容易漏掉的素材用了几次之后我发现大部分工程师给的输入里都缺三类信息一是实验数据。很多人只说“效果好很多”但不说具体多少。温度降12度、噪音降13分贝这些数据在交底书里是“有益效果”部分的论据而在挖掘阶段数据还能反向辅助判断技术特征是否必要——如果去掉均热板温度就压不住均热板就是必要技术特征必须写进独权。二是失败经历。调试过程中遇到的坑恰恰是“预料不到的技术效果”的最佳证据。比如你试过用导热硅脂直接贴外壳效果不好后来改成均热板才解决——这条“弯路”本身就能证明均热板方案不是显而易见的。三是边界条件。你的方案在什么范围内有效超过某个厚度均热板效果不再提升低于某个温度反而有冷凝风险这些边界条件写清楚权利要求的保护范围才能画好。Skill的追问里会带这些角度但它只能问答得出来还是得靠你脑子里那些没写进周报的细节。5. 交底书生成标准结构下的工程化写作5.1 交底书的黄金结构交底书是研发和代理人之间的翻译文件它的受众是代理人但不能默认代理人懂你的技术。所以一份完整的交底书至少要覆盖六个部分章节内容要求常见错误发明名称体现技术领域技术方案类型写得太宽泛或太像产品名技术领域一句话说明属于哪个技术方向复制粘贴项目名背景技术现有技术的方案缺陷写成产品宣传或纯技术综述发明内容要解决的技术问题、技术方案、有益效果与背景技术没有逻辑呼应具体实施方式至少一个完整可实现的实施例只写抽象概念不给参数附图说明结构图/流程图的对应说明有图无标注或无图这个结构不是谁拍脑袋定的它对应的是后续申请文件里“说明书”五部分的雏形。交底书写得清楚代理师翻译成权利要求书的效率就高交底书写得含糊后续来回沟通的成本会翻倍。5.2 Skill如何写“背景技术”这是我观察下来它写得最好的一个部分因为通用AI最容易在背景技术上翻车——它们会把背景技术写成“现有技术综述”大段引用行业常识完全没聚焦到问题本身。这个Skill写背景技术的逻辑是先定位最接近的现有技术然后用两三句话描述它的核心方案再重点指出它的缺陷。而且缺陷必须和你的发明所解决的问题对应。比如上面散热方案的例子它会写“现有散热方案通常采用轴流风扇强制对流芯片热量通过散热鳍片与空气热交换排出。该方案存在如下缺陷风扇运转产生持续噪音主动散热需持续供电增加整机功耗在密闭或小型化设备中散热风道受限鳍片热交换效率大幅下降。”注意这段话的表述每一句都在为后文的发明内容铺路——噪音对应“降噪效果”功耗对应“降低功耗”风道受限对应“外壳侧面散热”。背景技术和发明内容之间必须是“挖坑—填坑”的关系而不是各写各的。5.3 发明内容与具体实施方式的分工很多新人搞不清楚发明内容和具体实施方式的区别以为把方案重复写两遍就行了。实际上两者分工完全不同发明内容部分要说“我的方案是什么、能解决什么问题、效果怎么样”它是概述用的语言要略微抽象为后续权利要求的保护范围留空间。尤其“技术方案”这一段经常是权利要求书的文字雏形到时候代理师会直接从这里抽出独权。具体实施方式部分要说“这个方案在真实产品里怎么做、参数是多少、有没有替代方案”它是展开要具体到本领域技术人员能够实现。Skill在处理这两部分时会刻意控制抽象和具体的比例发明内容里的“均热板”不会轻易限定材质和厚度但具体实施方式里会列出铜板、铝板、石墨片、均热板厚度范围0.3-2.0mm、贴合方式用导热胶或钎焊等。5.4 人工必须介入的三个位置我必须泼一盆冷水交底书生成这个环节AI能做的大约是60%的框架搭建和素材组织剩下40%必须人工补缺了这40%交底书会非常“像样但虚”。第一个必须人工补的是真实实验数据。Skill生成的有益效果部分是推测性的它可能写“有效降低芯片表面温度”但你必须把“12度”“32分贝”这些实测数字填进去才有说服力。第二个必须人工补的是替代方案和可变换的设计。同样实现面接触导热除了均热板还可以用热管均热板组合、还可以用相变材料填充间隙。你是实际做过的人你知道哪些替代方案真能成立AI不一定判断得准。第三个必须人工补的是“发明点在哪一层”。如果一个方案里既有硬件改动又有软件逻辑调整哪个是主创新点哪个是辅助创新点这个判断需要研发对项目投入的理解深度。AI能把两条线都列出来但分主次得你说了算因为单独申请和打包申请的策略完全不同。6. 申请文件整理摘要、权利要求书、说明书的分工与衔接6.1 申请文件与交底书的关系交底书写完之后Skill的第三个模块开始介入申请文件的整理。这里有一个容易误解的点申请文件不是交底书的“格式化重排”而是换一种法律技术语言来重新表达。交底书可以按研发习惯写想到哪写到哪申请文件必须按审查要求组织尤其是权利要求书它的每一句话都在划定法律保护范围。这个范围既不能太宽太宽会被现有技术打回来也不能太窄太窄了别人轻松规避。所以Skill在处理申请文件时第一步不是生成而是做一次“交底书信息完整度检查”列出缺项让用户补充然后再动笔。我在实测时发现它甚至会追问“均热板与外壳边缘的连接处是否有密封设计”这个问题直接关系到独权要不要写“密封结构”这个技术特征。6.2 权利要求书初稿的生成逻辑权利要求书是专利文件里最核心也最讲究的部分。Skill生成的独权逻辑我看了下基本是标准的“前序部分特征部分”结构一种电子设备散热结构其特征在于包括 ——壳体具有外壳表面 ——热源设置于所述壳体内 ——均热板贴合于所述热源背离所述壳体底壁的一侧并自该侧延伸至所述壳体的外壳边缘 其中所述均热板通过所述外壳边缘与外部环境进行热交换。这个写法符合基本要求把设备的基础组成部分放在前序把作出改进的技术特征放在“其特征在于”之后。但说实话第一稿的权利要求书通常需要人工大改因为保护范围的大小要靠经验拿捏。Skill能做的是保证你不犯结构性错误比如把非必要特征写进独权、引用关系混乱、术语不一致。这类错误如果是人工写代理师可能返工三遍用AI生成初稿至少第一遍就能把骨架搭对。6.3 说明书与摘要的整理要点说明书是权利要求的支撑审查意见里最常见的负面评价就是“权利要求得不到说明书支持”。Skill在处理说明书的时候会强制把权利要求书里的每个技术特征展开到具体实施方式中。例如权利要求写了“均热板延伸至外壳边缘”说明书里必须展开说明延伸的具体路径、长度比例、与外壳的连接方式、材料选择对导热效率的影响。这些细节在交底书里通常都有但散落在各处Skill的贡献是帮你把它们归位。摘要相对简单它是“技术问题技术方案技术效果”的三句话压缩包。这里也有个常见错误摘要写完忘了和权利要求书对应。Skill会做一致性检查保证摘要里出现的每个技术名词都在权利要求书里有定义不会出现摘要写“散热膜”而权利要求写“均热板”这种术语漂移。6.4 一种高效的“三步审校法”用Skill整理完申请文件初稿后我自己总结了一套三步审校法分享出来供参考第一步通读权利要求书只干一件事逐个技术特征比对现有技术问自己“这个特征是不是必要的去掉它行不行”。不能去掉的留在独权里可以去掉但能优化效果的放到从权里。我实测里第一次生成的独权有7个技术特征我砍掉了2个保护范围立刻大了不少。第二步拿权利要求书当索引翻说明书确保每个特征在说明书里都能找到对应展开。找不到就用补充实施方式的方式补进去不能删权利要求了事。第三步排序和术语统一。全文检查一遍术语表均热板、散热板、导热板不能混用。这一步是最耗时的但也是AI做不了的——术语的选择会影响后续侵权判定时的解释空间。7. 实测案例一个散热结构专利从输入到初稿的全程记录7.1 实测环境与输入内容为了写这篇文章我专门在自己的环境里完整跑了一遍流程。环境是Claude Code配合本地部署的专利Skill输入就是前面提到的那段散热方案描述。我没有做任何修饰完全模拟一个普通工程师的“周报语气”。7.2 各阶段输出的质量观察第一轮专利挖掘输出质量惊喜。它给了6个潜在创新点从“均热板外壳一体化散热结构”到“可变转速风扇控制逻辑联动”再到“贴合层材料与导热系数的优化选择”。其中有些角度我自己都没意识到——比如它指出“散热路径从局部风冷改为面接触被动散热”本身就是一种可申请的“散热方法”而不只是“散热结构”。这就是典型的将“产品专利”扩展出“方法专利”的思路很多研发意识不到这一层。第二轮交底书生成初稿可用度约七成。结构完全合规逻辑链清晰背景技术和发明内容衔接得好。需要我手动补的是真实测试数据、均热板厚度范围、以及一组对比实验单风扇 vs 风扇均热板 vs 纯均热板的具体数据表。第三轮申请文件整理权利要求书骨架可参考但保护范围需要调。它生成的权利要求偏具体把所有实施例里的参数都写进去了这是AI的普遍毛病——它倾向于“安全地写具体”而不是“有策略地写抽象”。所以我把独权里关于厚度、材质、连接方式全部删掉或者降级到从权才得到合理的保护范围。7.3 意外情况与修整过程过程里也出了一次问题第一版交底书里Skill把“均热板延伸到外壳边缘”理解成了“均热板外露在外壳表面”这会导致防水防尘的技术问题。我在修整时补了“均热板位于外壳内侧与外壳边缘区域导热接触不直接外露”的描述后续权利要求书才没有跑偏。这种细节误差说明一个道理Skill可以帮你把80%的框架搭好但最后20%的“技术事实准确性”只能靠懂技术的人把关。AI不理解你的产品真实长什么样它只会照着文本逻辑推而专利文件的致命伤恰恰是“逻辑无误但事实错误”。7.4 效率对比和适用建议从我实测的耗时来看用Skill辅助一个普通技术方案的专利申请前期工作大致是这样的节奏环节纯人工习惯耗时Skill辅助耗时专利挖掘思路梳理2-3天含拖延2小时出候选点交底书初稿2-4天半天含人工补数据申请文件初稿思路整理2-3天3小时出骨架代理师审校修改无法节省依然无法节省注意我不建议把这个时间差宣传成“AI替代代理人”。它的价值恰恰是让研发在进入代理人环节之前手里已经有一份像样的交底书原来可能要来回磨一个月的需求沟通压缩成一次高质量的信息传递。8. 这套Skill的边界在哪里以及我为什么不建议你“全自动”8.1 AI做得好的环节和做不了的环节经过这段时间的使用我倾向于把Skill的职责边界分成两个清单。它能做好的信息结构化、规范性审查、术语一致性、框架搭建、多角度思路补充、以及“用专利语言把你的技术描述重写一遍”。这些环节的共同点是“有明确规则、有标准格式、有大量历史样本”AI在规则清晰的领域确实高效。它做不了的创造性判断的最终决策、保护范围的策略权衡、真实实验数据的补充、技术事实的准确性验证、以及“这个专利到底值不值得申请”的商业判断。这些环节靠的是研发对技术的理解深度、代理师对审查实践的把握、以及企业对专利布局的战略考量AI目前没有能力也没有立场替你做这些决定。8.2 误用场景把它当“专利生成器”的人我在网上看到一些评论抱怨“用这个Skill生成的东西根本不能直接用”。我看了下他们的用法基本都是在输入框里丢一句话然后让AI直接生成全套申请文件接着拿这个去申报。这不是Skill的错是用法错了。专利文件是有法律后果的文件它不是你写博客错了删掉重来专利一旦申请提交修改范围受到严格限制前期草率后期寸步难行。还有个更隐性的风险如果一个企业内部多名研发都直接用AI生成交底书而不做个性化修改最后产出的技术方案描述很容易出现相似的表述模式。虽然专利审查不看你是不是AI写的但近似文本放在不同的申请里可能导致审查员认为技术方案没有明显区别影响审查结果。所以我一直强调AI生成初稿研发必须做实质性改写尤其是实施例和技术参数的描述。8.3 我建议的正确用法三明治工作流最后分享一下我个人目前的工作流管它叫“三明治”——人工、AI、人工三层夹着来。第一层人工把技术方案的关键信息整理清楚包括核心技术改动、实验数据、失败经历、边界条件。这层信息越丰富AI后续输出的质量越高。我给这个Skill喂料花的时间通常比它跑的时间还长但这段时间花得值。第二层AI让Skill依次跑挖掘、交底、申请文件三个模块每一轮都拿输出结果和我自己的思路做对照。它会提供我没想到的角度也会暴露我自己没想清楚的模糊点。第三层人工对AI产出的每一段涉及技术事实的内容进行逐句核对对权利要求书的保护范围做策略性调整对术语和全文逻辑做最终审校。然后再交给代理师去处理法律细节。这三个环节里AI是放大器和脚手架不是决策者。如果你想给自己的专利工作提效拿它来搭框架、查漏补缺、对齐规范是值得的如果你想省掉动脑子的环节直接拿AI文档去申请那我不太建议。专利这个东西最后在法律文件上签字的还是人签字的人就得对内容负责。
