patent-disclosure-skill 迭代纠正流程：交底书纠错、保护点调整与「纠正摘要（留档）」实操指南-育师

patent-disclosure-skill 迭代纠正流程：交底书纠错、保护点调整与「纠正摘要（留档）」实操指南

【免费下载链接】patent-disclosure-skill中国专利.skill：专利点挖掘与交底书（发明/实用/外观）编写，通俗解读专利，嗅探政策动向，辅助审查答复。项目地址: https://gitcode.com/GitHub_Trending/pa/patent-disclosure-skill

导读

本文围绕中国专利交底书生成技能patent-disclosure-skill中的迭代模式「对话纠正」（对应 prompt 文件 prompts/disclosure/correction_handler.md），讲解当用户对已有交底书指出错误、参数不符、表述问题或保护点调整时，Agent 应执行的完整纠正流程：从纠正点提取与分类、落地为新时间戳文件、公式与附图同步、自检，到强制输出「纠正摘要（留档）」与维护「交底书修订对话记录」。读完本文，你将掌握如何在不对旧稿做默认覆盖的前提下，把一轮用户纠错意见安全、可追溯地转化为新一版交底书定稿，并理解底层脚本 tools/shared/iteration_dialog_log.py 如何支撑版本历史与对话留档。

迭代纠正在整个技能流程中的定位

patent-disclosure-skill的主流程从项目扫描、专利点挖掘、查新检索一路走到 Step 7 定稿（见 prompts/disclosure/invention/disclosure_builder.md）。但实际办案中，用户几乎总会在拿到初稿后继续反馈，这时就进入迭代模式。技能内部分了两条迭代路径，入口选择由 prompts/disclosure/iteration_context.md 的意图映射表决定：

用户意图	下一步模板
补充文档、扩展方案、合并新材料	`merger.md`（增量合并）
指出错误、与事实/参数不符、风格或保护点调整	`correction_handler.md`（对话纠正）
已声明侧重点，仅需第五章权利要求书式强化	`merger.md`（以第五章为主）

correction_handler.md与merger.md的分工很明确：merger 侧重新材料、新功能的扩展，correction_handler 侧重用户指出错误、风格或与事实不符的修正（见 prompts/disclosure/merger.md 末尾「与『纠正』的区别」）。判断依据是用户意图而非措辞——用户说「这里不对」「和 3.5 不一致」「保护点应强调 XXX」即应走纠正流程，不要求用户说出「迭代」等固定词，也不必先询问是否进入迭代模式。

执行门禁：先读上下文，再另存新稿

纠正流程有两条不可跳过的门禁规则（与 merger 相同）：

先Readprompts/disclosure/iteration_context.md，明确本轮用户意图与已有稿路径，再Read当前定稿与纠正意图。这一步防止 Agent 只读了纠正模板却转去跑 Step 3–4 全文专利点分析，或空泛「更新分析」而不落盘新稿。
纠正结果必须另存为新文件{案件名}_{YYYYMMDDHHmmss}.md及同名.docx，禁止默认覆盖旧稿。

文件命名规则出自 prompts/disclosure/invention/disclosure_builder.md §7.3：主文件名须体现正文中的「案件名称」，去占位、删 Windows 非法字符\ / : * ? " < > |、超 80 字符截断，并带14 位本地时间戳（年月日时分秒各 2 位，如20260408143025）。首次定稿与迭代纠正适用同一规则，每次交付都是新时间戳、新文件名，旧版.md/.docx保留在同目录，天然形成版本历史，无需iterations/子目录或快照脚本。

另外，禁止在迭代意图下无合并/纠正落盘却回到 Step 3–4 全文专利点分析——除非用户明确要求重新挖掘专利点。

纠正点提取与五类分类

纠正流程第一步是提取纠正点：记录具体章节、原问题、用户期望，可摘要用户原话。第二步是分类，不同类别对应不同的修改落点：

1. 事实与技术类

涉及流程、参数、模块关系 → 修改第三章及相关实施例、3.5 关键技术参数。

2. 符号与公式体例类

典型问题包括：维度写成上标（如^{cpu}）、出现\tilde等装饰音、符号多义、LaTeX 分隔符混用、3.5 与 3.4.1 不同形、未更新formula_plan。此时应改formula_plan.yaml、3.4.1 符号表、相关公式、3.5 符号列及第六章实施例，并遵循 prompts/disclosure/invention/disclosure_builder.md §7.7、范式库 references/formulas/ 与 prompts/disclosure/invention/template_reference.md §3.4.1 的正/反例。

