写专利这件事我以前一直觉得是个“手工作坊”的活找资料、梳理创新点、画技术方案、写权利要求书哪一步都得靠人一点点磨写一份靠谱的技术交底书有时候得憋一周。直到我自己把 AI 工作流搭起来跑通全流程才意识到过去那种“打开 Word 文档硬写”的玩法效率低得离谱。这篇文章想把我的完整玩法和盘托出我用 Coze、Dify 这类平台做底座把专利撰写拆成检索、构思、生成、校验四段式工作流配合提示词工程和模板化输出基本能做到输入一段想法几分钟内拿到一份结构完整、格式合规的专利交底书初稿后续人工打磨的成本直接砍掉一半以上。如果你是研发人员、项目经理、初创团队的技术负责人或者单纯好奇 AI agent 怎么落地到文档生产场景这篇应该对你有用。1. 先把问题想清楚专利“写不出来”到底卡在哪在谈工作流怎么搭之前先得说说专利撰写的痛点在哪里不然你会觉得“AI生成专利”又是一个噱头。我接触过不少研发人员技术水平没问题但一提“写专利”就头大原因不是不会写中文而是专利有自己的一套语法和逻辑。专利文本的本质不是科普文章而是一份法律技术文件。它必须满足几层要求技术方案要清楚、完整能够让本领域技术人员实施权利要求要界定保护范围既要往前推区别于现有技术又要往后留足等同侵权的空间说明书要支持权利要求做到“权利要求里出现的每一个特征说明书里都有对应描述”还有格式层面包括背景技术、发明内容、附图说明、具体实施方式等固定章节。这些要求叠加在一起光靠自然语言表达能力强是不够的你需要一套结构化的思维框架来组织信息。传统做法是技术交底书模式研发人员把自己的实现方案、创新点、技术效果写在文档里然后交给专利代理人去打磨成正式申请文件。这个流程最大的问题是什么是“转译损耗”。研发人员觉得“我这个东西很简单就是加了个缓存”但专利代理人需要知道缓存放在哪里、命中策略怎么设计、和现有方案的区别是什么、效果数据有没有——这些信息研发人员往往不会主动完整描述于是需要一个来回一个来回地沟通“挤牙膏”。等交底书终于完整了代理人还要拆解技术特征、做现有技术检索、设计权利要求布局又是一轮重型加工。AI 工作流在这里能解决的不是替代专利代理人的专业判断而是把两个最耗时的地方降下来一是把研发人员的碎片化想法快速扩展成结构完整的交底书初稿减少沟通轮次二是把初稿按专利审查逻辑做结构化重构自动补齐背景技术、技术问题、技术方案、有益效果这些模块的逻辑闭环。说白了AI 负责把“第一版垃圾”快速写完人负责把“垃圾”打磨成“可用”甚至“优秀”。还有一个容易被忽视的卡点格式。不同代理机构、不同企业内部模板对技术交底书的格式要求五花八门有的要求表格化列出技术特征有的要求按“问题-方案-效果”三段式展开。手写的时候光套格式就能耗掉不少时间。工作流里我专门设计了模板化输出层把格式规则变成可复用的结构化模板每次生成都自动落入固定框架这块节省的时间非常可观。2. 工具底座怎么选Coze、Dify 和其他选项的取舍标题拆出来专利工作流涉及的核心能力有五个长文本理解与生成、多轮对话梳理需求、检索外部资料、结构化数据提取、模板化文档输出。按这个能力清单去筛工具市面上的 AI 工作流平台其实能分三类。第一类是 Coze扣子这类偏业务编排的平台。它的特点是节点拖拽式搭建内置大量插件和知识库能力对普通用户非常友好适合快速验证想法。我在早期测试时就用 Coze 搭过一版简单流程用户输入想法调用大模型生成背景技术再调用另一个节点生成权利要求中间用变量传递状态。好处是上手极快坏处是当流程变复杂比如需要循环处理多个技术特征、条件分支判断、长文本分段生成时节点编排会变得很笨重调试体验也不太好。第二类是 Dify 这类偏应用开发的工作流平台。它是“配置 代码”混合模式支持更复杂的逻辑比如迭代节点、条件分支、变量聚合、外部 API 调用还可以挂知识库做 RAG 检索。Dify 的上下文管理比 Coze 更灵活支持“上下文超长”场景的分段处理这对专利这种动辄上万字的长文本非常关键。我最终用的是 Dify 自建的版本核心原因就是它的工作流编码能力更强能把“多轮问答梳理需求 → 分段生成 → 拼接组装 → 格式校验”这条链路完整串起来。第三类是 ComfyUI、Flowise 这类更偏专业或极客的工具。ComfyUI 现在很火但主要服务于图形图像生成场景虽然它也能跑文本节点但把专利流程塞进 ComfyUI 总觉得别扭属于“能跑但不是为这个设计的”。Flowise 算是 Dify 的同类竞品更适合玩本地部署的人但我个人体验下来它的中文支持和插件生态不如 Dify 成熟。如果团队里有好的 Java 开发资源也有人用 Camunda、Activiti 这类开源审批工作流自己做一套那就是另一条路了门槛高很多普通业务团队没必要碰。选型层面我给出一个可参考的取舍逻辑见下表需求特征推荐工具理由零代码快速验证、个人使用Coze拖拽式编排几十个节点内能跑通长文本分段生成、复杂逻辑、知识库 RAGDify上下文管理更灵活支持条件分支和迭代本地化部署、数据不出内网Dify 本地版 / Flowise可私有化满足企业保密要求纯视觉类工作流ComfyUI术业有专攻不推荐用于专利场景我自己最终的架构是这样的Dify 作为主流程引擎负责编排整体逻辑内部挂两个大模型一个偏生成负责扩写、撰写一个偏校验负责检查格式、逻辑一致性外部接了一个专利检索 API用来粗筛现有技术和知识库存放企业内部的技术交底书模板、历史专利案例。这套东西跑稳定之后从想法输入到交底书初稿输出基本就是几分钟的事。3. 四段式工作流检索、构思、生成、校验的完整链路核心工作流我给它起了个名字叫“四段式专利流水线”每一段解决一类问题段与段之间用变量和临时文档传递信息。下面我把每一段的输入、处理、输出讲清楚顺便给出一套可以直接抄的搭建思路。3.1 第一段需求梳理与现有技术粗检这一步是整条流水线的“入口”核心目标是拿到结构化的输入。很多 AI 项目死就死在第一步——让用户随便丢一段话就生成专利输出必然是一堆正确的废话。所以我的工作流第一段不是直接生成而是“结构化提问 选项确认”。Dify 里我配置了一个对话轮次节点先向使用者抛出一组固定问题你的技术方案解决的是什么问题现有方案有什么缺陷你的方案核心创新点在哪个环节有没有具体的参数、算法流程、系统架构预期效果是什么有没有实验数据这组问题的设计逻辑来自专利审查指南里对“技术问题—技术手段—技术效果”三位一体的要求。研发人员哪怕只给一个模糊想法经过这几轮追问也能挖出八九成关键信息。回答收集完后工作流会把答案自动整理成一张“发明点清单”按“背景痛点—创新手段—关键技术特征—预期效果”四个维度归档。与此同时系统会把关键词抽取出来调用检索 API 做一次现有技术粗筛。这一步不求查全只求发现最接近的对比文件防止后面生成的权利要求一开始就踩在已有技术上。这里有个实操细节不要在第一步就让 AI “写专利”。应该让它“问问题 记答案”。先把人的知识榨干再让 AI 干活因为 AI 无法无中生有你脑子里的那点技术内幕。3.2 第二段权利要求布局与技术特征拆分第二段是整个工作流技术含量最高的地方也是最能体现“工作流编码”价值的地方。收到第一段的发明点清单之后系统不是直接丢给大模型说“帮我写权利要求”而是先做一层逻辑拆解这份技术方案包含哪些必要技术特征哪些是非必要特征可以放到从属权利要求独立权利要求怎么写才能做到“保护范围最大且不被现有技术轻易规避”这层拆解我建议用两种方式配合实现。第一种是预设“权利要求逻辑模板”在提示词里要求模型区分“前序部分”和“特征部分”前序写背景和共有特征特征部分写创新点。第二种是做一个条件分支节点根据用户输入的技术类型方法类、系统类、装置类、介质类选择不同的权利要求生成腔。方法类写步骤流程系统类写模块构成装置类写物理结构连接关系。我踩过最大的坑就是不分类型直接生成权利要求书结果方法权利要求里出现“该模块”系统权利要求里出现“步骤 S1”行文完全混乱。加了这个类型分支之后生成质量直线上升。再往下走每个技术特征还要做“上位化”处理。什么叫上位化简单说就是把具体实现方式抽成更上层的功能描述扩大保护范围。比如“用 Redis 缓存用户 Token”可以上位化为“利用缓存模块存储用户身份验证信息”。这一操作对大模型来说其实不难但必须在工作流里设置一个明确的独立节点去处理不能和叙述段混在一起生成否则模型会在具体描述和抽象描述之间反复横跳。3.3 第三段说明书多模块并行生成与拼装说明书是专利里最长的部分通常包含技术领域、背景技术、发明内容、附图说明、具体实施方式五节。如果让大模型一口气生成很容易出现两类问题一是越到后面质量越差前面还能看后面纯粹是在凑字数二是章节之间的逻辑一致性崩坏背景技术里说的缺陷到了发明内容里对不上号。所以第三段我设计成了“模块并行生成 统一组装”。具体做法是先确立一份“生成规范”把说明书拆成 5 个子任务分别分配给不同的生成线程Dify 里就是多个并行节点每个线程只专注写一个章节。背景技术线程只需要读第一段的痛点信息发明内容线程需要读权利要求和发明点清单具体实施方式线程需要读权利要求技术细节。并行生成完再进入一个拼装节点把五块内容按固定模板拼接成完整的说明书初稿。拼装节点还要做一次“一致性检查”把权利要求里的每个技术特征和说明书里的描述做交叉比对发现缺漏就自动触发一次补写。这一段的工程本质是“把一个大任务拆成多个可并行的小任务降低单次生成的上下文负载”。尤其是碰到“上下文超长”的问题——专利说明书动辄两万字如果不用分段并行大模型在单次会话里根本处理不了那么长的上下文。Dify 的优势就在这它的迭代和并行节点能天然支持这种分段灌入的玩法这也是我为啥没有选纯单轮对话式 AI 的原因。3.4 第四段格式校验与人工接手通道最后一段不是生成而是“质检 组装”。先说质检。系统会把拼接好的说明书初稿过一遍规则检查主要包括几个方面段落编号是否连续章节标题是否齐全是否有“根据所述 xxx”这类指代不明或空泛表述是否有“明显优于现有技术”这类主观夸大词审查员不喜欢技术特征是否与权利要求一一对应。这些规则我写成了一套提示词配置给校验模型跑下来准确率还不错。然后是组装输出。按照目标专利类型发明 or 实用新型把权利要求书、说明书、摘要、附图说明打包成统一的交付文档。我在这里做了一个 Markdown 转 Word 的节点因为企业内部提交交底书往往要求 .docx 格式。Dify 支持通过外部 API 或自定义脚本调转换服务这一步非常实用省掉了手动复制粘贴排版的功夫。人工接手通道是什么意思就是工作流的最终产物不是“直接拿去申请”而是标注清楚每一段的置信度、待补充项、风险提示。比如它会输出一张清单“背景技术已完整权利要求 2 存在上位化不足的风险具体实施方式缺少实验对比数据建议补充”。这样写作者拿到初稿后知道该往哪里使劲而不是面对一坨看似完整实则漏洞百出的文本发呆。4. 踩坑实录上下文超长、格式崩坏和模板打架工作流搭出来跑第一版的时候我满心以为能“一键搞定”结果被现实抽了好几个耳光。这些坑现在回看都很有代表性写出来给你们省点时间。第一个坑是上下文超长导致的“记忆断裂”。早期我用的是单轮大模型生成全文档输入一长模型到后面就开始胡言乱语甚至出现前后矛盾的表述。后来拆成并行模块生成才解掉这个问题。但并行也有代价就是模块之间的风格不统一背景技术写得像学术论文具体实施方式写得像技术博客。解决办法是在每个并行节点里植入统一的“文风规范提示词”把术语使用习惯、句式长度、编号规则都锁死再用拼装节点做一次润色。第二个坑是专利模板和生成文本的结构性冲突。Dify、Coze 这类平台输出纯 Markdown但企业内部交底书模板通常是 Word 表格有严格的行数、列宽、字体要求。我最初天真地以为“模板里贴个链接就能搞定”结果转换出来的文档表格全崩编号错乱。后来我直接在模板层做了妥协交底书正文全部用标准的一级/二级/三级标题结构不依赖复杂表格需要表格的地方用极简结构线| 分隔让插件自动转成 Word 表格。现在跑了几十份文档稳定多了。第三个坑是“多 AI 协作”时的互相打架。我的校验模型和生成模型本来是独立的两个大模型按理说一个写一个查各司其职。结果有几次校验模型觉得“背景技术引用现有技术不足”触发补写节点补写生成的内容又和发明内容线程写的重复。最后我加了一条全局规则校验模型只允许“列问题清单”不允许直接改写正文一切修改必须走人工确认节点。从此世界清净了。第四个坑很隐蔽和专利本身有关——不要用 AI 生成的内容直接提交申请。不是合规问题而是质量问题。AI 生成的权利要求往往“看起来像样但保护范围设计得很松”独立权利要求写得太大从属权利要求写得太平审查员一驳一个准。我的工作流在第四段专门加了一个“权利要求保护范围诊断”节点让模型对每一项权利要求做“宽窄评分”如果独立权利要求覆盖的特征少于 3 个就自动提示“存在可获得性风险建议补充必要技术特征”。这个逻辑不复杂但确实能让初稿质量上一个台阶。5. 防泄密与合规AI 写专利的红线不能踩用 AI 写专利技术人员最担心的一件事就是泄密。这个担心非常合理因为专利本身就是企业最有价值的无形资产之一在申请日前泄露公开可能导致新颖性丧失直接废掉申请资格。我的建议是分三档处理数据边界。第一档完全公开的场景比如个人写一些不涉密的创意发明可以用 Coze 云端版本省事。第二档企业内部敏感技术必须用私有化部署的 Dify 或其它支持本地运行的工作流平台大模型也要走企业内网部署的模型服务绝不允许把技术交底书内容发送到第三方 API。第三档高度涉密的核心技术军工、芯片、药物合成路径这类我的建议是干脆不要让 AI 接触原始方案只让它处理脱敏后的抽象描述比如把“用 CRISPR-Cas9 编辑 T 细胞”改成“一种基因编辑工具在免疫细胞上的应用”等拿到初稿框架后再由人工补入真实细节。除了数据边界还有两个合规细节容易被忽略。第一专利申请日的确定和文档保存记录要可靠AI 生成的初稿不能作为唯一证据人力介入后的修改痕迹要留档以免未来遇到权属纠纷时说不清楚发明过程。第二部分国家和地区的专利机构对 AI 辅助写入有特殊要求虽然目前多数地区允许用 AI 工具辅助但署名和发明人认定还必须由自然人承担这一点要多留意监管口径的变化。我在工作流最后增加了一个“合规确认书”节点每次生成完初稿系统会输出一段提醒文字让使用者确认是否含涉密信息、是否需脱敏处理、发明人是否已确认。看起来是个笨办法但能挡住很多冲动操作。6. 从“初稿能用”到“申请能过”人工打磨才是胜负手说句得罪人的话任何 AI 工作流生成的专利初稿离“直接提交申请”至少还有两轮人工打磨的距离。我的体会是AI 能帮你把 60 分的素材变成 80 分的初稿但从 80 分到 90 分以上的正式申请文件拼的还是人的专业能力。第一轮打磨是技术维度。研发人员要审查技术方案是否准确无歧义有没有因为表达模糊留下“不清楚”的审查意见。AI 可以在语言层把句子理顺但它不知道你的真实系统里哪个模块是核心哪个模块是附属这些东西只有在人脑里才有答案。第二轮打磨是法律维度。这一步更适合交给专利代理人。代理人会做三件事重新检索现有技术调整权利要求的保护范围策略补写可能被答复审查意见时用到的争辩素材。AI 工作流能把这个环节的沟通成本降下来因为代理人接手时拿到的不再是一堆原始聊天记录而是一份结构齐全、漏洞清单明确的技术交底书可以直接开始专业加工。我个人的经验数据是没有工作流时一份交底书从研发人员口述到代理人写完平均要三个来回一周起步。现在工作流跑完拿到初稿人工打磨一个来回基本就能定稿时间压缩到一两天。这个效率提升是实打实的。7. 再往深走一步把专利检索和侵权分析也塞进工作流最后聊点进阶玩法。四段式工作流跑通之后我加了两个扩展模块让整套系统的价值不止于“写专利”还能覆盖到“看专利”和“躲专利”。第一个是“现有技术体检模板”。在生成权利要求之前工作流先跑一遍粗检列出最接近的三篇现有技术文献给出对比表和风险提示比如“你的特征 A 在文献 X 中已有类似描述建议增加限定”。这样研发人员在写的时候就知道靶子在哪里少做无用功。粗检的检索源我用的是公开的专利数据库接口覆盖中美欧主要地区够用了。第二个是“侵权配方扫描模板”。这个更实用——把自家的技术方案拆成特征清单然后让 AI 批量比对目标专利的权利要求范围输出“落入保护范围”或“规避成功”的判定参考。注意我这里说的是“参考”专利侵权判定是很严肃的法律行为AI 不能下结论但可以让技术团队快速筛掉明显踩雷的方案避免研发做到一半才发现撞在别人的专利墙上。这两个扩展模块本质上还是“检索 结构化输出 判定建议”的老三套但放到工作流里之后变成了一次点击就能跑完的自动化报告省下来的全是过去要人工逐一比对的时间。我自己现在跑下来最大的感受是AI 工作流不是“魔法”它是一台把文本生产工业化的机床。你给它设计好加工路径它会按部就班地产出合格品。你不给它设计路径它就只能生产一堆漂亮的废品。专利撰写这个场景因为本身逻辑高度结构化、格式规范极强、价值又大正好是工作流发挥优势的典型土壤。如果你想试试我建议你先从最简单的“需求梳理 背景技术生成”这两个节点开始跑顺了再加后面的模块不用一步到位。毕竟把机床的每一个齿轮都调顺才是稳定产出的前提。
