我見過太多研發(fā)工程師代碼寫得漂亮一提到專利就頭大。不是不想寫是根本不知道從哪下手。挖專利點、寫交底書、整理申請文件——這三件事聽起來是專利代理人的活但真正干過的都知道最前面的功夫全在研發(fā)手里。所以當(dāng)我看到GitHub上這個專門做專利的Skill項目而且Star沖到了10.0k的時候第一反應(yīng)不是“又一個AI套殼”而是趕緊拉下來跑了一遍。先說結(jié)論這個開源的專利Skill本質(zhì)上是把專利實務(wù)的整套SOP封裝成了AI Agent能直接調(diào)用的“技能包”你只需要把一個技術(shù)方案丟給它它就能按步驟幫你挖創(chuàng)新點、生成交底書、整理出申請文件的初稿結(jié)構(gòu)。全程免費(fèi)本地運(yùn)行數(shù)據(jù)也不出自己機(jī)器。這篇文我就把安裝、用法、實測結(jié)果還有我個人踩過的坑全部寫出來。1. 專利這行的真正痛點不在撰寫在“翻譯”1.1 研發(fā)與代理師之間的溝通斷層專利申請這件事行業(yè)里默認(rèn)是代理人的活但實際推進(jìn)的時候卡點永遠(yuǎn)在研發(fā)這邊。我見過太多方案研發(fā)自己覺得“很先進(jìn)”但要他說清楚現(xiàn)有技術(shù)是什么、你的方案和現(xiàn)有技術(shù)差在哪、這個差異帶來了什么效果——他就開始含糊其辭。這不是研發(fā)能力不行而是專利語境和工程語境是兩套語言。工程師習(xí)慣說“我用了某某模塊、跑了多少毫秒、降低了多少開銷”代理人需要聽到的是“相對于現(xiàn)有技術(shù)采用某種特定結(jié)構(gòu)解決了某個技術(shù)問題產(chǎn)生了某種預(yù)料不到的技術(shù)效果”。前者是描述后者是論證。1.2 三塊苦活到底苦在哪挖專利點難在“把隱性的創(chuàng)新顯性化”。很多工程師覺得自己每天都在做重復(fù)勞動根本沒創(chuàng)新但實際上他自己調(diào)了一周的Bug、繞過了一個架構(gòu)陷阱、換了一種數(shù)據(jù)結(jié)構(gòu)——這些全是潛在的專利點只是沒人幫他系統(tǒng)梳理。寫交底書難在“結(jié)構(gòu)化表達(dá)”。交底書有固定套路但也有固定的雷區(qū)。背景技術(shù)不能寫成產(chǎn)品介紹發(fā)明內(nèi)容不能寫成代碼注釋具體實施方式不能只說“用了某種算法”必須講清楚參數(shù)范圍、可選方案、技術(shù)效果的對應(yīng)關(guān)系。沒有模板新人根本寫不來。整理申請文件難在“術(shù)語一致性和邏輯閉環(huán)”。摘要、權(quán)利要求書、說明書三者的表述必須嚴(yán)格對應(yīng)權(quán)利要求書的每個詞都要有說明書支持否則后續(xù)審查意見會一條條打回來。這三步每一環(huán)都消耗大量時間而且容錯率極低。1.3 通用大模型為什么救不了專利撰寫有人會說不是有ChatGPT嗎讓它寫不就行了。我試過。通用模型寫出來的東西有三個問題一是沒有步驟感它不知道你目前處在“挖掘”還是“交底”還是“申請文件”階段經(jīng)?；熘鴮懚菍＠麑彶檫壿嫑]有概念寫出來像技術(shù)博客不像法律技術(shù)文件三是它不會主動追問關(guān)鍵信息——你給什么它寫什么給少了它也能編編出來全是廢話。這個專利Skill解決問題的思路完全不同它先把專利工作拆成固定流程然后在每個流程里塞入對應(yīng)的方法論、提示詞模板、規(guī)范檢查表讓AI按一個專業(yè)助理的標(biāo)準(zhǔn)路徑來執(zhí)行。這也正是“Skill”這個形態(tài)在最近半年快速流行的原因——它不只是提示詞它是“提示詞 知識庫 工作流”的打包。2. 拆開這個10k星Skill它不是提示詞是一套完整SOP2.1 Skill的底層形態(tài)一個目錄加一個說明書目前主流的AI Agent平臺都開始支持Skill機(jī)制無論是Claude這邊的Agent Skills還是其他支持類似規(guī)范的工具。一個Skill的基本形態(tài)就是一個文件夾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能做什么、調(diào)用條件是什么、輸入輸出格式是什么、內(nèi)部有哪些子模塊。AI Agent讀到這個文件就知道“哦當(dāng)用戶讓我寫專利相關(guān)的東西時我應(yīng)該按這套規(guī)則來”。prompts目錄下是不同場景的提示詞references是知識背景examples是輸出示例。這個結(jié)構(gòu)有一個非常大的好處普通人也能看懂整個流程而且可以自己改。你覺得它挖點的思路不夠細(xì)直接改prompts/mining.md就行不需要懂代碼。2.2 專利Skill的模塊劃分我拉下來看了一圈這個項目的模塊劃分很符合專利實務(wù)的真實節(jié)奏它不搞那種“一鍵生成專利”的噱頭而是老老實實分了三條線模塊輸入輸出對應(yīng)實務(wù)環(huán)節(jié)專利挖掘技術(shù)方案描述、研發(fā)背景、實驗數(shù)據(jù)候選創(chuàng)新點清單、可專利性初步判斷研發(fā)內(nèi)部挖掘交底書生成創(chuàng)新點清單、技術(shù)細(xì)節(jié)結(jié)構(gòu)完整的交底書初稿研發(fā)→代理人交接申請文件整理交底書、審查意見、補(bǔ)充材料摘要、權(quán)利要求書、說明書初稿代理人撰寫初稿這三個模塊是串行關(guān)系挖掘的結(jié)果是交底書的輸入交底書的質(zhì)量直接決定申請文件的產(chǎn)出。打個比方它像一條小型流水線而不是一個萬能生成器。這個設(shè)計我挺認(rèn)可因為專利工作本身就是分階段的每一階段的稿件用途、讀者、審查標(biāo)準(zhǔn)都不一樣。2.3 為什么“檢查表”比“自由發(fā)揮”重要這個項目里最值錢的東西可能不是那些prompt而是references里的一系列檢查表。比如寫權(quán)利要求書之前它會先過一遍是否包含必要技術(shù)特征缺少任何一個都無法解決技術(shù)問題是否使用了清楚、確定的術(shù)語有沒有“大概”“可能”這類模糊詞獨權(quán)和從權(quán)的引用關(guān)系是否正確每個技術(shù)特征是否都能在說明書里找到對應(yīng)描述這些條目全是專利代理師日常審核稿件時心里默念的點但普通人不知道。Skill把這一層隱性知識顯性化了AI在生成內(nèi)容的時候會主動對著檢查表自檢而不是“自由發(fā)揮”。這一點是它和普通prompt的核心差異——普通prompt要求AI寫得“好”這個Skill要求AI寫得“對”。3. 部署實操從GitHub克隆到第一個交底書產(chǎn)出3.1 環(huán)境準(zhǔn)備與安裝步驟先說明一下這個Skill依賴一個能加載Skill目錄的AI Agent環(huán)境目前主流的Claude Code、Codex CLI等工具都支持。你需要做的就是把項目從GitHub克隆下來然后放到Agent指定的skills目錄里。以Claude Code為例# 克隆項目到本地 git clone https://github.com/你的賬號/patent-skill.git # 進(jìn)入項目目錄 cd patent-skill # 把Skill復(fù)制到Claude Code的skills目錄 mkdir -p ~/.claude/skills cp -r patent-skill ~/.claude/skills/不同Agent的目錄位置不一樣但邏輯都差不多本質(zhì)上是“把技能包放在Agent能掃到的地方”。放好之后重啟一下Agent終端讓它重新加載技能列表。這里說一個我踩過的坑很多人直接把整個倉庫clone到了項目目錄里然后在別的目錄啟動Agent導(dǎo)致Agent完全沒掃到這個Skill。正確做法是先看Agent的文檔確認(rèn)skills目錄的掃描路徑再決定軟鏈接還是復(fù)制過去。3.2 首次調(diào)用測試放好目錄之后最簡單的一句話測試是請使用專利Skill幫我對以下技術(shù)方案進(jìn)行專利挖掘……如果Agent正確加載了Skill它通常會先回你一句類似“好的我會按照專利挖掘的標(biāo)準(zhǔn)流程來處理先補(bǔ)充幾個信息”這樣的反饋。這時候你就知道它已經(jīng)進(jìn)入Skill的工作流了而不是走通用對話。我第一次測試的時候Agent直接問我“這個技術(shù)方案相對于最接近的現(xiàn)有技術(shù)核心區(qū)別是什么有沒有實驗數(shù)據(jù)驗證效果”我當(dāng)時愣了一下——這個追問方式非常像代理人不像通用AI。這說明它已經(jīng)在按專利實務(wù)邏輯運(yùn)轉(zhuǎn)。3.3 常用配置項說明這類Skill一般會在SKILL.md里留幾個可調(diào)參數(shù)比如輸出語言、面向的專利類型、是否啟用嚴(yán)格檢查模式。我看了一下這個項目的默認(rèn)配置配置項默認(rèn)值我建議的調(diào)整輸出語言中文保持中文技術(shù)領(lǐng)域通用如果你們公司是機(jī)械/軟件/化學(xué)建議在配置里寫明檢查模式標(biāo)準(zhǔn)第一稿用標(biāo)準(zhǔn)模式終稿前開嚴(yán)格模式自問自答開啟保持開啟這個功能會主動追問關(guān)鍵信息技術(shù)領(lǐng)域這個參數(shù)一定不要省。同樣是一個“結(jié)構(gòu)優(yōu)化”的描述機(jī)械領(lǐng)域關(guān)注的是連接關(guān)系、材料力學(xué)軟件領(lǐng)域關(guān)注的是模塊劃分、數(shù)據(jù)流化學(xué)領(lǐng)域關(guān)注的是配比范圍、反應(yīng)條件。你不告訴它領(lǐng)域它就只能按通用框架來寫輸出的質(zhì)量會差一截。4. 專利挖掘模塊把“這玩意有點新”變成可表述的技術(shù)方案4.1 輸入什么才能挖出東西挖掘模塊是整個Skill里我最喜歡的一部分因為它解決的是“我不知道自己有什么可以申請”的問題。它的輸入不需要你寫出專利語言只需要你用人話描述你的工作。我在實測的時候用的輸入是這樣的我們的設(shè)備里原本用風(fēng)扇給主芯片散熱風(fēng)扇噪音大、功耗高。我改成了在芯片背面貼合一塊均熱板 再把均熱板延伸到外殼邊緣利用外殼整個面來散熱。試過之后芯片溫度降了12度風(fēng)扇可以降速運(yùn)行 噪音從45分貝降到了32分貝。這段話就是普通工程師寫周報的口吻完全沒有專利語言。Skill拿到之后它不會直接寫而是先做信息拆解原技術(shù)方案風(fēng)扇主動散熱核心技術(shù)改動新增均熱板貼合芯片背面延伸至外殼技術(shù)效果溫度降低、噪音降低、功耗降低相對現(xiàn)有技術(shù)的區(qū)別散熱路徑從“局部強(qiáng)制風(fēng)冷”改成了“面接觸被動散熱”這個拆解過程非常重要因為它把一段流水賬變成了結(jié)構(gòu)化的“問題—方案—效果”三元組。后面它還會進(jìn)一步追問均熱板的厚度、材質(zhì)銅、鋁、石墨、芯片到外殼的距離、均熱板與外殼的連接方式是否有間隙。這些追問全是代理師會問的問題因為缺少這些細(xì)節(jié)權(quán)利要求書根本寫不完整。4.2 可專利性判斷的三個維度挖掘模塊在生成候選創(chuàng)新點之后會對著三個維度做一輪自檢。這三個維度我建議每個研發(fā)都刻在腦子里新穎性這個方案是不是現(xiàn)有技術(shù)里完全沒有出現(xiàn)過的組合哪怕原來是風(fēng)扇現(xiàn)在換成均熱板外殼組合只要沒人這么干過就有新穎性。創(chuàng)造性這個方案是不是“本領(lǐng)域技術(shù)人員容易想到的”如果只是把A材料換成B材料且在已知范圍內(nèi)創(chuàng)造性就弱如果改變了整個散熱路徑的物理邏輯創(chuàng)造性就比較穩(wěn)。實用性能不能制造、能不能使用、能不能產(chǎn)生效果純理論的東西不滿足實用性。我實測的輸出里它不止列了創(chuàng)新點還按這三個維度給了初步結(jié)論比如“該方案創(chuàng)造性可能體現(xiàn)在導(dǎo)熱路徑的重新設(shè)計建議優(yōu)先檢索均熱板外殼一體化的現(xiàn)有技術(shù)”。4.3 挖掘過程中容易漏掉的素材用了幾次之后我發(fā)現(xiàn)大部分工程師給的輸入里都缺三類信息一是實驗數(shù)據(jù)。很多人只說“效果好很多”但不說具體多少。溫度降12度、噪音降13分貝這些數(shù)據(jù)在交底書里是“有益效果”部分的論據(jù)而在挖掘階段數(shù)據(jù)還能反向輔助判斷技術(shù)特征是否必要——如果去掉均熱板溫度就壓不住均熱板就是必要技術(shù)特征必須寫進(jìn)獨權(quán)。二是失敗經(jīng)歷。調(diào)試過程中遇到的坑恰恰是“預(yù)料不到的技術(shù)效果”的最佳證據(jù)。比如你試過用導(dǎo)熱硅脂直接貼外殼效果不好后來改成均熱板才解決——這條“彎路”本身就能證明均熱板方案不是顯而易見的。三是邊界條件。你的方案在什么范圍內(nèi)有效超過某個厚度均熱板效果不再提升低于某個溫度反而有冷凝風(fēng)險這些邊界條件寫清楚權(quán)利要求的保護(hù)范圍才能畫好。Skill的追問里會帶這些角度但它只能問答得出來還是得靠你腦子里那些沒寫進(jìn)周報的細(xì)節(jié)。5. 交底書生成標(biāo)準(zhǔn)結(jié)構(gòu)下的工程化寫作5.1 交底書的黃金結(jié)構(gòu)交底書是研發(fā)和代理人之間的翻譯文件它的受眾是代理人但不能默認(rèn)代理人懂你的技術(shù)。所以一份完整的交底書至少要覆蓋六個部分章節(jié)內(nèi)容要求常見錯誤發(fā)明名稱體現(xiàn)技術(shù)領(lǐng)域技術(shù)方案類型寫得太寬泛或太像產(chǎn)品名技術(shù)領(lǐng)域一句話說明屬于哪個技術(shù)方向復(fù)制粘貼項目名背景技術(shù)現(xiàn)有技術(shù)的方案缺陷寫成產(chǎn)品宣傳或純技術(shù)綜述發(fā)明內(nèi)容要解決的技術(shù)問題、技術(shù)方案、有益效果與背景技術(shù)沒有邏輯呼應(yīng)具體實施方式至少一個完整可實現(xiàn)的實施例只寫抽象概念不給參數(shù)附圖說明結(jié)構(gòu)圖/流程圖的對應(yīng)說明有圖無標(biāo)注或無圖這個結(jié)構(gòu)不是誰拍腦袋定的它對應(yīng)的是后續(xù)申請文件里“說明書”五部分的雛形。交底書寫得清楚代理師翻譯成權(quán)利要求書的效率就高交底書寫得含糊后續(xù)來回溝通的成本會翻倍。5.2 Skill如何寫“背景技術(shù)”這是我觀察下來它寫得最好的一個部分因為通用AI最容易在背景技術(shù)上翻車——它們會把背景技術(shù)寫成“現(xiàn)有技術(shù)綜述”大段引用行業(yè)常識完全沒聚焦到問題本身。這個Skill寫背景技術(shù)的邏輯是先定位最接近的現(xiàn)有技術(shù)然后用兩三句話描述它的核心方案再重點指出它的缺陷。而且缺陷必須和你的發(fā)明所解決的問題對應(yīng)。比如上面散熱方案的例子它會寫“現(xiàn)有散熱方案通常采用軸流風(fēng)扇強(qiáng)制對流芯片熱量通過散熱鰭片與空氣熱交換排出。該方案存在如下缺陷風(fēng)扇運(yùn)轉(zhuǎn)產(chǎn)生持續(xù)噪音主動散熱需持續(xù)供電增加整機(jī)功耗在密閉或小型化設(shè)備中散熱風(fēng)道受限鰭片熱交換效率大幅下降?！弊⒁膺@段話的表述每一句都在為后文的發(fā)明內(nèi)容鋪路——噪音對應(yīng)“降噪效果”功耗對應(yīng)“降低功耗”風(fēng)道受限對應(yīng)“外殼側(cè)面散熱”。背景技術(shù)和發(fā)明內(nèi)容之間必須是“挖坑—填坑”的關(guān)系而不是各寫各的。5.3 發(fā)明內(nèi)容與具體實施方式的分工很多新人搞不清楚發(fā)明內(nèi)容和具體實施方式的區(qū)別以為把方案重復(fù)寫兩遍就行了。實際上兩者分工完全不同發(fā)明內(nèi)容部分要說“我的方案是什么、能解決什么問題、效果怎么樣”它是概述用的語言要略微抽象為后續(xù)權(quán)利要求的保護(hù)范圍留空間。尤其“技術(shù)方案”這一段經(jīng)常是權(quán)利要求書的文字雛形到時候代理師會直接從這里抽出獨權(quán)。具體實施方式部分要說“這個方案在真實產(chǎn)品里怎么做、參數(shù)是多少、有沒有替代方案”它是展開要具體到本領(lǐng)域技術(shù)人員能夠?qū)崿F(xiàn)。Skill在處理這兩部分時會刻意控制抽象和具體的比例發(fā)明內(nèi)容里的“均熱板”不會輕易限定材質(zhì)和厚度但具體實施方式里會列出銅板、鋁板、石墨片、均熱板厚度范圍0.3-2.0mm、貼合方式用導(dǎo)熱膠或釬焊等。5.4 人工必須介入的三個位置我必須潑一盆冷水交底書生成這個環(huán)節(jié)AI能做的大約是60%的框架搭建和素材組織剩下40%必須人工補(bǔ)缺了這40%交底書會非常“像樣但虛”。第一個必須人工補(bǔ)的是真實實驗數(shù)據(jù)。Skill生成的有益效果部分是推測性的它可能寫“有效降低芯片表面溫度”但你必須把“12度”“32分貝”這些實測數(shù)字填進(jìn)去才有說服力。第二個必須人工補(bǔ)的是替代方案和可變換的設(shè)計。同樣實現(xiàn)面接觸導(dǎo)熱除了均熱板還可以用熱管均熱板組合、還可以用相變材料填充間隙。你是實際做過的人你知道哪些替代方案真能成立AI不一定判斷得準(zhǔn)。第三個必須人工補(bǔ)的是“發(fā)明點在哪一層”。如果一個方案里既有硬件改動又有軟件邏輯調(diào)整哪個是主創(chuàng)新點哪個是輔助創(chuàng)新點這個判斷需要研發(fā)對項目投入的理解深度。AI能把兩條線都列出來但分主次得你說了算因為單獨申請和打包申請的策略完全不同。6. 申請文件整理摘要、權(quán)利要求書、說明書的分工與銜接6.1 申請文件與交底書的關(guān)系交底書寫完之后Skill的第三個模塊開始介入申請文件的整理。這里有一個容易誤解的點申請文件不是交底書的“格式化重排”而是換一種法律技術(shù)語言來重新表達(dá)。交底書可以按研發(fā)習(xí)慣寫想到哪寫到哪申請文件必須按審查要求組織尤其是權(quán)利要求書它的每一句話都在劃定法律保護(hù)范圍。這個范圍既不能太寬太寬會被現(xiàn)有技術(shù)打回來也不能太窄太窄了別人輕松規(guī)避。所以Skill在處理申請文件時第一步不是生成而是做一次“交底書信息完整度檢查”列出缺項讓用戶補(bǔ)充然后再動筆。我在實測時發(fā)現(xiàn)它甚至?xí)穯枴熬鶡岚迮c外殼邊緣的連接處是否有密封設(shè)計”這個問題直接關(guān)系到獨權(quán)要不要寫“密封結(jié)構(gòu)”這個技術(shù)特征。6.2 權(quán)利要求書初稿的生成邏輯權(quán)利要求書是專利文件里最核心也最講究的部分。Skill生成的獨權(quán)邏輯我看了下基本是標(biāo)準(zhǔn)的“前序部分特征部分”結(jié)構(gòu)一種電子設(shè)備散熱結(jié)構(gòu)其特征在于包括 ——殼體具有外殼表面 ——熱源設(shè)置于所述殼體內(nèi) ——均熱板貼合于所述熱源背離所述殼體底壁的一側(cè)并自該側(cè)延伸至所述殼體的外殼邊緣 其中所述均熱板通過所述外殼邊緣與外部環(huán)境進(jìn)行熱交換。這個寫法符合基本要求把設(shè)備的基礎(chǔ)組成部分放在前序把作出改進(jìn)的技術(shù)特征放在“其特征在于”之后。但說實話第一稿的權(quán)利要求書通常需要人工大改因為保護(hù)范圍的大小要靠經(jīng)驗?zāi)媚?。Skill能做的是保證你不犯結(jié)構(gòu)性錯誤比如把非必要特征寫進(jìn)獨權(quán)、引用關(guān)系混亂、術(shù)語不一致。這類錯誤如果是人工寫代理師可能返工三遍用AI生成初稿至少第一遍就能把骨架搭對。6.3 說明書與摘要的整理要點說明書是權(quán)利要求的支撐審查意見里最常見的負(fù)面評價就是“權(quán)利要求得不到說明書支持”。Skill在處理說明書的時候會強(qiáng)制把權(quán)利要求書里的每個技術(shù)特征展開到具體實施方式中。例如權(quán)利要求寫了“均熱板延伸至外殼邊緣”說明書里必須展開說明延伸的具體路徑、長度比例、與外殼的連接方式、材料選擇對導(dǎo)熱效率的影響。這些細(xì)節(jié)在交底書里通常都有但散落在各處Skill的貢獻(xiàn)是幫你把它們歸位。摘要相對簡單它是“技術(shù)問題技術(shù)方案技術(shù)效果”的三句話壓縮包。這里也有個常見錯誤摘要寫完忘了和權(quán)利要求書對應(yīng)。Skill會做一致性檢查保證摘要里出現(xiàn)的每個技術(shù)名詞都在權(quán)利要求書里有定義不會出現(xiàn)摘要寫“散熱膜”而權(quán)利要求寫“均熱板”這種術(shù)語漂移。6.4 一種高效的“三步審校法”用Skill整理完申請文件初稿后我自己總結(jié)了一套三步審校法分享出來供參考第一步通讀權(quán)利要求書只干一件事逐個技術(shù)特征比對現(xiàn)有技術(shù)問自己“這個特征是不是必要的去掉它行不行”。不能去掉的留在獨權(quán)里可以去掉但能優(yōu)化效果的放到從權(quán)里。我實測里第一次生成的獨權(quán)有7個技術(shù)特征我砍掉了2個保護(hù)范圍立刻大了不少。第二步拿權(quán)利要求書當(dāng)索引翻說明書確保每個特征在說明書里都能找到對應(yīng)展開。找不到就用補(bǔ)充實施方式的方式補(bǔ)進(jìn)去不能刪權(quán)利要求了事。第三步排序和術(shù)語統(tǒng)一。全文檢查一遍術(shù)語表均熱板、散熱板、導(dǎo)熱板不能混用。這一步是最耗時的但也是AI做不了的——術(shù)語的選擇會影響后續(xù)侵權(quán)判定時的解釋空間。7. 實測案例一個散熱結(jié)構(gòu)專利從輸入到初稿的全程記錄7.1 實測環(huán)境與輸入內(nèi)容為了寫這篇文章我專門在自己的環(huán)境里完整跑了一遍流程。環(huán)境是Claude Code配合本地部署的專利Skill輸入就是前面提到的那段散熱方案描述。我沒有做任何修飾完全模擬一個普通工程師的“周報語氣”。7.2 各階段輸出的質(zhì)量觀察第一輪專利挖掘輸出質(zhì)量驚喜。它給了6個潛在創(chuàng)新點從“均熱板外殼一體化散熱結(jié)構(gòu)”到“可變轉(zhuǎn)速風(fēng)扇控制邏輯聯(lián)動”再到“貼合層材料與導(dǎo)熱系數(shù)的優(yōu)化選擇”。其中有些角度我自己都沒意識到——比如它指出“散熱路徑從局部風(fēng)冷改為面接觸被動散熱”本身就是一種可申請的“散熱方法”而不只是“散熱結(jié)構(gòu)”。這就是典型的將“產(chǎn)品專利”擴(kuò)展出“方法專利”的思路很多研發(fā)意識不到這一層。第二輪交底書生成初稿可用度約七成。結(jié)構(gòu)完全合規(guī)邏輯鏈清晰背景技術(shù)和發(fā)明內(nèi)容銜接得好。需要我手動補(bǔ)的是真實測試數(shù)據(jù)、均熱板厚度范圍、以及一組對比實驗單風(fēng)扇 vs 風(fēng)扇均熱板 vs 純均熱板的具體數(shù)據(jù)表。第三輪申請文件整理權(quán)利要求書骨架可參考但保護(hù)范圍需要調(diào)。它生成的權(quán)利要求偏具體把所有實施例里的參數(shù)都寫進(jìn)去了這是AI的普遍毛病——它傾向于“安全地寫具體”而不是“有策略地寫抽象”。所以我把獨權(quán)里關(guān)于厚度、材質(zhì)、連接方式全部刪掉或者降級到從權(quán)才得到合理的保護(hù)范圍。7.3 意外情況與修整過程過程里也出了一次問題第一版交底書里Skill把“均熱板延伸到外殼邊緣”理解成了“均熱板外露在外殼表面”這會導(dǎo)致防水防塵的技術(shù)問題。我在修整時補(bǔ)了“均熱板位于外殼內(nèi)側(cè)與外殼邊緣區(qū)域?qū)峤佑|不直接外露”的描述后續(xù)權(quán)利要求書才沒有跑偏。這種細(xì)節(jié)誤差說明一個道理Skill可以幫你把80%的框架搭好但最后20%的“技術(shù)事實準(zhǔn)確性”只能靠懂技術(shù)的人把關(guān)。AI不理解你的產(chǎn)品真實長什么樣它只會照著文本邏輯推而專利文件的致命傷恰恰是“邏輯無誤但事實錯誤”。7.4 效率對比和適用建議從我實測的耗時來看用Skill輔助一個普通技術(shù)方案的專利申請前期工作大致是這樣的節(jié)奏環(huán)節(jié)純?nèi)斯ち?xí)慣耗時Skill輔助耗時專利挖掘思路梳理2-3天含拖延2小時出候選點交底書初稿2-4天半天含人工補(bǔ)數(shù)據(jù)申請文件初稿思路整理2-3天3小時出骨架代理師審校修改無法節(jié)省依然無法節(jié)省注意我不建議把這個時間差宣傳成“AI替代代理人”。它的價值恰恰是讓研發(fā)在進(jìn)入代理人環(huán)節(jié)之前手里已經(jīng)有一份像樣的交底書原來可能要來回磨一個月的需求溝通壓縮成一次高質(zhì)量的信息傳遞。8. 這套Skill的邊界在哪里以及我為什么不建議你“全自動”8.1 AI做得好的環(huán)節(jié)和做不了的環(huán)節(jié)經(jīng)過這段時間的使用我傾向于把Skill的職責(zé)邊界分成兩個清單。它能做好的信息結(jié)構(gòu)化、規(guī)范性審查、術(shù)語一致性、框架搭建、多角度思路補(bǔ)充、以及“用專利語言把你的技術(shù)描述重寫一遍”。這些環(huán)節(jié)的共同點是“有明確規(guī)則、有標(biāo)準(zhǔn)格式、有大量歷史樣本”AI在規(guī)則清晰的領(lǐng)域確實高效。它做不了的創(chuàng)造性判斷的最終決策、保護(hù)范圍的策略權(quán)衡、真實實驗數(shù)據(jù)的補(bǔ)充、技術(shù)事實的準(zhǔn)確性驗證、以及“這個專利到底值不值得申請”的商業(yè)判斷。這些環(huán)節(jié)靠的是研發(fā)對技術(shù)的理解深度、代理師對審查實踐的把握、以及企業(yè)對專利布局的戰(zhàn)略考量AI目前沒有能力也沒有立場替你做這些決定。8.2 誤用場景把它當(dāng)“專利生成器”的人我在網(wǎng)上看到一些評論抱怨“用這個Skill生成的東西根本不能直接用”。我看了下他們的用法基本都是在輸入框里丟一句話然后讓AI直接生成全套申請文件接著拿這個去申報。這不是Skill的錯是用法錯了。專利文件是有法律后果的文件它不是你寫博客錯了刪掉重來專利一旦申請?zhí)峤恍薷姆秶艿絿?yán)格限制前期草率后期寸步難行。還有個更隱性的風(fēng)險如果一個企業(yè)內(nèi)部多名研發(fā)都直接用AI生成交底書而不做個性化修改最后產(chǎn)出的技術(shù)方案描述很容易出現(xiàn)相似的表述模式。雖然專利審查不看你是不是AI寫的但近似文本放在不同的申請里可能導(dǎo)致審查員認(rèn)為技術(shù)方案沒有明顯區(qū)別影響審查結(jié)果。所以我一直強(qiáng)調(diào)AI生成初稿研發(fā)必須做實質(zhì)性改寫尤其是實施例和技術(shù)參數(shù)的描述。8.3 我建議的正確用法三明治工作流最后分享一下我個人目前的工作流管它叫“三明治”——人工、AI、人工三層夾著來。第一層人工把技術(shù)方案的關(guān)鍵信息整理清楚包括核心技術(shù)改動、實驗數(shù)據(jù)、失敗經(jīng)歷、邊界條件。這層信息越豐富AI后續(xù)輸出的質(zhì)量越高。我給這個Skill喂料花的時間通常比它跑的時間還長但這段時間花得值。第二層AI讓Skill依次跑挖掘、交底、申請文件三個模塊每一輪都拿輸出結(jié)果和我自己的思路做對照。它會提供我沒想到的角度也會暴露我自己沒想清楚的模糊點。第三層人工對AI產(chǎn)出的每一段涉及技術(shù)事實的內(nèi)容進(jìn)行逐句核對對權(quán)利要求書的保護(hù)范圍做策略性調(diào)整對術(shù)語和全文邏輯做最終審校。然后再交給代理師去處理法律細(xì)節(jié)。這三個環(huán)節(jié)里AI是放大器和腳手架不是決策者。如果你想給自己的專利工作提效拿它來搭框架、查漏補(bǔ)缺、對齊規(guī)范是值得的如果你想省掉動腦子的環(huán)節(jié)直接拿AI文檔去申請那我不太建議。專利這個東西最后在法律文件上簽字的還是人簽字的人就得對內(nèi)容負(fù)責(zé)。