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.md指出错误、与事实/参数不符、风格或保护点调整correction_handler.md用户已按disclosure_builder.md§7.6 声明侧重点仅需第五章权利要求书式强化取向须与本稿已有材料及第五、三章已写观点一致禁止为交互而编造新场景merger.md以最近定稿为基准合并范围以第五章为主必要时微调第四章与第五章衔接句值得注意第三行即便用户没有「新增材料」只是希望第五章「技术关键点和欲保护点」更贴近权利要求书撰写习惯也走merger而非 correction。这是因为发明 builder 的 §7.6disclosure_builder.md在每次定稿交付时都会附带「权利要求偏向点」建议交互用户回应这一交互后后续强化请求天然属于「在定稿上做增量合并」——且合并范围被严格限定以第五章为主必要时只微调第四章与第五章的衔接句其他章节以保持既有结论为前提禁止为凑交互而编造本稿没有的新场景、模块或行业词。三、迭代的输入与输出以「新时间戳文件」为铁律3.1 输入清单开始迭代前Agent 需要收集三类输入对话中的本轮说明用户本次的意图、要点以及用户的文件或粘贴片段基准稿Read当前作为基准的交底书.md路径由用户给出或已在对话中出现附图与主题实用新型 / 外观专用迭代涉及附图或主题时必处理案件目录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_typeutility_model|design、theme_summary当前交底主题一句话主题变了必须重评清单每条figures[]fig正文「如图 N」编号不入文则为null、roleassembly总装 /detail局部 /ortho正交 /perspective立体 /reference参考 /rejected不入文、path、covers实用新型对应parts.id外观对应views.name、kindlineart/cad/photo_clean/photo_scene/other、score0–100同批内越高越优先入文、use_in_disclosure、reason、relates_torelates_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/cadassembly或关键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参数调用脚本改名。每条记录必须包含五项要素记录时间本地时间与UTC脚本自动生成手工追加时两者都要写类型合并迭代 / 纠正迭代用户说明摘要本轮用户意图、要点可含 文件名称本轮交付文件新时间戳.md、.docx文件名合并/纠正摘要摘录与当轮对话中「合并摘要留档」「纠正摘要留档」一致或为其缩写。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...ZUTC的小节若日志文件已存在则在文末追加并保证换行衔接不存在则先写入固定文件头注明由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_planRead基准稿与本轮补充材料实用/外观若改图或主题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 出图与 .docxWrite新时间戳.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: ok1、MATH:为准stderr 输出不等于失败。第 5 步追加修订对话记录按第四章用iteration_dialog_log.py--kind merge/correct或手工方式追加交底书修订对话记录.md。第 6 步回复中写明路径并输出留档摘要在回复中写明新文件路径并输出对应模板要求的「合并摘要留档」或「纠正摘要留档」含 figure_plan 是否同步若有 CAD 提示须写在回复末尾。六、合并与纠正的分工merger vs correction_handleriteration_context.md将「合并」与「纠正」定义为两种互补的迭代模式二者的核心区别在 merger.md 末尾一句话点明merger侧重新材料、新功能的扩展correction_handler侧重用户指出错误、风格或与事实不符的修正。6.1 merger增量合并修订与补充启用条件在已有交底书或上一轮输出上补充新材料新文档、新代码说明、粘贴片段、扩展章节等且以合并进现有结构为主或按 §7.6 仅要求第五章权利要求书式强化。不要求用户说出「迭代」等固定词也不必先询问是否进入迭代模式。其流程七步识别增量新内容主要影响哪些章节背景、1.1 现有技术、3.4 流程、实施例等实用/外观还须判断是否影响附图主题或材料集非破坏性合并以追加或局部重写为主不推翻未涉及且用户未要求修改的章节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.pySTEP 须用户确认后再step_to_views查新联动若增量改变技术实质判断是否需要补充检索并更新 1.1 / 区别论述一致性执行disclosure_self_check.md的 8.2、8.3实用/外观含 8.4/8.5 与 figure_plan 项快速检查涉及公式/参数则同步核对formula_plan.yaml与 §7.7落盘写入{案件名}_{YYYYMMDDHHmmss}.md并经mermaid_render.py生成同名.docx对话记录按本文档在案件目录追加交底书修订对话记录.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 补充「权利要求偏向点」建议交互合并可缩写纠正可 12 句缩写版不得写入交底书正文。§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以极简篇幅确立了交底书迭代的三条核心纪律与仓库配套模板、脚本共同构成完整闭环意图优先先读本文判定迭代意图与模板merger / correction不重跑主流程非破坏性落盘一切交付都写{案件名}_{YYYYMMDDHHmmss}.md 同名.docx旧稿保留多时间戳文件即版本历史实用/外观同步重评figure_plan.yaml强制留痕每轮迭代必须在交底书修订对话记录.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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
