patent-disclosure-skill 专利交底书增量合并merger模式实战从迭代门禁、figure_plan 同步到合并摘要留档【免费下载链接】patent-disclosure-skill中国专利.skill专利点挖掘与交底书发明/实用/外观编写通俗解读专利嗅探政策动向辅助审查答复。项目地址: https://gitcode.com/GitHub_Trending/pa/patent-disclosure-skill导读本文围绕开源仓库 patent-disclosure-skill 中的 prompts/disclosure/merger.md 展开系统讲解专利交底书写作流水线中「在已有稿上增量补充新材料」的增量合并merger迭代模式。你将掌握如何判断何时进入合并流程、合并前必须执行的门禁检查、七步非破坏性合并流程、实用新型/外观强制执行的 figure_plan 同步机制以及落盘交付时不可省略的「合并摘要留档」与修订对话记录。读完本文你既能按规则完成一轮合规的合并迭代也能从 tools/shared/iteration_dialog_log.py、references/schemas/figure_plan.schema.yaml 等源码与契约文件层面理解该模式的设计意图。一、merger 模式定位何时启用、解决什么问题1.1 触发条件由意图判断不依赖固定措辞merger 模式的启用不要求用户说出「迭代」「合并」等固定词Agent 也不必先询问是否进入迭代模式。判定依据是用户意图在已有交底书或上一轮输出上补充新材料新文档、新代码说明、粘贴片段、扩展章节等且用户诉求以合并进现有结构为主追加、局部重写而非推翻重写。此外用户按 prompts/disclosure/invention/disclosure_builder.md §7.6 仅要求做第五章「技术关键点和欲保护点」的权利要求书式强化、且已说明侧重点时同样走本流程——此时合并范围以第五章为主必要时微调第四章与第五章的衔接句。1.2 与「纠正」模式的区别扩展 vs 修正两个迭代模式在仓库中以两份独立 prompt 维护分工明确维度merger增量合并correction_handler对话纠正适用场景补充新材料、新功能的扩展用户指出错误、风格或与事实不符的修正典型用户话术「补充一份设计文档」「粘贴代码片段并扩展实施例」「这里不对」「和 3.5 不一致」「保护点应强调 XXX」对应模板prompts/disclosure/merger.mdprompts/disclosure/correction_handler.md强制摘要小节## 合并摘要留档3–6 句## 纠正摘要留档2–5 句两者共享同一执行门禁与落盘纪律新时间戳文件、禁止覆盖旧稿、维护修订对话记录区别只在于改动性质合并侧重扩容纠正侧重纠错。选择依据见 prompts/disclosure/iteration_context.md 开头的意图对照表。二、执行门禁迭代前必读不可跳过merger.md 将门禁列为优先执行、不可跳过的硬性动作先Readprompts/disclosure/iteration_context.md该文件约定「迭代时先干什么、产出什么」避免 Agent 只读了合并/纠正模板却转去跑主流程 Step 3–4 的专利点全文分析或空泛地「更新专利分析」而不落盘新稿。再Read用户给出的当前定稿.md以及本轮的补充材料文件或粘贴片段。落盘合并结果必须写入新文件文件名为{案件名}_{YYYYMMDDHHmmss}.md并经mermaid_render.py或等价流程生成同名.docx命名规则见 disclosure_builder §7.3 第 5 点。禁止覆盖上一轮交付文件除非用户明确要求覆盖。OMML 失败留原文若 Word 公式转换失败stderr 出现omml_text_fallback/OMML_FAIL:按 builder「OMML 失败后的公式 PNG」流程在交付末尾反问一次未得「是」禁止安装 matplotlib。iteration_context.md 进一步给出了两条禁止红线已判定为迭代意图时不经合并/纠正流程、不把结果写入新时间戳文件却去跑全文专利点挖掘或仅输出分析段落例外用户明确要求「重新挖掘专利点 / 从头再走查新」时才可回主流程 Step 3 起。三、七步合并流程非破坏性增量写入merger.md 将合并过程规范为七个步骤本文结合相关源码与契约逐一展开3.1 第 1 步识别增量判断新内容主要影响哪些章节背景、1.1 现有技术、3.4 流程、实施例等实用新型/外观还须判断是否影响附图主题或材料集。这一步决定后续合并的落点与 figure_plan 是否需要重评。3.2 第 2 步非破坏性合并以追加或局部重写为主不推翻未涉及且用户未要求修改的章节。这与 correction 模式的「勿无必要大段重写无关章节」是同一纪律合并只动增量覆盖到的范围保持既有结论稳定。3.3 第 3 步figure_plan 同步实用新型/外观强制这是本模式中最具「契约化」特征的一步详见本文第四节。核心原则是先更新附图清单再改正文插图与「如图/见图 N」。3.4 第 4 步查新联动若增量改变了技术实质须判断是否需要补充检索并同步更新 1.1 现有技术与区别论述。注意只有当增量触及技术方案本质时才触发检索而非每次合并都重跑查新。3.5 第 5 步一致性检查合并后执行 prompts/disclosure/disclosure_self_check.md 中的8.2、8.3实用新型/外观还含8.4/8.5与 figure_plan 项快速检查。若涉及3.4.1 公式 / 3.5 参数须同步核对formula_plan.yaml与 disclosure_builder§7.7范式库、符号表、维度下标、3.5 符号列同形详见本文第六节。3.6 第 6 步落盘将合并后的全文写入{案件名}_{YYYYMMDDHHmmss}.md再经mermaid_render.py生成同名.docx。命名与工具用法见本文第七节。3.7 第 7 步对话记录按 prompts/disclosure/iteration_context.md「修订对话记录」要求在案件目录追加交底书修订对话记录.md优先使用tools/shared/iteration_dialog_log.py --kind merge自动生成详见本文第八节。iteration_context.md 提供的「建议执行顺序短清单」可视为这七步的可执行压缩版读上下文 → 读基准稿与材料 → 合并 → 写新时间戳.md并跑mermaid_render.py -o→ 追加对话记录 → 回复中写明新文件路径并输出合并摘要。四、figure_plan 同步实用新型/外观合并的强制前置4.1 触发条件与动作本轮若新增/替换/删除附图或主题/保护侧重点/部件与设计要点变化必须处理案件目录下的figure_plan.yaml无figure_plan.yaml按prompts/shared/fill_structure_schema.md实用新型或prompts/shared/fill_appearance_schema.md外观创建有重评score、use_in_disclosure、fig、covers、relates_to、theme_summary。顺序硬性要求先更新清单再改正文插图与「如图/见图 N」。合同文件为 references/schemas/figure_plan.schema.yaml。4.2 清单结构一行一图的可审计契约figure_plan 的核心设计是成文与迭代只读清单中use_in_disclosure: true的条目禁止绕过清单扫全assets/临场挑图。每条图记录的关键字段字段含义说明fig交底「如图 N」编号不入文则为null入文须唯一正整数从 1 连续编号为佳role图角色assembly/detail/ortho/perspective/reference/rejectedpath图路径相对案件根或 knowledge 的路径covers覆盖对象实用新型填parts.id外观填views.name或要点短标签kind图源类型lineart/cad/photo_clean/photo_scene/otherscore选用评分0–100同批内越高越优先入文use_in_disclosure是否入文剔除图保留条目并设false便于审计勿默默丢路径reason选用/剔除一句话必填relates_to图际关联多图联读时填写4.3 图际关联relates_to的 relation 枚举机械/实用新型有总装 局部时强烈建议填写图际关系正文「如图 N…如图 M 为其局部…」必须与relates_to一致relation含义典型用法detail_of本图是目标图的局部放大/细节卡扣局部 ← 总装section_of本图是目标图的剖视/断面装配剖 ← 立体总装exploded_of本图是目标图的爆炸/分解爆炸图 ← 装配图same_state同一产品状态、不同角度外观多视互指alternate_view另一投影/视角非放大关系主视 ↔ 俯视、立体 ↔ 正交sequence使用/拆装步骤前后图步骤图 1→2约束relates_to[].fig必须是清单中已分配的入文图勿指向null局部图role: detail对总装assembly至少一条detail_of或section_of/exploded_of外观多视可用same_state/alternate_view互链。4.4 排序启发式与跨图核对清单按启发式打分排序实用新型优先lineart/cadassembly或关键detail且covers命中保护相关件号场景杂图默认use_in_disclosure: false外观优先产品区清晰的perspective/ortho。跨图核对强制四项同一parts.id在多图出现则各图covers均列入局部图与总装图件号命名一致禁止图 1 叫「卡扣臂」、图 2 另起「弹片」且无映射有assemblydetail入文对时 detail 侧须有relates_to联读后仍对不上的写入 Structure/Appearance 的uncertain勿静默忽略。4.5 多轮同步强制下列任一发生时先更新清单再改正文附图无文件则新建禁止跳过新增/删除/替换原材料图用户调整专利主题、保护侧重点或选定候选点部件表/设计要点变更导致covers失效图际关系变化新增局部图、拆分总装。更新动作包括重评score/use_in_disclosure/fig序号/relates_to改写theme_summary与reason被删图若仍被relates_to引用须改写或清除。4.6 辅助线稿可选默认关外观辅助线稿prompts/shared/design_lineart_assist.md与实用新型结构辅助线稿prompts/shared/structure_lineart_assist.md均默认关闭、须用户回「是」且有参考图才可启用产出追加为kind: lineart、use_in_disclosure: false、reason含「AI 辅助线稿非申报终稿」并用relates_to链回源图禁止纯文生图。五、CAD/STEP 补材与查新联动5.1 本轮补充 CAD/STEP 文件时的处置按 prompts/disclosure/project_scan.md 的「CAD / STEP」规则跑轻量分类扫描无重依赖python tools/shared/cad_scan.py -r 扫描根 --json依据 JSON 的action分支处理ask_enable_step_parse立即中断后续流程展示step_files反问用户是否开启解析回是/否未得「是」前禁止安装依赖与运行step_to_views.pyhint_export_step不中断扫描仅在本轮对话回复末尾提示可将原生 CAD 导出为.step/.stp后再开启解析none无 CAD 相关文件忽略。用户回复「是」后才执行pip install -r tools/shared/requirements-step.txt python tools/shared/step_to_views.py --check-deps python tools/shared/step_to_views.py --enable-step-parse \ -i path/to/model.step -o outputs/{案件标识}/cad_views产出views/*.pngiso/front/top/right、assembly_tree.yaml、structure_schema.seed.yaml、figure_plan.seed.yaml再按fill_structure_schema.md审改 seed 为定稿 schema。注意.step/.stp为可解析目标原生 CAD.sldprt/.sldasm/.ipt/.iam/.prt/.asm/.catpart等本技能不直接解析仅提示导出。5.2 查新联动的前提只有当增量改变了技术实质时才判断是否补充检索并更新 1.1/区别论述纯文字增补、实施例扩充通常不触发重新查新。这与 correction 模式「现有技术或区别论述不准 → 改第一章必要时再检索」的判断逻辑一致。六、一致性自检8.2/8.3 与 formula_plan 联动6.1 自检条目按类型选用prompts/disclosure/disclosure_self_check.md 规定发明必做 §8.1–§8.3含公式时 §8.2 必核实用新型做 §8.3 通用项 §8.4外观做 §8.3 相关项 §8.5。自检结果用于修订正文默认不单独输出报告不得将自检清单作为一章写入交底书正文。6.2 与公式相关的联动8.2若合并涉及 3.4.1 公式或 3.5 参数须同步核对案件目录已有formula_plan.yamlparadigm_ids属于 references/formulas/paradigms.yaml 合并结果且check_formula_plan.py通过或等价手检通过符号表3.4.1先定义符号含义、下标、量纲禁止^{cpu}等上标表示维度须用b_{i,\mathrm{cpu}}下标 \mathrm{}形式禁\tilde/\hat/\bar装饰音禁止同一字母多义任务侧用b、节点侧改用g/h3.4.1 符号表、正文首次定义式、3.5「符号」列、第六章实施例四处逐字同形修改任一处须同步更新formula_plan.yaml。其中formula_plan.yaml的契约见 references/schemas/formula_plan.schema.yaml硬性规则包括paradigm_ids必须能在合并后的范式库中找到、numeric_example至少给出一组输入与结果、写 3.4.1 前执行python tools/shared/check_formula_plan.py -i path/to/formula_plan.yaml --eval6.3 迭代相关的 8.3 检查项8.3 中与本文主题直接相关的检查项对话中已含## 合并摘要留档小节案件目录已追加交底书修订对话记录.md一条含记录时间、用户说明摘要、本轮交付文件名、摘要摘录交付文件名符合{案件名}_{YYYYMMDDHHmmss}.md及同名.docx且未无故覆盖旧稿附图与figure_plan的fig一致等。七、落盘与交付命名规则、mermaid_render 与 OMML 处理7.1 时间戳命名规则§7.3 第 5 点凡写入用户产出目录、作为向用户交付的交底书.md/.docx主文件名必须为{§7.3 规范化案件名}_{YYYYMMDDHHmmss}.md配套要点来自 prompts/disclosure/invention/disclosure_builder.md §7.3提取从**案件名称**行取完整名称去占位[待填写]、首尾空格规范化删除或替换 Windows 非法字符\ / : * ? |与换行连续空格压缩长度文件名不含扩展名建议≤ 80 字符超长截断并保留语义完整时间戳14 位本地时间数字年月日时分秒各 2 位如20260408143025首次定稿与迭代合并/纠正适用同一规则每次交付即新时间戳、新文件名不要覆盖已有交付文件例外仓库内examples/教学示例可固定文件名用户书面指定文件名时从其意仍建议保留时间戳。7.2 mermaid_render.py 定稿命令prompts/disclosure/invention/disclosure_builder.md 定稿节给出的合并落盘命令python tools/shared/mermaid_render.py -i 含图示的草稿.md -o 案件名_YYYYMMDDHHmmss.md默认在同目录生成同名.docx。从 tools/shared/mermaid_render.py 的参数定义main中argparse可确认-i/--input必填含 mermaid 围栏的.md、-o/--output必填输出.md及图片引用、--docx可指定 Word 路径、--no-docx跳过 Word 生成。命令示例见mermaid_render.py文件头 docstringpython tools/shared/mermaid_render.py -i draft.md -o out/disclosure.md --docx out/custom.docx python tools/shared/mermaid_render.py -i draft.md -o disclosure.md --no-docxmermaid 出图走 Playwright 内置mermaid.min.js禁止为出图执行npm/npx/playwright install chromium除非--probe显示本机无可用浏览器。判读纪律以退出码 0 和机读前缀MERMAID: ok、DOCX: ok1、MATH:为准PowerShell 红字/NativeCommandError/乱码不是失败DOCX: ok0才按终端提示的手动md_to_docx.py命令补做。7.3 OMML 失败后的公式 PNG可选默认关Word 公式主路径为latex2mathml→ 可编辑 OMML失败则留 LaTeX 原文。定稿默认不预渲染公式 PNG禁止自动pip install matplotlib。若 stderr 出现omml_text_fallback/OMML_FAIL:先完成交付再在本轮回复末尾反问一次请回是/否说明需额外安装 matplotlib约 100MB未得「是」含未回复保持当前 docx用户回「是」后本会话最多一次安装并用--math-render重出同名 WordPNG 也画不出的保持原文不再问第二轮。八、修订对话记录iteration_dialog_log.py 自动留档每完成一轮合并或纠正并在磁盘上写出新.md/.docx后必须在案件产出目录与本轮交付文件同一目录维护固定文件交底书修订对话记录.md禁止完全不更新。推荐执行python tools/shared/iteration_dialog_log.py --case-dir {案件目录} --kind merge \ --user {用户说明摘要} --summary {摘要摘录} \ --artifacts {案件名_时间戳.md},{案件名_时间戳.docx}从 tools/shared/iteration_dialog_log.py 源码可确认其参数契约参数说明--case-dir必填案件产出目录须已存在--kind必填merge合并迭代correct纠正迭代--user用户本轮说明摘要建议 1–8 句--summary合并/纠正摘要的简短摘录可与对话留档段落一致--artifacts本轮交付文件名多个用英文逗号分隔--log-name日志文件名默认交底书修订对话记录.md环境对中文路径敏感时可用--log-name disclosure_revision_log.md脚本自动生成含本地时间 UTC 双时间戳的记录条目%Y-%m-%d %H:%M:%S本地·%Y-%m-%dT%H:%M:%SZUTC每个条目含类型、用户说明摘要、本轮交付文件清单、合并/纠正摘要摘录且追加不删除既有条目FILE_HEADER明确「请勿删除既有条目」。若无法执行脚本须Read已有记录文件无则创建后手工追加同构条目时间须真实。版本历史依赖同目录下多个带时间戳的文件不需要iterations/子目录或快照脚本。九、强制输出合并摘要留档与定稿延续9.1## 合并摘要留档不可省略在交付修改后的正文或说明已写入路径之后必须在同一条回复中追加独立小节标题固定为## 合并摘要留档其下用3–6 句完整中文依次说明改了哪些章节原因是否影响保护点或检索结论是否已做 8.2/8.3 核对实用新型/外观若动过图或主题须点明figure_plan是否已同步若有 CAD 导出提示写在回复末尾。若未输出本节视为未完成本 prompt。这一设计使每轮合并都有可审计的「变更留档」与修订对话记录文件互为补充对话内摘要 vs 磁盘留档。9.2 定稿延续权利要求偏向点建议交互若本轮合并结果作为向用户交付的定稿在同一条回复中于上文之后还须按 prompts/disclosure/invention/disclosure_builder.md§7.6补充「权利要求偏向点」建议交互可缩写不得写入交底书正文.md/.docx交互中的对举选项须来自本稿已有论述禁止捏造§7.6 第 3 点侧重点必须能从当前定稿与上游已用材料推出不得为凑交互编造本案未涉及的场景、模块或行业词若全文仅有一条清晰保护主线只须忠实概括该主线并询问改为更「方法/系统/流程步骤」或更「装置/模块」等书式侧重仍须对应文中已有结构不新增技术事实迭代再次交付定稿时仍须附带同类引导可缩短为 12 句但须保留「第五章」「新时间戳」「iteration_context merger」三要素之一或等效说明且仍遵守不捏造。9.3 可选附加政策感知低频提示定稿交付回复末尾可按 prompts/evolution/soft_nudge.md 决定是否加至多一句政策感知提示默认低频不入正文不自动进入模式 C。十、三份迭代文档的选择矩阵与禁止事项综合 prompts/disclosure/iteration_context.md 的意图对照表可将迭代选择归纳如下用户意图下一步模板补充文档、扩展方案、合并新材料merger.md指出错误、与事实/参数不符、风格或保护点调整correction_handler.md已按 §7.6 声明侧重点仅需第五章权利要求书式强化merger.md以最近定稿为基准合并范围以第五章为主取向须与本稿已有材料及第五、三章已写观点一致禁止为交互编造新场景贯穿始终的禁止事项已判定迭代意图时不落盘新时间戳文件却去跑 Step 3–4 全文专利点分析或仅泛泛「更新专利分析」默认覆盖上一轮交付文件除非用户明确要求完成迭代交付却不更新交底书修订对话记录.md输出「合并摘要留档」缺失或字数不符为「权利要求偏向」交互捏造本稿不存在的选项。结语merger 模式是 patent-disclosure-skill 交底书流水线中承上启下的关键环节它以「门禁—七步流程—强制摘要」的闭环把「在已有稿上补材料」这一高频诉求规范为可审计、可回滚、不破坏既有结论的增量操作。其设计精髓在于三处一是 figure_plan/formula_plan 等契约文件先行references/schemas/figure_plan.schema.yaml、references/schemas/formula_plan.schema.yaml保证正文与清单始终同频二是时间戳文件即版本历史§7.3 第 5 点不依赖任何快照机制三是对话内留档 磁盘留档双轨合并摘要小节与 tools/shared/iteration_dialog_log.py让每一轮改动的「改了什么、为什么改、影响什么」都可追溯。理解并遵循这套纪律即可在发明、实用新型、外观三类案件中稳定、合规地完成多轮迭代交付。【免费下载链接】patent-disclosure-skill中国专利.skill专利点挖掘与交底书发明/实用/外观编写通俗解读专利嗅探政策动向辅助审查答复。项目地址: https://gitcode.com/GitHub_Trending/pa/patent-disclosure-skill创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 patent-disclosure-skill 专利交底书增量合并（merger）模式实战：从迭代门禁、figure_plan 同步到合并摘要留档
patent-disclosure-skill 专利交底书增量合并merger模式实战从迭代门禁、figure_plan 同步到合并摘要留档【免费下载链接】patent-disclosure-skill中国专利.skill专利点挖掘与交底书发明/实用/外观编写通俗解读专利嗅探政策动向辅助审查答复。项目地址: https://gitcode.com/GitHub_Trending/pa/patent-disclosure-skill导读本文围绕开源仓库 patent-disclosure-skill 中的 prompts/disclosure/merger.md 展开系统讲解专利交底书写作流水线中「在已有稿上增量补充新材料」的增量合并merger迭代模式。你将掌握如何判断何时进入合并流程、合并前必须执行的门禁检查、七步非破坏性合并流程、实用新型/外观强制执行的 figure_plan 同步机制以及落盘交付时不可省略的「合并摘要留档」与修订对话记录。读完本文你既能按规则完成一轮合规的合并迭代也能从 tools/shared/iteration_dialog_log.py、references/schemas/figure_plan.schema.yaml 等源码与契约文件层面理解该模式的设计意图。一、merger 模式定位何时启用、解决什么问题1.1 触发条件由意图判断不依赖固定措辞merger 模式的启用不要求用户说出「迭代」「合并」等固定词Agent 也不必先询问是否进入迭代模式。判定依据是用户意图在已有交底书或上一轮输出上补充新材料新文档、新代码说明、粘贴片段、扩展章节等且用户诉求以合并进现有结构为主追加、局部重写而非推翻重写。此外用户按 prompts/disclosure/invention/disclosure_builder.md §7.6 仅要求做第五章「技术关键点和欲保护点」的权利要求书式强化、且已说明侧重点时同样走本流程——此时合并范围以第五章为主必要时微调第四章与第五章的衔接句。1.2 与「纠正」模式的区别扩展 vs 修正两个迭代模式在仓库中以两份独立 prompt 维护分工明确维度merger增量合并correction_handler对话纠正适用场景补充新材料、新功能的扩展用户指出错误、风格或与事实不符的修正典型用户话术「补充一份设计文档」「粘贴代码片段并扩展实施例」「这里不对」「和 3.5 不一致」「保护点应强调 XXX」对应模板prompts/disclosure/merger.mdprompts/disclosure/correction_handler.md强制摘要小节## 合并摘要留档3–6 句## 纠正摘要留档2–5 句两者共享同一执行门禁与落盘纪律新时间戳文件、禁止覆盖旧稿、维护修订对话记录区别只在于改动性质合并侧重扩容纠正侧重纠错。选择依据见 prompts/disclosure/iteration_context.md 开头的意图对照表。二、执行门禁迭代前必读不可跳过merger.md 将门禁列为优先执行、不可跳过的硬性动作先Readprompts/disclosure/iteration_context.md该文件约定「迭代时先干什么、产出什么」避免 Agent 只读了合并/纠正模板却转去跑主流程 Step 3–4 的专利点全文分析或空泛地「更新专利分析」而不落盘新稿。再Read用户给出的当前定稿.md以及本轮的补充材料文件或粘贴片段。落盘合并结果必须写入新文件文件名为{案件名}_{YYYYMMDDHHmmss}.md并经mermaid_render.py或等价流程生成同名.docx命名规则见 disclosure_builder §7.3 第 5 点。禁止覆盖上一轮交付文件除非用户明确要求覆盖。OMML 失败留原文若 Word 公式转换失败stderr 出现omml_text_fallback/OMML_FAIL:按 builder「OMML 失败后的公式 PNG」流程在交付末尾反问一次未得「是」禁止安装 matplotlib。iteration_context.md 进一步给出了两条禁止红线已判定为迭代意图时不经合并/纠正流程、不把结果写入新时间戳文件却去跑全文专利点挖掘或仅输出分析段落例外用户明确要求「重新挖掘专利点 / 从头再走查新」时才可回主流程 Step 3 起。三、七步合并流程非破坏性增量写入merger.md 将合并过程规范为七个步骤本文结合相关源码与契约逐一展开3.1 第 1 步识别增量判断新内容主要影响哪些章节背景、1.1 现有技术、3.4 流程、实施例等实用新型/外观还须判断是否影响附图主题或材料集。这一步决定后续合并的落点与 figure_plan 是否需要重评。3.2 第 2 步非破坏性合并以追加或局部重写为主不推翻未涉及且用户未要求修改的章节。这与 correction 模式的「勿无必要大段重写无关章节」是同一纪律合并只动增量覆盖到的范围保持既有结论稳定。3.3 第 3 步figure_plan 同步实用新型/外观强制这是本模式中最具「契约化」特征的一步详见本文第四节。核心原则是先更新附图清单再改正文插图与「如图/见图 N」。3.4 第 4 步查新联动若增量改变了技术实质须判断是否需要补充检索并同步更新 1.1 现有技术与区别论述。注意只有当增量触及技术方案本质时才触发检索而非每次合并都重跑查新。3.5 第 5 步一致性检查合并后执行 prompts/disclosure/disclosure_self_check.md 中的8.2、8.3实用新型/外观还含8.4/8.5与 figure_plan 项快速检查。若涉及3.4.1 公式 / 3.5 参数须同步核对formula_plan.yaml与 disclosure_builder§7.7范式库、符号表、维度下标、3.5 符号列同形详见本文第六节。3.6 第 6 步落盘将合并后的全文写入{案件名}_{YYYYMMDDHHmmss}.md再经mermaid_render.py生成同名.docx。命名与工具用法见本文第七节。3.7 第 7 步对话记录按 prompts/disclosure/iteration_context.md「修订对话记录」要求在案件目录追加交底书修订对话记录.md优先使用tools/shared/iteration_dialog_log.py --kind merge自动生成详见本文第八节。iteration_context.md 提供的「建议执行顺序短清单」可视为这七步的可执行压缩版读上下文 → 读基准稿与材料 → 合并 → 写新时间戳.md并跑mermaid_render.py -o→ 追加对话记录 → 回复中写明新文件路径并输出合并摘要。四、figure_plan 同步实用新型/外观合并的强制前置4.1 触发条件与动作本轮若新增/替换/删除附图或主题/保护侧重点/部件与设计要点变化必须处理案件目录下的figure_plan.yaml无figure_plan.yaml按prompts/shared/fill_structure_schema.md实用新型或prompts/shared/fill_appearance_schema.md外观创建有重评score、use_in_disclosure、fig、covers、relates_to、theme_summary。顺序硬性要求先更新清单再改正文插图与「如图/见图 N」。合同文件为 references/schemas/figure_plan.schema.yaml。4.2 清单结构一行一图的可审计契约figure_plan 的核心设计是成文与迭代只读清单中use_in_disclosure: true的条目禁止绕过清单扫全assets/临场挑图。每条图记录的关键字段字段含义说明fig交底「如图 N」编号不入文则为null入文须唯一正整数从 1 连续编号为佳role图角色assembly/detail/ortho/perspective/reference/rejectedpath图路径相对案件根或 knowledge 的路径covers覆盖对象实用新型填parts.id外观填views.name或要点短标签kind图源类型lineart/cad/photo_clean/photo_scene/otherscore选用评分0–100同批内越高越优先入文use_in_disclosure是否入文剔除图保留条目并设false便于审计勿默默丢路径reason选用/剔除一句话必填relates_to图际关联多图联读时填写4.3 图际关联relates_to的 relation 枚举机械/实用新型有总装 局部时强烈建议填写图际关系正文「如图 N…如图 M 为其局部…」必须与relates_to一致relation含义典型用法detail_of本图是目标图的局部放大/细节卡扣局部 ← 总装section_of本图是目标图的剖视/断面装配剖 ← 立体总装exploded_of本图是目标图的爆炸/分解爆炸图 ← 装配图same_state同一产品状态、不同角度外观多视互指alternate_view另一投影/视角非放大关系主视 ↔ 俯视、立体 ↔ 正交sequence使用/拆装步骤前后图步骤图 1→2约束relates_to[].fig必须是清单中已分配的入文图勿指向null局部图role: detail对总装assembly至少一条detail_of或section_of/exploded_of外观多视可用same_state/alternate_view互链。4.4 排序启发式与跨图核对清单按启发式打分排序实用新型优先lineart/cadassembly或关键detail且covers命中保护相关件号场景杂图默认use_in_disclosure: false外观优先产品区清晰的perspective/ortho。跨图核对强制四项同一parts.id在多图出现则各图covers均列入局部图与总装图件号命名一致禁止图 1 叫「卡扣臂」、图 2 另起「弹片」且无映射有assemblydetail入文对时 detail 侧须有relates_to联读后仍对不上的写入 Structure/Appearance 的uncertain勿静默忽略。4.5 多轮同步强制下列任一发生时先更新清单再改正文附图无文件则新建禁止跳过新增/删除/替换原材料图用户调整专利主题、保护侧重点或选定候选点部件表/设计要点变更导致covers失效图际关系变化新增局部图、拆分总装。更新动作包括重评score/use_in_disclosure/fig序号/relates_to改写theme_summary与reason被删图若仍被relates_to引用须改写或清除。4.6 辅助线稿可选默认关外观辅助线稿prompts/shared/design_lineart_assist.md与实用新型结构辅助线稿prompts/shared/structure_lineart_assist.md均默认关闭、须用户回「是」且有参考图才可启用产出追加为kind: lineart、use_in_disclosure: false、reason含「AI 辅助线稿非申报终稿」并用relates_to链回源图禁止纯文生图。五、CAD/STEP 补材与查新联动5.1 本轮补充 CAD/STEP 文件时的处置按 prompts/disclosure/project_scan.md 的「CAD / STEP」规则跑轻量分类扫描无重依赖python tools/shared/cad_scan.py -r 扫描根 --json依据 JSON 的action分支处理ask_enable_step_parse立即中断后续流程展示step_files反问用户是否开启解析回是/否未得「是」前禁止安装依赖与运行step_to_views.pyhint_export_step不中断扫描仅在本轮对话回复末尾提示可将原生 CAD 导出为.step/.stp后再开启解析none无 CAD 相关文件忽略。用户回复「是」后才执行pip install -r tools/shared/requirements-step.txt python tools/shared/step_to_views.py --check-deps python tools/shared/step_to_views.py --enable-step-parse \ -i path/to/model.step -o outputs/{案件标识}/cad_views产出views/*.pngiso/front/top/right、assembly_tree.yaml、structure_schema.seed.yaml、figure_plan.seed.yaml再按fill_structure_schema.md审改 seed 为定稿 schema。注意.step/.stp为可解析目标原生 CAD.sldprt/.sldasm/.ipt/.iam/.prt/.asm/.catpart等本技能不直接解析仅提示导出。5.2 查新联动的前提只有当增量改变了技术实质时才判断是否补充检索并更新 1.1/区别论述纯文字增补、实施例扩充通常不触发重新查新。这与 correction 模式「现有技术或区别论述不准 → 改第一章必要时再检索」的判断逻辑一致。六、一致性自检8.2/8.3 与 formula_plan 联动6.1 自检条目按类型选用prompts/disclosure/disclosure_self_check.md 规定发明必做 §8.1–§8.3含公式时 §8.2 必核实用新型做 §8.3 通用项 §8.4外观做 §8.3 相关项 §8.5。自检结果用于修订正文默认不单独输出报告不得将自检清单作为一章写入交底书正文。6.2 与公式相关的联动8.2若合并涉及 3.4.1 公式或 3.5 参数须同步核对案件目录已有formula_plan.yamlparadigm_ids属于 references/formulas/paradigms.yaml 合并结果且check_formula_plan.py通过或等价手检通过符号表3.4.1先定义符号含义、下标、量纲禁止^{cpu}等上标表示维度须用b_{i,\mathrm{cpu}}下标 \mathrm{}形式禁\tilde/\hat/\bar装饰音禁止同一字母多义任务侧用b、节点侧改用g/h3.4.1 符号表、正文首次定义式、3.5「符号」列、第六章实施例四处逐字同形修改任一处须同步更新formula_plan.yaml。其中formula_plan.yaml的契约见 references/schemas/formula_plan.schema.yaml硬性规则包括paradigm_ids必须能在合并后的范式库中找到、numeric_example至少给出一组输入与结果、写 3.4.1 前执行python tools/shared/check_formula_plan.py -i path/to/formula_plan.yaml --eval6.3 迭代相关的 8.3 检查项8.3 中与本文主题直接相关的检查项对话中已含## 合并摘要留档小节案件目录已追加交底书修订对话记录.md一条含记录时间、用户说明摘要、本轮交付文件名、摘要摘录交付文件名符合{案件名}_{YYYYMMDDHHmmss}.md及同名.docx且未无故覆盖旧稿附图与figure_plan的fig一致等。七、落盘与交付命名规则、mermaid_render 与 OMML 处理7.1 时间戳命名规则§7.3 第 5 点凡写入用户产出目录、作为向用户交付的交底书.md/.docx主文件名必须为{§7.3 规范化案件名}_{YYYYMMDDHHmmss}.md配套要点来自 prompts/disclosure/invention/disclosure_builder.md §7.3提取从**案件名称**行取完整名称去占位[待填写]、首尾空格规范化删除或替换 Windows 非法字符\ / : * ? |与换行连续空格压缩长度文件名不含扩展名建议≤ 80 字符超长截断并保留语义完整时间戳14 位本地时间数字年月日时分秒各 2 位如20260408143025首次定稿与迭代合并/纠正适用同一规则每次交付即新时间戳、新文件名不要覆盖已有交付文件例外仓库内examples/教学示例可固定文件名用户书面指定文件名时从其意仍建议保留时间戳。7.2 mermaid_render.py 定稿命令prompts/disclosure/invention/disclosure_builder.md 定稿节给出的合并落盘命令python tools/shared/mermaid_render.py -i 含图示的草稿.md -o 案件名_YYYYMMDDHHmmss.md默认在同目录生成同名.docx。从 tools/shared/mermaid_render.py 的参数定义main中argparse可确认-i/--input必填含 mermaid 围栏的.md、-o/--output必填输出.md及图片引用、--docx可指定 Word 路径、--no-docx跳过 Word 生成。命令示例见mermaid_render.py文件头 docstringpython tools/shared/mermaid_render.py -i draft.md -o out/disclosure.md --docx out/custom.docx python tools/shared/mermaid_render.py -i draft.md -o disclosure.md --no-docxmermaid 出图走 Playwright 内置mermaid.min.js禁止为出图执行npm/npx/playwright install chromium除非--probe显示本机无可用浏览器。判读纪律以退出码 0 和机读前缀MERMAID: ok、DOCX: ok1、MATH:为准PowerShell 红字/NativeCommandError/乱码不是失败DOCX: ok0才按终端提示的手动md_to_docx.py命令补做。7.3 OMML 失败后的公式 PNG可选默认关Word 公式主路径为latex2mathml→ 可编辑 OMML失败则留 LaTeX 原文。定稿默认不预渲染公式 PNG禁止自动pip install matplotlib。若 stderr 出现omml_text_fallback/OMML_FAIL:先完成交付再在本轮回复末尾反问一次请回是/否说明需额外安装 matplotlib约 100MB未得「是」含未回复保持当前 docx用户回「是」后本会话最多一次安装并用--math-render重出同名 WordPNG 也画不出的保持原文不再问第二轮。八、修订对话记录iteration_dialog_log.py 自动留档每完成一轮合并或纠正并在磁盘上写出新.md/.docx后必须在案件产出目录与本轮交付文件同一目录维护固定文件交底书修订对话记录.md禁止完全不更新。推荐执行python tools/shared/iteration_dialog_log.py --case-dir {案件目录} --kind merge \ --user {用户说明摘要} --summary {摘要摘录} \ --artifacts {案件名_时间戳.md},{案件名_时间戳.docx}从 tools/shared/iteration_dialog_log.py 源码可确认其参数契约参数说明--case-dir必填案件产出目录须已存在--kind必填merge合并迭代correct纠正迭代--user用户本轮说明摘要建议 1–8 句--summary合并/纠正摘要的简短摘录可与对话留档段落一致--artifacts本轮交付文件名多个用英文逗号分隔--log-name日志文件名默认交底书修订对话记录.md环境对中文路径敏感时可用--log-name disclosure_revision_log.md脚本自动生成含本地时间 UTC 双时间戳的记录条目%Y-%m-%d %H:%M:%S本地·%Y-%m-%dT%H:%M:%SZUTC每个条目含类型、用户说明摘要、本轮交付文件清单、合并/纠正摘要摘录且追加不删除既有条目FILE_HEADER明确「请勿删除既有条目」。若无法执行脚本须Read已有记录文件无则创建后手工追加同构条目时间须真实。版本历史依赖同目录下多个带时间戳的文件不需要iterations/子目录或快照脚本。九、强制输出合并摘要留档与定稿延续9.1## 合并摘要留档不可省略在交付修改后的正文或说明已写入路径之后必须在同一条回复中追加独立小节标题固定为## 合并摘要留档其下用3–6 句完整中文依次说明改了哪些章节原因是否影响保护点或检索结论是否已做 8.2/8.3 核对实用新型/外观若动过图或主题须点明figure_plan是否已同步若有 CAD 导出提示写在回复末尾。若未输出本节视为未完成本 prompt。这一设计使每轮合并都有可审计的「变更留档」与修订对话记录文件互为补充对话内摘要 vs 磁盘留档。9.2 定稿延续权利要求偏向点建议交互若本轮合并结果作为向用户交付的定稿在同一条回复中于上文之后还须按 prompts/disclosure/invention/disclosure_builder.md§7.6补充「权利要求偏向点」建议交互可缩写不得写入交底书正文.md/.docx交互中的对举选项须来自本稿已有论述禁止捏造§7.6 第 3 点侧重点必须能从当前定稿与上游已用材料推出不得为凑交互编造本案未涉及的场景、模块或行业词若全文仅有一条清晰保护主线只须忠实概括该主线并询问改为更「方法/系统/流程步骤」或更「装置/模块」等书式侧重仍须对应文中已有结构不新增技术事实迭代再次交付定稿时仍须附带同类引导可缩短为 12 句但须保留「第五章」「新时间戳」「iteration_context merger」三要素之一或等效说明且仍遵守不捏造。9.3 可选附加政策感知低频提示定稿交付回复末尾可按 prompts/evolution/soft_nudge.md 决定是否加至多一句政策感知提示默认低频不入正文不自动进入模式 C。十、三份迭代文档的选择矩阵与禁止事项综合 prompts/disclosure/iteration_context.md 的意图对照表可将迭代选择归纳如下用户意图下一步模板补充文档、扩展方案、合并新材料merger.md指出错误、与事实/参数不符、风格或保护点调整correction_handler.md已按 §7.6 声明侧重点仅需第五章权利要求书式强化merger.md以最近定稿为基准合并范围以第五章为主取向须与本稿已有材料及第五、三章已写观点一致禁止为交互编造新场景贯穿始终的禁止事项已判定迭代意图时不落盘新时间戳文件却去跑 Step 3–4 全文专利点分析或仅泛泛「更新专利分析」默认覆盖上一轮交付文件除非用户明确要求完成迭代交付却不更新交底书修订对话记录.md输出「合并摘要留档」缺失或字数不符为「权利要求偏向」交互捏造本稿不存在的选项。结语merger 模式是 patent-disclosure-skill 交底书流水线中承上启下的关键环节它以「门禁—七步流程—强制摘要」的闭环把「在已有稿上补材料」这一高频诉求规范为可审计、可回滚、不破坏既有结论的增量操作。其设计精髓在于三处一是 figure_plan/formula_plan 等契约文件先行references/schemas/figure_plan.schema.yaml、references/schemas/formula_plan.schema.yaml保证正文与清单始终同频二是时间戳文件即版本历史§7.3 第 5 点不依赖任何快照机制三是对话内留档 磁盘留档双轨合并摘要小节与 tools/shared/iteration_dialog_log.py让每一轮改动的「改了什么、为什么改、影响什么」都可追溯。理解并遵循这套纪律即可在发明、实用新型、外观三类案件中稳定、合规地完成多轮迭代交付。【免费下载链接】patent-disclosure-skill中国专利.skill专利点挖掘与交底书发明/实用/外观编写通俗解读专利嗅探政策动向辅助审查答复。项目地址: https://gitcode.com/GitHub_Trending/pa/patent-disclosure-skill创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考