§7.7 的核心体例约束值得展开：资源维度/类型标签（cpu、mem、io 等）一律写入下标并用\mathrm{}正体（如b_{i,\mathrm{cpu}}），禁止^{cpu}这类上标（易被读作幂次）；禁止\tilde/\hat/\bar装饰音，平滑量用范式ema_smooth+ 独立符号 (A)；禁止同一字母多义（任务侧权重用 (b)，节点侧饱和度应改用 (g)、(h)）；行内公式全文统一$...$或 $...$ 二选一，块级统一\[...\]或$$...$$，不得混用；防零除用与分母同量纲的 (\varepsilon)，禁止在容量类分母上裸写max(1, b_{\mathrm{mem}})。最关键的是跨节同形：3.4.1 符号表、正文首次定义式、3.5「符号」列、第六章实施例四处须逐字同形。

3. 查新与区别类

现有技术或区别论述不准 → 修改第一章，必要时按 prompts/disclosure/prior_art_search.md 重新检索。特别地，若国知局检索 JSON 中该专利带非空abstract，1.1 中的方案概括必须以对该摘要的完整理解为前提，禁止与摘要矛盾或脱离摘要杜撰。

4. 保护点与表述类

第四章、第五章论点与第三章对齐，避免矛盾；实用/外观若侧重点/主题转向，须按附图类规则先重评或新建figure_plan.yaml。

5. 附图与主题类（实用/外观）

换图、改件号/视图、主题转向 →先更新或新建figure_plan.yaml（重排入文图fig、covers、relates_to），再改正文「如图/见图 N」与插图路径。清单合同见 references/schemas/figure_plan.schema.yaml：每条图须含fig、role（assembly/detail/ortho/perspective/reference/rejected）、path、covers、kind、score（0–100）、use_in_disclosure、reason，多图联读时relates_to用detail_of/section_of/exploded_of/same_state/alternate_view/sequence描述图际关系；总装+局部入文时 detail 侧至少一条detail_of之类关联，跨图件号命名必须一致。

落地修改：新文件 + mermaid_render 出 Word

第三步落地修改：形成纠正后全文，写入新文件{案件名}_{YYYYMMDDHHmmss}.md，并经mermaid_render.py生成同名.docx（§7.3 第 5 点）。典型命令（见 prompts/disclosure/invention/disclosure_builder.md 定稿交付节）：

python tools/shared/mermaid_render.py -i "纠正后草稿.md" -o "一种XXX方法及系统_20260915041008.md"

脚本默认在同目录生成同名.docx，可用--docx指定路径、--no-docx跳过 Word。mermaid 出图走 Playwright + 内置tools/shared/vendor/mermaid.min.js（与查新共用浏览器，见 tools/shared/browser.py），禁止为此执行npm/npx/playwright install chromium（除非--probe显示本机无 Chrome/Edge 且无自带 Chromium）。判读以退出码 0和机读前缀为准（MERMAID: ok=、DOCX: ok=1），PowerShell 红字/NativeCommandError/中文乱码不是失败。

OMML 失败时（stderr 出现omml_text_fallback=或OMML_FAIL:），按发明 builder 定稿节反问一次是否装 matplotlib（约 100MB，Word 中图片不可再编辑）；未得「是」（含未回复）禁止安装 matplotlib，保持 LaTeX 原文的 docx。全成功则不问。

落地修改还强调：禁止无必要大段重写无关章节；勿默认覆盖用户上一版文件名。

自检：8.2、8.3 必做，实用/外观加 8.4/8.5

纠正后的稿子须执行 prompts/disclosure/disclosure_self_check.md 的自检，且发现问题直接改稿，不要只向用户报告：

§8.2 公式与参数一致性（发明，含公式时必做）：主动复核公式正确性、公式逻辑是否与第三章叙述一致；核formula_plan.yaml存在且paradigm_ids属于 references/formulas/paradigms.yaml；查维度上标、装饰音、字母多义、LaTeX 分隔符统一、3.5 与符号表同形、阈值范围一致、实施例数值与formula_plan.numeric_example互证；可算性用python tools/shared/check_formula_plan.py -i …/formula_plan.yaml --eval验证。
§8.3 格式与引用：迭代路径是否已输出「纠正摘要（留档）」；案件目录是否已追加修订对话记录；交付文件名是否符合时间戳规则；正文「如图 N」与figure_plan的fig/path一致；1.1 公开 URL 非编造且与著录项一致；文末无技能仓库名、examples/等元信息脚注。
§8.4 实用新型专项：文头专利类型正确；第三章可追溯 StructureSchema；第五章为装置/结构书式；未把外观美感或算法步骤当构造创新主线；入文图优先 lineart/cad；跨图件号一致。
§8.5 外观设计专项：只写可见造型/图案/色彩；视图清单齐全或uncertain标明缺失；not_design_signals已处理；未写内部电路、受力、工艺作为设计要点。

