---
name: patent
description: 撰写中国发明专利技术交底书 (供专利代理师转写为申请文件)。当用户要写交底书、挖专利点、做现有技术检索、把项目材料/代码/论文整理成可申报的发明专利材料时使用。
---

# Patent (交底书)

把项目素材变成可交给专利代理师的**技术交底书** .docx。**先挖专利点 → 检索现有技术 → 八条对齐 spec → 逐章起草 → 验收渲染** —— 不要一口气出全文。

## 资源

下面所有路径都相对 **`<skill_dir>`** —— `load_skill` 返回头里的 `[skill=patent, dir=<绝对路径>]`,用这个绝对路径拼脚本/资源,不要假设 cwd。

- `<skill_dir>/references/disclosure_structure.md` —— 交底书 7 章骨架 + 字数预算 + 必填要素 (always read)
- `<skill_dir>/references/patent_point_taxonomy.md` —— 专利点分类(方法/装置/系统/介质)+ 三性自检(新颖/创造/实用)+ 客体排除清单
- `<skill_dir>/references/prior_art_search.md` —— 检索关键词构造 + 数据源优先级 + 区别技术特征写法
- `<skill_dir>/references/self_check.md` —— 渲染前自查清单(参数/公式一致、逻辑闭环、脱敏、附图)
- `<skill_dir>/templates/spec.md` —— task 级"宪法"模板(案件名 / 技术领域 / 创新点清单 / 检索结论 / 脱敏边界 / 附图清单)
- `<skill_dir>/templates/disclosure.md` —— 交底书 7 章 Markdown 模板,阶段四照抄
- **渲染复用平台层 + proposal 图脚本**:docx 调 `rendering/render.py --profile proposal`(见下);mermaid 图仍用 `skills/proposal/scripts/render_diagrams.py` 预渲染 `figures/fig_<caption>.png` —— 同样的 markdown + ```mermaid``` + `%% caption:` 约定,不另写

## 阶段零: 摄取素材 (有 PDF/DOCX/PPTX/XLSX/URL 时才走)

用户给项目文档 / 代码截图 / 论文 PDF / 设计方案 PPT → 用 `markitdown` CLI 统一转 md 落到 `<task_dir>/source/<name>.md`,后续阶段直接 read:

```bash
markitdown <path>/方案.docx     -o <task_dir>/source/方案.md
markitdown <path>/汇报.pptx     -o <task_dir>/source/汇报.md
markitdown <path>/论文.pdf      -o <task_dir>/source/论文.md
markitdown https://example.com/ -o <task_dir>/source/外部.md
```

代码仓库 / 单文件代码 → 直接 `read`,关键算法在哪个函数、参数怎么传、跟现有方案差异在哪 —— 边读边记到 spec 草稿里。

## 阶段一: 专利点挖掘与筛选

产物:**候选专利点清单**(写到 spec §3,先粗筛,再细化)。不要直接进章节起草 —— 一份交底书原则上对应 **1 个发明专利**(独立权利要求一项),先把"这次到底要保哪一个"定下来。

1. **读 `<skill_dir>/references/patent_point_taxonomy.md`** —— 先建立分类与三性自检的判断框架
2. **从素材里抓 candidates**:列 3-8 个"看起来可专利"的技术点,每条按下表填:

   | 候选 | 解决的技术问题 | 关键技术手段 (≥1 个区别于现有的步骤/结构) | 客体类型 (方法/装置/系统/介质) | 三性初判 (新/创/实) |
   |---|---|---|---|---|
   | 1 | ... | ... | ... | ... |

3. **合并/淘汰**:语义重复的合并;纯商业方法 / 智力活动规则 / 数学算法本身 / 单纯展示信息 → 按 taxonomy §客体排除清单淘汰
4. **推荐 1-2 个主推点**,说明理由,⛔ **BLOCKING:等用户选定后才进阶段二**

> **小心 ≠ 创新点不等于专利点**。"用了 LLM 做摘要"不是专利点(已是通用范式);"针对 X 场景设计的 Y 步骤组合 + Z 阈值"才可能是。

## 阶段二: 现有技术检索

