Paper to CN Patent

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

最终输出始终以两个明确部分收尾：

• 人工复核清单
• 缺失信息与高风险问题

在适用时，至少标出以下风险类别：

• 泛化过度、缺乏支撑
• 权利要求与说明书术语不一致
• 缺少实施例或替代方案
• 披露不足，可能影响充分公开
• 某些内容更适合留在内部材料中，不宜直接进入提交版本
• 逻辑漏洞、技术可行性问题、描述不足、保护范围不当、新颖性风险和创造性风险

不要把草稿表述为法律终稿，也不要暗示其必然可以授权。

当用户要求输出审核式结果时，按 references/rewrite-review-risks-cn.md 的结构组织，至少包括：

• 专利类型
• 三性风险判断
• 创新点摘要
• 问题清单，包含问题类型、严重程度和修改建议
• 总体评价

10. Run a Compliance Pass

在将输出称为“接近终稿”前，必须用 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 个候选标题
• 是否保持标题简洁、直接、正式，能够概括技术对象与核心方案
• 是否避免营销式、宣传式或效果导向过强的措辞
• 是否避免过宽而失去技术指向，或过窄到仅覆盖单一实施例
• 是否与拟定的独立权利要求主题、技术领域和说明书正文保持一致

当用户需要分阶段交付时，按以下概念结构组织：

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 导出辅助工具

除非用户明确要求实现，否则不要自行假设这些工具已经存在。