zcdsj
/
zcbot
5
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
zcbot/skills/patent/SKILL.md

17 KiB
Raw Blame History

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

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:

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 条要点骨架;若已是本章最后一段,改预告下一章首段要点
  • 提问: "本段可以了吗?下一段要点要改 / 加 / 删什么?"
  1. ⛔ BLOCKING:停下来等用户明确反馈 ("OK"、"下一段"、"继续") 后才动笔。"看起来不错"、沉默、追问都不算确认 —— 用户对下一段要点没异议也算默认通过,但关键参数 / 公式 / 区别技术特征异常时必须主动追问
  2. 用户确认了实质改动(改写区别技术特征 / 调关键参数 / 换实施例 / 增删章节)后,追加一行到 <task_dir>/REVISIONS.md —— 见 §修订日志

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

阶段五: 自查 + 渲染

# 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 共同沉淀的实质决策",不是流水账(那是对话历史的事)。

格式

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

# 修订日志

> 产物迭代过程中每次用户确认的实质改动,按时间倒序追加(最新在上)。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> 待补项清单(待用户/发明人补充的参数 / 实验数据 / 附图)