产物:**检索报告**(写到 spec §4)。**没有检索就直接写交底书是评审/审查员视角的重大风险** —— 同一发明被检出会导致驳回。

1. **读 `<skill_dir>/references/prior_art_search.md`** —— 拿关键词构造法 + 数据源优先级
2. **构造检索式**:中文术语 + 英文术语(领域里通行那个)+ 同义/近义词 + 用途词;3-5 组检索式
3. **执行检索**(优先级从高到低):
   - **`web_search`** —— 优先搜中国专利文库 / Google Patents / 期刊综述。query 里带 `site:patents.google.com` / `专利` / `CN10` 等限定符可显著提升信号
   - **`web_fetch`** —— 命中的关键专利/论文页拉全文摘要
   - **`documents` skill** —— 本地材料学科库(7 个学科共 100W+ 论文)如果命中
   - **`research` skill** —— OpenAlex 学术文献库,找综述与对比方案
4. **每条命中归档** (写到 spec §4):
   - 公开号 / 标题 / 申请人 / 公开日 (专利) 或 DOI / 作者 / 期刊 / 年 (论文)
   - 一句话概括其技术方案
   - **与本发明的区别**(这条最关键 —— 写交底书时"区别技术特征"段直接复用)
5. **判定**:
   - 命中高度近似 (技术问题 + 关键手段都重合) → ⛔ **BLOCKING 告诉用户"已有 XX 在先,建议改方案 / 换创新点 / 放弃"**,等用户决策
   - 命中部分相关 → 记录,作为本发明"区别技术特征"对照
   - 无相关命中 → 检索式可能太窄,再换 1-2 组关键词验证;仍无 → 标记"未检出近似",进阶段三
6. ⛔ **BLOCKING:把检索结论给用户确认后才进阶段三**

> **不要编公开号 / DOI / 作者**。检不到就说"未检出近似",不要靠训练数据脑补一个 `CN112345678A`。

## 阶段三: 八条对齐 (spec)

产物:**task 级 spec 文件**(交底书"宪法",阶段四每章前都要重读)。文件路径按 system prompt 的《task 级「宪法」文件命名约定》:

    <task_dir>/<today>-<task_short_id>-<task_name>.spec.md

`<today>` / `<task_short_id>` / `<task_name>` 用 system prompt 注入的实际值替换。

**0. 先检测已有 spec**:

```
glob <task_dir>/*-<task_short_id>-*.spec.md → 按文件名字典序排,取最大者作 current
```

- 若已有 current → 展示给用户,问「**沿用进阶段四** / **重定调**(以 today 为前缀写新版,旧版保留)」,⛔ BLOCKING 等用户决定
- 仅有其它 task 的(`*-<别的 short_id>-*.spec.md`)→ 不当 current 用,继续走下面
- 完全没有 → 直接走下面

1. **复制模板**: `read <skill_dir>/templates/spec.md` → `write <task_dir>/<today>-<task_short_id>-<task_name>.spec.md`
2. **按字段填**(阶段一二的产物直接抄进去):案件名 / 发明名称 / 技术领域 / 主推专利点 / 检索结论 / 脱敏边界 / 附图清单 / 发明人清单 / TODO
3. 给用户预览
4. ⛔ **BLOCKING:用户确认后才进阶段四**

字段清单见 `<skill_dir>/templates/spec.md`。

## 阶段四: 逐章起草

每章两段式:**先列要点 → 用户确认 → 再起草 → 用户确认**。不要直接出正文。

读 `<skill_dir>/references/disclosure_structure.md` 拿 7 章骨架(技术领域 / 背景技术 / 发明内容 / 附图说明 / 具体实施方式 / 有益效果 / 权利要求建议),每章对应字数预算。

**A. 起草前列要点**:
1. 读 **current spec** 与 `<skill_dir>/references/disclosure_structure.md`
2. 列 3-6 条要点骨架:本章覆盖的论点 / 关键参数 / 公式 / 附图,每条贴上对齐的检索结论与预估字数
3. ⛔ **BLOCKING:用户确认要点后才动正文**

