企业官网建设流程全解析

patent-disclosure-skill 交底书迭代上下文：合并/纠正双模式、时间戳落盘与修订留痕的实战指南

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

导读

在patent-disclosure-skill中国专利交底书工作流中，用户往往不是一次性定稿，而是在已有交底书或上一轮交付稿上继续补材料、改章节、纠错误、调整保护点表述。prompts/disclosure/iteration_context.md正是为这类「迭代」场景设计的执行前置契约：它先于merger.md/correction_handler.md被读取，用来约定「迭代时先干什么、产出什么」，防止 Agent 拿到迭代意图后跑偏去重做 Step 3–4 专利点全文分析，或只输出空泛的「更新分析」却不落盘新稿。读完本文，你将掌握：如何判定迭代意图并选择对应模板、如何以「案件名 + 14 位时间戳」非破坏性落盘新稿、如何维护固定文件交底书修订对话记录.md（含脚本与手工两种方式），以及实用新型/外观案件在迭代时必须同步的figure_plan.yaml重评规则。

一、本文作用：一份防跑偏的迭代执行契约

交底书生成主流程（disclosure_builder.md）包含从项目文档扫描（Step 2）、专利点挖掘（Step 3–4）到成文（Step 7）的完整链路。但当用户说「补一段材料」「这里写得不对」「保护点想再强调某一点」时，正确的做法不是把整条主流程重跑一遍，而是走增量迭代。

iteration_context.md用一句话概括了它的存在意义：

约定迭代时先干什么、产出什么，避免 Agent 只读了合并/纠正模板却转去跑Step 3–4 专利点分析或空泛「更新分析」而不落盘新稿。

也就是说，这份文档是迭代模式的门禁与路标：先判定意图，再选模板，最后必须产出「带时间戳的新文件 + 修订对话记录」这一可审计的交付物。它与merger.md（增量合并）、correction_handler.md（对话纠正）构成一组配套模板，而本文档在三者中处于最前端的「读前必读」位置。

二、何时读本文：判定迭代意图与模板选择

触发条件非常宽泛：只要用户在已有交底书或上一轮交付稿上继续工作（补材料、改章节、纠错、调保护点表述等），就属于迭代场景。此时必须在Readmerger.md或correction_handler.md之前先读本文，再读对应的迭代模板。

文档给出了一张「意图 → 下一步模板」的决策表，这是整个迭代流程的入口：

值得注意第三行：即便用户没有「新增材料」，只是希望第五章「技术关键点和欲保护点」更贴近权利要求书撰写习惯，也走merger而非 correction。这是因为发明 builder 的 §7.6（disclosure_builder.md）在每次定稿交付时都会附带「权利要求偏向点」建议交互，用户回应这一交互后，后续强化请求天然属于「在定稿上做增量合并」——且合并范围被严格限定：以第五章为主，必要时只微调第四章与第五章的衔接句，其他章节以保持既有结论为前提，禁止为凑交互而编造本稿没有的新场景、模块或行业词。

三、迭代的输入与输出：以「新时间戳文件」为铁律

3.1 输入清单

开始迭代前，Agent 需要收集三类输入：

1. 对话中的本轮说明：用户本次的意图、要点，以及用户@的文件或粘贴片段；
2. 基准稿：Read当前作为基准的交底书.md，路径由用户给出或已在对话中出现；
3. 附图与主题（实用新型 / 外观专用）：迭代涉及附图或主题时，必处理案件目录figure_plan.yaml——无则创建、有则 Read 后重评；并 Readstructure_schema/appearance_schema（若存在）。

3.2 输出契约：绝不覆盖旧稿

迭代结果写入新文件，不得默认覆盖旧稿：

{规范化案件名}_{YYYYMMDDHHmmss}.md {规范化案件名}_{YYYYMMDDHHmmss}.docx ← 由 mermaid_render.py 生成的同名 Word

这一命名规则与Step 7 首次定稿为同一规则，详见发明 builder disclosure_builder.md §7.3 第 5 点：凡落盘交付均带 14 位本地时间戳（YYYYMMDDHHmmss，年月日时分秒各 2 位，如20260408143025）；每次交付取当次落盘时的本地时间，不覆盖已有交付文件，新一次交付即新时间戳、新文件名；用户明确要求覆盖某路径时才从其意。

