patent-disclosure-skill 结构事实链：StructureSchema 与 FigurePlan 的填写规范、源码门禁与双模式消费实战

patent-disclosure-skill 结构事实链StructureSchema 与 FigurePlan 的填写规范、源码门禁与双模式消费实战【免费下载链接】patent-disclosure-skill中国专利.skill专利点挖掘与交底书发明/实用/外观编写通俗解读专利嗅探政策动向辅助审查答复。项目地址: https://gitcode.com/GitHub_Trending/pa/patent-disclosure-skill导读本文围绕开源仓库 patent-disclosure-skill中国专利交底书编写 Skill中的核心提示词文档 fill_structure_schema.md 展开系统讲解「图 / 原文 → 结构事实」这一关键环节如何把实用新型或发明案中的装置结构的实拍照片、CAD 截图、爆炸图、专利附图整理成可供交底书与专利解读共用的结构化事实StructureSchema并配套固化附图选用清单FigurePlan。读完本文你将掌握 StructureSchema / FigurePlan 两份合同的字段语义、落盘目录约定、8 步填写流程、图际关联relates_to的强制规则、多轮同步纪律以及结构辅助线稿的可选链路与源码级门禁校验原理能够直接在一个实用新型交底或装置向解读任务中按规范落地执行。一、合同定位结构事实的单一事实源在 patent-disclosure-skill 的整个流水线中「结构」信息不是散落在交底书正文或解读笔记里的描述文字而是先被提炼成一份结构化实例再被下游消费。承担这一职责的契约文件是 structure.schema.yaml其文件头即点明定位用于实用新型交底与实用新型及装置向专利解读。单一事实源写读共用。与之配套的附图选用清单合同是 figure_plan.schema.yaml文档明确要求「交底必做」——在成文前固化「贴哪些图、图序、为何选用、图与图如何关联」。1.1 两份合同的分工合同文件职责StructureSchemastructure.schema.yaml记录产品形状 / 构造事实部件、连接、空间关系、结构功能、不确定项FigurePlanfigure_plan.schema.yaml固化交底附图选用与排序贴哪些图、图序、为何选用、图与图如何关联两者配套使用且都具备「写读共用」属性交底成文阶段写入、成文与迭代阶段只读解读阶段同样写入并在生成 Obsidian 笔记时消费。1.2 消费者谁在消费这两份产物fill_structure_schema.md 明确列出了下游消费者交底侧prompts/disclosure/utility_model/实用新型交底成文Step 7 要求成文前必须已有 StructureSchema 与同目录figure_plan.yaml见 disclosure_builder.md解读侧prompts/reader/实用新型或装置附图的通俗解读工作目录约定写入structure_schema.json见 patent_plain_reader.md。从源码结构看这种「双模式」设计让同一份结构事实既可以驱动交底书第三章的技术方案撰写又可以驱动解读笔记的「结构说明」章节避免了两条链路各自维护一套结构描述的重复劳动。二、何时需要 Read 本流程fill_structure_schema.md 给出了两个明确触发条件二者满足其一即应执行交底类型为实用新型或发明案中需写清装置结构解读对象为实用新型或附图以装配/结构为主。在解读链路中patent_plain_reader.md 进一步强化了这一要求若专利类型判定为实用新型或外观设计在写笔记正文之前必须先在 workdir 写入structure_schema.json或appearance_schema.json且「用户未声明时不得因『没说类型』而跳过 Schema」。三、落盘目录约定交底模式默认落盘目录为outputs/{案件标识}/与交底定稿同级。同目录需要写出两份文件文件说明structure_schema.yaml或.jsonStructureSchema 实例figure_plan.yaml入文附图选用、排序与图际关联关键约定figure_plan.schema_ref字段应填本实例的相对路径如structure_schema.yaml切勿误填合同文件references/schemas/structure.schema.yaml——前者指向案件目录里实际写出的实例后者只是 schema 定义。解读模式则使用脚本约定名工作目录下的structure_schema.json此时figure_plan可选不强制但若写了 figure_plan 仍建议补relates_to。四、StructureSchema 字段全解structure.schema.yaml 提供了完整的字段骨架结合 fill_structure_schema.md 的口径逐字段说明如下$schema: structure.schema version: 1 mode: disclosure # disclosure | reader source_images: [] # 看过的图路径或说明交底入文以 figure_plan 为准 parts: - id: 1 name: # 部件名 shape: # 板状/杆状/壳体/鳍片阵列等 material_hint: # 可空unknown 则写 unknown relations: - from: 1 to: 2 type: # 卡扣|螺栓|铰接|焊接|一体成型|过盈|粘接|其他 where: # 位置 seen_in: [] # 可选figure_plan 的 fig 号表示哪些图能看见该连接 spatial: [] # 上下/内外/同轴/阵列等短句 function_of_structure: [] # 该结构解决什么问题非纯方法步骤 delta_hypothesis: [] # 相对常见结构可能新在哪 uncertain: [] # 看不清 / 说明书未写明 not_utility_model_signals: [] # 若更像方法/外观列于此供分流4.1 字段语义与填写要点mode二选一disclosure交底或reader解读。不同模式影响落盘文件名structure_schema.yamlvsstructure_schema.json与消费方式。source_images记录本轮看过的图可以是路径或说明但注意「交底入文以 figure_plan 为准」即source_images只用于溯源不承担附图选用职责。parts部件清单id是跨图统一的件号name是部件名shape用「板状/杆状/壳体/鳍片阵列」等结构化短词描述形态material_hint可空确不知时写unknown。relations连接关系。type有受控枚举卡扣|螺栓|铰接|焊接|一体成型|过盈|粘接|其他where写位置seen_in可选列出 figure_plan 中能看见该连接的fig号为图际可追溯提供证据链。spatial空间关系短句数组如「上下/内外/同轴/阵列」。function_of_structure该结构解决什么问题强调是结构功能而非纯方法步骤——这条口径与实用新型「禁止把算法步骤/工艺参数当主保护点」的成文纪律直接呼应。delta_hypothesis相对常见结构可能新在哪属于撰写欲保护点时的灵感输入。uncertain看不清、说明书未写明的内容。硬性纪律uncertain不得写成确定保护点跨图对不上的信息也写入这里勿静默忽略。not_utility_model_signals若观察到的内容更像方法或外观列于此供分流决策是「实用新型 / 发明 / 外观」类型判断的结构侧证据。4.2 必填项parts至少 1 个若实在无法识出部件须在uncertain中说明relations或显式[] 说明uncertain数组可为[]但字段必须存在。五、FigurePlan附图选用与图际关联合同figure_plan.schema.yaml 解决了「成文前先定图」的问题避免成文时扫全assets/临场挑图。成文与迭代只读本清单中use_in_disclosure: true的条目。5.1 字段骨架$schema: figure_plan version: 1 patent_type: utility_model # utility_model | design theme_summary: # 当前交底主题一句话主题变了须重评本清单 schema_ref: # 相对路径如 structure_schema.yaml / appearance_schema.json updated_at: # 可选ISO 本地时间 figures: - fig: 1 # 交底「如图 N」不入文则为 null role: assembly # 见 role 枚举 path: # 相对案件根或 knowledge 的路径 covers: [] # 实用新型parts.id外观views.name 或要点短标签 kind: lineart # lineart | cad | photo_clean | photo_scene | other score: 0 # 0–100同批内越高越优先入文 use_in_disclosure: true reason: # 选用或剔除的一句话 relates_to: [] # 可选图际关联5.2role枚举实用新型 / 外观双列role实用新型外观assembly总装/装配关系—detail局部卡扣、缺口等造型局部ortho正交/投影结构图六视中的正投影perspective立体结构示意立体图reference仅参考、默认不入正文场景/包装等参考rejected明确不入文同左5.3relates_to[].relation枚举多图联读时填写机械/实用新型有总装局部时强烈建议写清relation含义典型用法detail_of本图是目标图的局部放大/细节卡扣局部 ← 总装section_of本图是目标图的剖视/断面装配剖 ← 立体总装exploded_of本图是目标图的爆炸/分解爆炸图 ← 装配图same_state同一产品状态、不同角度外观多视互指alternate_view另一投影/视角非放大关系主视 ↔ 俯视、立体 ↔ 正交sequence使用/拆装步骤前后图步骤图 1→2三条硬性约定relates_to[].fig必须是本清单中已分配的fig入文图勿指向null局部图role: detail对总装assembly至少一条detail_of或section_of/exploded_of成文时正文「如图 N…如图 M 为其局部…」须与relates_to一致。5.4 排序启发式填表时打分实用新型高→低lineart/cadassembly或关键detail且covers命中保护相关件号photo_clean结构照 / 局部 cropphoto_scene/ 与主题无关 →use_in_disclosure: falserole: rejected或reference。外观高→低产品区清晰的perspective/orthophoto_clean或线稿均可造型detail重场景、广告包装 → 默认reference或不入文缺正式六视时在 AppearanceSchemauncertain标明。5.5 跨图核对填表强制同一parts.id/ 设计要点若出现在多张图各图covers均应列入局部图与总装图的件号命名须一致禁止图1叫「卡扣臂」、图2另起「弹片」且无映射有assemblydetail入文对时detail 侧须有relates_to联读后仍对不上的写入 Structure/Appearance 的uncertain勿静默忽略。5.6 必填项顶层patent_type、theme_summary、figures可为空数组但空则须在 schemauncertain说明无可用图每条path、role、kind、score、use_in_disclosure、reason凡use_in_disclosure: true须有唯一正整数fig从 1 连续编号为佳relates_to可空数组满足「总装局部」条件时不得空置。六、8 步填写流程fill_structure_schema.md 给出了从原料收集到落盘的完整流程逐条展开如下。第 1 步收集结构图并处理 STEP 场景收集照片、CAD 截图、爆炸图、专利附图。若存在.step/.stp且用户已确认开启解析先按 project_scan.md 的「CAD / STEP」小节运行python ${CLAUDE_SKILL_DIR}/tools/shared/step_to_views.py --enable-step-parse以产出的views/*.png*.seed.yaml为材料起点。注意两个默认值与边界默认不开启、不装依赖仅有原生 CAD、无 STEP勿假装已解析应提示用户导出 STEP对应源码见 cad_scan.py。第 2 步跨图联读总装 / 爆炸 / 局部图须对照同一套件号先建立「图角色」再填parts禁止每张图各起一套命名。这是后续所有covers、relates_to、成文「如图 N」一致性的根基。第 3 步先填 StructureSchema再写正文禁止「看图直接长文」——结构事实必须先结构化落盘再进入交底/笔记写作。这保证了第三章技术方案的部件表、连接关系表与 schema 严格闭环。第 4 步交底模式落盘在outputs/{案件标识}/目录Writestructure_schema.yaml或 json与figure_plan.yaml若有figure_plan.seed.yaml/structure_schema.seed.yaml可复制审改为定稿须人工核对件名、covers、主题自动relates_toalternate_view可保留对每张候选图判定role/kind/covers对齐parts.id/score图际关联局部/剖视/爆炸图填写relates_to如detail_of→ 总装fig有 assemblydetail 入文对时不得漏写可选关键relations[].seen_in列出能看见该连接的fig号优先lineart、cad场景杂图默认不入文仅use_in_disclosure: true分配连续fig1…Ntheme_summary写当前结构主题patent_type: utility_model。第 5 步辅助线稿可选默认关材料中已有结构相关图且缺干净线稿/CAD 时可反问用户是否开启是/否。用户回是后执行详见第七节先写structure_lineart_brief.yaml再运行门禁脚本仅带参考图出轮廓序号层推荐callout_mode: overlay禁止模型自创件号。无图则禁止本流程辅助线稿默认use_in_disclosure: false勿与外观design_lineart_*混用。第 6 步解读模式落盘工作目录写入structure_schema.json入库脚本约定名figure_plan可选不强制若写 figure_plan 仍建议补relates_to。第 7 步uncertain 纪律uncertain不得写成确定保护点跨图对不上的写入uncertain。第 8 步mode 声明mode取disclosure|reader二选一与落盘文件名和消费方式对应。七、结构辅助线稿可选链路的源码门禁fill_structure_schema.md 第 5 步指向的辅助线稿流程在仓库中有完整的提示词、合同与脚本三重支撑提示词structure_lineart_assist.md合同structure_lineart_brief.schema.yaml门禁脚本structure_lineart_gate.py。7.1 核心纪律默认关闭未询问或用户未答是前不得写 brief不得调用出图工具禁止无参考图纯文生图brief 中每个views[]至少有一个存在的source_paths件号必须对齐 StructureSchemaparts_legend抄自structure.parts跨图同一套件号uncertain中的件不得画死序号非申报终稿不得写成「已按国知局规范绘制的正式附图」。7.2 门禁脚本的运行与校验逻辑用户确认开启后运行python ${CLAUDE_SKILL_DIR}/tools/shared/structure_lineart_gate.py --enable-structure-lineart \ --case-dir outputs/{案件标识} --prepare-jobs从 structure_lineart_gate.py 源码可以确认门禁的完整拒绝链run_check函数约 L253–L298授权检查--enable-structure-lineart或环境变量PATENT_SKILL_STRUCTURE_LINEART1脚本第 L18、L27–L30 的parse_enabled支持1/true/yes/on取值无授权旗标直接拒绝前置文件检查案件目录缺少figure_plan/structure_schema即拒绝禁止纯文生图figure_plan中无可用图片路径时拒绝第 L277–L280brief 校验validate_brief约 L79–L154enabled必须为 true、patent_type必须为utility_model、views非空、每条source_paths至少一张真实存在的图、parts_legend的id/name必须与structure.parts一致、visible_part_ids必须 ⊆parts_legend且 ⊆structure.parts、callout_mode只能是overlay | in_prompt | contour_only。校验通过后--prepare-jobs写出lineart_assist/structure_lineart_jobs.json其中每个 job 都携带forbid_text_only: True与host_hint提示宿主工具「轮廓须附带 reference_images、禁止自创件号」从数据层面对下游生图/叠号环节做了约束。7.3 出线稿的两层分工轮廓层以source_paths/reference_images为视觉参考生成线稿callout_mode: overlay时生图提示词明确「Do NOT draw part numbers」脚本 L223把件号留给后续叠图序号层推荐overlay用 job 内calloutsidname来自parts_legend在轮廓图上叠加引出线与件号优先宿主标注 / 图层 / SVG / 人工核对不依赖模型一次性「猜位置猜编号」。in_prompt是降级方案仅当宿主无法叠图时才在带参考图的条件下把「可见件号列表」写入提示contour_only只出无号轮廓。生成后回写 figure_plan 追加条目默认use_in_disclosure: falsereason为「AI 辅助结构线稿非申报终稿件号对齐 StructureSchema」relates_to链回源图。八、多轮同步原材料一变先改清单再改正文fill_structure_schema.md 强调原材料增删换、主题/候选点变更、新增局部图时无清单则新建、有则重评figure_plan.yaml含relates_to再改交底附图与「如图 N」。figure_plan 合同「多轮同步」小节给出了强制触发条件与动作下列任一发生时先更新本文件再改交底正文附图无文件则新建禁止跳过新增 / 删除 / 替换原材料图用户调整专利主题、保护侧重点或选定候选点部件表 / 设计要点变更导致covers失效图际关系变化如新增局部图、拆分总装→ 同步改relates_to。更新动作重评score/use_in_disclosure/fig序号 /relates_to改写theme_summary与reason已剔除图保留条目并设use_in_disclosure: false便于审计勿默默丢路径被删图若仍被relates_to引用须改写或清除。九、最低输出与成文衔接9.1 最低输出要求StructureSchema 实例合法 JSON/YAML含必填parts、relations或显式[] 说明、spatial、uncertain交底另须同目录figure_plan.yaml可无入文图但须条目说明原因有总装局部则须relates_to。9.2 与实用新型交底成文的衔接disclosure_builder.md 的第三章写作要点与 schema 闭环先表后文部件表件号、名称、形状→ 关系表from/to/type/where→ 叙述图必有号正文「如图 N」与figure_plan的fig/path/covers一致钩部、缺口等关键局部单独说明图际可追溯有总装局部时叙述顺序与relates_to如detail_of对齐结构作用一句清该构造解决什么装配 / 受力 / 通道 / 拆装问题与 schema 闭环parts/relations/spatial在正文均有落点schema 未写的复杂公差勿杜撰。template_reference.md 给出了配套填表示例部件表散热基板、鳍片、弹性卡扣臂、钩部、连接关系表一体成型、卡扣、欲保护点短句以及「如图 N」的正文引用写法如图1所示基板1上表面设鳍片2……如图2为图1的局部放大钩部4与板缘缺口咬合……。其中附图引用的 YAML 片段展示了fig: 2条目通过relates_to: [{fig: 1, relation: detail_of, note: 图1卡扣局部放大}]与总装图建立关联的典型写法与本文第五节的枚举规则一一对应。教学样例目录为 examples/example_utility_model_snap_heatsink含真实结构附图须自填 StructureSchema figure_plan。十、常见误区与硬性纪律清单schema_ref 误填figure_plan.schema_ref应填本实例相对路径勿填合同文件references/schemas/structure.schema.yaml跨图件号分裂禁止总装图叫「卡扣臂」、局部图另起「弹片」且无映射uncertain 当事实uncertain不得写成确定保护点跨图对不上的必须写入无图开线稿无任何图片不得反问「开启线稿」来绕过缺图应要求补图或开启 STEP有清晰kind: lineart/cad入文图时可不反问辅助线稿越权辅助线稿默认use_in_disclosure: false、不入「如图 N」主序列不得替代原始结构图作为唯一证据纯方法当构造function_of_structure、欲保护点必须落在结构特征上避免「一种方法包括以下步骤……」作为唯一独立点清单与正文脱节成文附图只来自 figure_plan 中use_in_disclosure: true的条目禁止绕开清单扫assets/临场挑图原材料变化时先同步 figure_plan 再改正文。结语StructureSchema 与 FigurePlan 构成 patent-disclosure-skill 中「图 → 结构事实 → 成文」的关键中间层前者把视觉信息沉淀为可复用的结构化事实单一事实源后者把附图选用与图际关联在成文前固化下来两者共同支撑交底书第三章的「先表后文、图必有号、图际可追溯」纪律并在解读链路中以structure_schema.json的形式被入库脚本消费。配合结构辅助线稿的「默认关闭 门禁校验 两层出图」机制整个结构事实链路在规范性与可审计性上形成了完整闭环——这也是在实用新型专利写作场景中保证「不臆造、可追溯、可迭代」的工程化答案。【免费下载链接】patent-disclosure-skill中国专利.skill专利点挖掘与交底书发明/实用/外观编写通俗解读专利嗅探政策动向辅助审查答复。项目地址: https://gitcode.com/GitHub_Trending/pa/patent-disclosure-skill创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考