--- 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/patent-structure-cn.md) 和 [references/paper-to-patent-mapping.md](references/paper-to-patent-mapping.md)。 生成或修改权利要求前，先读取 [references/claim-writing-guide.md](references/claim-writing-guide.md)。 输出接近终稿的内容或审核报告前，先读取 [references/review-checklist-cn.md](references/review-checklist-cn.md)。 执行完整性或一致性检查前，先读取 [references/compliance-check-cn.md](references/compliance-check-cn.md)。 当用户要求输出发明名称、发明人或申请人字段、申请元数据占位信息，或更完整的申请包结构时，先读取 [references/front-matter-cn.md](references/front-matter-cn.md)。 规划附图、图名或参考标号规则前，先读取 [references/diagram-guidelines-cn.md](references/diagram-guidelines-cn.md)。 将论文语言改写成专利语言前、准备放宽权利要求范围前、以及输出审核或质量判断前，先读取 [references/rewrite-review-risks-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 最终输出始终以两个明确部分收尾： - 人工复核清单 - 缺失信息与高风险问题 在适用时，至少标出以下风险类别： - 泛化过度、缺乏支撑 - 权利要求与说明书术语不一致 - 缺少实施例或替代方案 - 披露不足，可能影响充分公开 - 某些内容更适合留在内部材料中，不宜直接进入提交版本 - 逻辑漏洞、技术可行性问题、描述不足、保护范围不当、新颖性风险和创造性风险 不要把草稿表述为法律终稿，也不要暗示其必然可以授权。 当用户要求输出审核式结果时，按 [references/rewrite-review-risks-cn.md](references/rewrite-review-risks-cn.md) 的结构组织，至少包括： - 专利类型 - 三性风险判断 - 创新点摘要 - 问题清单，包含问题类型、严重程度和修改建议 - 总体评价 ### 10. Run a Compliance Pass 在将输出称为“接近终稿”前，必须用 [references/compliance-check-cn.md](references/compliance-check-cn.md) 做一次结构化自检。 至少核查以下内容： - 必要章节是否齐全 - 权利要求术语是否被说明书支撑 - 附图引用是否前后一致 - 标题、摘要和前置信息是否与正文一致 - 尚未确认的占位内容是否已明确标出 - 文本是否明确指出仍需人工确认的地方 - 改写完成后，逻辑、技术可行性、创新定位和保护范围是否仍然一致 如果用户希望得到更接近申请包的交付形式，则将结果组织为分阶段产物，而不是一个巨大的单体文本。 ## Output Contract 除非用户明确只要较小的中间产物，否则默认按以下顺序输出： 1. 发明摘要与输入充分性检查 2. 如适用，输出前置可专利性说明 3. 专利映射结果 4. 专利骨架 5. 权利要求草稿 6. 完整说明书草稿 7. 附图与参考标号规划 8. 如需要，输出前置信息占位 9. 合规性检查摘要 10. 人工复核清单 11. 缺失信息与高风险问题 如果用户只想要更快的第一版，也仍然要保持“先权利要求、后说明书”的顺序。 在每次输出答案前，都必须额外执行一次语言风格检查，至少确认以下事项： - 是否使用正式、书面的语言 - 是否存在影响阅读和理解的长句、堆叠并列或表意不清的问题 - 是否可以在不改变技术含义的前提下进一步压缩句式、提升可读性 - 是否仍保持专利文风、术语一致性和技术表述准确性 - 是否符合中文专利说明书常见的短段写法，优先控制为每段一至两句，避免单段过长 - 当段落中出现较长句或并列层级过多时，是否进一步拆句、分段，或替换为更直接、更稳定的书面表达方式 当输出包含“权利要求书”部分时，还必须额外确认以下事项： - 对于模型改进型专利，权利要求书的重点是否已经明确落在模型本身及其关键改进结构上，而不是泛泛描述整套应用流程 - 若模型名称已经确定，是否优先围绕该模型名称、基准模型和关键模块组织独立权利要求 - 独立权利要求是否优先写清模型构成、模块关系和输出内容，从属权利要求是否再分别限定定向边界框、骨干网络、特征融合模块、检测头、剪枝策略和后处理等内容 - 在论文、结构图或用户材料已经提供明确支撑的前提下，是否可以适度在从属权利要求中加入公式，以增强技术特征限定的明确性 - 公式是否仅选取真正有支撑且对权利要求限定有价值的内容，避免为追求形式而加入无支撑、无必要或过度论文化的公式 - 当公式进入权利要求时，是否优先以简洁、规范的 LaTeX 形式表达，并确保符号含义可由说明书充分支撑 当输出包含“技术领域”部分时，还必须额外确认以下事项： - 是否位于背景技术之前，并作为独立部分出现 - 是否通常用一句话概括发明所属的技术领域 - 是否优先采用“本发明涉及……技术领域，具体涉及一种……”或与之等效的书面句式 - 是否只说明技术归属，而未混入背景现状、现有缺陷、技术效果、创新点或实施细节 - 是否采用简洁、正式、边界清晰的书面表达 当输出包含“发明内容”部分时，还必须额外确认以下事项： - 开头是否明确承接背景技术中的现有问题 - 第一处目的性表述是否优先采用“本发明的目的在于提供一种……，以解决上述背景技术中提出的问题”或与之等效的书面表达 - 开头是否优先采用两段式结构：第一段概括“本发明的目的在于提供一种……，以解决上述背景技术中提出的问题”，第二段概括“为实现上述目的，本发明提供一种……，所述……包括：” - 是否先写要解决的技术问题，再写技术方案和有益效果 - 对“要解决的技术问题”的表述是否点到为止，避免在发明内容开头大段重复背景技术中已经写过的问题 - 第一段是否仅对目的作简洁概括，并用“以解决上述背景技术中提出的问题”或近似句式完成承接 当输出包含“摘要”部分时，在最终输出前还必须额外确认以下事项： - 是否已经做过一次专门的摘要风格检查，确认文本更接近中国发明专利公开文本，而非论文摘要或技术简介 - 对于以具体模型为核心的方案，摘要是否优先突出模型本身及其关键改进，而非泛化为整个方法流程的平铺描述 - 当用户明确要求强调某一模型时，是否围绕该模型名称、基准网络和关键改进模块组织摘要主句 - 第二段是否用于引出方法、系统、装置或介质及其具体内容、模块或步骤，并优先采用“为实现上述目的，本发明提供一种……，所述……包括：”的句式 - “技术方案”部分是否写得充分，不仅列出步骤名称，还交代各步骤的主要处理内容和作用 - 对方法步骤的描述是否优先控制为每步 2 至 3 句；在保证清晰的前提下，不写得过短 - 各步骤是否尽量说明该步骤解决什么问题、起到什么作用，必要时可点出对应的创新点 - 对创新点的表述是否嵌入对应步骤中自然说明，而不是脱离技术步骤单独堆砌 - 各步骤之间的顺序、输入输出和逻辑衔接是否清楚 - 是否避免把步骤写成仅有标题的一行式表述，也避免把细节写死到不利于后续权利要求概括 - 当方案属于改进现有检测模型、分割模型或识别模型的专利时，是否在“发明内容”中明确写出模型名称、基准模型名称以及核心改进模块名称 - 对于模型改进型方案，是否优先采用“所述模型以……模型为基础，并在其基础上进行改进，具体改进为……”或与之等效的书面表达 - 是否将核心改进模块按结构层次写清，例如骨干网络、特征融合模块、检测头、损失函数、剪枝策略或部署结构 - 是否区分“可保留专有模型名用于说明书描述”和“后续权利要求中需适度概括”的边界，避免在说明书中遗漏关键模块名称 - “有益效果”部分是否相对充分展开，而不是仅用一句空泛结论带过 - 各项有益效果是否尽量对应前文的具体技术手段，例如定向边界框、轻量化骨干、动态特征融合、检测头结构或剪枝压缩 - 各项有益效果是否可用 2 至 3 句进行说明，但仍保持句式清晰，不堆砌修饰 - “有益效果”条目数量是否优先控制为 2 至 3 条，只保留最重点、最明显、最有支撑的效果 - 是否避免将若干相近效果机械拆分成过多条目，导致内容分散和重复 - 是否避免将实验指标、夸张性结论或未经支撑的绝对优势直接写成有益效果 - 是否避免在首句中堆叠过多并列问题，影响阅读和理解 当输出包含“标题”部分时，还必须额外确认以下事项： - 是否根据文章的主要技术贡献生成标题，而不是照搬论文题目 - 是否优先生成多个候选标题供用户比较和选择；如无特别说明，默认给出 3 至 5 个候选标题 - 是否保持标题简洁、直接、正式，能够概括技术对象与核心方案 - 是否避免营销式、宣传式或效果导向过强的措辞 - 是否避免过宽而失去技术指向，或过窄到仅覆盖单一实施例 - 是否与拟定的独立权利要求主题、技术领域和说明书正文保持一致 当用户需要分阶段交付时，按以下概念结构组织： ```text 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 导出辅助工具 除非用户明确要求实现，否则不要自行假设这些工具已经存在。