同时旧版.md/.docx保留在同目录，便于对照。也就是说，版本历史完全依赖同目录下多个带时间戳的文件即可追溯，不需要iterations/子目录或快照脚本——这是一个刻意简化、靠命名自描述的设计。

对实用/外观案件还有一条附加输出：材料或主题有变时，同目录更新figure_plan.yaml（该清单文件本身可覆盖，正文仍用新时间戳），使入文图、相关性排序与relates_to与当前主题保持一致。

3.3 figure_plan.yaml：实用新型/外观迭代的强制同步项

figure_plan.yaml的合同定义在 references/schemas/figure_plan.schema.yaml，是「交底附图选用与排序合同」。它的核心设计是：在成文前固化「贴哪些图、图序、为何选用、图与图如何关联」，成文与迭代只读本清单中use_in_disclosure: true的条目，禁止绕过清单扫全assets/临场挑图。

清单的关键字段包括：

• patent_type（utility_model|design）、theme_summary（当前交底主题一句话，主题变了必须重评清单）；
• 每条figures[]：fig（正文「如图 N」编号，不入文则为null）、role（assembly总装 /detail局部 /ortho正交 /perspective立体 /reference参考 /rejected不入文）、path、covers（实用新型对应parts.id，外观对应views.name）、kind（lineart/cad/photo_clean/photo_scene/other）、score（0–100，同批内越高越优先入文）、use_in_disclosure、reason、relates_to；
• relates_to[].relation枚举：detail_of（局部放大）、section_of（剖视/断面）、exploded_of（爆炸/分解）、same_state（同一状态不同角度）、alternate_view（另一投影）、sequence（步骤前后图）。

schema 明确约定：relates_to[].fig必须指向本清单中已分配的入文图；局部图对总装图至少一条detail_of（或section_of/exploded_of）；成文时「如图 N…如图 M 为其局部…」的表述必须与relates_to一致。排序启发式方面，实用新型优先lineart/cad+assembly或关键detail且covers命中保护相关件号，场景杂图默认rejected/reference；外观优先产品区清晰的perspective/ortho。

多轮同步（强制）：当出现以下任一情况——新增/删除/替换原材料图、用户调整专利主题或保护侧重点、部件表/设计要点变更导致covers失效、图际关系变化——都必须先更新 figure_plan 再改交底正文附图（无文件则新建，禁止跳过）。更新动作包括重评score/use_in_disclosure/fig/relates_to，改写theme_summary与reason；已剔除图保留条目并设use_in_disclosure: false（便于审计），不要默默丢路径；被删图若仍被relates_to引用，须改写或清除。

四、修订对话记录：每条迭代的强制留痕

4.1 固定文件与五要素

每完成一轮合并或纠正并在磁盘上写出新.md/.docx后，须在案件产出目录（与本轮交付文件同一目录，如outputs/{案件标识}/）维护一个固定文件：

• 文件名：交底书修订对话记录.md（默认）；若环境对中文路径敏感，可用--log-name disclosure_revision_log.md参数调用脚本改名。

每条记录必须包含五项要素：

1. 记录时间：本地时间与UTC（脚本自动生成；手工追加时两者都要写）；
2. 类型：合并迭代 / 纠正迭代；
3. 用户说明摘要：本轮用户意图、要点（可含 @ 文件名称）；
4. 本轮交付文件：新时间戳.md、.docx文件名；
5. 合并/纠正摘要摘录：与当轮对话中「合并摘要（留档）」「纠正摘要（留档）」一致或为其缩写。

4.2 脚本追加（推荐）

在写出交付文件并生成 Word 之后，推荐执行：

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

--kind纠正时用correct。从 tools/shared/iteration_dialog_log.py 的源码可以看到它的完整参数与行为：

• --case-dir（必填）：案件产出目录，脚本会校验其存在且为目录，否则打印ERROR: 目录不存在或不是目录并返回退出码 2；
• --kind（必填）：枚举merge/correct，分别映射为中文「合并迭代」「纠正迭代」；
• --user：用户本轮说明摘要（建议 1–8 句），未传入时条目内会写入提示「未传入 --user，请 Agent 用编辑工具在本条内补写用户说明摘要」；
• --summary：合并/纠正摘要的简短摘录（可为空，缺省显示—）；
• --artifacts：本轮交付文件名，多个用英文逗号分隔，脚本会逐条转为- \文件名`` 列表；
• --log-name：日志文件名，默认交底书修订对话记录.md。

