做了上百件AI专利后，我把从项目挖点到成稿的全流程细节都拆透了

做AI和软件类专利快十年，从自己一线写稿打磨，到带团队做企业内部的专利布局和技术交底，前前后后经手捋顺的案子没有一百也有大几十。见过太多技术人项目做得漂亮，一沉淀专利就卡壳：要么抓不住核心创新点，要么权利要求写得要么过宽要么过窄，还有的附图画得花里胡哨实则全是问题。

很多人觉得写专利就是套模板，填填空就行。其实根本不是。真正能稳定授权、保护范围又合理的专利，从最开始的项目背景梳理，到最后附图里每一个框的文字表述，全是细节和分寸感。今天就把完整全流程拆开来，从一线实操的角度讲透每个环节的逻辑和注意事项。

一、第一步：先锚定「技术问题」，别上来就堆方案

这是90%的新手第一步就踩的坑：拿到点子就迫不及待写技术方案，把算法、流程、参数全堆上去，从头到尾没说清到底解决了什么问题。专利的核心逻辑是「问题-方案-效果」三位一体，问题是根，根歪了，后面的方案写得再漂亮也站不住脚。

1. 拆技术链路找真痛点

别对着业务需求找创新，要顺着项目的完整技术链路拆，每个节点抠痛点。比如做企业级RAG系统，别上来就说“做了个知识库问答”，要拆成：文档解析→向量切片→索引构建→检索召回→重排序→生成回复→后处理校验。每一个环节都问三个问题：

• 现有开源/通用方案在这个环节有什么缺陷？
• 这个缺陷在我们的业务场景里被放大了吗？
• 我们是用什么技术手段解决的，而非靠人工堆数据？

很多人找不到创新点，就是因为没拆细，总在宏观层面打转。拆到具体技术节点，痛点自然就冒出来了。

2. 严格区分「业务问题」和「技术问题」

这是最容易混淆的点，也是很多专利被驳回的隐形原因。

• 业务问题：面向用户和业务的表象问题，比如“客服回答不准确”“文档检索效率低”“用户体验差”
• 技术问题：导致业务问题的底层技术根源，比如“长上下文窗口下实体信息注意力衰减导致事实性错误”“固定切片策略导致语义碎片化，召回准确率不足”“检索与生成阶段算力分配不均，响应延迟波动大”

写专利的时候，绝对不能用业务问题当技术问题。审查员不认“提升用户体验”这种说法，只认你解决了什么具体的技术矛盾。我改稿子的时候，第一件事就是把所有空泛的业务表述，全部落地成具体的技术问题。这一步做对了，创造性的根基就稳了一半。

3. 合格技术问题的三个标准

• 具体：不能是“提升模型效果”，要精确到“提升XX场景下XX指标”
• 客观：是现有技术普遍存在的缺陷，不是自己造出来的伪需求
• 有针对性：你的方案正好能解决这个问题，不能问题和方案两张皮

二、第二步：创新点分层布局，别一个点子写到底

很多人写专利，想到一个点子就从头到尾写一件，写完就觉得完事了。其实好的专利布局从来不是单点作战，是一套组合拳。我一般会把挖出来的创新点分成三层，核心、外围、延伸，层层设防，进可攻退可守。

1. 核心创新点：独权的根基，解决最本质的技术矛盾

核心点是整个专利的灵魂，是和现有技术最本质的区别。它必须满足：去掉它，就解决不了核心技术问题。比如做低显存DPO微调，核心创新点不是“用了量化”——量化是公知常识；核心是“训练前离线量化KV缓存权重，训练阶段直接复用，避免实时量化的算力开销与精度损失”。

核心点一定要提炼到最本质的原理层面，不要绑定具体的参数、具体的算法实现。比如不要限定“AWQ 4bit量化”，就写“离线KV缓存量化处理”，把具体的量化方式放到从权里，保护范围才能拉满。

2. 外围创新点：从权的素材，优化效果、强化稳定性