**B. 正文起草**:
4. 从 `<skill_dir>/templates/disclosure.md` 复制对应小节到 `<task_dir>/sections/NN_xxx.md`(章节命名见 §章节骨架速查)
5. **关键章节一段一卡** —— 背景技术(必须含"现有技术 1/2/3 + 缺陷")/ 发明内容(技术问题 / 技术方案 / 有益效果 三段)/ 具体实施方式(嵌入实施例): 写一段 → 报字数 + **预告下一段** → 等用户确认 → 写下一段
   普通章节一节一卡: 整节写完再报 + **预告下一节要点**
6. 报告格式 (每次卡点都按这个出):
   - **本段 (节)**: 章节名 / 实际字数 / 字数预算 / 与检索结论对齐情况(引用了哪几条现有技术作对比)
   - **下一段 (节) 预告**: 标题 + 3-5 条要点骨架;若已是本章最后一段,改预告**下一章**首段要点
   - 提问: "本段可以了吗?下一段要点要改 / 加 / 删什么?"
7. ⛔ **BLOCKING:停下来等用户明确反馈** ("OK"、"下一段"、"继续") 后才动笔。"看起来不错"、沉默、追问都不算确认 —— 用户对下一段要点没异议也算默认通过,但**关键参数 / 公式 / 区别技术特征异常**时必须主动追问
8. 用户确认了**实质改动**(改写区别技术特征 / 调关键参数 / 换实施例 / 增删章节)后,追加一行到 `<task_dir>/REVISIONS.md` —— 见 §修订日志

**例外**: 用户**主动且明确**说"别问,直接全做"或"一气呵成" —— 才能一次跑完,跑完必须按阶段五自查。

## 阶段五: 自查 + 渲染

```bash
# 1. 自查 (按 self_check.md 清单逐条核 — 这一步无脚本,模型逐条对照)
read <skill_dir>/references/self_check.md
# 模型按清单 6 类逐项过一遍 sections/*.md, 不过则回头 edit

# 2. mermaid 附图预渲染 (章节有 ```mermaid``` 块就跑)
python <skill_dir>/../proposal/scripts/render_diagrams.py <task_dir>/sections/

# 3. 渲染 .docx (调平台渲染层,复用 proposal profile)
python /sandbox/rendering/render.py --profile proposal --format docx <task_dir>/sections/ --fund-type key_rd -o <task_dir>/<案件名>_技术交底书.docx
```

> `render_docx.py` 的 `--fund-type` 只影响目录页表头文案与封面,不影响章节解析 —— 交底书复用 `key_rd` 排版规范(国标黑体/宋体/1.5 倍行距)。封面页用户拿到后手动改成"技术交底书"标题,或在 sections/00_封面.md 自定义。

复用的 proposal 脚本是 patent 的**兄弟 skill**,用 `<skill_dir>/../proposal/scripts/...` 定位(`<skill_dir>` = load_skill 头部给的本 skill 绝对目录,host 下是宿主路径、docker 沙盒里是 `/sandbox/skills/patent`,`../proposal` 在两种后端都落到同级 proposal 目录)。**不要**拼 repo 根的宿主绝对路径 —— docker 容器里看不到宿主路径。

## 工作目录

`<task_dir>` = system prompt 给的**绝对路径**(host 下形如 `…/workspace/users/<uid>/<wd>/`,docker 沙盒里是 `/workspace/<wd>/`)。**所有产物都写到 task_dir 下**,不要写到 cwd / `skills/` / repo 根。

```
<task_dir>/
├── source/                                  # markitdown 转出的素材(同 working_dir 多 task 共享)
├── <today>-<task_short_id>-<task_name>.spec.md  # 阶段三定调,task 级宪法;命名见 system prompt 约定;按 short_id 主锚,重定调时写新日期,旧版保留
├── sections/                                # 阶段四逐章产物(按章节模板切的小节)
├── figures/                                 # mermaid 预渲染 PNG (由 render_diagrams.py 生成)
├── REVISIONS.md                             # 修订日志:每次卡点用户确认的实质改动,见 §修订日志
└── <案件名>_技术交底书.docx                  # 最终产物 (按案件名命名,不要 output.docx)
```

## 修订日志 (REVISIONS.md)

