patent-disclosure-skill 专利交底书增量合并（merger）模式实战：从迭代门禁、figure

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.md	prompts/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`/`rejected`
`path`	图路径	相对案件根或 knowledge 的路径
`covers`	覆盖对象	实用新型填`parts.id`；外观填`views.name`或要点短标签
`kind`	图源类型	`lineart`/`cad`/`photo_clean`/`photo_scene`/`other`
`score`	选用评分	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/cad+assembly或关键detail且covers命中保护相关件号，场景杂图默认use_in_disclosure: false；外观优先产品区清晰的perspective/ortho。跨图核对强制四项：同一parts.id在多图出现则各图covers均列入；局部图与总装图件号命名一致（禁止图 1 叫「卡扣臂」、图 2 另起「弹片」且无映射）；有assembly+detail入文对时 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.py；
hint_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/*.png（iso/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.yaml，paradigm_ids属于 references/formulas/paradigms.yaml 合并结果，且check_formula_plan.py通过或等价手检通过；
符号表（3.4.1）先定义符号（含义、下标、量纲）；禁止^{cpu}等上标表示维度，须用b_{i,\mathrm{cpu}}下标 +\mathrm{}形式；
禁\tilde/\hat/\bar装饰音；禁止同一字母多义（任务侧用b、节点侧改用g/h）；
3.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 --eval

6.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文件头 docstring：

python 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-docx

mermaid 出图走 Playwright + 内置mermaid.min.js，禁止为出图执行npm/npx/playwright install chromium（除非--probe显示本机无可用浏览器）。判读纪律：以退出码 0 和机读前缀（MERMAID: ok=、DOCX: ok=1、MATH:）为准，PowerShell 红字/NativeCommandError/乱码不是失败；DOCX: ok=0才按终端提示的手动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重出同名 Word；PNG 也画不出的保持原文，不再问第二轮。

八、修订对话记录：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:%SZ（UTC）），每个条目含类型、用户说明摘要、本轮交付文件清单、合并/纠正摘要摘录，且追加不删除既有条目（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 点：侧重点必须能从当前定稿与上游已用材料推出，不得为凑交互编造本案未涉及的场景、模块或行业词）；
若全文仅有一条清晰保护主线，只须忠实概括该主线并询问改为更「方法/系统/流程步骤」或更「装置/模块」等书式侧重（仍须对应文中已有结构，不新增技术事实）；
迭代再次交付定稿时仍须附带同类引导（可缩短为 1～2 句，但须保留「第五章」「新时间戳」「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），让每一轮改动的「改了什么、为什么改、影响什么」都可追溯。理解并遵循这套纪律，即可在发明、实用新型、外观三类案件中稳定、合规地完成多轮迭代交付。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考