很多研发人员第一次接触AI写专利，通常是从一个很现实的场景开始的：专利代理师发来一份技术交底书模板，要求下周反馈；项目刚上线，需求文档散在飞书、邮件和会议纪要里；代码确实能跑，但要把“为什么这么设计”讲清楚，却不知道从哪里下笔。
于是有人把产品介绍、代码注释和几句技术描述丢给大模型，让它直接生成一份专利技术交底书。几分钟后，文档看起来很像那么回事：有背景技术、发明内容、有益效果，也有“提高效率、降低成本、增强稳定性”这类表达。但交给专利代理师以后，对方往往还要追问一连串问题：你的改进点到底落在哪个步骤？现有技术是怎么做的？区别特征有没有对应结构？哪些内容是确定实现，哪些只是想法？
这也是我越来越倾向于把AI定位成“整理和追问工具”，而不是“自动发明人”的原因。AI生成专利技术交底书这件事能成立，前提是发明人手里确实有技术，只是不擅长按专利材料的逻辑表达。如果输入端只有几句宣传语，AI大概率会补出一篇格式完整、技术空心的文本。
第一个误区，是把写得像样当成写得到位。专利交底书不是论文，也不是项目申报书，它的核心任务是帮助专利代理师理解技术方案，并判断可专利化的切入点。一份合格的交底书，至少要让没有参与项目的人看懂四件事：现有方案哪里受限、本方案采用了什么手段、各个手段之间如何配合、它带来的技术效果为什么能够成立。
AI很擅长补齐章节，却不擅长替你确认事实。比如你输入“通过动态调度提高系统性能”，它可能顺理成章地写出“实时采集负载指标并自动分配资源”。但如果系统实际上只按任务优先级做队列调整，并没有实时负载采集，这句话就会把方案带偏。更麻烦的是，这类表述读起来很顺，发明人扫一眼容易默认“差不多就是这个意思”，最后造成技术方案被模型自己的常识补写替换。
第二个误区，是追求一次生成完整文档。我更建议把过程拆开。先不要急着让AI输出正式交底书，而是让它根据已有材料列问题清单。比如针对一个推荐算法改进，可以先问：这份材料里哪些是业务目标，哪些是具体技术手段？现有协同过滤方案的缺陷有没有被明确写出？用户特征、召回策略、排序模型之间的数据流向是否完整？哪些效果有实验数据支撑？
这一步的价值比直接生成正文大得多。因为专利代理师后续真正需要的，往往不是更多漂亮段落，而是更细的技术事实。你可以把接口文档、流程图、核心伪代码、测试结果分别提供给AI，再让它按“问题—手段—效果”的链条归并。材料不完整时，宁可在文档里标注待确认，也不要让模型凭空补全。
具体到写作时，我通常会先让AI整理现有技术。这里要提醒一点：背景技术不能只写竞品缺点，更不能用“现有技术效率低、用户体验差”一句话带过。更好的写法是把机制讲出来。例如，原有规则引擎在规则数量增加后，需要重启服务才能生效；规则之间存在优先级冲突时，依赖人工在配置文件中排序；高峰交易期间单次匹配要遍历全量规则，平均延迟随之上升。这样写，后面的改进点才有落脚点。
接着再处理核心方案。可以要求AI不要先写抽象优点，而是按执行步骤重述：系统如何获取输入数据，数据经过哪些模块，每个模块执行什么处理，输出结果如何被下一环节使用，异常情况如何回退。对于软件类发明，最好把虚拟模块和实际流程对应起来，避免只堆“采集模块、分析模块、处理模块”这类名词。模块名称本身没有意义，关键是模块内部的输入、处理规则和输出。
如果涉及算法，不要把模型名称当成技术方案。写“采用大模型进行判断”通常过于宽泛，需要继续拆开：输入样本包含哪些字段，提示词或特征工程如何设计，模型输出如何被校验，阈值如何确定，误判时是否有人工复核或规则兜底。专利保护关注的是具体技术构思，而不是采用了某个热门工具。AI可以帮你把这些细节追问出来，但答案必须来自真实研发过程。
技术效果部分也适合让AI做反向检查。你可以让它对照每个技术特征，找出文档里声称的效果，再判断二者之间有没有因果关系。比如“设置缓存”不能直接推出“系统稳定性显著提升”，更接近的效果可能是减少重复查询、降低数据库压力、缩短接口响应时间。若有压测数据，就写清条件和结果：缓存命中率、P95延迟、服务器配置、样本周期。没有数据时，也应使用克制表述，不要把商业收益包装成技术效果。
在实际协作中，我见过比较顺的做法，是发明人先用AI把零散材料拉成一版“事实底稿”，再由专利代理师基于底稿调整权利要求布局。这样工程师不用面对空白模板，代理师也不必反复询问基础信息。对企业而言，这种方式能明显缩短沟通周期，尤其适合产品迭代快、发明点密集的团队。它不会让一项平庸改进凭空变成高质量专利，但能减少“技术没讲透”导致的遗憾。
如果你想先试工具，可以看看专利Pro，它更偏向围绕专利材料的结构化生成和整理，适合把研发素材往交底书格式上收。不过工具只是入口，别把生成按钮当成终点。
还要特别注意保密和权属问题。涉及未公开算法、客户数据、源代码和业务指标时，应优先使用企业授权的私有化或合规环境，不要随意把敏感内容贴进公共对话框。上传前可以做脱敏，例如替换客户名称、账号、内部地址和真实业务规模。对于共同开发项目，还要确认合同里的专利申请权和使用权约定，避免交底书写完后才发现申请主体存在争议。
另一个容易忽略的点，是公开节奏。技术交底书本身不会自动让技术公开，但论文发表、会议演讲、开源代码发布、产品手册上线，都可能影响新颖性。稳妥做法是在相关内容对外披露前，先完成专利申请或至少提交申请文本。AI加速了初稿形成，也可能让团队放松对时间节点的管理，这反而需要项目负责人更早介入。
最后说回人的角色。AI能帮你重排材料、补齐章节、发现逻辑缺口，也能提醒你补充流程图、实施例和替代方案，但它不知道团队在方案取舍时放弃了什么，也不知道某个看似普通的参数调整背后，踩过哪些线上事故。恰恰是这些技术上下文，决定了交底书有没有筋骨。
所以，与其问AI能不能替发明人写专利，不如换个问法：研发人员能不能用AI把自己的技术方案讲得更清楚、更完整、更便于专利代理师接手。按这个目标使用，结果通常不会太差。