脚本内部逻辑：取datetime.now().astimezone()作为本地时间、datetime.now(timezone.utc)作为 UTC 时间，生成形如## 2026-09-15 04:23:44（本地） · 2026-09-15T...Z（UTC）的小节；若日志文件已存在则在文末追加（并保证换行衔接），不存在则先写入固定文件头（注明由iteration_dialog_log.py或 Agent 按本文档追加、请勿删除既有条目）。成功时输出LOG_FILE={日志路径}并返回 0。

4.3 手工追加兜底

若无法执行脚本，必须Read已有交底书修订对话记录.md（若无则Write创建），再以StrReplace或等价方式在文末追加一条与上述结构相同、含五项要素的记录，时间必须真实。

禁止：完成迭代交付却完全不更新该对话记录文件。

五、建议执行顺序：六步短清单拆解

iteration_context.md给出了压缩为 6 步的执行顺序，下面结合仓库配套模板与工具逐条展开：

第 1 步：读本文 → 按意图表选模板

按第二节的决策表选定merger.md或correction_handler.md并Read。注意merger.md的执行门禁与本文一致：先 Readiteration_context.md，再 Read 当前定稿与补充材料，不要跳过合并去跑专利点分析。

第 2 步：读基准稿 + 本轮补充材料；实用/外观处理 figure_plan

Read基准稿与本轮补充材料；实用/外观若改图或主题，Read/Writefigure_plan.yaml（无则创建），并可按第三节的 schema 合同重评。本步还有几个条件分支：

• CAD / STEP 扫描：若本轮新增/更新了目录内文件，再跑python ${CLAUDE_SKILL_DIR}/tools/shared/cad_scan.py -r …（规则同 project_scan.md 的「CAD / STEP」节）。cad_scan.py输出的 JSONaction有三态：
  • ask_enable_step_parse→先反问，展示step_files，用户确认前不装依赖、不改 STEP 视图；
  • hint_export_step→ 本轮交付回复末尾提示可将原生 CAD 导出为.step/.stp后再开启解析；
  • none→ 无 CAD 相关文件，忽略。
• 外观辅助线稿：外观且用户本轮要求辅助线稿，按 design_lineart_assist.md（须用户回「是」+ 有参考图，禁止纯文生图）；
• 实用新型结构辅助线稿：实用且用户本轮要求结构辅助线稿，按 structure_lineart_assist.md（须「是」+ 有参考图 + 已有 Structure；序号优先 overlay 分层，禁止自创件号）。

structure_lineart_assist.md的门禁强调：默认关闭，未询问或用户未答「是」前不得写structure_lineart_brief.yaml、不得调出图工具；辅助线稿回写 figure_plan 时默认use_in_disclosure: false、reason注明「AI 辅助结构线稿（非申报终稿；件号对齐 StructureSchema）」，仅当用户明确要求「辅助线稿也写入交底」才置 true 并分配连续fig。

第 3 步：在稿内完成合并/纠正逻辑并自检

在稿内完成合并或纠正逻辑，自检见 disclosure_self_check.md 的8.2、8.3（实用/外观核8.4/8.5）。与迭代直接相关的自检项包括：

• §8.3「迭代路径」：本次走merger.md/correction_handler.md时，对话中是否已含## 合并摘要（留档）或## 纠正摘要（留档）；
• §8.3「修订对话记录」：案件目录是否已追加交底书修订对话记录.md一条（含时间、用户说明摘要、交付文件名、摘要摘录）；
• §8.3「交付文件名」：是否均为{案件名}_{YYYYMMDDHHmmss}.md及同名.docx，未无故覆盖旧稿；
• §8.3「figure_plan（实用/外观）」：案件目录存在figure_plan.yaml，主题/材料有变时清单已重评（含relates_to），未入文图有reason。