`<task_dir>/REVISIONS.md` 是产物迭代过程的紧凑可读 changelog。**spec 是宪法(定调一次),REVISIONS 是实施日志(每次卡点累加)** —— 两份独立但互参,后期 review / 复盘 / 跨周回看"上周这节为啥改成这样"靠这份。

### 何时记 / 何时不记

| 情形 | 记? |
|---|---|
| 用户确认改写**关键参数 / 公式 / 区别技术特征** | ✅ 必记 |
| 用户确认换 / 增 / 删**实施例**或**章节** | ✅ 必记 |
| 用户对要点骨架的主动修改(改 / 加 / 删) | ✅ 必记 |
| 自查阶段发现术语 / 参数不一致后的统一改 | ✅ 必记(说明触发自查项,如"自查 2.5") |
| 章节首次起草(从 0 写出来) | ❌ 不记(初稿不是改动) |
| 错别字 / 标点 / 纯排版调整 | ❌ 不记 |
| 模型自己改改撤撤、用户没明确确认 | ❌ 不记 |

> 拿不准 → 倾向不记。`REVISIONS.md` 是"用户与 LLM 共同沉淀的实质决策",不是流水账(那是对话历史的事)。

### 格式

文件首次创建时写头(只写一次):

```markdown
# 修订日志

> 产物迭代过程中每次用户确认的实质改动,按时间倒序追加(最新在上)。spec 是宪法定调,本文件是实施日志。
```

每次记一笔追加在头注释之后、最新一笔的顶部(一行 = 一次改动):

```
- `<YYYY-MM-DD HH:MM>` | <文件:章节/段> | <一句话改了什么> — <为什么>
```

### 实例

```
- `2026-05-26 15:08` | sections/06_有益效果.md §2 | 删除"显著提升"改为"准确率 82%→91%、时延 200ms→50ms" — 自查 6.3 拦截不可考核词
- `2026-05-26 14:32` | sections/03_发明内容.md §技术方案 "其中"段 | 区别技术特征从"采用 Y 算法"细化为"采用 Y + Z 组合,Y 处理粗筛 Z 做精排" — 检索新增 CN98765432A 命中纯 Y 算法,需细化区别
- `2026-05-26 11:50` | <today>-<short>-<name>.spec.md §7 关键参数 | 学习率 1e-4 → 5e-5 — 发明人提供 8 epoch 收敛实测,原 1e-4 偏大
```

### 操作

每次卡点用户确认后,用 `edit` 在头注释之后插入新一行(不要 append 到文件末尾 —— 倒序读才能秒看最新)。文件不存在就 `write` 创建带头注释的新文件。

## 章节骨架速查

写每章前在脑子里过一遍这 7 章顺序,sections 文件按 `NN_<名>.md` 命名(NN 影响目录顺序):

| NN | 文件 | 章节 | 字数预算 | 关键 |
|---|---|---|---|---|
| 01 | 01_技术领域.md | 一、技术领域 | 50-150 字 | 一句话,IPC 大类(如"本发明涉及自然语言处理领域") |
| 02 | 02_背景技术.md | 二、背景技术 | 800-1500 字 | **现有技术 1/2/3 + 缺陷**,引检索结论的公开号/DOI |
| 03 | 03_发明内容.md | 三、发明内容 | 1500-3000 字 | 三段式:**技术问题 → 技术方案 → 有益效果**,技术方案给完整步骤/结构(给代理师写权利要求的种子) |
| 04 | 04_附图说明.md | 四、附图说明 | 100-300 字 | 图 1/图 2/... 一句话题注,跟 `figures/fig_xxx.png` 对齐 |
| 05 | 05_具体实施方式.md | 五、具体实施方式 | 2000-5000 字 | ≥1 个实施例,含**关键参数取值**(模型参数 / 阈值 / 时序 / 物理量纲);可多实施例展示变体 |
| 06 | 06_有益效果.md | 六、有益效果 | 300-800 字 | 量化(精度提升 X%、时延降低 Y ms、成本下降 Z 元),不写"显著提升""效果良好" |
| 07 | 07_权利要求建议.md | 七、权利要求建议(可选) | 300-1000 字 | 给代理师参考的独权 + 从权草稿,**不是最终权要**(代理师会重写,你提建议) |

