Metadata

name: patentmax-disclosure
description: 技术交底书生成。当用户要写技术交底书、专利交底、把研发材料或技术方案整理成交底书、挖专利点、只有一个想法想看看能往哪几个方向申请，或说「帮我写个交底书」「专利挖掘」「发明专利交底书」「交底书模板」「这个能写成专利吗」时使用。所用模型全部国产，国外模型 0 使用。Use when the user wants to turn R&D materials or an idea into a patent technical disclosure (invention disclosure) document (Word). All models are made in China; no foreign models are used. Requires a PatentMax API key.
version: 1.1.0
author: PatentMax
user-invocable: true
argument-hint: [材料文件路径 / 技术方案描述 / 一个想法]
allowed-tools: Bash, Read, Write, Glob

专利技术交底书 · PatentMax

把研发材料、技术方案，甚至只是一个想法，写成一份可以直接交给代理人的技术交底书 Word。附图自动画，发明点逐条和全球专利库比对，正文干净；系统推导和待补充的地方在核对说明里逐条列出，方便核对。

所用模型全部国产，国外模型 0 使用。 专利数据来自 PatentMax 专利库。

使用问题、企业采购：访问 ip930.com，右下角「联系客服」。

需要 PatentMax 密钥。 在 https://api.ip930.com 注册（新用户送 ¥50 体验额度）、创建密钥，设成环境变量 PATENTMAX_API_KEY。没设时脚本会返回中文提示，原样转告用户即可。

运行环境（必读，所有命令都适用）

部分 WorkBuddy 等环境的命令行不完整，cat、ls、sleep、rm 等可能找不到。为保证任何电脑都能跑通：

脚本路径一律写绝对路径：$DIR/scripts/patentmax_disclosure.py（$DIR 是本技能所在目录），不要写 cd ... && ...（前一步失败会让后面整条静默不执行）
python 找不到时依次试 python3、py；还找不到就用 WorkBuddy 自带的：先用 Glob 在 ~/.workbuddy/binaries/python/versions/ 下找到 python.exe，用它的完整路径。下文所有 python 都按这条替换
不要用 cat 读文件、不要用 sleep 等待：读文件用 Read 工具；等待由脚本自己完成
命令在用户的工作目录里运行，生成的 Word 会存到这个目录；也可以用 --out-dir 指定
命令超时设为 120 秒。脚本每条命令最多跑 30 秒就返回，不会卡住

核心原则

材料越全，技术交底书越好。 服务端是无人值守生成的，材料里缺的信息会按通行做法自动补，补得越多，要人确认的条目就越多。先把用户手上的材料读全，再提交。

这是付费任务，执行前必须取得用户同意。 命令必须显式加 --yes。

只有一个模糊想法时，先出方向，别直接写。 用 ideas 出几个可申请的方向，用户挑一个再写。

不重新提交。 生成要十几分钟，跑得久不代表失败。只要没有报错，就继续 wait。重新提交是这个技能最常见、代价最大的错误：材料写法一变就会新建任务、重复扣费，用户还要从头再等一遍，而原来那份其实还在正常生成。

什么时候用

用户说	怎么做
「帮我写个技术交底书」「把这些材料整理成交底书」	✅ 读材料 → `create`
「这个项目有什么能申请专利的」	✅ 读项目文档 → `create`
「我有个想法，能不能申请专利」（只有一两句）	✅ 先 `ideas` 出方向，挑一个再 `create`
「技术交底书写好了，帮我看看有没有人做过」	❌ 那是查新，用专利查新
「查一下这个方向有哪些专利」	❌ 用全球专利检索
「帮我看懂 CN×××」「这篇专利讲了什么」	❌ 用全球专利检索的单篇速览（`brief`）

第 1 步：读材料

这一步决定技术交底书的质量。 用户给了项目目录或文件，先自己读一遍，挑出和技术方案有关的：

优先读：设计文档、技术方案、研发报告、实验记录、需求说明、README
代码：不要整份塞进去。读懂之后，用文字写出处理流程、关键判断条件、模块划分
图片、图纸、PDF、PPT：脚本读不到。由你读完后，把结构、连接关系、流程和要点用文字写进 --supplement

.md / .txt / .docx 可以直接用 --file 交给脚本（可多次）。提交前用 preview 看一眼拼好的材料有多少字（不花钱）：

python "$DIR/scripts/patentmax_disclosure.py" preview --file "<绝对路径>/设计方案.docx"

字数	情况
800 字以上	充分，直接提交
200–800 字	偏薄，能写，但推断的地方多。先问用户两三个问题补上
200 字以下	脚本会拦下来。先用 `ideas` 出方向

材料最少要讲清三件事：解决什么问题、具体怎么做（结构 / 步骤 / 参数）、达到什么效果。详见 references/materials-guide.md。

第 2 步：提交

提交前先用几行列给用户确认（这一步不花钱）：

📋 准备生成技术交底书
- 案件名称：……
- 要解决的问题：……（1–3 条）
- 核心技术手段：……（3–6 条，从材料里摘，不要编）
- 材料：约 N 字
- 预计用时：通常 6～15 分钟

用户回「确认」或补充修改后，再加 --yes 提交：

# 材料齐的：直接出技术交底书
python "$DIR/scripts/patentmax_disclosure.py" create --file "<绝对路径>/设计方案.docx" --supplement "补充：……" --title "案件名称" --yes

# 只有一个想法：先出方向（默认 3 个，最多 5 个）
python "$DIR/scripts/patentmax_disclosure.py" ideas --idea "冬天水渠闸门老被冰卡住，想做个能自己判断卡滞并清理的装置" --count 3 --yes

# 用户挑中第 2 个方向，接着写技术交底书
python "$DIR/scripts/patentmax_disclosure.py" create --from-ideas <方向分析的 report_id> --direction 2 --yes

