Patent Disclosure Builder

专利交底书生成助手（对话式引导）

用途

帮不熟悉专利撰写的发明人本人，通过对话式一问一答，把脑子里的技术方案系统地整理成一份结构规范、内容完整的专利交底书。产出物可直接交给执业专利代理人进入正式撰写，也可先用 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 截图、手绘拍照、白板照片等。

处理步骤：

1. 提取文本/内容（不要重造轮子，调用工作区现成能力）：
   • 首选 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 流）。
2. 归位预填：把提取出的信息按官方模板章节归入 disclosure_template.md 对应位置（发明点、背景、方案 3.1/3.2、有益效果、实施例参数、替代方案、术语……）。素材里已有的架构图/流程图/UI 图直接留用，保存到内容 JSON 同目录（如 figs/），后续用 [[IMG]] 插入。
3. 反向补问（衔接第 1 步）：对照模板列出"素材已覆盖 / 仍空缺 / 需确认"三类；进入阶段 A~H 时，素材已答清楚的只做一句确认或直接跳过，只深问缺口，不重复问已知信息。

• 消化纪律（务必遵守）：
  • 忠实来源、不臆造：素材没写的技术细节不脑补；基于素材的归纳/推断标注"（据素材理解，需你确认）"请发明人核对，区分"素材事实"与"我的推断"。
  • 新颖性预警：若素材是已发表论文、已上线产品文档、已对外 PPT/投标书等，立即提示可能构成现有技术的新颖性风险，并在阶段 H 重点确认公开时间与范围。
  • 区别点不豁免：素材通常只把方案讲清楚，很少写清"与现有技术的区别点"，故阶段 D 的区别点深挖仍须完整执行，一步不省。

第 1 步：按阶段对话引导（核心）

严格参照 references/interview_playbook.md 的追问链推进，顺序为：

若已走过第 0.5 步（消化过素材），则以"预填 + 确认 + 补缺"方式推进：素材已讲清的阶段只做一句复述确认，把追问火力集中在素材未覆盖或含糊之处；阶段 D 区别点深挖不因有素材而豁免。

1. 阶段 A 破冰 + 抓住发明核心（先让发明人放松地讲清"这是干嘛的"）
2. 阶段 B 背景与痛点 → 锁定"要解决的技术问题"
3. 阶段 C 把技术方案一步步讲清楚
4. 阶段 D 挖区别技术特征（最关键，必须追到底）
   • 软件/算法/AI 类发明：D 之后、E 之前必须执行"客体/技术性自查"三问（技术问题—技术手段—技术效果），把方案从"纯规则"锚定到技术方案，详见 interview_playbook.md。有客体风险须如实提示，不替发明人硬凑技术性。
5. 阶段 E 有益效果 + "改动→效果"因果链
6. 阶段 F 具体实施例、参数、数值
7. 阶段 G 替代方案 + 上位概括 + 扩展场景（发明人常想不到，主动引导）
8. 阶段 H 附图（主动收图，不只是问）+ 公开情况（新颖性风险）+ 收尾补充
   • 交底书极度依赖图文结合。此阶段要主动请发明人把图发过来（系统架构图、方法流程图、时序图、UI 交互图、装置结构图等），来源不限：现成截图、PPT 导出、手绘拍照都行。
   • 对每张图问清"这是什么图、应该放在哪一章（一般架构/流程/时序放 3.2 技术侧，UI 交互放 3.1 产品侧）、一句话图注"。
   • 发明人给不出图、或图不清晰/不规范时，主动提出"我按你讲的方案先画一张示意图，你看着改"——用 scripts/gen_diagram.py 依据方案生成架构图/流程图草图（详见第 4 步）。生成的图属🤖 AI 依口述整理的示意图，须让发明人核对，图注注明"（示意图，供核对）"，绝不臆造未提及的模块/步骤。发明人明确表示自己补图的，才标注"（此处待补：xxx图）"。

对话纪律（务必遵守）：