修订对话记录：iteration_dialog_log.py 的使用与源码细节

每完成一轮纠正并落盘新.md/.docx后，必须在案件产出目录维护固定文件交底书修订对话记录.md（默认名），每条记录含：记录时间（本地 + UTC）、类型（纠正迭代）、用户说明摘要、本轮交付文件名、纠正摘要摘录。禁止完成迭代交付却完全不更新该文件。

优先使用脚本 tools/shared/iteration_dialog_log.py：

python ${CLAUDE_SKILL_DIR}/tools/shared/iteration_dialog_log.py \ --case-dir "{案件目录}" \ --kind correct \ --user "{用户说明摘要}" \ --summary "{纠正摘要摘录}" \ --artifacts "{案件名_时间戳.md},{案件名_时间戳.docx}"

从源码看（tools/shared/iteration_dialog_log.py），脚本参数与行为如下：

--case-dir（必填）：案件产出目录，须已存在，否则返回退出码 2 并输出ERROR: 目录不存在或不是目录。
--kind（必填）：枚举merge/correct，纠正迭代用correct，内部映射为中文「纠正迭代」。
--user/--summary：缺省时分别回退为「（未传入 --user，请 Agent 用编辑工具在本条内补写用户说明摘要。）」和「—」。
--artifacts：多个交付文件用英文逗号分隔，脚本逐项渲染为- \文件名`` 列表，缺省为「—」。
--log-name：默认交底书修订对话记录.md；若环境对中文路径敏感，可用--log-name disclosure_revision_log.md换名。

写入行为可推断：若日志文件已存在则追加（自动补换行分隔），否则先写固定文件头（含「请勿删除既有条目」提示），每条记录以本地时间 + UTC 双时间戳的 H2 标题开头，末尾以---分隔；成功后 stdout 输出LOG_FILE=<路径>并返回 0。若无法执行脚本，则须Read已有记录（无则创建）后手动追加同样结构的一条，时间须真实。

输出强制项：「纠正摘要（留档）」与定稿延续

correction_handler.md的输出是强制且不可省略的：在交付修改后的正文（或说明已写入路径）之后，必须在同一条回复中追加独立小节，标题固定为：

## 纠正摘要（留档）

其下用2–5 句完整中文，说明：修改位置、依据、是否影响保护点或检索；若动过附图/主题，点明figure_plan已同步。若未输出本节，视为未完成本 prompt（§8.3 自检也据此核对）。

定稿延续：若本轮纠正结果作为向用户交付的定稿，在同一条回复中于上文之后，还须按 prompts/disclosure/invention/disclosure_builder.md §7.6 补充「权利要求偏向点」建议交互（可 1～2 句缩写版），不得写入.md/.docx正文。§7.6 的核心约束是禁止编造偏向：对话里提出的可对举侧重点必须能从当前定稿与上游已用材料（Step 2 扫描文档、Step 3–4 专利点、第三至五章已写明的技术方案与保护点表述）中推出，不得为凑交互而编造本案未涉及的场景、模块或行业词；若全文仅有一条清晰保护主线，只须忠实概括该主线并询问是否改为更「方法/系统/流程步骤」或更「装置/模块」等书式侧重。若本轮走纠正流程但纠正结果并非定稿，则无需该交互。

一句话总结的完整闭环

一次合规的纠正迭代 = 读iteration_context.md→ 提取并分类纠正点 → 先同步figure_plan.yaml/formula_plan.yaml再改正文 → 另存{案件名}_{时间戳}.md并经mermaid_render.py出同名.docx→ 执行 8.2/8.3（实用/外观加 8.4/8.5）自检并直接改稿 → 用iteration_dialog_log.py --kind correct追加修订对话记录 → 同一条回复输出「纠正摘要（留档）」，定稿则追加 §7.6 偏向建议交互。每一步都以「新时间戳文件 + 留档」为契约，确保多轮纠错可审计、可回退，这正是patent-disclosure-skill迭代体系区别于一次性生成的核心工程能力。