为什么我把专利交底书做成 Skill
昨晚我把一个新工具推到了 GitHub，名字叫 patent-mining-disclosure-skill。它不是一个"帮你润色专利文档"的小脚本，而是一个给 AI Agent 用的专利挖掘与交底书生成 Skill。
我做它的原因很简单：写专利交底书最难的，往往不是写字，而是先判断什么值得公开、什么不该公开、什么根本不适合写成专利。
看完这篇你能知道：
- 为什么我不再相信"直接让大模型写一篇交底书"这个流程
- 这个 Skill 到底把专利挖掘拆成了哪几步
- 它适合什么团队，不适合什么场景
- 如果你也想试，最小上车路径是什么
我的判断：交底书不是写作问题
很多团队第一次用大模型写专利交底书，都会从一句话开始：
帮我根据这个项目生成一份专利交底书。
这个提示词看起来很自然，但我现在觉得它是错的。因为它默认了一件事：项目里已经存在一个明确、值得公开、适合申请的技术点。
现实不是这样。
一个软件项目里通常会混着几类东西：有些是普通工程实现，有些是业务经验沉淀，有些是可公开的技术方案，还有些是公开以后反而吃亏的内部策略。比如完整 prompt、真实规则表、客户口径、训练样本、阈值配置，这些东西不一定适合写进专利正文。
我的判断是：专利交底书生成的第一步不应该是"成文"，而应该是"资产盘点和取舍"。
这也是我最后把它做成 Skill 的原因。Agent 不只是会写，它还应该被流程约束住：先盘点，再查新，再确认取舍，最后才生成 Word 或 PDF。
我把流程拆成了几道门
这个 Skill 的核心不是某个神奇 prompt，而是一套门禁流程。
| 阶段 | 做什么 | 为什么重要 |
|---|---|---|
| 项目扫描 | 读取代码、README、设计文档、Word、PPT | 先让 Agent 看到真实材料，而不是凭空想象 |
| 专利点清单 | 列出可申请点、不适合点、商业秘密点 | 避免把普通功能硬包装成创新 |
| 轻量查新 | 对候选点做相似专利初筛 | 提前发现明显撞车的方向 |
| 用户取舍 | 用户确认写哪些、不写哪些 | 把技术公开权交还给项目 owner |
| 深度查新 | 对确认点补充更细的现有技术分析 | 给背景技术和区别特征提供依据 |
| 说明书式成稿 | 写技术领域、背景、发明内容、实施方式 | 让代理人能继续加工，而不是拿到一篇项目介绍 |
| 附图处理 | 生成流程图、架构图、子流程图 | 专利交底不是纯文字，图很关键 |
| Word / PDF | 生成可交付文件 | 让产物能进入真实协作流程 |
这里面我最看重的是第二步和第四步。
第二步让 Agent 不再只输出一个"最强专利点"，而是输出一份资产清单。它要说明为什么某个点能写，为什么某个点暂时不能写，为什么某些东西更适合商业秘密保护。
第四步让用户介入。因为专利不是纯技术判断，它还涉及公开代价、竞争策略和公司资产布局。这个决策不应该被模型悄悄替你做掉。
它具体能干什么
现在这个 Skill 叫 patent-mining-disclosure-skill，定位是"专利挖掘交底书生成 Skill"。
它能做的事包括：
- 从技术项目、软件系统、产品方案里扫描材料
- 先生成专利点资产清单
- 对候选点做轻量相似专利查新
- 标出可申请、暂不适合申请、建议商业秘密保护的点
- 在用户确认后生成说明书式技术交底书
- 生成方法流程图、系统结构图和关键子流程图
- 支持 Markdown、Word、PDF
- Word 里的图可以用本地 mermaid 渲染，也可以用图片模型自动生成
- 支持发明人信息，但未知时只写
[待填写]，不瞎猜 - 后续补材料或纠错时另存新版本，并保留修订记录
最小使用方式大概是这样：
bash
git clone https://github.com/AqooDer/patent-mining-disclosure-skill.git \
~/.cursor/skills/patent-mining-disclosure-skill然后在 Agent 里直接说：
text
请阅读 /path/to/project 的代码，先盘点专利点，做相似专利初筛，然后让我选择写哪些。等清单出来后，再说：
text
写 A、B、C 三个，输出 Word，图用自动生图，发明人为[待填写]，同时导出 PDF。这套交互看起来多了几步，但它解决的是一个很现实的问题：不要在你还没想清楚公开策略之前，就生成一份看似完整的专利交底书。
反方观点：这是不是过度工程
我能理解一个反方观点：写交底书嘛，给大模型一个模板，让它输出 Markdown，不就行了？搞这么多清单、查新、取舍、Word、PDF、图片接口，好像有点重。
这个观点有成立的地方。
如果你只是写一个内部 demo，或者只是想快速整理材料给同事看，确实没必要上这么完整的流程。甚至直接用一个提示词，让模型生成一个粗稿，已经足够。
但我不太被这个反方说服的地方在于：真实专利工作不是"写得像不像"，而是"该不该这么写"。
直接生成交底书有三个坑：
- 它会把普通工程实现写得像创新点。
- 它会把不该公开的细节写进正文。
- 它会绕过查新和取舍，给用户一种"已经可以申请了"的错觉。
这几个坑都不是润色能解决的。它们是流程问题。
所以我宁愿把 Skill 做得啰嗦一点，也不想让它一上来就产出一篇很漂亮但方向可能错的文档。
不适合谁，以及隐藏成本
这个 Skill 不是专利代理人的替代品，也不是法律意见生成器。
它更像一个"技术材料预处理器"：帮你从项目里挖出候选资产，做初步查新，整理技术方案，把交底书写到代理人能继续加工的程度。
不适合这几类场景：
- 你已经有成熟专利团队和固定模板，只缺一个排版工具
- 你希望它直接判断"这个一定能授权"
- 你的项目高度依赖未公开配方、客户数据、训练样本，不适合让 Agent 读取
- 你不愿意花时间审查它生成的专利点清单
隐藏成本也很明显。
第一，查新永远不是一次搜索就能结束。Google Patents、国知局、论文、开源项目都可能影响判断。Skill 可以把流程做得更稳，但不能替代最终检索。
第二，自动生图很方便，但专利附图不能只看好不好看。节点名、箭头方向、模块边界都要审。图片模型偶尔会把文字画错，这件事必须人工确认。
第三，维护 prompt 和流程本身有成本。专利交底书不是通用博客模板，不同行业、不同公司、不同代理机构的偏好都可能不一样。这个 Skill 后续肯定要持续调整。
如果我是读者，我会怎么用
如果你也在做技术项目，我不建议一上来就拿它生成最终 Word。
我会按这三步试：
- 先拿一个非敏感项目跑专利点资产清单，看看它能不能发现你没意识到的技术点。
- 再挑一个候选点，让它生成说明书式交底书，重点检查"发明内容"和"具体实施方式"是否讲清楚。
- 最后再试 Word/PDF 和附图生成，确认产物能不能进入你自己的协作流程。
我接下来会盯一个指标：它能不能减少第一版交底书和代理人之间的来回次数。
如果一个 Skill 只是把 Markdown 写得更长，那价值有限；如果它能让技术 owner 在生成正文前先完成"可写、不可写、该藏"的判断，那它才真的有用。
这也是我做这个项目的核心原因。
你怎么看？如果你也写过专利交底书，最痛的是"想不到专利点"，还是"想到了但写不清楚"？评论区聊聊。