• 每问完一段，先复述确认发明人的意思，再进入下一阶段，防止理解偏差。
• 发明人答不上来时，给脚手架、举例子，而不是反复追问同一句。
• 需要用到专利术语时，用 references/patent_concepts.md 里的"大白话解释"顺带说明一句。
• 分领域的专项追问（数据流/连接关系/电路/信令等），在阶段 C/D 按识别到的领域从 playbook 叠加。

第 2 步：随时可暂停与续接

• 发明人可能分多次完成。每轮结束时，简要小结"已经填好哪些、还差哪些"，并把当前进度落进模板，方便下次继续。
• 允许发明人跳着答；助手负责记住哪些 【待填】 还空着，最后统一回补。

第 3 步：整合成交底书并自检

对话阶段 → 官方模板章节的映射（把各阶段问到的料，填进对应章节）：

所有关键项问完后：

1. 把对话内容整理进模板的各章节，语言从口语转为清晰的书面技术描述（忠实于发明人原意，不臆造技术细节）。
2. 删除模板中的 💡 提示和残余 【待填】；若仍有未答项，明确列出"以下几处仍需你补充"，不要自行编造。
3. 做一次完整性自检（对照 references/patent_concepts.md 的"常见误区"）：
   • 技术问题是否具体、是技术层面？
   • 区别技术特征是否逐条讲清、而非只描述好产品？
   • 有益效果是否量化、是否能对应到某个改动？
   • 是否有至少一个可落地实施例 + 参数范围？
   • 替代方案/上位概括是否补充，以利扩大保护范围？
   • 是否问清对外公开情况（新颖性风险）？
   • 附图需求是否列出？
   • （软件/算法类）是否已完成客体自查、并在方案中写清"技术问题—技术手段—技术效果"？有风险是否已提示？

第 4 步：交付（默认输出 Word，套用官方模板）

• 默认交付 Word（.docx）交底书，章节结构与文案严格对齐官方《发明专利交底书模板 2026VT1.0》（assets/官方交底书模板_2026VT1.0.doc）。 ⚠️ 注意：本 skill 的交付默认与 Timson 的"全局默认只交 md"偏好相反——发明人交底书场景是 Timson 明确要求的例外，默认转 Word，不影响其他任务。
• 章节顺序（务必与官方模板一致）：
  1. 抬头信息表（交底书名称 / 发明人 / 撰写人 / 所在部门 / 涉及产品和技术 / 竞争对手产品 / 紧急联络方式）
  2. 【关键术语】表
  3. 1、发明点概述
  4. 2、【背景技术】（2.1 现有技术方案 / 2.2 缺点及要解决的问题）
  5. 3、【发明内容】（3.1 产品侧 / 3.2 技术侧）
  6. 4、技术方案所产生的有益效果
  7. 5、发散思维：替代方案
  8. 6、参考文献
• 生成步骤：
  1. 先按第 3 步把内容整理进结构、完成自检（先落一份 .md 便于逐段核对）。
  2. 用 scripts/build_docx.py 生成 .docx：该脚本用 python-docx 按官方模板的章节标题、顺序与表格重建文档并填入内容。运行环境用 /Users/zhangtianxiang/.workbuddy/binaries/python/envs/default/bin/python（若缺 python-docx 先 pip install python-docx）。
     • 用法：准备一份填好的内容 JSON（结构见脚本头部注释），执行 python scripts/build_docx.py 内容.json 输出.docx。
  3. 若模板缺少某内容项（如"上位概括"没有独立章节），就近并入最贴近的章节（如并入"5、替代方案"）；不要新增官方模板没有的一级章节。
  4. 写入当前工作目录，用结果展示能力呈现 .docx。
• 插入附图（图文混排，符合官方模板要求）：把发明人提供的图片保存到与内容 JSON 同一目录（或子目录如 figs/），在对应章节字段的正文里，用 [[IMG:图片路径|图注]] 单独占一行来插图。例如在 发明内容_技术侧 里写：

  本系统整体架构如下图所示：
  [[IMG:figs/arch.png|系统整体架构图]]
  各模块的具体交互如下……
  

  • 路径相对内容 JSON 所在目录解析（也支持绝对路径）；脚本会自动等比缩放到正文宽度内、居中，并在图下方自动加"图N 图注"（N 全文自动累加编号，勿手写图号）。
  • 图片缺失时脚本插入红色"【缺图：路径】"提示且不中断，便于事后补图。
  • 不要再用"图X. 说明"这种纯文字占位——有真图就用 [[IMG]] 插入；确实还没有图，就在正文写明"（此处待补：xxx图）"。
