Skip to main content Início Criadores thomasmoreai legal-skills-open paper-to-cn-patent
paper-to-cn-patent Convert finished research papers, figures, and author notes into Chinese invention patent application drafts. Use when Codex needs to rewrite a paper as a China invention patent, draft claims, abstract, specification sections, and figure descriptions, assess whether the source materials are sufficient for patent drafting, or produce a missing-information report and manual review checklist before filing.
Ir para a instalação Skills Marketplace Descubra e explore skills de IA criadas pela comunidade.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Mostrar detalhes do prompt Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
npx skills add https://github.com/ThomasMoreAI/legal-skills-open --skill paper-to-cn-patentO comando permanece em uma só linha. Role horizontalmente para revisá-lo antes de copiar.
Prefere uma cópia local? Baixe os arquivos disponíveis atualmente no SkillsMP.
Baixar Zip Baixando... determining-pl-request-regime Use when choosing the Polish legal regime for letters, requests, applications, complaints, petitions, public-information requests, KPA filings, PPSA complaints, RODO access requests, registry extracts, court-file access, tax/ZUS/cudzoziemcy/USC procedures, or professional lawyer letters. Prevents mixing UDIP, KPA, PPSA, RODO, registry, special-procedure, and advocate/radca letter regimes.
Ocupações relacionadas SOC
Baseado na classificação ocupacional SOC
name paper-to-cn-patent title Paper to CN Patent description Convert finished research papers, figures, and author notes into Chinese invention patent application drafts. Use when Codex needs to rewrite a paper as a China invention patent, draft claims, abstract, specification sections, and figure descriptions, assess whether the source materials are sufficient for patent drafting, or produce a missing-information report and manual review checklist before filing. author learnljs author_url https://github.com/learnljs/paper-to-cn-patent license MIT version 0.1.0 execution_mode open jurisdiction cn practice ip language zh
Paper to CN Patent
Overview
将已完成的论文、附图和作者备注重构为接近可提交质量的中文发明专利草稿，同时始终保留明确的人工复核门槛。
除非用户明确要求其他语言，否则默认用中文输出。
默认语言风格要求如下，并适用于所有中间产物与最终产物：
使用正式、书面的语言
表达应利于阅读和理解，优先使用句式清晰、逻辑直接的表述
避免过长句、并列过多、口语化表达以及不必要的修饰
在保持专利文风的前提下，优先保证信息传达清楚、段落结构稳定
本 skill 同时支持两类输入场景：一类是“论文转专利”改写，另一类是当材料中还包含发明交底、会议纪要或结构化作者备注时的更宽泛专利起草场景。
Load References
开始起草前，先读取 references/patent-structure-cn.md 和 references/paper-to-patent-mapping.md 。
生成或修改权利要求前，先读取 references/claim-writing-guide.md 。
输出接近终稿的内容或审核报告前，先读取 references/review-checklist-cn.md 。
执行完整性或一致性检查前，先读取 references/compliance-check-cn.md 。
当用户要求输出发明名称、发明人或申请人字段、申请元数据占位信息，或更完整的申请包结构时，先读取 references/front-matter-cn.md 。
规划附图、图名或参考标号规则前，先读取 references/diagram-guidelines-cn.md 。
将论文语言改写成专利语言前、准备放宽权利要求范围前、以及输出审核或质量判断前，先读取 references/rewrite-review-risks-cn.md 。
Drafting Workflow
严格按以下顺序执行，不要直接从论文跳到完整终稿。
1. Intake and Invention Triage
尽量收集以下输入材料：
论文全文或论文主要章节
图题、流程图说明或系统结构图
作者备注，包括真正的创新点、希望保护的重点、不能公开的内容、可接受的泛化程度
当论文信息不足时，补充发明交底、实验记录、会议纪要或产品需求说明
正式起草前，先输出一份简短的发明摘要，至少覆盖：
所属技术领域
实际要解决的技术问题
可能的可保护核心
当前材料支持的实施形态，例如方法、系统、装置、模块或存储介质
主要披露缺口或保密风险
在这一阶段，必须明确给出专利类型建议：
如果材料主要围绕方法、算法、控制逻辑、技术流程、系统或技术产品，则优先判断为发明专利
只有当创新主要体现为产品形状、结构或构造改进，而非算法或处理逻辑时，才考虑实用新型
如果材料不足以做出稳定判断，则标记为“类型待确认”
当材料明显指向其他类型时，不要默认套用原有类型。
如果缺少下列任一信息，在起草终稿前必须先追问：
核心可保护技术特征
实施步骤或模块关系
可选变体、替代方案或兜底实施例
不能公开的边界条件
如果用户要更完整申请包，还包括发明人、申请人、标题或优先权占位信息
如果材料不完整，先输出缺失信息清单。不要虚构技术细节。
2. Front-End Patentability Check
当用户要求的不只是纯改写，而是更像专利方案评估时，在权利要求起草前加入一轮轻量前置评估。
输出一份简短的研究与可专利性说明，至少包括：
用户已描述或材料中可识别的最接近现有技术方向
可能的区别特征
第一项独立权利要求的大致保护宽度建议
当前更适合直接继续、缩小目标，还是先补充材料
除非用户已经提供正式检索结果，否则对新颖性、创造性和实用性的判断一律写成“初步风险判断”，不要写成最终法律结论。
除非用户明确提供了正式检索结果，或明确要求并完成了相关检索工作，否则不要声称已经完成正式现有技术检索。
3. Build the Patent Mapping 在撰写权利要求和说明书前，先把论文重组为面向专利的结构。
技术领域
背景技术
要解决的技术问题
核心技术方案
关键技术效果
候选实施例、替代方案、可选模块或流程变体
论文原文已经明确支撑的内容
可以在原文基础上合理泛化的内容
仍然需要作者确认的内容
不要把实验指标、对比排名或学术结论直接当作保护范围本身。
离开映射阶段前，必须做一次闭环检查，将以下四项连起来：
如果这四部分之间不一致，先修正结构，再进入权利要求起草。
Checkpoint A 在进入正式起草阶段前，先展示发明摘要、前置评估说明（如果有）以及专利映射结果。
如果映射结果显示当前材料支撑不了目标保护范围，先暂停，并说明应该缩小范围、补充材料还是重新定义方案。
如果已经出现明显的新颖性或创造性风险，要在这一阶段直接指出，而不是拖到最后的复核部分。
4. Generate the Patent Skeleton
标题
技术领域
摘要
背景技术
发明内容
附图简要说明
具体实施方式
权利要求
如果用户需要，则加入前置信息占位
如果用户需要，则加入申请包占位结构
如果材料同时支撑方法保护和系统或装置保护，要在骨架阶段先标出这种双路径机会，再进入权利要求起草。
5. Draft Claims First
核心独立项范围
适合放入从属项的优选限定特征
兜底实施方式
只有在材料确实支撑时，才扩展方法、系统、装置或存储介质等备选路径
可选技术特征
模块关系
只有在有支撑且策略上确有必要时才加入参数范围或阈值
能够稳定保护范围的实现细节
优先写清楚技术特征，不要用学术动机语言替代技术限定。除非效果确实对应具体技术手段，否则不要把优势或结果直接写成权利要求特征。
对于模型改进型方案，若用户已经明确模型名称，权利要求的重心应优先放在该模型本身及其关键改进结构上，而不是将全文重心放在泛化的“训练‑部署‑输出”流程描述上。
当发明的核心在于某一改进模型时，独立权利要求应优先围绕“基于什么基准模型构建何种改进模型、该模型包括哪些关键模块、这些模块之间如何配合实现检测或计数”进行组织；训练、剪枝、部署和结果输出等流程内容可以保留，但不应掩盖模型本体这一保护重点。
从属权利要求应优先围绕模型中的关键技术特征逐层展开，例如定向边界框表示方式、骨干网络结构、特征融合模块、检测头结构、剪枝策略、后处理方式等，使保护层次与模型结构层次保持一致。
如果材料只支撑方法类权利要求，要明确说清，不要凭空补出没有支撑的装置或系统结构。
在最终确定权利要求语言前，再做一次技术可行性检查：
当前权利要求中的步骤或模块，是否能由已披露材料支撑实施
关键参数和条件是否合理
所述技术原理是否与描述的技术机制一致
是否存在只是目标表达、却并未真正使能的权利要求要素
仅方法
方法加系统
方法加装置
方法加系统加存储介质
当用户要求将权利要求写得更接近“可提交草稿”时，还必须额外确认以下事项：
独立权利要求是否已经围绕真正的核心创新进行收紧，而不是停留在宽泛、空泛的流程性描述
是否在保持保护范围合理的前提下，突出模型名称、基准模型及关键改进模块
是否避免将过多实验条件、训练超参数或仅实施例层面的细节直接写入独立项
是否通过从属权利要求逐层限定关键结构与关键计算关系，而不是把所有细节一次性塞入独立项
Checkpoint B 在扩写完整说明书前，先展示权利要求策略和第一版权利要求集合。
当保护宽度、实施形态拆分或保密边界仍不明确时，先征求用户反馈。
6. Expand the Specification
标题
技术领域
摘要
背景技术
发明内容
附图简要说明
具体实施方式
权利要求
如用户要求，还应包含前置信息占位
使用客观、可实施的表述
避免学术争论腔
避免无支撑的绝对化或夸张性表达
保持术语与权利要求一致
使用正式、书面的语言，并确保表达利于阅读和理解
优先拆分冗长句子，减少单句中的并列层级，避免影响可读性
各章节之间存在逻辑矛盾
缺少关键参数、前提条件或实施细节
技术表述与基本工程、物理或化学原理冲突
泛化过度，超出原始材料支撑范围
某些细节过于敏感不宜公开，但又重要到不能省略，否则会削弱充分公开
当输出包含“摘要”部分时，还必须额外确认以下事项：
是否优先采用中国发明专利公开文本常见的摘要写法，而不是论文摘要式写法
对于模型改进型方案，摘要重心是否优先放在“提出了什么模型、模型基于什么基准进行改进、包含哪些关键改进模块、能够实现什么技术效果”，而不是完整展开方法流程
当模型名称已经确定时，是否优先在摘要中点明模型名称，并围绕该模型的改进构成进行组织
是否优先概括基准模型、骨干网络改进、特征融合改进、检测头改进、压缩或部署改进等核心技术特征
是否避免将训练、部署、输入输出流程逐步写成“步骤一、步骤二”的过程性表述，除非该流程本身就是用户明确要求保护的重点
是否避免堆叠实验数据、宣传性结论和论文式评价语言，优先使用“能够……”“适于……”等专利文风表述技术效果
是否在保持技术信息完整的前提下控制句式紧凑，使整体表达更接近专利公开文本的摘要风格
当输出包含“具体实施方式”部分时，还必须额外确认以下事项：
是否优先采用专利说明书常见的连续展开式写法，而不是自拟“大标题+一、二、三”式结构
是否优先使用“下面结合附图和实施例对本发明作进一步说明”“在一个实施例中”“如图1所示”“步骤1”“其中”“进一步地”等衔接句式
是否先概括主流程，再围绕步骤、模型、模块和参数逐步展开
对于模型改进型方案，是否在具体实施方式中自然展开模型名称、基准模型、骨干网络、特征融合模块、检测头和剪枝策略，而不是割裂成多个大节标题
是否可以适度引入必要的参数化表达、损失函数、结构公式或原理说明，但不应达到论文式推导深度
是否保持段落衔接自然、逻辑连续，并便于与附图说明和发明内容对应
当用户提供了结构图、模块图或对应论文时，是否优先参考结构图中的组成关系来展开“具体实施方式”
对于 StarNet、C2f-Dynamic、LMBD、LAMP 等关键模块，是否按结构图进一步拆分为若干子模块或处理单元进行说明，而不只停留在模块作用概述层面
每个关键模块是否尽量写清“由什么组成、如何处理、输出什么、起什么作用”这四类信息
是否将关键公式自然融合到模块说明中，以支撑公开充分，但避免形成大段论文式推导
公式输出时是否优先使用 LaTeX 形式书写，并保持符号定义完整、上下文衔接清楚
公式后的符号定义是否也优先使用 LaTeX 形式表达，避免正文说明与公式表示风格割裂
对于检测或推理过程，是否优先细化为输入预处理、特征提取、特征融合、检测头输出、候选框筛选、旋转非极大值抑制、计数输出等环节
即使附图不完整，也应先给出最小可用的附图说明，并明确标出所有假设。
主实施例
可选变体
替代实施例
在有帮助时加入实现示例
7. Plan Figures and Reference Numbers 在最终定稿前，先识别支撑说明书所需的最小附图集合。
图号列表
每幅图的一句话用途说明
建议的参考标号范围
是否需要系统结构图、流程图、模块关系图或变体图
流程图步骤数是否优先控制为 5 至 6 个步骤
是否按技术主流程进行归并，优先体现输入、处理、模型构建或调用、结果输出等主线环节
是否避免将骨干网络、特征融合模块、检测头、剪枝策略等模块细节拆成过多独立流程步骤
各步骤名称是否简洁、稳定，并能够直接对应附图说明和具体实施方式中的主步骤
若模型训练与模型部署均属于方案关键内容，是否分别保留为独立步骤
当用户后续据此绘制专利流程图时，是否提醒流程图中的图形要素应保留必要引线，以保证步骤框、说明文字和指向关系清楚
如果用户没有要求实际生成图片，就只输出文字版的附图规划和说明。
Checkpoint C 说明书骨架和附图规划就绪后，如果任务较大，或用户明显需要先审一轮结构，再暂停等待确认。
8. Prepare Front Matter and Filing Metadata
标题
发明人姓名
申请人或受让人
联系信息占位
优先权或关联申请占位
摘要
仍需用户确认的书目信息
9. Finish with Review and Risk Controls
泛化过度、缺乏支撑
权利要求与说明书术语不一致
缺少实施例或替代方案
披露不足，可能影响充分公开
某些内容更适合留在内部材料中，不宜直接进入提交版本
逻辑漏洞、技术可行性问题、描述不足、保护范围不当、新颖性风险和创造性风险
不要把草稿表述为法律终稿，也不要暗示其必然可以授权。
专利类型
三性风险判断
创新点摘要
问题清单，包含问题类型、严重程度和修改建议
总体评价
10. Run a Compliance Pass
必要章节是否齐全
权利要求术语是否被说明书支撑
附图引用是否前后一致
标题、摘要和前置信息是否与正文一致
尚未确认的占位内容是否已明确标出
文本是否明确指出仍需人工确认的地方
改写完成后，逻辑、技术可行性、创新定位和保护范围是否仍然一致
如果用户希望得到更接近申请包的交付形式，则将结果组织为分阶段产物，而不是一个巨大的单体文本。
Output Contract 除非用户明确只要较小的中间产物，否则默认按以下顺序输出：
发明摘要与输入充分性检查
如适用，输出前置可专利性说明
专利映射结果
专利骨架
权利要求草稿
完整说明书草稿
附图与参考标号规划
如需要，输出前置信息占位
合规性检查摘要
人工复核清单
缺失信息与高风险问题
如果用户只想要更快的第一版，也仍然要保持“先权利要求、后说明书”的顺序。
在每次输出答案前，都必须额外执行一次语言风格检查，至少确认以下事项：
是否使用正式、书面的语言
是否存在影响阅读和理解的长句、堆叠并列或表意不清的问题
是否可以在不改变技术含义的前提下进一步压缩句式、提升可读性
是否仍保持专利文风、术语一致性和技术表述准确性
是否符合中文专利说明书常见的短段写法，优先控制为每段一至两句，避免单段过长
当段落中出现较长句或并列层级过多时，是否进一步拆句、分段，或替换为更直接、更稳定的书面表达方式
当输出包含“权利要求书”部分时，还必须额外确认以下事项：
对于模型改进型专利，权利要求书的重点是否已经明确落在模型本身及其关键改进结构上，而不是泛泛描述整套应用流程
若模型名称已经确定，是否优先围绕该模型名称、基准模型和关键模块组织独立权利要求
独立权利要求是否优先写清模型构成、模块关系和输出内容，从属权利要求是否再分别限定定向边界框、骨干网络、特征融合模块、检测头、剪枝策略和后处理等内容
在论文、结构图或用户材料已经提供明确支撑的前提下，是否可以适度在从属权利要求中加入公式，以增强技术特征限定的明确性
公式是否仅选取真正有支撑且对权利要求限定有价值的内容，避免为追求形式而加入无支撑、无必要或过度论文化的公式
当公式进入权利要求时，是否优先以简洁、规范的 LaTeX 形式表达，并确保符号含义可由说明书充分支撑
当输出包含“技术领域”部分时，还必须额外确认以下事项：
是否位于背景技术之前，并作为独立部分出现
是否通常用一句话概括发明所属的技术领域
是否优先采用“本发明涉及……技术领域，具体涉及一种……”或与之等效的书面句式
是否只说明技术归属，而未混入背景现状、现有缺陷、技术效果、创新点或实施细节
是否采用简洁、正式、边界清晰的书面表达
当输出包含“发明内容”部分时，还必须额外确认以下事项：
开头是否明确承接背景技术中的现有问题
第一处目的性表述是否优先采用“本发明的目的在于提供一种……，以解决上述背景技术中提出的问题”或与之等效的书面表达
开头是否优先采用两段式结构：第一段概括“本发明的目的在于提供一种……，以解决上述背景技术中提出的问题”，第二段概括“为实现上述目的，本发明提供一种……，所述……包括：”
是否先写要解决的技术问题，再写技术方案和有益效果
对“要解决的技术问题”的表述是否点到为止，避免在发明内容开头大段重复背景技术中已经写过的问题
第一段是否仅对目的作简洁概括，并用“以解决上述背景技术中提出的问题”或近似句式完成承接
当输出包含“摘要”部分时，在最终输出前还必须额外确认以下事项：
是否已经做过一次专门的摘要风格检查，确认文本更接近中国发明专利公开文本，而非论文摘要或技术简介
对于以具体模型为核心的方案，摘要是否优先突出模型本身及其关键改进，而非泛化为整个方法流程的平铺描述
当用户明确要求强调某一模型时，是否围绕该模型名称、基准网络和关键改进模块组织摘要主句
第二段是否用于引出方法、系统、装置或介质及其具体内容、模块或步骤，并优先采用“为实现上述目的，本发明提供一种……，所述……包括：”的句式
“技术方案”部分是否写得充分，不仅列出步骤名称，还交代各步骤的主要处理内容和作用
对方法步骤的描述是否优先控制为每步 2 至 3 句；在保证清晰的前提下，不写得过短
各步骤是否尽量说明该步骤解决什么问题、起到什么作用，必要时可点出对应的创新点
对创新点的表述是否嵌入对应步骤中自然说明，而不是脱离技术步骤单独堆砌
各步骤之间的顺序、输入输出和逻辑衔接是否清楚
是否避免把步骤写成仅有标题的一行式表述，也避免把细节写死到不利于后续权利要求概括
当方案属于改进现有检测模型、分割模型或识别模型的专利时，是否在“发明内容”中明确写出模型名称、基准模型名称以及核心改进模块名称
对于模型改进型方案，是否优先采用“所述模型以……模型为基础，并在其基础上进行改进，具体改进为……”或与之等效的书面表达
是否将核心改进模块按结构层次写清，例如骨干网络、特征融合模块、检测头、损失函数、剪枝策略或部署结构
是否区分“可保留专有模型名用于说明书描述”和“后续权利要求中需适度概括”的边界，避免在说明书中遗漏关键模块名称
“有益效果”部分是否相对充分展开，而不是仅用一句空泛结论带过
各项有益效果是否尽量对应前文的具体技术手段，例如定向边界框、轻量化骨干、动态特征融合、检测头结构或剪枝压缩
各项有益效果是否可用 2 至 3 句进行说明，但仍保持句式清晰，不堆砌修饰
“有益效果”条目数量是否优先控制为 2 至 3 条，只保留最重点、最明显、最有支撑的效果
是否避免将若干相近效果机械拆分成过多条目，导致内容分散和重复
是否避免将实验指标、夸张性结论或未经支撑的绝对优势直接写成有益效果
是否避免在首句中堆叠过多并列问题，影响阅读和理解
当输出包含“标题”部分时，还必须额外确认以下事项：
是否根据文章的主要技术贡献生成标题，而不是照搬论文题目
是否优先生成多个候选标题供用户比较和选择；如无特别说明，默认给出 3 至 5 个候选标题
是否保持标题简洁、直接、正式，能够概括技术对象与核心方案
是否避免营销式、宣传式或效果导向过强的措辞
是否避免过宽而失去技术指向，或过窄到仅覆盖单一实施例
是否与拟定的独立权利要求主题、技术领域和说明书正文保持一致
patent-application/
01-intake/
02-research/
03-claims/
04-specification/
05-diagrams/
06-front-matter/
07-compliance/
08-filing-package/
即使当前还没有真正落盘成文件，也要把它当作输出组织模型。
Scope Boundaries
生成 .docx 文件
应用 Word 排版或样式
组装正式提交级申请包
对接实时数据库做正式现有技术检索或法律层面的可专利性分析
scripts/ 目录为后续自动化能力预留，例如：
权利要求与说明书术语一致性检查
参考标号一致性检查
分阶段产物生成
Word 导出辅助工具
除非用户明确要求实现，否则不要自行假设这些工具已经存在。