外围点是对核心方案的补充和优化，是用来撑从属权利要求的。它的作用有两个：一是增加专利的技术厚度，让方案更完整；二是层层设防，就算独权被挑战，从权还能守住保护范围。
还是拿低显存微调举例，外围创新点可以有：

• 按批次内最长序列动态裁剪冗余padding，进一步降低空显存占用
• 针对不同模块采用差异化量化精度，平衡显存与效果
• 加入量化精度校准步骤，减少量化带来的对齐效果损失

每一个外围点，都对应一条从属权利要求，每条只加一个附加技术特征，对应一个明确的技术效果。别把好几个改进堆在一条从权里，堆得越多，保护范围越窄，等于白写。

3. 延伸创新点：扩大保护半径，覆盖更多落地场景

延伸点是把核心方案往其他场景、其他技术领域扩展，用来扩大专利的覆盖范围。比如核心方案是针对大语言模型的DPO微调，延伸点就可以写：

• 该方案同样适用于SFT、PPO等其他微调范式
• 该方案可扩展至多模态大模型的图文对齐微调
• 该方案的量化逻辑可迁移至推理部署场景

延伸点不用写得太细，在说明书里充分公开，在从权里做适当的限定，就能把保护半径撑开，避免别人换个场景就绕开你的专利。

三、第三步：权利要求书撰写，边界感是核心

权利要求是专利的灵魂，直接决定了保护范围有多大、授权稳不稳。写宽了容易被驳回，写窄了没保护价值，分寸感全在细节里。

1. 独权：只保留必要技术特征，多一个都不加

独权的核心原则是：只保留解决核心技术问题必不可少的技术特征，多一个都不加。很多人怕保护范围太宽被驳回，总忍不住往独权里加细节，比如把优化步骤、具体参数全塞进去。殊不知在「全面覆盖原则」下，权利要求每多一个技术特征，保护范围就小一圈。别人只要跳过你这个特征，就不侵权了。

判断一个特征该不该放进独权，就问自己一句话：去掉这个特征，还能不能解决核心技术问题？能解决就别放，不能解决才是必要特征。

2. 从权：层层递进，单条单特征

从权不是随便凑字数的，是有章法的。我写从权一般遵循三个规则：

1. 单条单特征：每条从权只附加一个技术特征，对应一个技术效果，避免捆绑
2. 按权重排序：技术效果越重要、越核心的改进，放在越靠前的从权里
3. 多层递进：可以多层引用，比如权3引用权2，权2引用权1，形成阶梯式保护

这样一层一层叠下来，就像剥洋葱，外面一层被驳掉了，里面还有一层，稳定性极强。

3. 三件套标配：方法+系统+存储介质

标配是三件套：方法独权、系统独权、计算机可读存储介质权。很多人写系统权的时候，就是把方法步骤换个“XX模块”的说法，这其实是偷懒，也容易出问题。

• 方法权：侧重步骤、流程、动作，是动态的
• 系统权：侧重模块、单元、连接关系，是静态的；每个功能模块对应方法里的一个步骤，但要写成“用于执行XX步骤的模块”，不能直接抄步骤
• 存储介质权：标准客体写法，用来覆盖软件产品形态

系统权一定要写清楚模块之间的连接关系、数据流向，不能只是一堆模块名字的罗列。否则审查员很容易以“公开不充分”为由下审查意见。

四、两个核心流程图

图2-1 创新点三层布局架构图

图2-2 专利成稿质量自查流程图

五、最后想说

做了这么多年专利，最大的感受是，好的专利从来不是“写”出来的，是从项目里挖出来、布局出来的。技术是根，撰写只是把技术的价值用规范的方式表达出来而已。

很多技术人总觉得专利是法务的事、是专门部门的事，其实不是。懂一点专利的逻辑，懂一点布局的思路，不管是对自己的技术沉淀，还是对项目的价值提升，都非常有用。毕竟你自己做的东西，你最清楚创新点在哪，价值在哪。

大家平时写专利的时候，有没有遇到过什么印象深刻的坑？欢迎评论区一起交流。