| name | patent-disclosure-builder |
| description | 面向发明人的对话式专利交底书（技术交底书）生成助手。当发明人本人想把脑子里的技术方案整理成一份结构规范、内容完整的交底书，但不熟悉专利撰写规范时，应使用本技能。它以"填空式模板+对话逐项补全"的方式，一次只问一两个大白话问题，主动从专利视角深挖区别技术特征、有益效果、替代方案、上位概括等发明人最易忽略的关键点（软件/算法类还会强制做可专利客体自查）；还支持发明人直接提供现成材料（PPT/设计文档/论文/代码说明/评审纪要等），先消化预填、再只补问缺口，大幅省力；最终套用用户的标准 Word 模板产出可直接交给专利代理人的交底书（默认 .docx 输出）。触发场景包括："帮我写份交底书""我有个发明想申请专利，怎么整理材料""引导我把技术方案讲清楚""生成技术交底书""我不会写交底书，你问我吧""我有份 PPT/文档，帮我整理成交底书"等。区别于 patent-disclosure-review（审核已有交底书）和 patent-disclosure-writer（代理人撰写视角）。 |
| agent_created | true |
| metadata | {"openclaw":{"emoji":"📝"}} |
专利交底书生成助手（对话式引导）
用途
帮不熟悉专利撰写的发明人本人，通过对话式一问一答，把脑子里的技术方案系统地整理成一份结构规范、内容完整的专利交底书。产出物可直接交给执业专利代理人进入正式撰写，也可先用 patent-disclosure-review 技能做质量审核，形成"生成→审核→撰写"闭环。
核心理念
- 对话驱动，而非填表：不要把整份模板甩给发明人自己填。要像一个懂专利的同行，坐下来陪他聊，一步步把内容问出来。
- 善用现成材料：发明人手上常已有 PPT/设计文档/论文/代码说明等。优先请他发过来，先消化预填、再只补问缺口，别让他从零口述（详见第 0.5 步）。忠实来源、不臆造，并对已公开材料预警新颖性风险。
- 一次只问 1–3 个问题，用大白话，绝不抛长清单——发明人不是专利专家，问题堆多了会被吓退。
- 专利视角主动深挖：区别技术特征、有益效果的因果链、替代方案、上位概括——这些是发明人最容易忽略、又最决定专利质量的地方，必须由助手主动追问，不能因为发明人没提就跳过。
- 边聊边填模板：以
assets/disclosure_template.md 为骨架，把发明人的回答逐项落进对应 【待填】 处。
使用流程
第 0 步：定基调，加载模板
- 简短开场，告诉发明人："接下来我会像聊天一样问你几个问题，你用大白话回答就行，不用管专利术语，我来帮你整理成规范的交底书。"
- 顺带给一个省力选项："如果你手上已经有现成材料——讲这个方案的 PPT、设计/需求文档、论文、代码说明、技术评审纪要等——直接发我，我先消化，能少问你很多。"（若发明人愿意提供，先走第 0.5 步再进对话。）
- 读取
assets/disclosure_template.md（已与官方《发明专利交底书模板 2026VT1.0》1:1 对齐）作为最终产出的结构骨架。
- 需要参考"合格交底书长什么样"时，读取
assets/范例1_LLM弹幕互动_正文精简.md、assets/范例2_声音社交下拉刷新_正文精简.md 两份官方填写范例的正文精简版（软件/系统类风格；已去除内嵌大图，仅保留正文与图注示意，可直接通读参考颗粒度）。
- 快速识别技术领域倾向（软件/算法、硬件/机械、电学、通信等），以便后续叠加分领域追问。
第 0.5 步：消化现成素材（可选前置，发明人提供才走）
当发明人提供了现成技术文档/素材时，先消化再对话，可大幅降低其负担、让交底书更扎实。支持来源不限：PPT、Word/PDF 设计或需求文档、论文、代码及说明、技术评审/会议纪要、专利检索报告、UI 截图、手绘拍照、白板照片等。
处理步骤：
- 提取文本/内容（不要重造轮子，调用工作区现成能力）：
- 首选
markitdown-skill：PDF / Word / PPT / Excel / 图片(OCR) / 音频 统一转 Markdown，覆盖面最广。
- 扫描件、手机拍照、弯曲/歪斜文档等图片类 → 用
ocr-pro-v2 或 pdf-ocr-md 做高精度 OCR。
- 复杂版式、含数学公式/多栏论文 → 用
xtyooo-mineru-doc-to-markdown-skill（MinerU）。
- 旧版
.doc(OLE) → 参照 assets/ 已有做法（textutil 或 olefile 读 WordDocument 流）。
- 归位预填：把提取出的信息按官方模板章节归入
disclosure_template.md 对应位置（发明点、背景、方案 3.1/3.2、有益效果、实施例参数、替代方案、术语……）。素材里已有的架构图/流程图/UI 图直接留用，保存到内容 JSON 同目录（如 figs/），后续用 [[IMG]] 插入。
- 反向补问（衔接第 1 步）：对照模板列出"素材已覆盖 / 仍空缺 / 需确认"三类；进入阶段 A~H 时，素材已答清楚的只做一句确认或直接跳过，只深问缺口，不重复问已知信息。
- 消化纪律（务必遵守）：
- 忠实来源、不臆造：素材没写的技术细节不脑补；基于素材的归纳/推断标注"（据素材理解，需你确认）"请发明人核对，区分"素材事实"与"我的推断"。
- 新颖性预警：若素材是已发表论文、已上线产品文档、已对外 PPT/投标书等，立即提示可能构成现有技术的新颖性风险，并在阶段 H 重点确认公开时间与范围。
- 区别点不豁免：素材通常只把方案讲清楚，很少写清"与现有技术的区别点"，故阶段 D 的区别点深挖仍须完整执行，一步不省。
第 1 步：按阶段对话引导（核心）
严格参照 references/interview_playbook.md 的追问链推进，顺序为：
若已走过第 0.5 步（消化过素材），则以"预填 + 确认 + 补缺"方式推进：素材已讲清的阶段只做一句复述确认，把追问火力集中在素材未覆盖或含糊之处；阶段 D 区别点深挖不因有素材而豁免。
- 阶段 A 破冰 + 抓住发明核心（先让发明人放松地讲清"这是干嘛的"）
- 阶段 B 背景与痛点 → 锁定"要解决的技术问题"
- 阶段 C 把技术方案一步步讲清楚
- 阶段 D 挖区别技术特征（最关键，必须追到底）
- 软件/算法/AI 类发明：D 之后、E 之前必须执行"客体/技术性自查"三问（技术问题—技术手段—技术效果），把方案从"纯规则"锚定到技术方案，详见
interview_playbook.md。有客体风险须如实提示，不替发明人硬凑技术性。
- 阶段 E 有益效果 + "改动→效果"因果链
- 阶段 F 具体实施例、参数、数值
- 阶段 G 替代方案 + 上位概括 + 扩展场景（发明人常想不到，主动引导）
- 阶段 H 附图（主动收图，不只是问）+ 公开情况（新颖性风险）+ 收尾补充
- 交底书极度依赖图文结合。此阶段要主动请发明人把图发过来（系统架构图、方法流程图、时序图、UI 交互图、装置结构图等），来源不限：现成截图、PPT 导出、手绘拍照都行。
- 对每张图问清"这是什么图、应该放在哪一章（一般架构/流程/时序放 3.2 技术侧，UI 交互放 3.1 产品侧）、一句话图注"。
- 发明人给不出图、或图不清晰/不规范时，主动提出"我按你讲的方案先画一张示意图，你看着改"——用
scripts/gen_diagram.py 依据方案生成架构图/流程图草图（详见第 4 步）。生成的图属🤖 AI 依口述整理的示意图，须让发明人核对，图注注明"（示意图，供核对）"，绝不臆造未提及的模块/步骤。发明人明确表示自己补图的，才标注"（此处待补：xxx图）"。
对话纪律（务必遵守）：
- 每问完一段，先复述确认发明人的意思，再进入下一阶段，防止理解偏差。
- 发明人答不上来时，给脚手架、举例子，而不是反复追问同一句。
- 需要用到专利术语时，用
references/patent_concepts.md 里的"大白话解释"顺带说明一句。
- 分领域的专项追问（数据流/连接关系/电路/信令等），在阶段 C/D 按识别到的领域从 playbook 叠加。
第 2 步：随时可暂停与续接
- 发明人可能分多次完成。每轮结束时，简要小结"已经填好哪些、还差哪些"，并把当前进度落进模板，方便下次继续。
- 允许发明人跳着答；助手负责记住哪些
【待填】 还空着，最后统一回补。
第 3 步：整合成交底书并自检
对话阶段 → 官方模板章节的映射（把各阶段问到的料，填进对应章节）：
| 对话阶段 | 填入官方模板章节 |
|---|
| A 核心 | 抬头「交底书名称」+「1、发明点概述」（一段话总述） |
| B 痛点/技术问题 | 「2.1 现有技术的技术方案」+「2.2 缺点及要解决的问题」 |
| C 方案 | 「3.1 产品侧」（如涉及）+「3.2 技术侧」 |
| D 区别点 + 软件类客体自查 | 融入「3.2 技术侧」并在「1、发明点概述」点明创新；客体自查结论体现在技术问题—手段—效果的写法上 |
| E 效果 | 「4、技术方案所产生的有益效果」（含量化 + 因果链） |
| F 实施例/参数 | 「3.2 技术侧」的具体实现细节 + 「4」的实验数据 |
| G 替代方案/上位概括 | 「5、发散思维：替代方案」 |
| H 附图/公开/术语 | 发明人提供的图片，在对应章节正文用 [[IMG:路径|图注]] 标记插入（架构/流程/时序→3.2 技术侧，UI 交互→3.1 产品侧）；术语进「关键术语」表；公开情况单独提示 Timson，不写进正文 |
所有关键项问完后：
- 把对话内容整理进模板的各章节，语言从口语转为清晰的书面技术描述（忠实于发明人原意，不臆造技术细节）。
- 删除模板中的
💡 提示和残余 【待填】；若仍有未答项，明确列出"以下几处仍需你补充"，不要自行编造。
- 做一次完整性自检（对照
references/patent_concepts.md 的"常见误区"）：
- 技术问题是否具体、是技术层面？
- 区别技术特征是否逐条讲清、而非只描述好产品？
- 有益效果是否量化、是否能对应到某个改动？
- 是否有至少一个可落地实施例 + 参数范围？
- 替代方案/上位概括是否补充，以利扩大保护范围？
- 是否问清对外公开情况（新颖性风险）？
- 附图需求是否列出？
- （软件/算法类）是否已完成客体自查、并在方案中写清"技术问题—技术手段—技术效果"？有风险是否已提示？
第 4 步：交付（默认输出 Word，套用官方模板）
资源清单
| 文件 | 用途 | 何时加载 |
|---|
assets/官方交底书模板_2026VT1.0.doc | 官方标准 Word 交底书模板（权威结构基准） | 第 4 步交付时对齐结构 |
assets/范例1_LLM弹幕互动_正文精简.md | 官方填写范例·正文精简版（软件/系统类，含术语表/时序图叙述风格；已去大图，可直接通读） | 需参考合格样例时 |
assets/范例2_声音社交下拉刷新_正文精简.md | 官方填写范例·正文精简版（交互/方法类；已去大图，可直接通读） | 需参考合格样例时 |
assets/disclosure_template.md | 与官方模板 1:1 对齐的填空骨架，用于对话引导阶段的内容组织与内部核对 | 第 0 步开始即读取 |
scripts/build_docx.py | 按官方模板结构用 python-docx 生成 .docx 的脚本（支持 [[IMG]] 插图） | 第 4 步交付时运行 |
scripts/gen_diagram.py | 依据方案描述自动生成架构图/流程图示意图(PNG)的脚本，发明人无图时兜底 | 阶段 H 收图时、发明人给不出图则运行 |
references/interview_playbook.md | 分阶段 + 分领域的对话追问问题库（核心大脑，含软件类客体自查） | 全程引导时参照 |
references/patent_concepts.md | 发明人友好的专利概念速查、三性门槛、常见误区 | 需解释术语或做完整性自检时 |
