ThomasMoreAI 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
除非用户明确只要较小的中间产物，否则默认按以下顺序输出：
- 发明摘要与输入充分性检查
- 如适用，输出前置可专利性说明
- 专利映射结果
- 专利骨架
- 权利要求草稿
- 完整说明书草稿
- 附图与参考标号规划
- 如需要，输出前置信息占位
- 合规性检查摘要
- 人工复核清单
- 缺失信息与高风险问题
如果用户只想要更快的第一版，也仍然要保持“先权利要求、后说明书”的顺序。
在每次输出答案前，都必须额外执行一次语言风格检查，至少确认以下事项：
- 是否使用正式、书面的语言
- 是否存在影响阅读和理解的长句、堆叠并列或表意不清的问题
- 是否可以在不改变技术含义的前提下进一步压缩句式、提升可读性
- 是否仍保持专利文风、术语一致性和技术表述准确性
- 是否符合中文专利说明书常见的短段写法，优先控制为每段一至两句，避免单段过长
- 当段落中出现较长句或并列层级过多时，是否进一步拆句、分段，或替换为更直接、更稳定的书面表达方式
当输出包含“权利要求书”部分时，还必须额外确认以下事项：
- 对于模型改进型专利，权利要求书的重点是否已经明确落在模型本身及其关键改进结构上，而不是泛泛描述整套应用流程
- 若模型名称已经确定，是否优先围绕该模型名称、基准模型和关键模块组织独立权利要求
- 独立权利要求是否优先写清模型构成、模块关系和输出内容，从属权利要求是否再分别限定定向边界框、骨干网络、特征融合模块、检测头、剪枝策略和后处理等内容
- 在论文、结构图或用户材料已经提供明确支撑的前提下，是否可以适度在从属权利要求中加入公式，以增强技术特征限定的明确性
- 公式是否仅选取真正有支撑且对权利要求限定有价值的内容，避免为追求形式而加入无支撑、无必要或过度论文化的公式
- 当公式进入权利要求时，是否优先以简洁、规范的 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 导出辅助工具
除非用户明确要求实现，否则不要自行假设这些工具已经存在。