若本轮涉及3.4.1 公式 / 3.5 参数（发明含公式案件），还须同步核对formula_plan.yaml与 builder §7.7（范式库 references/formulas/、符号表、维度下标、3.5 符号列同形），并可用tools/shared/check_formula_plan.py校验——这是 §8.2 的硬性要求。

第 4 步：写入新时间戳 .md → mermaid_render 出图与 .docx

Write新时间戳.md，再运行python tools/shared/mermaid_render.py -i "…草稿.md" -o "{案件名_YYYYMMDDHHmmss}.md"，默认在同目录生成同名.docx（可用--docx指定路径、--no-docx跳过 Word）。mermaid 出图走 Playwright + 内置 vendor 脚本，与查新共用浏览器（见 tools/shared/browser.py），禁止为出图执行npm/npx/playwright install chromium（除非--probe显示本机无可用浏览器）。判读以退出码 0与机读前缀（MERMAID:、DOCX: ok=1、MATH:）为准，stderr 输出不等于失败。

第 5 步：追加修订对话记录

按第四章用iteration_dialog_log.py（--kind merge/correct）或手工方式追加交底书修订对话记录.md。

第 6 步：回复中写明路径并输出留档摘要

在回复中写明新文件路径，并输出对应模板要求的「合并摘要（留档）」或「纠正摘要（留档）」（含 figure_plan 是否同步；若有 CAD 提示须写在回复末尾）。

六、合并与纠正的分工：merger vs correction_handler

iteration_context.md将「合并」与「纠正」定义为两种互补的迭代模式，二者的核心区别在 merger.md 末尾一句话点明：

• merger：侧重新材料、新功能的扩展；
• correction_handler：侧重用户指出错误、风格或与事实不符的修正。

6.1 merger：增量合并（修订与补充）

启用条件：在已有交底书或上一轮输出上补充新材料（新文档、新代码说明、粘贴片段、扩展章节等），且以合并进现有结构为主；或按 §7.6 仅要求第五章权利要求书式强化。不要求用户说出「迭代」等固定词，也不必先询问是否进入迭代模式。

其流程七步：

1. 识别增量：新内容主要影响哪些章节（背景、1.1 现有技术、3.4 流程、实施例等）；实用/外观还须判断是否影响附图主题或材料集；
2. 非破坏性合并：以追加或局部重写为主，不推翻未涉及且用户未要求修改的章节；
3. figure_plan 同步（实用/外观，强制）：新增/替换/删除附图或主题/侧重点变化时，无figure_plan.yaml则按fill_*_schema.md创建，有则重评score、use_in_disclosure、fig、covers、relates_to、theme_summary；先更新清单，再改正文插图与「如图/见图 N」。补充 CAD/STEP 文件时按project_scan.md跑cad_scan.py；STEP 须用户确认后再step_to_views；
4. 查新联动：若增量改变技术实质，判断是否需要补充检索并更新 1.1 / 区别论述；
5. 一致性：执行disclosure_self_check.md的 8.2、8.3（实用/外观含 8.4/8.5 与 figure_plan 项）快速检查；涉及公式/参数则同步核对formula_plan.yaml与 §7.7；
6. 落盘：写入{案件名}_{YYYYMMDDHHmmss}.md并经mermaid_render.py生成同名.docx；
7. 对话记录：按本文档在案件目录追加交底书修订对话记录.md（优先iteration_dialog_log.py --kind merge）。

输出（强制）：交付正文后必须在同一条回复中追加独立小节，标题固定为## 合并摘要（留档），其下用3–6 句完整中文依次说明：改了哪些章节、原因、是否影响保护点或检索结论、是否已做 8.2/8.3 核对；实用/外观若动过图或主题，须点明figure_plan是否已同步。若未输出本节，视为未完成该 prompt。

6.2 correction_handler：对话纠正

启用条件：用户针对已有交底书指出错误、与事实或参数不符、表述问题、保护点调整等（例如「这里不对」「和 3.5 不一致」「保护点应强调 XXX」）。

其步骤五步，核心在第 2 步的纠正点分类，不同类别对应不同修改落点：

