如果把专利工作拆开看,检索很可能是 AI 最早、也最容易产生实际价值的环节之一。 原因并不复杂。技术交底书越来越长,专利文献越来越多,技术表达越来越跨学科;一件看似简单的技术方案,往往既涉及算法、硬件、通信,也涉及具体业务场景。传统检索当然仍然有效,但检索人员经常要花大量时间做几件重复而耗神的事: 从交底书里拆出真正值得检索的技术特征;把研发语言翻译成专利语言、英文表达和分类号;在大量看起来“有点像”的文献里筛出少量值得精读的候选;沿着引证、同族、分类号不断扩展;最后把结果整理成研发、代理师和决策者都看得懂的对比材料。 AI 对这些工作确实有帮助。 但“AI 能帮忙检索”和“AI 可以完成查新”,中间隔着一条很长的路。 尤其当我们把图文并茂的技术交底书直接交给一个通用大模型,再让它“加强交底书”“找相似专利”“判断新颖性”时,效率可能提高了,风险也可能一起被放大:它可能看漏图、误解图,也可能把原本没有披露的技术细节补得煞有介事。 所以,这篇文章想讨论的不是“哪个 AI 最强”,而是一套更稳妥的工作方式: 让 AI 扩大检索的视野、压缩阅读的成本、提高整理的效率; 很多人使用 AI 检索时,第一步是复制一段技术交底书,问: “帮我找一下相关专利。” 这类提问看起来方便,实际上把几个完全不同的任务混在了一起: 1.理解原始技术方案; 2.识别图文中的技术特征; 3.补全可能缺失的研发信息; 4.生成检索表达; 5.搜索和筛选文献; 6.判断技术方案是否被现有技术公开。 而这些任务,恰恰有着完全不同的风险等级。 特别是技术交底书通常不是纯文本。它可能包含: 系统架构图;处理流程图;时序图;电路图;结构示意图;算法框图;图中模块、箭头、标号;图注、表格与实施例之间的交叉引用。 有时,真正有区分度的技术特征,并不完整地写在某一个段落里,而是散落在“图 2 的连接关系”“图 3 的先后顺序”以及“实施例中的一句补充说明”中。 因此,在零代码工作流里,选择通用大模型时,第一优先级不应只是“回答是否流畅”,而应是它是否具备较稳定的多模态文档理解能力: 能否同时读取 PDF 正文、附图、表格和图注;能否识别图号、模块名、标号和箭头关系;能否对回答回指页码、段落、图号或原始摘录;能否在无法确定时明确说“无法从原始材料确认”。 这里有一个很实用的判断标准: 不要问模型“这个方案的创新点是什么”; 前者鼓励模型归纳、发挥和补足;后者则要求模型回到证据。 对于专利工作,后者更重要。 “帮我加强交底书”是一个很危险的指令。 因为在通用写作任务中,“加强”通常意味着: 补足逻辑;丰富细节;完善因果链;增加实施方式;让表达更专业、更完整。 但在专利交底场景中,很多“补足”其实意味着:增加原始材料中不存在的技术事实。 例如,原交底书只写了“根据图像识别结果完成商品结算”,AI 很可能自动补出: 识别置信度阈值;图像与重量的融合权重;异常检测机制;多模态深度学习模型;实时反馈闭环;降低误识别率、提升处理效率等技术效果。 这些内容语言上都很合理,甚至看上去比原文专业得多。 但如果研发人员从未披露、从未确认,它们就不是“表达优化”,而是技术编造。后续如果这些内容被混入检索特征、权利要求、说明书或 OA 答复材料,整条工作链都会受到污染。 因此,更稳妥的做法是:在检索之前,先建立一份技术事实账本。 它可以是一张简单的表格: 这张表的价值不在于形式,而在于它建立了一个基本秩序: 原始交底书是事实源; 尤其是 F04 这一类内容,不要简单删掉。 AI 提出的“看似合理但未披露”的内容,可以被放进一个单独的栏目:待研发确认池。它可以成为向发明人追问的线索,但不能直接变成既有技术方案的一部分。 这样既避免了技术编造,也不会浪费 AI 发现问题的能力。 图文交底书中,AI 最容易“越界”的地方是附图。 图中模块 A 与模块 B 之间绘制有方向箭头。 这一步看起来比“直接让 AI 检索”多了一层流程,但它能避免后面几十小时的无效检索和错误分析。 下面这段提示词,可以直接用于交底书的首次处理。 在技术特征被人工确认前,不建议让 AI 自由“加强”材料。 等技术事实账本稳定后,再让 AI 做第二阶段工作:术语统一、逻辑整理、图文引用补足和文字表达优化。 此时的提示词可以换成: 一句话概括: AI 可以做交底书的编辑、书记员和问题提问者; 顺带一提:这两段提示词,就是第一篇里说的“把环节封装成 Skill”的起点——把它们连同证据抽取模板一起固化下来,下次直接调用,而不是每次重写。 在输入材料可信的前提下,AI 在检索中的价值会变得非常具体。 它不应承担“给出最终结论”的任务,而适合承担以下五类工作: 将交底书从长篇描述拆成可检索的最小单元,例如: 研发人员常用的语言,与专利文献中的语言并不总是一致。 AI 可以帮助形成“同义词—上位概念—下位实现”的关键词矩阵,也可以将中文研发描述翻译成更接近英文专利语境的表达。 但必须注意:AI 给出的词不是标准答案,而是待验证的检索假设。 相比“给我一个检索式”,更好的做法是让 AI 输出检索路径: 首轮:宽召回,寻找种子文献;第二轮:从种子文献提取 CPC/IPC、申请人、引证和同族;第三轮:围绕关键区别特征补漏;第四轮:补充跨语言文献和论文等非专利文献。 面对几十篇候选文献,AI 可以先做: 标题、摘要、权利要求的结构化摘要;技术特征对应表初稿;相似点和区别点的初步梳理;文献分组和优先级排序。 这能显著减少人工在低相关文献上的阅读时间。 AI 很适合整理: 检索词演进过程;检索式及命中数量;候选文献清单;特征对比表;待核验问题;检索盲区和后续建议。 这些工作看似不“智能”,却直接影响查新报告是否可复核、可交接、可解释。 如果不考虑商业数据库,仅使用公开或低门槛工具,也可以搭出一条相对完整的检索链路。 入口: Google Patents 很适合做检索的第一站。它的优势不只是文献覆盖广,更在于方便快速尝试不同的技术表达、查看引证关系,并从一篇命中文献继续扩展相关文献。 例如,对“基于图像识别的自助结算”方向,可以从一个较宽的式子开始: 再逐步加入分类号、日期、申请人等约束: 实际使用时,不要期待第一次检索就得到正确答案。Google Patents 更适合帮助我们找到 3—5 篇高相关的种子文献,再从这些文献中继续挖: 标题、摘要和权利要求的不同表述;CPC/IPC 分类号;引证文献和被引证文献;相似文献;同一申请人或发明人的其他布局;非专利文献线索。 入口: 如果说 Google Patents 更适合快速探索,Espacenet 则更适合把检索做得系统化。 为什么同族核验很重要? 因为你找到的一篇候选文献,未必是最早公开的版本。某件技术方案可能先在一个国家公开,后又进入其他国家或地区。若不核验同族和公开日,就可能把“看似较早”的文献误判为有效对比文件,或者遗漏真正更早公开的家族成员。 所以,一个基本动作应当成为习惯: 对进入重点候选列表的文献,逐篇核验其同族和公开时间。 入口: 对于中国研发团队而言,PATENTSCOPE 的价值很大一部分在于跨语言检索。 不少技术在日本、韩国、德国等国家和地区存在较早布局。只用英文关键词或只盯中文专利,容易遗漏表达体系完全不同、但技术实质相近的文献。 PATENTSCOPE 可以作为跨语言补漏的一环: 1.先用 AI 将已确认技术特征形成中英文检索词; 2.用 Google Patents 或 Espacenet 获取种子文献和分类号; 3.再到 PATENTSCOPE 扩展 PCT 及其他语言的相关文献; 4.对高相关结果回到原文、同族和公开日进行核验。 入口: 在算法、材料、生物技术、芯片、通信等领域,论文、会议文章、技术报告等非专利文献,往往不能被忽略。 The Lens 的一个重要特点,是将专利和学术文献放在同一检索视野中。它尤其适合做两件事: 从技术关键词出发寻找早期论文;从论文出发反查其被哪些专利引用。 对于“模型、方法、材料机理”类技术方案,建议至少增加一次论文侧检索。因为有些看起来很新的专利特征,可能早已出现在公开论文或会议材料中。 下面用一个脱敏场景说明整个流程。 假设收到一份技术交底,主题是: 一种基于图像识别与货架重量传感器融合的商品识别及自助结算方法。 先从交底书中确认: 图像采集装置获取商品图像;识别模块基于图像确定商品类别;重量传感器获取货架或商品重量信息;图像识别结果与重量信息共同参与商品识别或校验;识别结果用于触发或完成结算流程。 此时不要因为“多模态融合”听起来很合理,就自动写入“动态权重融合”“置信度阈值”“异常检测机制”等未披露内容。 围绕每个特征,建立中英文和多层次表达。 关键词矩阵不是越多越好,而是要能反映技术特征的不同表达路径。 使用 Google Patents,以“自助结算 + 图像识别 + 货架/重量”等组合开始检索。 采用了什么技术表达;使用了哪些 CPC/IPC;相关文献来自哪些申请人;其引证和相似文献有哪些。 从种子文献中提取分类号,在 Espacenet 中结合关键词继续扩展。 这一步的目标是防止只靠关键词造成漏检。因为同样的技术方案,可能被不同申请人用完全不同的文字描述;但它们往往仍会落入相近的分类体系。 然后沿着引证链继续向前、向后扩展,并核验同族成员。 对于命中较多、技术成熟度较高的方向,再到 PATENTSCOPE 补充跨语言文献;对算法、识别模型、传感融合等部分,可在 The Lens 或学术检索平台补充论文线索。 在候选文献收敛后,可以让 AI 做结构化比对: 新创性分析关注的不是“多篇文献拼起来像不像”,而是需要在法律和事实框架下分析:相关技术特征是否被有效公开、公开时间是否合格、单篇文献是否完整披露等问题。 不同团队的工具基础不同,可以选择不同成熟度的路径。 适合多数代理师、研发人员、IP 管理人员。 这一版的核心不是“自动化”,而是建立人机协作的正确顺序。 适合有数据能力、会 SQL 或 Python 的团队。 适合有研发资源、希望将检索流程产品化的团队。 为了让 AI 用得更稳,可以把它的工作分成三类。 如果只记住七件事,我建议是下面这些: AI 最适合改变的,不是查新结论的责任归属,而是查新过程中的信息处理效率。别只问 AI“有没有相似专利”:一套可落地的 AI 查新检索工作流
但让证据、原文和专业判断,始终留在人的手里。
一、AI 查新最容易犯的第一个错误:把交底书当成一段文字
“请判断这个方案有没有新颖性。”
“把这个交底书加强一下,再帮我检索。”
先问它“这份材料中,哪些技术事实可以被明确证明?证据在哪里?”
二、比“加强交底书”更安全的做法:先建立技术事实账本
AI 的输出只是衍生材料;
只有能回指到证据、并经人确认的内容,才能进入后续工作。
三、附图理解的一个基本原则:描述看见的,不解释没写的
比如,一张系统图上画了模块 A 指向模块 B 的箭头。
AI 可以安全地描述:
但不能自动写成:
模块 A 与模块 B 进行实时双向闭环通信,从而实现动态协同控制。
后者包含了“实时”“双向”“闭环”“协同控制”等多个技术限定,而这些限定未必能从图中直接得出。
所以,处理附图时可以遵循一条非常朴素、但很有效的规则:
先描述视觉事实,再引用文字说明;图上看不见、文字没写明的技术含义,不由 AI 补充。
对于图文材料,建议让 AI 输出三类内容:
因为检索质量的上限,往往由输入材料的可信度决定。---四、给 AI 的第一条指令:不是“写得更好”,而是“只说有证据的话”
你现在处于“交底书证据抽取模式”,而不是自由写作模式。
请仅依据我提供的交底书原文、附图、图注和表格提取技术信息。
禁止使用外部知识、行业常识或合理推断补充任何技术细节。
请遵守以下规则:
1.每一项技术特征必须标注证据位置:页码、段落号、图号、表号或原文摘录。 2.如技术特征只能从附图推测,必须标记为“图示推测,待人工确认”。 3.如原始材料未明确披露,请明确写“原始材料未披露”,不得补写。 4.不得新增算法、模型结构、参数范围、控制逻辑、模块连接关系、技术效果或实施步骤。 5.不得将“可能”“可以”“例如”等表述改写为确定性技术事实。 6.请按以下三类输出:
A. 已明确披露的技术特征;
B. 图文结合后可合理识别、但需人工确认的内容;
C. 原始材料未披露、不得写入交底书的内容。请依据“已确认技术特征清单”改写交底书,使术语、逻辑和图文对应关系更清晰。
严格要求:
1.只能使用清单中已确认的技术特征; 2.不得新增模块、步骤、参数、算法、技术效果或应用场景; 3.每个改写段落后附上所依据的特征编号; 4.如为了语句通顺必须补充连接性表述,请用【待确认】标识; 5.输出“改写稿”和“新增/删减差异表”两部分。
但在研发人员确认之前,它不应该成为技术方案的“共同发明人”。
五、AI 查新真正适合做什么?
1. 技术特征拆解
技术问题;必要技术手段;可替换实现方式;输入、处理、输出关系;关键模块及连接关系;可能形成区别点的技术效果。2. 检索词扩展
例如“图像识别商品”,在不同文献中可能写成:
image recognition;computer vision;visual product identification;object classification;shelf scanning;product detection。3. 生成多轮检索策略
4. 候选文献初筛和摘要归纳
5. 留痕和报告整理
六、一套零代码也能上手的查新工具箱
1. Google Patents:适合首轮探索和滚雪球
https://patents.google.com (title:(self checkout) OR abstract:(self checkout))
AND abstract:(image AND shelf)cpc:G06V20/52
before:publication:20200101
assignee:(company name)
需要提醒的是:相似度排序只是线索,不是新颖性判断;摘要命中也不等于某项特征被完整公开。2. Espacenet:适合分类检索、同族核验和引证扩展
https://worldwide.espacenet.com
它最重要的几个用途是:
通过 CPC/IPC 分类体系查找同类技术;沿引证链扩展候选文献;核验同族成员;查找更早公开的同族版本;查看较完整的书目信息与法律状态线索。
3. PATENTSCOPE:适合 PCT 与跨语言补漏
https://patentscope.wipo.int 4. The Lens:适合补非专利文献盲区
https://www.lens.org 七、一个完整的实战流程:从技术交底到候选对比文件
第一步:拆技术特征,不急着检索
第二步:形成关键词矩阵
第三步:首轮检索,寻找种子文献
首轮目的不是穷尽,而是找到几篇真正接近的种子文献,并记录:第四步:分类号、引证、同族扩展
第五步:跨语言与论文补漏
第六步:让 AI 生成候选对比表初稿
八、从零代码到 Agent:三档使用路线
路线 A:零代码免费版
使用多模态模型提取图文交底书中的已确认特征;使用 Google Patents 做关键词探索和种子文献发现;使用 Espacenet 做分类、同族、引证和公开日核验;使用 PATENTSCOPE 补跨语言文献;使用 The Lens 或其他学术检索工具补论文;使用 AI 整理检索词、候选文献和对比表;由专业人员精读原文并完成判断。路线 B:轻代码与数据版
可以关注 Google 的专利公共数据项目:
GitHub:https://github.com/google/patents-public-data;
定位:基于 Google Patents Public Datasets 的专利数据分析项目;
许可证:Apache-2.0。
它不是一个可以直接替代检索平台的产品,而是一条数据路线:当需要对大规模专利数据按分类号、时间、申请人、关键词做批量预筛、统计和分析时,可以借助 BigQuery 等数据工具提高效率。
对于 EPO 数据,也可以通过 OPS 接口及社区客户端获取部分书目、同族、引证等信息。比如:
GitHub:https://github.com/ip-tools/python-epo-ops-client。
需要注意,代码和接口能解决“批量获取、结构化处理、自动归档”的问题,但不能自动解决“技术特征是否被完整公开”的问题。路线 C:Agent / MCP 版
一个典型的 Agent 工作流可以是:
1.Agent 读取已确认的技术事实账本; 2.调用检索工具形成关键词和分类号策略; 3.调用专利数据源拉取候选文献; 4.自动去重、按相关度分组; 5.生成候选文献摘要和特征对比表; 6.标记公开日、同族、引证、缺失字段等待核验项; 7.将结果交给代理师或检索人员复核。
公开社区中已经出现面向专利数据的 MCP 项目。例如:
https://github.com/riemannzeta/patent_mcp_server 面向 USPTO 数据,提供专利全文、权利要求、审查历史、引证等数据能力的 MCP 封装。https://github.com/patsnap/mcp 提供与专利检索、分析、法律状态等相关的 MCP 接入能力,但具体可用范围仍取决于对应的平台账户、权限和服务配置。
但这里必须强调:
MCP 解决的是“让 Agent 能调用工具和数据”;
它不自动解决“判断是否正确”的问题。
即使 Agent 能在几分钟内生成 50 篇候选文献、整理一张漂亮的对比表,仍然需要人确认:
文献是否真实存在;公开号、公开日是否正确;同族中是否有更早公开版本;技术特征的出处在何处;文献是否真正、完整地公开了相关技术方案;最终结论是否经得起复核。九、AI 查新中的红黄绿灯
十、最后的七条实操提醒
结语:AI 的价值,不是替人宣布“查新完成”
它可以帮助我们更快读懂交底书,更系统地构建检索策略,更高效地筛选候选文献,更清晰地整理比对材料。
但在专利工作中,速度从来不是唯一目标。
一个经得起复核的检索结果,应当能够回答这些问题:
技术特征从哪里来?;检索词为什么这样设计?;候选文献为什么被选中?;公开时间是否真实有效?;特征比对的证据在哪里?;哪些是 AI 的初筛意见,哪些是人工的专业判断?
AI 可以把“读 100 篇文献”的工作,尽量压缩为“优先精读 10 篇文献”。
但那 10 篇文献是否真正重要,最终仍需要专业人员回到原文、回到证据、回到技术事实本身。
这才是 AI 在查新检索中最合适的位置:它负责把路找出来、把文献读薄,但“仍值得保护的部分”这个结论,必须落在人手里。