边界 (最容易混):
- 背景技术回答 **WHY 不够** (现有方案 + 它们的缺陷) | 发明内容回答 **WHAT 做了** (技术问题 / 技术方案 / 有益效果) | 具体实施方式回答 **HOW 做的** (实施例 + 参数 + 流程) | 有益效果回答 **HOW MUCH 提升** (量化数据)

## 附图 (流程图 / 结构图 / 时序图)

**所有附图都要落成 png 并在 md 里 `![](...)` 引用**;ASCII 字符画 (`┌─┐│`) Word 里必错位。附图编号 `render_docx.py` 全局自增(图 1 / 图 2 ...),**不要手写"图 2-2"**。

| 图类型 | 工具 | 怎么用 |
|---|---|---|
| 流程 / 结构 / 时序 / 模块关系 | **mermaid** | 直接写 ```mermaid 块,**首行必须** `%% caption: <题>`(必填 + 全 task 唯一,既是文件名也是 docx 图题),`render_diagrams.py` 渲成 `figures/fig_<caption>.png` |
| 数据图表 (实验对比柱/折线) | **matplotlib** | 落到 `<task_dir>/figures/<name>.png`,md 里 `![desc](figures/<name>.png)` |
| 已有截图 (产品 UI / 实验结果照片) | 直接 | 同上 `![]()` |

附图说明章节(04_附图说明.md)每个图一句题注;实施方式章节(05_具体实施方式.md)正文里通过"如图 N 所示"引用。

## 硬规则速查 (违反即被代理师/审查员退回)

- **客体合规**: 纯商业方法 / 智力活动规则 / 数学算法本身 / 单纯展示信息 / 疾病诊断和治疗方法 / 动植物品种 —— 直接不可专利,见 taxonomy §客体排除清单
- **技术方案要"能实施"**: 完整步骤 + 关键参数 + 输入输出,代理师按你写的能复现;不要写"基于深度学习方法,根据训练结果输出结果"这种黑盒
- **关键参数必须给具体值**: "阈值取 0.5"、"窗口 100ms"、"学习率 1e-4";不给值就写 `<TODO 待用户确认>`
- **公式必须自洽**: 符号定义 → 公式 → 量纲一致;不要凑公式
- **不可信检索/文献**: 检索式 / 公开号 / DOI / 作者一字不编;不确定就 `<TODO 待检索>`
- **脱敏边界**: 商业机密(具体客户名 / 内部代号 / 数据源 url)→ 按 spec §脱敏边界中性化("某客户" / "目标数据源");关键技术参数**不脱敏**(脱敏完了代理师没法写)
- **不堆形容词**: "颠覆性""国际领先""填补空白"一律不用 —— 专利文件靠技术特征区别于现有技术,不靠形容词
- **量化效果**: "显著提升"❌;"准确率从 82% 提升到 91%,时延从 200ms 降到 50ms"✅
- **一份交底书一个发明**: 多发明分多份(独权数量 = 发明数量),不要一份塞 5 个发明 —— 代理师拆不清

## 反模式

- 没挖专利点 / 没检索就硬写正文 —— 评审/审查员视角的高风险路径
- 一次性出全文,跳过"列要点"段段卡
- 关键章节(背景 / 发明内容 / 实施方式)整章一次出 —— 必须段段卡
- 自己编公开号 / DOI / 作者(检不到就说"未检出近似")
- "本发明采用 LLM 方法实现 XXX"这种黑盒写法 —— 必须有可复现步骤 + 参数
- 把商业代号 / 内部 url / 客户名直接写进去(脱敏边界没过)
- 把多个发明塞一份交底书(一份 → 1 个独权)
- 文件名 `output.docx` / `交底书.docx`(按案件名命名)
- 跳过 self_check.md 直接交付

## 输出

完成后给用户:
- 文件路径(`<案件名>_技术交底书.docx` + 各章 sections/*.md + figures/*.png)
- 各章字数 vs 预算
- 主推专利点摘要(独权种子的 3 句话)
- 现有技术对照表(本发明 vs 检出的 N 条最近似 —— 区别点清单)
- `<TODO>` 待补项清单(待用户/发明人补充的参数 / 实验数据 / 附图)
