262 lines
17 KiB
Markdown
262 lines
17 KiB
Markdown
---
|
|
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 skill**:`skills/proposal/scripts/render_diagrams.py` + `render_docx.py` —— 跟交底书 md 兼容(同样的 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 个学科共 21W+ 论文)如果命中
|
|
- **`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 <repo_root>/skills/proposal/scripts/render_diagrams.py <task_dir>/sections/
|
|
|
|
# 3. 渲染 .docx (复用 proposal skill 的脚本,patent 不另写)
|
|
python <repo_root>/skills/proposal/scripts/render_docx.py <task_dir>/sections/ --fund-type key_rd -o <task_dir>/<案件名>_技术交底书.docx
|
|
```
|
|
|
|
> `render_docx.py` 的 `--fund-type` 只影响目录页表头文案与封面,不影响章节解析 —— 交底书复用 `key_rd` 排版规范(国标黑体/宋体/1.5 倍行距)。封面页用户拿到后手动改成"技术交底书"标题,或在 sections/00_封面.md 自定义。
|
|
|
|
`<repo_root>` 取自 `<skill_dir>` 的父级再父级,e.g. `skill_dir = D:/projects/zcbot/skills/patent` → `repo_root = D:/projects/zcbot`。
|
|
|
|
## 工作目录
|
|
|
|
`<task_dir>` = system prompt 给的**绝对路径**(`…/workspace/tasks/<task_id>/`)。**所有产物都写到 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 里 `` |
|
|
| 已有截图 (产品 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>` 待补项清单(待用户/发明人补充的参数 / 实验数据 / 附图)
|