命令约 15 秒后返回。返回退出码 10 时，先发这一句，再发输出里的进度：

技术交底书已开始生成，通常 6～15 分钟，排队或材料多时可能到 30 分钟，进度会实时告诉你。

记下输出 JSON 里的 operation_id，后面都用它。不主动向用户展示任务编号，用户问起再给。

第 3 步：等待并报告进度

python "$DIR/scripts/patentmax_disclosure.py" wait --operation-id <operation_id>

每条 wait 最多 30 秒就返回。按退出码处理：

退出码	含义	怎么做
10	还在生成	发送输出里的进度，然后立即再运行一次 `wait`
0	完成了，Word 已自动下载	执行第 4 步
1	出错	按「出错时」处理
3	同样的任务已经在跑	用输出里的 `operation_id` 运行 `wait`，不要换写法重新提交

进度怎么发（照原文，不改字）

把每条 [进度] …… / [进度 X%] …… 去掉方括号部分，按下表加图标后原文发送：

进度行	发送
`[进度] 已开始生成……`	🚀 已开始生成……
`[进度] 排队中，已等待……`	🕒 排队中，已等待……
`[进度] 生成中，已用时……`	📝 生成中，已用时……
`[进度 X%] 某阶段，已用时……`	📝 X% 某阶段，已用时……

例：[进度] 生成中，已用时 6分30秒 → 发送 📝 生成中，已用时 6分30秒。

等待期间只发进度，不附加其它文字；不改写进度文字，不自己估算剩余时间，不编造没出现的百分比
一次输出里有几行就发几行；[提示] …… 行原样转告一次
出结果之前不要结束回复。 退出码为 10 时，发完进度立即再运行 wait
等了十几二十分钟还没完成 → 正常，继续 wait。命令断了、对话重开了，也用同一个 operation_id 运行 wait 接着看，不要重新 create

第 4 步：交付

退出码 0 时两份 Word 已经下载好，输出 JSON 的 files 里是完整路径。按顺序发送：

✅ 100% 技术交底书已生成，用时 <elapsed>
📄 技术交底书：<files 里的技术交底书路径>
📋 核对说明：<files 里的核对说明路径>

交底书正文是干净的，可以直接交给代理人：发明名称、背景技术、技术方案、优点、实施方式及附图、权利要求结构预览、说明书摘要、附图标号表。核对说明汇总了正文里需要确认的推导和待补充。

再用几句话讲下面几项（没有的不讲）：

字段	怎么讲
`pending_count`	大于 0 时：「有 N 处是系统按通行做法推断的，请在核对说明里逐条确认」
`missing_sections`	缺哪几节，需要发明人补什么事实
`figures`	共 `total` 张附图，已画好 `auto` 张；`need_drawing` 里的只给了绘图说明，需要另外画
`novelty`	`features` 个发明点里有 `found` 个在专利库里找到了相近文献（`hits` 是公开号）。这是发明点比对，不是正式查新
`conflicts`	大于 0 时：材料里有 N 处数值前后不一致，在核对说明里，要用户定一个

再用一句话给一个可选的下一步。只挑最相关的一条，没有就不说；这句是文字，不调用工具：

pending_count 大于 0 或 missing_sections 不为空：「核对说明里待确认的地方，你把实际情况告诉我，我可以连同原材料重新生成一版（会再计费一次，旧文件保留）。」
否则：「想确认有没有人做过，可以把这份技术交底书交给 PatentMax 专利查新。」

最后一句固定是：

在 https://api.ip930.com 控制台可以查看所有任务和余额。

不要打开 Word 把正文贴进对话，也不要读「完整结果」JSON 全文：用户直接打开 Word 看。贴进来既拖长对话，又白白消耗积分
以上是本轮最后的输出，发完就停：之后不再调用工具、不补表格、不写总结和建议，等用户回复。在这之后再调工具，收尾信息会被埋掉，用户看不到

交付后要改

只改个别字句：让用户直接在 Word 里改，不用重新生成
补事实、确认推断的地方：把用户的回复写进 --supplement，连同原来的材料再 create 一版。先说明会再计费一次，取得同意。 新文件会另存，旧的保留
这和「生成中不重新提交」是两回事：只有上一版已经交付之后才可以这样做

出错时

脚本出错时输出 {"error": true, "message": "……"}，message 是写给用户看的中文说明，里面已经写明了下一步怎么办。

原样转述 message，不猜原因、不补充建议、不自己换写法重试
退出码 2（输入有误：材料太短、文件读不了、少参数）：什么都没提交、没扣费，按 message 补齐后再运行
任务失败或取消时，预扣的费用会全额退回，告诉用户这一点

方向分析的结果

ideas 完成后，输出的 directions 里每个方向有标题、概述、创新点、现有技术和评分（新颖性、可行性、差异化、综合分）。

把方向列给用户挑，不要替他选。 每个方向用一两句话讲清楚它和原始想法的区别，附上综合分。existing_tech 写的是「未检索到」时照实说，不要包装成「很新颖」。用户挑定后再用 --from-ideas 写技术交底书。

它不做什么

不出具专利申请文件。 交底书是给代理人的技术说明，正式的权利要求书和说明书需要专利代理师撰写并递交。

不保证能授权。 发明点比对只能说明在专利库里撞没撞上，不能代替审查。

不做外观设计。 适合发明和实用新型这类技术方案。

材料会发送到服务端生成。 涉及还没申请的核心参数时，提醒用户一句。

参考

references/materials-guide.md：材料怎么准备，不同领域要写到什么程度
references/workflow.md：完整流程，结果字段怎么读
references/faq.md：常见问题

技术交底书 · PatentMax

安装技能