# Patent Disclosure Builder

> 面向发明人的对话式专利交底书（技术交底书）生成助手。当发明人本人想把脑子里的技术方案整理成一份结构规范、内容完整的交底书，但不熟悉专利撰写规范时，应使用本技能。它以"填空式模板+对话逐项补全"的方式，一次只问一两个大白话问题，主动从专利视角深挖区别技术特征、有益效果、替代方案、上位概括等发明人最易忽略的关键点（软件/算法类还会强制做可专利客体自查）；还支持发明人直接提供现成材料（PPT/设计文档/论文/代码说明/评审纪要等），先消化预填、再只补问缺口，大幅省力；最终套用用户的标准 Word 模板产出可直接交给专利代理人的交底书（默认 .docx 输出）。触发场景包括："帮我写份交底书""我有个发明想申请专利，怎么整理材料""引导我把技术方案讲清楚""生成技术交底书""我不会写交底书，你问我吧""我有份 PPT/文档，帮我整理成交底书"等。区别于 patent-disclosure-review（审核已有交底书）和 patent-disclosure-writer（代理人撰写视角）。

- Skill: `cslawyer1985/patent-disclosure-builder` (Agent Skill, multi-file: 9 files)
- Install (CLI): `npx skillmds@latest add cslawyer1985/patent-disclosure-builder`
- Raw SKILL.md: https://api.skillmd.com/api/skills/cslawyer1985/patent-disclosure-builder/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: cslawyer1985 (https://skillmd.com/u/cslawyer1985)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/cslawyer1985/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 步：整合成交底书并自检

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

| 对话阶段 | 填入官方模板章节 |
|----------|------------------|
| 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，不写进正文 |

所有关键项问完后：
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` 技能。
- 若有仍需补充的项，在交付消息里清单式列出，方便发明人回头补。

## 资源清单

| 文件 | 用途 | 何时加载 |
|------|------|----------|
| `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` | 发明人友好的专利概念速查、三性门槛、常见误区 | 需解释术语或做完整性自检时 |