• 事实与技术（流程、参数、模块关系）→ 改第三章及相关实施例、3.5；
• 符号与公式体例（上标维度如^{cpu}、装饰音\tilde等、符号多义、LaTeX 分隔符混用、3.5 与 3.4.1 不同形、未更新formula_plan）→ 改formula_plan、3.4.1 符号表、相关公式、3.5 符号列及第六章实施例；遵循 builder §7.7、references/formulas/ 与 template_reference.md §3.4.1 正/反例；
• 查新与区别（现有技术或区别论述不准）→ 改第一章，必要时再检索；
• 保护点与表述（第四章、第五章论点）→ 与第三章对齐，避免矛盾；实用/外观若侧重点/主题转向，按附图类同样先重评或新建figure_plan.yaml；
• 附图与主题（实用/外观）（换图、改件号/视图、主题转向）→先更新或新建figure_plan.yaml（重排入文图、covers、relates_to），再改正文「如图/见图 N」与插图路径。

落地修改同样写入新文件{案件名}_{YYYYMMDDHHmmss}.md并经mermaid_render.py生成同名.docx，禁止无必要大段重写无关章节，勿默认覆盖用户上一版文件名。

输出（强制）：交付后必须追加独立小节，标题固定为## 纠正摘要（留档），其下用2–5 句完整中文说明：修改位置、依据、是否影响保护点或检索；若动过附图/主题，点明figure_plan已同步。同样，未输出本节视为未完成。

6.3 定稿延续：权利要求偏向点交互

若本轮合并/纠正结果作为向用户交付的定稿，两个模板都要求在同一条回复中、在留档摘要之后，按发明 builder disclosure_builder.md §7.6 补充「权利要求偏向点」建议交互（合并可缩写，纠正可 1～2 句缩写版），不得写入交底书正文。§7.6 第 3 点是硬约束：对话中提出的「可对举的两类侧重点」必须能从当前定稿与上游已用材料中推出（包括 Step 2 扫描文档、Step 3–4 已整理专利点、第三至五章已写明的技术方案与保护点表述），禁止捏造；若全文仅有一条清晰保护主线，只须忠实概括该主线并询问书式侧重（更「方法/系统/流程步骤」或更「装置/模块」），仍须对应文中已有结构，不新增技术事实。合并/纠正迭代若再次交付定稿，仍须附带同类引导（可缩短，但须保留「第五章」「新时间戳」「iteration_context + merger」三要素之一或等效说明）。

七、禁止事项与例外

iteration_context.md的「禁止」章节是整个迭代契约的底线：

• 禁止：已判定为迭代意图时，不经合并/纠正流程、不把结果写入新时间戳文件，却去跑全文专利点挖掘或仅输出分析段落；
• 例外：用户明确要求「重新挖掘专利点 / 从头再走查新」时，可走主流程 Step 3 起。

这条规则在merger.md与correction_handler.md的执行门禁中被各自复述强化：「在已判定为『在已有稿上迭代』时，去跑 Step 3–4 专利点全文分析、或仅泛泛『更新专利分析』而未把合并结果写入用户案件目录下的新带时间戳文件」一律禁止，除非用户明确要求重新挖掘/重写专利点。

八、总结：迭代即增量、落盘即留痕

iteration_context.md以极简篇幅确立了交底书迭代的三条核心纪律，与仓库配套模板、脚本共同构成完整闭环：

1. 意图优先：先读本文判定迭代意图与模板（merger / correction），不重跑主流程；
2. 非破坏性落盘：一切交付都写{案件名}_{YYYYMMDDHHmmss}.md+ 同名.docx，旧稿保留，多时间戳文件即版本历史；实用/外观同步重评figure_plan.yaml；
3. 强制留痕：每轮迭代必须在交底书修订对话记录.md追加一条含「时间（本地+UTC）、类型、用户说明、交付文件、摘要摘录」的记录，并推荐用iteration_dialog_log.py自动生成；回复中必须输出「合并摘要（留档）」或「纠正摘要（留档）」，定稿还须附 §7.6 的权利要求偏向点交互。

对任何使用patent-disclosure-skill在已有交底书上继续打磨的开发者或 Agent 而言，这份迭代上下文不仅是流程文档，更是保证「多轮对话修改可追溯、不覆盖、不跑偏」的操作契约——读懂它，就能让交底书的每次修订都干净、可控、可审计。

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