• 发明人无图时自动生成示意图（兜底能力）：当发明人给不出图、或图不合格时，用 scripts/gen_diagram.py 依据方案生成示意图：
  1. 与发明人对齐要画的模块/步骤后，准备一份图描述 JSON（结构见脚本头部注释）：
     • 架构图 {"type":"arch","title":"...","nodes":[{"id","text","col","row","accent"}],"edges":[{"from","to","label"}]}（col 列/row 行定位；accent: blue/red/amber/green/gray，核心模块用 red、兜底用 amber）；
     • 流程图 {"type":"flow","title":"...","steps":[{"text","kind","accent","branch"}]}（kind: start/process/decision/end；decision 菱形可带 branch 支路说明）。
  2. 运行 python scripts/gen_diagram.py 图描述.json 输出.png 生成 PNG（150dpi、中文字体自适配、浅底深框），存到与内容 JSON 同目录（建议 figs/ 子目录）。
  3. 在对应章节正文用 [[IMG:figs/xxx.png|图注（示意图，供核对）]] 插入。
  4. 务必忠实于发明人讲过的内容：只画他提到的模块/步骤/连接关系，不新增、不臆造；生成后请发明人核对修改。
• 非强制章节：5、发散思维（替代方案） 与 6、参考文献 为非必填项——发明人未提供时，脚本自动填 "无"（黑色正文），不留红色"待补充"，也不要硬凑。其余带 * 的章节为必填，缺失才提示补。
• 文末反馈与联系区块（默认自动附加）：build_docx.py 会在正文末尾自动附上一个"反馈与联系"区块（分隔线 + 引导语 + 联系方式 + 署名），方便发明人拿到交底书后就疑问/建议直接联系维护者、形成反馈闭环。
  • 默认联系方式固化在脚本顶部 CONTACT_DEFAULT（署名 IP老张、微信 IPlaozhang、邮箱 45752733@qq.com）；在线反馈链接为可选项，填了才显示。
  • 二维码（多张并排）：默认内置两张码，图片放在 skill 自带的 assets/qr/ 目录（wechat_friend.jpg 加好友、reward.jpg 打赏码），脚本自动定位、以无边框表格横向并排展示、各带标题（图 3.6cm）。要换码只需替换 assets/qr/ 里的同名图片即可；如需增减码，改脚本顶部 CONTACT_DEFAULT["二维码列表"]。
  • 如需临时改联系方式，可在内容 JSON 里加 "联系方式": {...} 覆盖对应字段（如换微信、改 "二维码列表": [{"图片":"xxx.jpg","标题":"…"}]、加在线表单链接）；无需覆盖时不用管，走默认即可。
  • 如某次不想附加（如对外正式提交版），在内容 JSON 里加 "附加联系方式": false 即可关闭。
  • 长期改默认联系方式：直接改脚本顶部 CONTACT_DEFAULT 常量。
• 排版规范（已固化进脚本，保持协调统一，勿随意改动）：文档标题 黑体二号(22pt)；一级标题 黑体四号(14pt)；二级标题 黑体小四(12pt)；正文 宋体小四(12pt)、1.5 倍行距；表格 五号(10.5pt，表头黑体加粗)、列宽固定（抬头表 4+12cm、术语表 3.5+3.5+9cm）；页眉右侧固定显示"保护创新，积累资产"（黑体小五）。如需微调字号/字体，改 scripts/build_docx.py 顶部的 SZ_* 常量即可。
• 交付时附一句简短说明：建议交由执业专利代理人复核；如需先做质量审核，可用 patent-disclosure-review 技能。
• 若有仍需补充的项，在交付消息里清单式列出，方便发明人回头补。

资源清单