专利撰写 · PatentMax
把研发材料、技术方案，甚至只是一个想法，写成一份专利初稿 Word：技术方案、实施方式、附图、权利要求结构、说明书摘要都有，代理人拿到就能往下改。附图自动画，发明点逐条和全球专利库比对，正文干净；系统推导和待补充的地方在核对说明里逐条列出，方便核对。
所用模型全部国产，国外模型 0 使用。 专利数据来自 PatentMax 专利库。
使用问题、企业采购：访问 ip930.com，右下角「联系客服」。
不需要 API Key 就能用。
初稿里有什么
| 节 | 内容 |
|---|---|
| 1 | 发明创造名称 |
| 2 | 背景技术及现有技术的缺陷和不足 |
| 3 | 具体的技术方案描述 |
| 4 | 本发明创造的优点 |
| 5 | 具体实施方式及附图（附图自动绘制） |
| 6 | 权利要求结构预览：独立项、从属项连续编号，引用关系标清；产品和方法各出一条独立项 |
| 7 | 说明书摘要（300 字以内） |
| 8 | 附图标号表 |
另附一份核对说明：系统推断的内容、待补充的事实、附图绘图说明、发明点比对、可替换的实现方式。
运行环境（必读，所有命令都适用）
部分 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补齐后再运行 - 第一次运行时输出里有「[PatentMax] 已自动领取免费试用……」：把这句话原样转告用户一次
- 出现
"free_trial": true：免费试用用完、过期或想用其他功能，message里写着怎么办（注册 PatentMax 再送 ¥50 体验额度），原样转告 - 任务失败或取消时，预扣的费用会全额退回，告诉用户这一点
方向分析的结果
ideas 完成后，输出的 directions 里每个方向有标题、概述、创新点、现有技术和评分（新颖性、可行性、差异化、综合分）。
把方向列给用户挑，不要替他选。 每个方向用一两句话讲清楚它和原始想法的区别，附上综合分。existing_tech 写的是「未检索到」时照实说，不要包装成「很新颖」。用户挑定后再用 --from-ideas 写专利初稿。
它不做什么
初稿不是可以直接递交的申请文件。 权利要求给的是结构预览，独立项按「宁少勿多」写，但最终的保护范围要专利代理师定稿后才能递交。
不保证能授权。 发明点比对只能说明在专利库里撞没撞上，不能代替审查。
不做外观设计。 适合发明和实用新型这类技术方案。
材料会发送到服务端生成。 涉及还没申请的核心参数时，提醒用户一句。
相关能力
同一把正式密钥、同一个余额（免费试用只开通本技能，其他功能要注册后用正式密钥）：
- 全球专利检索：写之前先摸摸这个方向有哪些专利
- 专利查新：专利初稿写完，判断能不能申请
- 企业情报分析 / 技术路线分析：方向都还没定时先看这两个
典型顺序：检索摸底 → 写专利初稿 → 查新确认 → 交给代理人。
参考
references/materials-guide.md：材料怎么准备，不同领域要写到什么程度references/workflow.md：完整流程，结果字段怎么读references/faq.md：常见问题