尧图网站建设 
AppearanceSchema 填表实战用 patent-disclosure-skill 把外观设计材料图固化为可写交底的事实合同【免费下载链接】patent-disclosure-skill中国专利.skill专利点挖掘与交底书发明/实用/外观编写通俗解读专利嗅探政策动向辅助审查答复。项目地址: https://gitcode.com/GitHub_Trending/pa/patent-disclosure-skill本文是专利交底技能 patent-disclosure-skill 中 外观设计事实合同填写规范 的完整技术指南它讲解了在编写外观设计交底书或反向解读外观专利之前如何把看图得到的六视图 / 立体图 / 效果图翻译成一份结构化、可机器校验、写读共用的appearance_schema.yaml与配套figure_plan.yaml。读完本文你将掌握外观设计交底中最关键的图 → 外观事实 → 入文视图三段链路包括字段语义、跨图联读纪律、relates_to图际关联、多轮同步以及可选的 AI 辅助线稿门禁流程并能直接对照仓库源码与测试验证每一步的正确性。1. 定位为什么外观设计交底需要事实合同在中国专利实践中外观设计的保护客体是产品的外观造型、图案、色彩及其结合交底书与设计说明只写看得见的东西。正因如此外观交底容易出现两类典型事故一是把内部电路、卡扣受力、工艺步骤写进外观要点功能构造越界二是跨视图描述互相矛盾——立体图里是圆角正交图里却写成了直角。patent-disclosure-skill 的解法是在动笔之前先由 Agent 把看图结果落成一份单一事实源Single Source of Truth——AppearanceSchema。它在仓库中的合同定义位于 references/schemas/appearance.schema.yaml配套的入文视图清单合同是 references/schemas/figure_plan.schema.yaml。按照 SKILL.md 的路由约定prompts/shared/目录是写读共用层交底模式 A 的外观类型子流程与解读模式 B 的外观专利反向阅读都会用到这套填表指令。具体到 fill_appearance_schema.md其消费者Consumer被明确标注为两条链路交底prompts/disclosure/design/挖点、成文、模板参考解读prompts/reader/外观设计专利的通俗解读笔记。判定何时需要 Read 本指令的触发条件同样只有两个交底类型为外观设计或解读对象为外观设计专利。也就是说只要材料里有图、目标是要写外观设计相关文字就必须先过 Schema 这一关禁止看图直接长文。2. AppearanceSchema 字段全解合同 YAML 逐行拆解合同文件给出了完整的 YAML 骨架。以下是逐字段注释版也是实际outputs/{案件标识}/appearance_schema.yaml的填写模板$schema: appearance.schema version: 1 mode: disclosure # disclosure | reader source_images: [] # 看过的图交底入文以 figure_plan 为准 product_name: overall_shape: # 整体造型一句话 views: # 已见视图 - name: 立体图 # 主视/俯视/左视/立体等 notes: source_image: # 可选对应材料图路径 # 视图间关联优先写在 figure_plan.relates_tosame_state / alternate_view ornament: [] # 图案、线条、纹理 color: [] # 色彩搭配不明则 uncertain design_points: [] # 欲强调的外观要点 contrast_to_prior: [] # 与常见外观差异假设须标 uncertain: [] not_design_signals: [] # 若更像结构功能/方法列于此各字段的语义与填写纪律如下字段语义填写要点mode工作模式disclosure交底或reader解读二选一source_images本轮看过的全部材料图只做取证记录交底时入文以 figure_plan 为准不靠本字段决定贴图product_name产品名称须与后续交底文头、挖点表中的产品名称完全一致overall_shape整体造型一句话必填例如圆盘底座 多关节折臂 弯月形灯头views[]已见视图清单每项含name立体图/主视/俯视/左视…、可选notes、可选source_image视图间关联不写这里统一放 figure_plan 的relates_toornament[]图案、线条、纹理没有可留空color[]色彩搭配看不明时不得乱写放入uncertaindesign_points[]欲强调的外观要点与后续disclosure/design/挖点、成文的设计要点一节对齐contrast_to_prior[]与在先外观的差异属于假设时必须标注查新--type design后再收紧uncertain[]不确定项必填缺图、看不清、跨图对不上的特征都进这里单独列出not_design_signals[]疑似非外观信号若材料里出现内部构造、电路、受力分析、工艺步骤等列于此——它是触发反问改实用新型/发明的依据合同明确给出的必填项只有三个overall_shape、views可为空数组但须在uncertain说明缺图、uncertain。这是最低输出的底线哪怕一张图都没有也必须诚实写views: []并在uncertain里说明缺图而不是跳过 Schema。与实用新型的 StructureSchema 填写规范 相比外观合同刻意弱化了部件关系无parts/relations/spatial把重心放在整体造型 可见视图 装饰/色彩 不确定性上体现了外观专利只保护看得见的这一法律特性。3. 双文件落盘appearance_schema.yaml与figure_plan.yaml交底模式下填表不是终点Agent 必须在案件工作目录默认outputs/{案件标识}/同目录写出两个文件文件说明appearance_schema.yaml或.jsonAppearanceSchema 实例即外观事实合同figure_plan.yaml入文视图选用、排序与视图关联一个极易踩的坑figure_plan.schema_ref字段要填本实例的相对路径如appearance_schema.yaml不能填合同文件路径references/schemas/appearance.schema.yaml——前者指向案件自己的数据后者只是仓库里的空模板。解读模式reader的约定不同工作目录固定使用appearance_schema.json这是入库脚本约定的文件名见 patent_plain_reader.md 中对类型挂钩的说明且figure_plan为可选。4. 标准流程从材料图到外观事实的八个动作fill_appearance_schema.md 给出了明确的流程拆解如下收集视图材料六视图 / 立体图 / 效果图 / 专利视图。若材料中存在 STEP 文件且用户已确认开启解析可调用 step_to_views.py 自动投影生成视图材料——但外观交底仍以可见造型为准场景图规则不变默认低优先。跨图联读强制多张视图视为同一产品比例、开口、装饰位置必须在各图之间一致联读后仍对不上的写入uncertain绝不静默忽略。这与 figure_plan 合同中的跨图核对四条强制项一一对应。先填 Schema再写提纲或笔记禁止看图直接长篇输出——Schema 是中间事实层正文文字必须建立在它之上。交底模式 Write写出appearance_schema.yaml或 json与figure_plan.yaml两份文件。covers对齐views.name或设计要点短标签多视之间可用relates_tosame_state/alternate_view局部造型用detail_of指向立体/主视图views[].source_image可选指向材料路径优先产品区清晰的立体/正交图photo_clean或线稿均可重场景/包装图默认reference或不入文外观不强制线稿缺正式六视图时写入 AppearanceSchema 的uncertaintheme_summary写当前产品外观主题patent_type: design。辅助线稿反问可选默认关材料中已有图片时才可反问是否开启外观辅助线稿是/否用户回是后进入 design_lineart_assist.md 流程详见第 6 节。解读模式工作目录appearance_schema.jsonfigure_plan可选。区分整体造型与装饰图案/色彩两者在 Schema 中分属overall_shape与ornament/coloruncertain单独列出。mode二选一disclosure|reader。流程末尾的最低输出底线是AppearanceSchema 实例含overall_shape、views或uncertain说明缺图、ornament/color可空、uncertain交底另须同目录figure_plan.yaml。5. figure_plan入文视图的选用、排序与图际关联figure_plan.yaml是实用新型 / 外观交底的附图选用与排序合同。它的核心设计是成文与迭代只读本清单中use_in_disclosure: true的条目禁止再扫全assets/临场挑图——这从机制上杜绝了正文见图 N 与附件对不上的混乱。完整合同见 references/schemas/figure_plan.schema.yaml落盘约定为案件工作目录下的figure_plan.yaml或figure_plan.json与appearance_schema.*同级。其 YAML 骨架外观视角如下$schema: figure_plan version: 1 patent_type: design # utility_model | design theme_summary: # 当前交底主题一句话主题变了须重评本清单 schema_ref: appearance_schema.yaml # 本实例相对路径 updated_at: # 可选ISO 本地时间 figures: - fig: 1 role: perspective # 见下方枚举 path: assets/view_perspective.jpg covers: [立体图] # 外观views.name 或要点短标签 kind: photo_clean # lineart | cad | photo_clean | photo_scene | other score: 90 # 0–100同批内越高越优先入文 use_in_disclosure: true reason: 产品区清晰的立体图 relates_to: [] - fig: 2 role: ortho path: assets/views_ortho.jpg covers: [主视图, 俯视图] kind: photo_clean score: 85 use_in_disclosure: true reason: 六视中的正投影确认比例与对称 relates_to: - fig: 1 # 指向本清单中另一条的 fig 号 relation: alternate_view note: 立体 ↔ 正交5.1role枚举外观列role外观语义assembly—仅实用新型的总装/装配关系detail造型局部ortho六视中的正投影perspective立体图reference场景/包装等参考默认不入正文rejected明确不入文5.2relates_to[].relation枚举relation含义典型用法detail_of本图是目标图的局部放大/细节造型局部 ← 立体/主视section_of本图是目标图的剖视/断面装配剖 ← 立体总装exploded_of本图是目标图的爆炸/分解爆炸图 ← 装配图same_state同一产品状态、不同角度外观多视互指alternate_view另一投影/视角非放大关系主视 ↔ 俯视、立体 ↔ 正交sequence使用/拆装步骤前后图步骤图 1→2关联写作的硬约定relates_to[].fig必须是本清单已分配的fig入文图不得指向null外观多视可用same_state/alternate_view互链场景参考图可不写。成文时正文如图 N…如图 M 为其局部…必须与relates_to完全一致。5.3 外观排序启发式打分依据从高到低产品区清晰的perspective/orthophoto_clean或线稿均可造型detail重场景、广告包装 → 默认reference或不入文缺正式六视时在 AppearanceSchema 的uncertain标明。5.4 跨图核对填表强制同一设计要点若出现在多张图各图covers均应列入局部图与整体图的命名须一致禁止图 1 叫灯臂、图 2 另起悬臂且无映射联读后仍对不上的写入 AppearanceSchema 的uncertain勿静默忽略。5.5 必填与多轮同步强制每条 figure 必填path、role、kind、score、use_in_disclosure、reason凡use_in_disclosure: true须有唯一正整数fig从 1 连续编号为佳。当以下任一情况发生时必须先更新 figure_plan 再改交底正文附图无文件则新建禁止跳过新增 / 删除 / 替换原材料图用户调整专利主题、保护侧重点或选定候选点设计要点变更导致covers失效图际关系变化如新增局部图→ 同步改relates_to。更新动作要求重评score/use_in_disclosure/fig序号 /relates_to改写theme_summary与reason已剔除图保留条目并设use_in_disclosure: false便于审计勿默默丢路径被删图若仍被relates_to引用须改写或清除。6. 外观辅助线稿可选默认关从 YAML 描述到参考图出图的门禁闭环外观交底不强制线稿但材料缺干净线稿时技能提供了一条默认关闭的辅助链路完整流程见 prompts/shared/design_lineart_assist.md描述合同见 references/schemas/design_lineart_brief.schema.yaml。6.1 开关与触发条件默认关闭未询问或用户未答是之前不得写design_lineart_brief.yaml不得调用任何出图工具。触发反问的前提是专利类型 外观设计且扫描/材料中已有至少一张产品相关图。无任何图片时不反问而是要求补图——无图则禁止本辅助流程。用户回是后可用环境变量PATENT_SKILL_DESIGN_LINEART1或校验脚本参数--enable-design-lineart标记本轮已授权。design_lineart_brief.yaml的结构要点enabled: true仅用户确认后、patent_type: design、appearance_ref/figure_plan_ref指向本实例文件、overall_shape/design_points/uncertain对齐 AppearanceSchema且views[]中每一视必须绑定至少一张已存在的源图。合同还硬性规定生成时的forbid列表内部结构 / 电路 / 受力品牌 LOGO / 广告文案无依据的背面或底面臆造彩色渲染 / 阴影棚拍风。6.2 门禁脚本与源码级校验逻辑确认开启后推荐执行门禁校验与任务准备python tools/shared/design_lineart_gate.py --enable-design-lineart \ --case-dir outputs/{案件标识} --prepare-jobs从 design_lineart_gate.py 的源码可以确认其校验逻辑validate_brief约 66–97 行未带--enable-design-lineart且无环境变量 →拒绝parse_enabled约 26–29 行enabled不为 true、patent_type非 design、views为空、overall_shape与design_points都空 → 拒绝任一条views缺少source_paths或源图文件不存在、无任何可读源图 → 拒绝禁止纯文生图校验通过后build_jobs约 114–158 行为每视生成一个 job写出lineart_assist/design_lineart_jobs.json每条含source_paths/reference_images两者相同供各宿主把路径当参考图入参、gen_prompt、output_path、absolute_output_path以及forbid_text_only: true与host_hint——提示使用当前宿主的图像生成能力并附带参考图不要写死某一产品工具名。gen_prompt为空时脚本会自动拼装默认提示英文含Black-and-white patent-style line artno logosno invented internal structure等约束见约 129–140 行。另有两个实用子命令--check仅校验与--print-confirm打印反问文案CONFIRM_ZH约 20–23 行。对应的测试 tests/shared/test_design_lineart_gate.py 直接验证了四条核心行为test_default_off默认关闭、test_check_disabled未授权拒绝、test_no_images_forbidfigure_plan 无图禁止开启、test_validate_and_jobs有源图时校验通过、job 的forbid_text_only为真、source_paths与reference_images一致、gen_prompt含 line art。6.3 出图、回写与成文纪律出图阶段的要求是对design_lineart_jobs.json中每个 job使用当前宿主环境的图像生成能力内置生图工具、图生图 API、本地模型或插件均可必须以该 job 的source_paths作视觉参考/条件输入禁止仅用gen_prompt做纯文生图输出写到 job 的output_path默认lineart_assist/*.png若宿主工具不能指定落盘路径生成后须把结果复制/保存到该路径。每张辅助线稿都要回写 figure_plan 追加一条默认不入正文- fig: null # 或分配序号但不入文 role: reference # 或与源图同 role path: lineart_assist/….png covers: [立体图] # 对齐 view_name kind: lineart score: 50 use_in_disclosure: false reason: AI 辅助线稿非申报终稿 relates_to: - fig: 1 # 源实拍/参考图 fig relation: same_state note: 由图1辅助生成的线稿草稿成文纪律三条正文视图说明以实拍/原始参考图为主辅助线稿可一句带过另附线稿草稿供代理人参考禁止把 AI 线稿写成已按国知局规范绘制的正式视图uncertain中的特征不得在线稿说明里写成既定设计要点。7. 下游衔接挖点、成文与解读如何使用这份事实合同填表完成后Schema 与 figure_plan 成为所有下游步骤的只读输入。7.1 外观专利点挖掘Step 3–4design/patent_points.md 要求挖点必须联读figure_plan.relates_to多视一致、局部造型落点并给出了多视关系 → 挖点启发式relates_to.relation挖点用法alternate_view/same_state多视交叉核对轮廓、开口、装饰位置仅在多视稳定出现的特征才升为设计要点detail_of局部相对整体多出的可见造型倒角、筋线、纹理、接口造型→ 可作设计要点候选须仍属外观、非内部构造sequence使用状态变化若带来可见形态差异可单列变化状态要点勿写成操作方法候选外观点限定1–3 个每项必须视图与图证能落到具体fig及relates_to上某特征只在一张图出现、其它关联视图对不上 → 写入uncertain或降权。若not_design_signals非空则反问是否改实用新型/发明禁止把功能构造写成外观要点。7.2 外观设计说明成文Step 7design/disclosure_builder.md 规定成文前必须已有 AppearanceSchema 与同目录figure_plan.yaml。建议结构为注意事项 → 产品名称与用途 → 设计要点对齐design_points→ 视图说明对齐views仅嵌 figure_plan 入文图→ 与在先外观的主要差异查新后写→ 其它可选。硬性要求包括正文见图 N只引用figure_plan 中use_in_disclosure: true的条目按fig勿临场扫全目录多视联读用relates_to且正文须与之一致查新走 cnipa_epub_search.py --type design可选md_to_docx.py交付 Word 版。视图清单与与在先差异短句的示例见 design/template_reference.md其中引用了教学样例 examples/example_design_desk_lamp/需自填 AppearanceSchema figure_plan其 brief 为教学虚构实拍图位于knowledge/assets/。7.3 解读模式reader反向解读外观专利时Agent 在拿到公开号后按 type_hooks.md 判别类型若是外观设计则同样走本填表指令在工作目录写appearance_schema.json再写笔记正文figure_plan可选。8. 多轮迭代与自检闭环交底迭代换图、改产品侧重点或设计要点时填表指令给出的纪律是无则新建、有则重评figure_plan.yaml含relates_to再改正文视图引用——与第 5.5 节的多轮同步强制项一致。成文阶段的内部自检design/disclosure_builder.md §7.5要求逐项确认文头为外观设计、设计要点可追溯 AppearanceSchema、视图仅来自 figure_plan 且见图 N与fig对齐、入文多视/局部的relates_to已写且正文联读一致、辅助线稿有授权有参考图无纯文生图、未把功能构造写成外观要点、查新带--type design。整套设计的核心价值在于把看图这一主观动作物化为可校验、可追溯、可重入的 YAML 事实层。无论交底还是解读、无论 Agent 还是代理人接手只要appearance_schema.yaml与figure_plan.yaml在场且与正文一致外观设计的证据链就是完整可审计的——这正是 patent-disclosure-skill 在外观类型上区别于看图直接写的关键工程化设计。【免费下载链接】patent-disclosure-skill中国专利.skill专利点挖掘与交底书发明/实用/外观编写通俗解读专利嗅探政策动向辅助审查答复。项目地址: https://gitcode.com/GitHub_Trending/pa/patent-disclosure-skill创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 AppearanceSchema 填表实战：用 patent-disclosure-skill 把外观设计材料图固化为可写交底的事实合同
AppearanceSchema 填表实战用 patent-disclosure-skill 把外观设计材料图固化为可写交底的事实合同【免费下载链接】patent-disclosure-skill中国专利.skill专利点挖掘与交底书发明/实用/外观编写通俗解读专利嗅探政策动向辅助审查答复。项目地址: https://gitcode.com/GitHub_Trending/pa/patent-disclosure-skill本文是专利交底技能 patent-disclosure-skill 中 外观设计事实合同填写规范 的完整技术指南它讲解了在编写外观设计交底书或反向解读外观专利之前如何把看图得到的六视图 / 立体图 / 效果图翻译成一份结构化、可机器校验、写读共用的appearance_schema.yaml与配套figure_plan.yaml。读完本文你将掌握外观设计交底中最关键的图 → 外观事实 → 入文视图三段链路包括字段语义、跨图联读纪律、relates_to图际关联、多轮同步以及可选的 AI 辅助线稿门禁流程并能直接对照仓库源码与测试验证每一步的正确性。1. 定位为什么外观设计交底需要事实合同在中国专利实践中外观设计的保护客体是产品的外观造型、图案、色彩及其结合交底书与设计说明只写看得见的东西。正因如此外观交底容易出现两类典型事故一是把内部电路、卡扣受力、工艺步骤写进外观要点功能构造越界二是跨视图描述互相矛盾——立体图里是圆角正交图里却写成了直角。patent-disclosure-skill 的解法是在动笔之前先由 Agent 把看图结果落成一份单一事实源Single Source of Truth——AppearanceSchema。它在仓库中的合同定义位于 references/schemas/appearance.schema.yaml配套的入文视图清单合同是 references/schemas/figure_plan.schema.yaml。按照 SKILL.md 的路由约定prompts/shared/目录是写读共用层交底模式 A 的外观类型子流程与解读模式 B 的外观专利反向阅读都会用到这套填表指令。具体到 fill_appearance_schema.md其消费者Consumer被明确标注为两条链路交底prompts/disclosure/design/挖点、成文、模板参考解读prompts/reader/外观设计专利的通俗解读笔记。判定何时需要 Read 本指令的触发条件同样只有两个交底类型为外观设计或解读对象为外观设计专利。也就是说只要材料里有图、目标是要写外观设计相关文字就必须先过 Schema 这一关禁止看图直接长文。2. AppearanceSchema 字段全解合同 YAML 逐行拆解合同文件给出了完整的 YAML 骨架。以下是逐字段注释版也是实际outputs/{案件标识}/appearance_schema.yaml的填写模板$schema: appearance.schema version: 1 mode: disclosure # disclosure | reader source_images: [] # 看过的图交底入文以 figure_plan 为准 product_name: overall_shape: # 整体造型一句话 views: # 已见视图 - name: 立体图 # 主视/俯视/左视/立体等 notes: source_image: # 可选对应材料图路径 # 视图间关联优先写在 figure_plan.relates_tosame_state / alternate_view ornament: [] # 图案、线条、纹理 color: [] # 色彩搭配不明则 uncertain design_points: [] # 欲强调的外观要点 contrast_to_prior: [] # 与常见外观差异假设须标 uncertain: [] not_design_signals: [] # 若更像结构功能/方法列于此各字段的语义与填写纪律如下字段语义填写要点mode工作模式disclosure交底或reader解读二选一source_images本轮看过的全部材料图只做取证记录交底时入文以 figure_plan 为准不靠本字段决定贴图product_name产品名称须与后续交底文头、挖点表中的产品名称完全一致overall_shape整体造型一句话必填例如圆盘底座 多关节折臂 弯月形灯头views[]已见视图清单每项含name立体图/主视/俯视/左视…、可选notes、可选source_image视图间关联不写这里统一放 figure_plan 的relates_toornament[]图案、线条、纹理没有可留空color[]色彩搭配看不明时不得乱写放入uncertaindesign_points[]欲强调的外观要点与后续disclosure/design/挖点、成文的设计要点一节对齐contrast_to_prior[]与在先外观的差异属于假设时必须标注查新--type design后再收紧uncertain[]不确定项必填缺图、看不清、跨图对不上的特征都进这里单独列出not_design_signals[]疑似非外观信号若材料里出现内部构造、电路、受力分析、工艺步骤等列于此——它是触发反问改实用新型/发明的依据合同明确给出的必填项只有三个overall_shape、views可为空数组但须在uncertain说明缺图、uncertain。这是最低输出的底线哪怕一张图都没有也必须诚实写views: []并在uncertain里说明缺图而不是跳过 Schema。与实用新型的 StructureSchema 填写规范 相比外观合同刻意弱化了部件关系无parts/relations/spatial把重心放在整体造型 可见视图 装饰/色彩 不确定性上体现了外观专利只保护看得见的这一法律特性。3. 双文件落盘appearance_schema.yaml与figure_plan.yaml交底模式下填表不是终点Agent 必须在案件工作目录默认outputs/{案件标识}/同目录写出两个文件文件说明appearance_schema.yaml或.jsonAppearanceSchema 实例即外观事实合同figure_plan.yaml入文视图选用、排序与视图关联一个极易踩的坑figure_plan.schema_ref字段要填本实例的相对路径如appearance_schema.yaml不能填合同文件路径references/schemas/appearance.schema.yaml——前者指向案件自己的数据后者只是仓库里的空模板。解读模式reader的约定不同工作目录固定使用appearance_schema.json这是入库脚本约定的文件名见 patent_plain_reader.md 中对类型挂钩的说明且figure_plan为可选。4. 标准流程从材料图到外观事实的八个动作fill_appearance_schema.md 给出了明确的流程拆解如下收集视图材料六视图 / 立体图 / 效果图 / 专利视图。若材料中存在 STEP 文件且用户已确认开启解析可调用 step_to_views.py 自动投影生成视图材料——但外观交底仍以可见造型为准场景图规则不变默认低优先。跨图联读强制多张视图视为同一产品比例、开口、装饰位置必须在各图之间一致联读后仍对不上的写入uncertain绝不静默忽略。这与 figure_plan 合同中的跨图核对四条强制项一一对应。先填 Schema再写提纲或笔记禁止看图直接长篇输出——Schema 是中间事实层正文文字必须建立在它之上。交底模式 Write写出appearance_schema.yaml或 json与figure_plan.yaml两份文件。covers对齐views.name或设计要点短标签多视之间可用relates_tosame_state/alternate_view局部造型用detail_of指向立体/主视图views[].source_image可选指向材料路径优先产品区清晰的立体/正交图photo_clean或线稿均可重场景/包装图默认reference或不入文外观不强制线稿缺正式六视图时写入 AppearanceSchema 的uncertaintheme_summary写当前产品外观主题patent_type: design。辅助线稿反问可选默认关材料中已有图片时才可反问是否开启外观辅助线稿是/否用户回是后进入 design_lineart_assist.md 流程详见第 6 节。解读模式工作目录appearance_schema.jsonfigure_plan可选。区分整体造型与装饰图案/色彩两者在 Schema 中分属overall_shape与ornament/coloruncertain单独列出。mode二选一disclosure|reader。流程末尾的最低输出底线是AppearanceSchema 实例含overall_shape、views或uncertain说明缺图、ornament/color可空、uncertain交底另须同目录figure_plan.yaml。5. figure_plan入文视图的选用、排序与图际关联figure_plan.yaml是实用新型 / 外观交底的附图选用与排序合同。它的核心设计是成文与迭代只读本清单中use_in_disclosure: true的条目禁止再扫全assets/临场挑图——这从机制上杜绝了正文见图 N 与附件对不上的混乱。完整合同见 references/schemas/figure_plan.schema.yaml落盘约定为案件工作目录下的figure_plan.yaml或figure_plan.json与appearance_schema.*同级。其 YAML 骨架外观视角如下$schema: figure_plan version: 1 patent_type: design # utility_model | design theme_summary: # 当前交底主题一句话主题变了须重评本清单 schema_ref: appearance_schema.yaml # 本实例相对路径 updated_at: # 可选ISO 本地时间 figures: - fig: 1 role: perspective # 见下方枚举 path: assets/view_perspective.jpg covers: [立体图] # 外观views.name 或要点短标签 kind: photo_clean # lineart | cad | photo_clean | photo_scene | other score: 90 # 0–100同批内越高越优先入文 use_in_disclosure: true reason: 产品区清晰的立体图 relates_to: [] - fig: 2 role: ortho path: assets/views_ortho.jpg covers: [主视图, 俯视图] kind: photo_clean score: 85 use_in_disclosure: true reason: 六视中的正投影确认比例与对称 relates_to: - fig: 1 # 指向本清单中另一条的 fig 号 relation: alternate_view note: 立体 ↔ 正交5.1role枚举外观列role外观语义assembly—仅实用新型的总装/装配关系detail造型局部ortho六视中的正投影perspective立体图reference场景/包装等参考默认不入正文rejected明确不入文5.2relates_to[].relation枚举relation含义典型用法detail_of本图是目标图的局部放大/细节造型局部 ← 立体/主视section_of本图是目标图的剖视/断面装配剖 ← 立体总装exploded_of本图是目标图的爆炸/分解爆炸图 ← 装配图same_state同一产品状态、不同角度外观多视互指alternate_view另一投影/视角非放大关系主视 ↔ 俯视、立体 ↔ 正交sequence使用/拆装步骤前后图步骤图 1→2关联写作的硬约定relates_to[].fig必须是本清单已分配的fig入文图不得指向null外观多视可用same_state/alternate_view互链场景参考图可不写。成文时正文如图 N…如图 M 为其局部…必须与relates_to完全一致。5.3 外观排序启发式打分依据从高到低产品区清晰的perspective/orthophoto_clean或线稿均可造型detail重场景、广告包装 → 默认reference或不入文缺正式六视时在 AppearanceSchema 的uncertain标明。5.4 跨图核对填表强制同一设计要点若出现在多张图各图covers均应列入局部图与整体图的命名须一致禁止图 1 叫灯臂、图 2 另起悬臂且无映射联读后仍对不上的写入 AppearanceSchema 的uncertain勿静默忽略。5.5 必填与多轮同步强制每条 figure 必填path、role、kind、score、use_in_disclosure、reason凡use_in_disclosure: true须有唯一正整数fig从 1 连续编号为佳。当以下任一情况发生时必须先更新 figure_plan 再改交底正文附图无文件则新建禁止跳过新增 / 删除 / 替换原材料图用户调整专利主题、保护侧重点或选定候选点设计要点变更导致covers失效图际关系变化如新增局部图→ 同步改relates_to。更新动作要求重评score/use_in_disclosure/fig序号 /relates_to改写theme_summary与reason已剔除图保留条目并设use_in_disclosure: false便于审计勿默默丢路径被删图若仍被relates_to引用须改写或清除。6. 外观辅助线稿可选默认关从 YAML 描述到参考图出图的门禁闭环外观交底不强制线稿但材料缺干净线稿时技能提供了一条默认关闭的辅助链路完整流程见 prompts/shared/design_lineart_assist.md描述合同见 references/schemas/design_lineart_brief.schema.yaml。6.1 开关与触发条件默认关闭未询问或用户未答是之前不得写design_lineart_brief.yaml不得调用任何出图工具。触发反问的前提是专利类型 外观设计且扫描/材料中已有至少一张产品相关图。无任何图片时不反问而是要求补图——无图则禁止本辅助流程。用户回是后可用环境变量PATENT_SKILL_DESIGN_LINEART1或校验脚本参数--enable-design-lineart标记本轮已授权。design_lineart_brief.yaml的结构要点enabled: true仅用户确认后、patent_type: design、appearance_ref/figure_plan_ref指向本实例文件、overall_shape/design_points/uncertain对齐 AppearanceSchema且views[]中每一视必须绑定至少一张已存在的源图。合同还硬性规定生成时的forbid列表内部结构 / 电路 / 受力品牌 LOGO / 广告文案无依据的背面或底面臆造彩色渲染 / 阴影棚拍风。6.2 门禁脚本与源码级校验逻辑确认开启后推荐执行门禁校验与任务准备python tools/shared/design_lineart_gate.py --enable-design-lineart \ --case-dir outputs/{案件标识} --prepare-jobs从 design_lineart_gate.py 的源码可以确认其校验逻辑validate_brief约 66–97 行未带--enable-design-lineart且无环境变量 →拒绝parse_enabled约 26–29 行enabled不为 true、patent_type非 design、views为空、overall_shape与design_points都空 → 拒绝任一条views缺少source_paths或源图文件不存在、无任何可读源图 → 拒绝禁止纯文生图校验通过后build_jobs约 114–158 行为每视生成一个 job写出lineart_assist/design_lineart_jobs.json每条含source_paths/reference_images两者相同供各宿主把路径当参考图入参、gen_prompt、output_path、absolute_output_path以及forbid_text_only: true与host_hint——提示使用当前宿主的图像生成能力并附带参考图不要写死某一产品工具名。gen_prompt为空时脚本会自动拼装默认提示英文含Black-and-white patent-style line artno logosno invented internal structure等约束见约 129–140 行。另有两个实用子命令--check仅校验与--print-confirm打印反问文案CONFIRM_ZH约 20–23 行。对应的测试 tests/shared/test_design_lineart_gate.py 直接验证了四条核心行为test_default_off默认关闭、test_check_disabled未授权拒绝、test_no_images_forbidfigure_plan 无图禁止开启、test_validate_and_jobs有源图时校验通过、job 的forbid_text_only为真、source_paths与reference_images一致、gen_prompt含 line art。6.3 出图、回写与成文纪律出图阶段的要求是对design_lineart_jobs.json中每个 job使用当前宿主环境的图像生成能力内置生图工具、图生图 API、本地模型或插件均可必须以该 job 的source_paths作视觉参考/条件输入禁止仅用gen_prompt做纯文生图输出写到 job 的output_path默认lineart_assist/*.png若宿主工具不能指定落盘路径生成后须把结果复制/保存到该路径。每张辅助线稿都要回写 figure_plan 追加一条默认不入正文- fig: null # 或分配序号但不入文 role: reference # 或与源图同 role path: lineart_assist/….png covers: [立体图] # 对齐 view_name kind: lineart score: 50 use_in_disclosure: false reason: AI 辅助线稿非申报终稿 relates_to: - fig: 1 # 源实拍/参考图 fig relation: same_state note: 由图1辅助生成的线稿草稿成文纪律三条正文视图说明以实拍/原始参考图为主辅助线稿可一句带过另附线稿草稿供代理人参考禁止把 AI 线稿写成已按国知局规范绘制的正式视图uncertain中的特征不得在线稿说明里写成既定设计要点。7. 下游衔接挖点、成文与解读如何使用这份事实合同填表完成后Schema 与 figure_plan 成为所有下游步骤的只读输入。7.1 外观专利点挖掘Step 3–4design/patent_points.md 要求挖点必须联读figure_plan.relates_to多视一致、局部造型落点并给出了多视关系 → 挖点启发式relates_to.relation挖点用法alternate_view/same_state多视交叉核对轮廓、开口、装饰位置仅在多视稳定出现的特征才升为设计要点detail_of局部相对整体多出的可见造型倒角、筋线、纹理、接口造型→ 可作设计要点候选须仍属外观、非内部构造sequence使用状态变化若带来可见形态差异可单列变化状态要点勿写成操作方法候选外观点限定1–3 个每项必须视图与图证能落到具体fig及relates_to上某特征只在一张图出现、其它关联视图对不上 → 写入uncertain或降权。若not_design_signals非空则反问是否改实用新型/发明禁止把功能构造写成外观要点。7.2 外观设计说明成文Step 7design/disclosure_builder.md 规定成文前必须已有 AppearanceSchema 与同目录figure_plan.yaml。建议结构为注意事项 → 产品名称与用途 → 设计要点对齐design_points→ 视图说明对齐views仅嵌 figure_plan 入文图→ 与在先外观的主要差异查新后写→ 其它可选。硬性要求包括正文见图 N只引用figure_plan 中use_in_disclosure: true的条目按fig勿临场扫全目录多视联读用relates_to且正文须与之一致查新走 cnipa_epub_search.py --type design可选md_to_docx.py交付 Word 版。视图清单与与在先差异短句的示例见 design/template_reference.md其中引用了教学样例 examples/example_design_desk_lamp/需自填 AppearanceSchema figure_plan其 brief 为教学虚构实拍图位于knowledge/assets/。7.3 解读模式reader反向解读外观专利时Agent 在拿到公开号后按 type_hooks.md 判别类型若是外观设计则同样走本填表指令在工作目录写appearance_schema.json再写笔记正文figure_plan可选。8. 多轮迭代与自检闭环交底迭代换图、改产品侧重点或设计要点时填表指令给出的纪律是无则新建、有则重评figure_plan.yaml含relates_to再改正文视图引用——与第 5.5 节的多轮同步强制项一致。成文阶段的内部自检design/disclosure_builder.md §7.5要求逐项确认文头为外观设计、设计要点可追溯 AppearanceSchema、视图仅来自 figure_plan 且见图 N与fig对齐、入文多视/局部的relates_to已写且正文联读一致、辅助线稿有授权有参考图无纯文生图、未把功能构造写成外观要点、查新带--type design。整套设计的核心价值在于把看图这一主观动作物化为可校验、可追溯、可重入的 YAML 事实层。无论交底还是解读、无论 Agent 还是代理人接手只要appearance_schema.yaml与figure_plan.yaml在场且与正文一致外观设计的证据链就是完整可审计的——这正是 patent-disclosure-skill 在外观类型上区别于看图直接写的关键工程化设计。【免费下载链接】patent-disclosure-skill中国专利.skill专利点挖掘与交底书发明/实用/外观编写通俗解读专利嗅探政策动向辅助审查答复。项目地址: https://gitcode.com/GitHub_Trending/pa/patent-disclosure-skill创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考