1. 项目概述一个10k星的开源专利Skill到底解决了什么问题这个项目说起来挺直白一套托管在 GitHub 上的开源“专利 Skill”技能包靠着挖专利点、写交底书、整理申请文件这三项能力拿下了 10.0k star而且完全免费。它不是商业软件也不是传统意义上那种“套模板生成文件”的在线工具而是以 AI 智能体技能Skill形式存在的开源资产。你可以把它装进支持技能机制的 AI 助手里也可以接到本地部署的模型上让它变成一个随时可调用的“专利协作流程”。为了后面叙述方便我统一用 PatentSkill 来指代这套开源技能包。先说这个项目适合谁。我最直接的反应是它首先是给研发工程师用的。很多工程师做了好几年技术一提专利第一反应是“手头这点优化没什么值得申请的”但现实是有授权前景的创新点往往藏在“不起眼的细节改进”里。第二类适合的是企业 IPR 和专利工程师他们每天要消化大量交底书发明人写的初稿通常需要大改这套技能可以把初稿质量抬起来让专业时间花在真正复杂的权利要求布局上。第三类是技术管理者想用最低成本把研发产出转成无形资产在没有充足预算请外部代理做全量挖掘的阶段这样一个免费开源技能包就相当于前置筛选器。从使用链路看它把专利工作拆成了三个环节挖专利点、写交底书、整理申请文件。为什么是这三段因为这是企业专利流程里最耗时、最需要“翻译”能力的三段。技术本身在发明人脑子里专利文件是代理人、审查员使用的语言中间隔着巨大的表达鸿沟。PatentSkill 做的事就是不断用提问和模板把隐形的技术信息翻译成显性的结构化描述。这也是它区别于其他“一次性生成脚本”的核心设计。1.1 它不是普通提示词而是把老师傅经验做成“技能包”很多人第一次听到“Skill”反应是“这不就是一段 prompt 吗”。我一开始也这么想实际用下来差别很大。普通提示词像你临时抓一个专家来聊天问得好就答得好换个说法可能就崩了Skill 则像一个封装好的标准流程内部至少包含四样东西角色与边界设定、任务拆解步骤、输出模板与字段约束、示例库与校验清单。打个比方。普通提示词是你问路边大厨“这道菜怎么做”他凭经验和状态给你讲一段话Skill 是经过反复测试的菜谱写明了配料克数、火候、装盘和常见的补救手法任何人照着跑都能接近同一个结果。PatentSkill 的价值就在确定性——它不靠“灵感”造专利点而是把专利挖掘和交底书写作拆成可重复执行的步骤让 AI 每一次输出都有结构、有依据、不飘。这套技能包能做到 10k 星我觉得本质上不是靠花哨的界面而是靠“沉淀老师傅经验”这个动作本身。GitHub 上跑过不少专利相关脚本但很多是一次性的“生成器”或者半成品模板这个项目把“从技术到法律文件”的整套翻译流程固化成可复用资产并且不绑定单一平台这才带动了口碑。1.2 专利链路为什么天然需要AI技能化写交底书这件事的反直觉程度只有写过的人才知道。工程师习惯讲“我优化了什么”专利需要讲“方案由哪些技术特征构成、解决了什么问题、为什么能解决”。一个是结果导向一个是特征导向中间的翻译恰好是大模型擅长的事。专利挖掘真正难的地方是“不知道自己不知道”。工程师看自己的技术久了容易把改进想得太小觉得“就换了个材料哪算创新”。但专利审查看的是该方案和现有技术相比有没有区别特征区别特征是否非显而易见。有价值的创新点不一定惊天动地。PatentSkill 通过设定好的提问模板把“与之前相比多了什么部件、少了什么步骤、成本降了多少、性能稳不稳定”这类问题反复抛给发明人一点点撬出隐性信息。另外一个现实原因是企业内部真正值钱的专利往往来自已经被验证过的细节改进这类细节最容易流失。项目一忙没人记录几个月后想申报当事人自己也说不清当时的方案参数了。所以我把这个技能当成“研发过程中的记录器”而不是“申报前的加速器”这也是我向研发团队推荐它的核心原因。用一个判断标准收尾这部分当你拿一个开源技能包时要看的不是它能生成多少字而是它能不能每次稳定地把你推向“结构化的技术特征”。能就是好技能包只是会聊天那就是玩具。2. 三大核心功能拆解挖点、交底书、申请文件2.1 挖专利点从研发项目里筛出能打的新颖方向挖专利点是整条链路里最关键的一环。它的工作方式不是让 AI 凭空给你十几个专利点子而是通过一组“问题—手段—效果”的主线把项目拆开再逐条判断差异点有没有申请潜力。我用下来最欣赏的是它内置的“多维度扫描”。PatentSkill 会按五个维度走一遍功能改进原来做不到的现在做到了性能提升响应速度、精度、稳定性这类指标变了成本优化工序减少、材料替代、能耗下降体验改善操作更简单、交互更自然可维护性提升故障更容易定位、模块更容易替换。每个维度下会生成一个“创新点候选 证据要求”的小卡片发明人就着卡片勾选“哪个点我有真实验证数据”。这一步设计得很聪明因为它逼着人不把“感觉”当“事实”。它还设了“必要技术特征”反问这个方案里哪些特征是实施所必需的哪些特征是可以替换的换成别的之后效果还成立吗这其实是专利代理人写独立权利要求时的经典思维却被前置到了挖掘阶段。我见过不少交底书失败案例都是因为发明人把自己以为的亮点一股脑全写进独立权利要求导致保护范围又窄又脆如果早点做这个自检会少走很多弯路。2.2 写交底书把几个星期的成果浓缩成两页结构确认创新点之后调用“写交底书”模块Skill 会按标准技术交底书的结构输出初稿发明名称与技术领域、背景技术及缺陷、发明目的、技术方案、有益效果、具体实施方式、附图说明与附图标注。每个章节有硬性要求比如背景技术必须写清楚现有方案是什么、现有什么问题、这个问题和本方案之间有什么因果联系而不是堆“现有技术较为落后”之类的空话。它最打动我的一个细节是“三层技术特征”的分层要求第一层是必要技术特征缺了它方案不成立第二层是附加技术特征属于优化项适合放进从属权利要求第三层是效果验证数据比如对比测试结果、实验数据用于后续创造性论证。大部分非专业发明人写交底书脑子里根本没有这三层区分结果就是技术方案一团糊。PatentSkill 把这一套引导做成了强制结构AI 的输出质量立刻就不一样。这里必须提醒一条红线交底书初稿生成后所有技术细节都必须人工核验。专利是“以公开换保护”的制度技术方案要写到本领域技术人员能够实现的程度。AI 不会帮你补实验也不会知道你用的材料牌号是不是真的替代得动。凡是涉及参数范围、工艺流程顺序、结构连接关系的内容必须发明人亲自确认再作为正式方案展开。2.3 整理申请文件让交底书向“专利五书”靠拢第三个模块“整理申请文件”负责把交底书翻译成申请文件初稿的骨架包括请求书要素、说明书、权利要求书、说明书附图说明和摘要。它的工作逻辑是先抓出“必要技术特征”作为独立权利要求的雏形再把“附加技术特征”拆成多条从属权利要求并标注引用关系。实测下来生成从属权利要求是它最稳的部分因为从权本质是“原方案加限定”AI 对这种排列组合很擅长。用户只要确认好“附加特征池”的粒度它就能按单一从权、多从权引用等模式生成一批候选写法供代理人做选择。但注意这份内容只能叫“草稿框架”不能直接当成申请文件提交。权利要求保护范围宽窄是否合适、独权是否缺少必要技术特征、说明书是否支持权利要求这些都要由有资质的专利代理师把关。不少这类项目的 README 里都注明“本工具不构成法律意见”这是负责任的提醒。如果让我再总结一句这个模块适合“把工作量从三天压缩到半天”但不适合“把人都省掉”。专业的事永远要专业的人来拍板。3. 实操全流程获取、安装、跑通一个真实案例3.1 获取与安装把Skill装进你自己的智能体安装方法取决于你手里用的是哪款支持 Skill 机制的智能体。这一类开源项目通常以目录结构发布下载下来后把 skills 目录下的各个子文件夹放进去再在配置文件里声明名称和描述重新加载后就能用命令触发。我习惯的通用操作流程是四步。第一步在 GitHub 上找到项目页面看 README 确认它支持的 Skill 目录格式第二步把仓库克隆到本地第三步将 skill 文件夹复制到你的助手约定目录第四步在对话里问一句“请加载专利挖掘 Skill”如果返回的是结构化引导提示说明加载成功。给你看一个典型的目录结构骨架我手动整理过patent-skill/ ├── README.md ├── LICENSE ├── skills/ │ ├── patent-mining/ │ │ ├── SKILL.md │ │ └── templates/ │ │ ├── innovation_scan.md │ │ └── comparison_table.md │ ├── disclosure-drafting/ │ │ ├── SKILL.md │ │ └── templates/ │ │ ├── disclosure_structure.md │ │ └── three_layer_feature.md │ └── application-prep/ │ ├── SKILL.md │ └── templates/ │ └── claims_outline.md └── examples/ ├── example_water_temp_module.md └── example_ui_interaction.md不同平台的配置方式略有差异但核心就一条让助手能读到 SKILL.md 和 templates 目录里的内容。安装过程不涉及任何授权或者密钥这也是开源免费项目的优势——代码完全在你手里你甚至可以把它改造成符合自己公司术语体系的内部版本比如把“背景技术”改成你团队习惯的表达把示例换成自己产品线里的真实场景。3.2 真实演练水温监测模块的专利点挖掘到交底书我拿一个典型硬件场景来演示。某团队做“工业冷却水温度监测模块”改进点是“把外置的温度传感器集成进不锈钢壳体并在壳体上增加自检用的加热元件”。第一步调用挖专利点模块输入以下信息项目名称工业冷却水温度监测模块现有技术外置 PT100 温度传感器螺纹安装传感器头部暴露在水中本方案描述传感器与不锈钢壳体一体化封装壳体底部新增微型加热电阻周期性地执行温漂自检主要诉求想解决现场校准繁琐和传感器结垢导致的测量不准Skill 会输出五个维度的扫描结果。在这个案例里“功能改进”维度会给出高潜力点一体化封装加内置自检热源实现了“不拆卸状态下的在线自校”。对照其他维度后我锁定这个点因为它具备完整的三要素技术问题结垢导致漂移、技术手段内置热源加温漂检测算法、技术效果无需拆卸即可判断偏差。第二步调用写交底书模块把技术信息按三个层级喂进去必要技术特征温度传感器与保护壳体一体化安装壳体内设有可控加热元件附加技术特征加热元件间歇性工作在未加热时段与加热时段分别采样并求差效果验证数据结垢 2mm 条件下本方案自检误差不超过 0.1℃传统外置方案偏差达 0.8℃AI 输出的交底书初稿会围绕这三点展开背景技术、技术方案、有益效果写得很规整代理人拿到后基本不用补框架只需要看数据来源和使用场景是否写得足够具体。最后再用整理申请文件模块生成初步的权利要求骨架整个流程半小时内就能走完一遍。对一个以前要磨两三天的交底书来说这个效率提升是实打实的。3.3 输入参数模板以及把输出质量抬上来的技巧用过一段时间后我总结了一套比较有效的输入模板四块信息能覆盖八成场景。技术领域与产品背景一两句话说明产品是什么、用在哪现有技术及痛点写具体不足比如精度偏差、校准停机时间别写“不好用”本方案差异点按“多了什么、少了什么、改了什么”来说效果验证数据哪怕只有一组初步实验数据也直接贴进来。想让输出质量再上一个台阶我有个很实用的小技巧尽量用“对比表”形式输入而不是一连串文字。比如这么写维度现有技术本方案安装方式外置螺纹安装一体化封装校准方式人工拆卸、季度校准内置热源自检无需拆卸结垢 2mm 时的误差0.8℃0.1℃这种结构化对比对模型的信息抽取能力非常友好它会自动把两边差异识别成“技术特征组合”再据此判断哪些点适合独立申请、哪些点适合做成从属权利要求。我自己用下来同样的项目背景用表格输入比纯文字输入的可用度高出一大截。别嫌这个动作麻烦它比事后改三版交底书要省力得多。4. 高频问题与排查技巧4.1 生成内容“AI味”重全是空话怎么办这个问题不是专利 Skill 独有所有生成式工具都会遇到。根因多数是输入信息太稀疏。你只给“现有技术效率低、成本高”模型也只能回“本方案提高效率、降低成本”这种让人提不起精神的句子但你要是写“现有方案每季度需人工拆卸校准单次停机 4 小时”输出立刻就会落到具体比较上。我常用的补救手段是“强制细节追问”让 Skill 在每个技术特征后面自己补一句——该特征是否必须存在是否可以替换替换后对效果的影响是什么并把这些补充信息单独列出来。如果 AI 在“编”参数那不是它飘了而是上下文里没有足够的事实约束及时回填真实信息即可。4.2 挖出的创新点其实早就被别人申请了专利挖掘最怕的不是没点子而是点子不够新。Skill 的输出不能替代专业查新检索。我的做法是把它输出的每个候选点当成“检索线索”用公开专利数据库做一次粗检。检索的重点不是看标题像不像而是比对该创新点对应的“技术特征组合”尤其是必要特征那一层。另外AI 有时会给出一个范围特别大的点比如“一种传感器自校准方法”这种大领域通常布满在先专利。遇到这种情况别急着放弃把它收敛降维。往“工业冷却水环境 不锈钢一体化封装 间歇式加热自检”这个具体组合上靠很可能你就绕开了拥挤的宽泛区域。真正好的专利挖掘本质上就是把“好听的创意”收敛成“具体到不撞车的技术方案”。4.3 输出结构不稳定、字段缺失怎么解同一次对话里偶尔会出现章节缺失尤其输入特别长的时候。解决办法是给 Skill 很强的格式约束要求它严格按给定 Markdown 模板输出碰到缺字段就写“待补充”绝对不要省章节。这种显式约束会压住模型偷懒的冲动。如果平台允许还可以在 Skill 里加一个“输出自检”步骤让它在交付前核对一遍关键字段发明名称、背景技术、必要技术特征、有益效果一个都不能少。还有一个我踩过的坑不要同时在会话里加载多个 Skill。有一次我把“挖专利点”和“写交底书”同时开着结果它把交底书的背景技术写成了创新点罗列角色都串了。一个会话一个 Skill是更稳妥的策略。4.4 问题速查表遇到问题可以直接查下表现象可能原因处理方式输出全是宽泛套话输入没有具体技术事实补充现有技术痛点、差异点、验证数据创新点重复度高范围太宽未结合具体特征缩小到必要技术特征的组合维度再检索交底书缺具体实施方式输入参数缺少过程性信息补写材料牌号、工艺步骤、连接关系从权写得像说明书附加特征与必要特征未分层用三层特征模板重新梳理多个模块输出互相污染同时加载多个 Skill拆成独立会话一次只用一个这五类现象几乎覆盖了新手前两周会遇到的大部分问题。总的原则是别把生成结果当结果把它当“第一版草稿”后面所有环节都需要人站在专业立场上做裁判。5. 把PatentSkill接进研发日常的三种姿势5.1 在代码PR流程里做“顺风车”式提示研发团队最不缺的就是技术改动最缺的是把改动同步记录成“潜在专利资产”。你可以把专利挖掘动作挂在代码合并流程之后每次 PR 合并时由 Skill 基于变更文件、改动描述和关联任务自动生成一张“潜在专利点提示卡”内容包括涉及的技术领域、可能的核心特征、建议补充的实验数据。这样不打断开发节奏但相当于每个重要改动都留下一张带时间戳的“技术记忆”。这个用法对管理者的价值尤其大。季度复盘专利时不用再翻聊天记录或者问“当时为什么这么改”系统里已经有一批轻量预筛结果人工只需要每周花几分钟删改勾选。时间一长积累下来的素材库比临时抱佛脚写出来的交底书扎实得多。5.2 与技术评审、项目文档联动在技术方案文档或者评审结论里可以顺手加一段“创新点假设”由 Skill 把已经写明的方案自动抽成候选专利点。技术人员在写周报、写详细设计时本来就不可避免地要描述“方案、理由、效果”Skill 做的事情只是多加一道映射。我团队现在的做法是每次详设评审通过后给技术负责人发一条“可申请性初筛建议”并附一句话如果觉得值得申报下周用完整挖掘流程跑一遍。半年下来技术资产记录的整齐程度远胜从前。这不是让 AI 替工程师思考而是让工程师随手把思考痕迹留下来。5.3 用竞品公开专利反向寻找迭代方向第三个场景有点进阶把竞品的公开专利号或标题贴给 Skill让它提取权利要求骨架然后基于这些特征反向列出“如果我们想避开这些特征可以从哪些路径切入”的研发思路。这个用途对研发决策层很实用因为它把竞争情报变成了可操作的方向清单。需要强调的是这一步只适合内部研发方向参考绝不应该替代专业机构的侵权分析和规避设计。专利风险判断涉及法律解释和具体司法实践不是生成式工具能拍板的。理解边界才用得好开源工具。写到这里我想停一下说点个人体会。这套开源专利 Skill 真正稀缺的不是那几段提示词而是它把“专利思维”变成了一种研发团队可以低成本复用的流程。我拿它搭过一套轻量级专利预审流程最明显的变化不是专利数量涨了多少而是工程师开始觉得专利工作“够得着”了。如果你也想试建议不要一上来就追完美的交底书先拿一个真实项目的技术方案跑一遍完整挖掘体会一下“从技术细节到技术特征”的翻译过程后面的事自然就顺了。