写专利这件事，我以前一直觉得是个“手工作坊”的活：找资料、梳理创新点、画技术方案、写权利要求书，哪一步都得靠人一点点磨，写一份靠谱的技术交底书有时候得憋一周。直到我自己把 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 这类开源审批工作流自己做一套，那就是另一条路了，门槛高很多，普通业务团队没必要碰。

选型层面我给出一个可参考的取舍逻辑，见下表：

我自己最终的架构是这样的：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 工作流不是“魔法”，它是一台把文本生产工业化的机床。你给它设计好加工路径，它会按部就班地产出合格品。你不给它设计路径，它就只能生产一堆漂亮的废品。专利撰写这个场景，因为本身逻辑高度结构化、格式规范极强、价值又大，正好是工作流发挥优势的典型土壤。如果你想试试，我建议你先从最简单的“需求梳理 + 背景技术生成”这两个节点开始，跑顺了再加后面的模块，不用一步到位。毕竟，把机床的每一个齿轮都调顺，才是稳定产出的前提。