专利撰写这个方向最近在 AI 编程代理圈里确实很热。网上常见的“专利撰写 Skill”不是某个独立软件而是一套基于 SKILL.md 结构化指令的工作流包运行在 Claude Code、Codex、Cursor、OpenCode 这类支持 Skill 机制的代码代理里。你把论文摘要、实验数据、技术方案丢进去模型会按预设流程输出一份结构完整的专利交底书草稿包括技术领域、背景技术、发明内容、实施方式、创新点描述甚至权利要求草拟建议。核心价值就一句话把“论文 idea 变成发明专利申请底稿”这件事从手搓变成流程化组装。这类 Skill 真正值得关注的特点也很明确一是可复用一套 SKILL.md 可以在不同项目里反复加载团队分发容易二是输入灵活论文摘要、正文、实验记录、竞品对比都能作为输入三是输出结构化交底书章节固定方便工程师和专利代理师二次加工四是能批量配合脚本可以一次处理多篇论文五是门槛不算高云端 API 方案不需要本地 GPU本地模型方案则需要按显存实测。当然也有明确边界AI 生成的是草稿不是法律意见新创性和保护范围判定仍然需要人工和专业代理师介入。这篇文章会带你走一遍完整落地路径先解释 Skill 机制和 MCP 的区别再讲环境准备、安装部署、一次从论文到交底书的完整功能测试然后给出接口与批量任务的脚本思路最后列出资源占用观察和常见问题排查清单。所有代码和命令都给出可复制的通用模板具体目录和参数按你自己的代理版本调整即可。如果你正在写论文、做横向项目或者在公司里负责专利交底书整理这篇文章可以收藏后边看边操作。1. 专利撰写 Skill 核心能力速览在动手之前先把这套方案的技术画像说清楚避免期望偏差。能力项说明项目类型AI Skill 工作流包本质是带结构指令的文本模板不是独立软件运行环境Claude Code、Codex、Cursor、OpenCode 等支持 SKILL.md 的编程代理主要功能论文 Idea 转专利交底书草稿、创新点提取、权利要求草拟建议输入素材论文摘要、论文全文、实验数据、技术方案描述、竞品对比输出物结构化专利交底书 Markdown 文档通常含技术领域、背景、发明内容、实施方式、创新点等硬件需求取决于底层模型。云端 API 方案不需要本地 GPU本地模型方案按显存和模型版本实测启动方式在代理内加载 Skill 后自然对话或通过 CLI 指定 Skill 执行接口能力Skill 本身不单独提供 HTTP API调用能力跟随宿主代理的 CLI/SDK批量任务支持通过目录遍历加脚本循环逐个处理适合场景高校课题组预研、企业研发交底书整理、技术文档转专利草案合规边界AI 草稿需人工复核不构成法律意见不得提交虚假发明从这张表能看出来Skill 方案的定位不是“替代专利代理师”而是把“结构化整理”这个体力活先做完让人的精力集中在技术事实确认和法理判断上。2. 适用场景与使用边界这类专利撰写 Skill 最适用的场景有三类。第一类是高校课题组学生写完论文后可以用 Skill 快速产出交底书初稿再让导师或技术转移部门补充发明人贡献、实施细节。第二类是企业研发部门研发人员把内部技术方案提交后Skill 能先把背景技术、要解决的技术问题、技术方案逻辑梳理成稿减少专利工程师来回沟通成本。第三类是独立开发者和技术博主如果你手头有论文或开源项目也可以用它快速整理自己的技术思路判断哪些内容可能具备创新点。但它不适合做三件事。第一不适合直接决定“这个 idea 到底能不能授权”。AI 没有检索能力时无法判断现有技术是否已经公开相同方案也不能保证权利要求保护范围合理。第二不适合在没有任何技术事实支撑的情况下编造实验数据。专利交底书必须基于真实研发内容模型只能组织表达不能无中生有。第三不适合处理未获授权的机密材料。如果论文尚未公开或者涉及企业保密信息请在输入前确认知识产权归属和保密协议不要让 AI 服务意外泄露内容。这里必须强调一条合规红线专利相关材料和生成内容都有严格的版权、署名和真实性问题。不要拿侵权论文片段直接喂给模型不要虚构实验数据不要在未授权情况下把他人成果包装成自己的专利。AI 生成的草稿如果后续要提交一定要由发明人逐条核对技术事实再由具备资质的专利代理师完成法律审核。3. Skill 机制与环境准备先解决一个基础问题Skill 到底是什么为什么它比“写一段 prompt”更可靠。Skill 本质上是一个带有 SKILL.md 文件的目录。SKILL.md 用 Markdown 写清楚“这件事该怎么做”包括任务目标、输入要求、处理步骤、输出模板、注意事项。模型加载 Skill 后会把这些指令当作行为准则而不是依赖用户在对话里临时描述。这样做的优势是稳定和可复用同样的输入无论谁运行只要模型能力达标输出结构基本一致。它和 MCP 的区别也要说清楚。MCPModel Context Protocol解决的是“模型能连什么”比如连接数据库、读取文件、调用外部 APISkill 解决的是“模型该怎么干”提供的是任务流程和输出模板。两者可以叠加使用你可以用 MCP 让模型读取专利数据库或检索现有技术再用 Skill 规定交底书的撰写结构。理解这个区别排错时就不会乱。环境准备方面你需要先确认宿主代理的版本。常见方案包括Claude Code需要 Node.js 环境支持项目级和用户级 Skill 目录。Codex CLIOpenAI 官方 CLI支持通过指令目录加载 Skill配置方式取决于版本。Cursor在.cursor/skills下放置 Skill重启后生效。OpenCode支持.opencode/skill或全局配置目录。系统方面Windows、macOS、Linux 都可以。如果你使用云端 API不需要本地 GPU如果你用本地模型则需要准备足够的显存和磁盘空间具体数值以模型官网要求为准。另外因为论文可能很长建议优先选择上下文窗口在 128K 以上的模型否则后续会频繁遇到截断问题。磁盘空间几乎可以忽略Skill 本体只是几个 Markdown 文件。真正占空间的是模型文件或者代理缓存这个要看你的部署方式。4. 安装部署与启动方式下面给出一套通用的 Skill 安装流程。虽然不同代理的目录名略有区别但思路一致把 Skill 目录放到代理能识别的位置然后重启代理。先看目录结构示例。假设你的 Skill 命名为patent-drafterpatent-drafter/ ├── SKILL.md ├── templates/ │ ├── patent_disclosure_template.md │ └── claim_suggestion_template.md └── examples/ ├── input_abstract.md └── output_sample.mdSKILL.md 是核心它告诉模型“你的角色是专利交底书撰写助手必须按以下流程执行”。下面是一个可改写的模板片段--- name: patent-drafter description: 将论文或技术方案转换为结构化专利交底书草稿。 --- # 专利交底书撰写 Skill ## 任务目标 根据用户提供的论文摘要、技术方案或实验记录生成结构化专利交底书。 ## 输入要求 - 必须包含技术领域、背景技术、发明内容、实施方式、创新点。 - 如果用户输入不足先提问补充不要自行编造实验数据。 ## 处理流程 1. 提取核心技术问题。 2. 拆解创新点编号列出。 3. 根据 templates/patent_disclosure_template.md 输出交底书。 4. 最后输出权利要求草拟建议。 ## 输出模板 遵循 templates/patent_disclosure_template.md 的章节结构。实际使用时你需要把模板里的内容替换成你们团队内部交底书模板的要求。有些公司交底书还会要求“技术效果”“替代方案”“附图说明”这些都可以在模板文件里体现。安装到不同代理的命令也差不多。以 Claude Code 为例放在项目级目录# 在项目根目录创建 Skill mkdir -p .claude/skills/patent-drafter/templates mkdir -p .claude/skills/patent-drafter/examples # 将 SKILL.md、templates、examples 放入对应目录 # 重启 Claude Code 后插件会被自动识别Cursor 用户则是把 Skill 放到.cursor/skills/patent-drafter/重启 Cursor 后即可在对话中引用。Codex 和 OpenCode 的目录位置在不同版本有差异更稳妥的做法是查看你当前版本的官方文档避免写错路径。启动方式分两种。一种是在交互界面里直接说“请使用 patent-drafter Skill根据这篇论文生成交底书”另一种是用命令行非交互执行。例如# 示例命令实际路径和参数按项目调整 claude 请使用 patent-drafter Skill 生成专利交底书 \ --input-file docs/paper_abstract.md \ --output-file output/disclosure.md这里要提醒一下不同代理的 CLI 参数命名不一样不存在一份通用的命令行语法。上面的命令是示例用来解释“通过 CLI 指定输入输出”这个思路正式使用时请先跑--help确认参数。5. 功能测试与效果验证部署完成后不要直接拿真实论文去跑先准备一份测试素材。下面是示例输入仅用于验证流程不构成真实研发信息论文标题一种基于双分支注意力机制的轻量文档版面分析方法 摘要本文提出一种轻量级文档版面分析方法。该方法采用双分支结构 一个分支负责全局版面结构感知另一个分支负责局部文本区域分类。 两个分支通过注意力融合模块交互并在推理阶段配合剪枝策略减少计算量。 实验表明在公开版面数据集上达到接近主流模型的精度同时参数量降低40%。跑通一次完整的测试建议按下面几个维度来做。5.1 创新点提取测试测试目的是看模型能不能从论文里拆出可专利化的技术点。输入上面的摘要观察输出是否包含现有技术不足、本方案改进点、技术效果。预期结果是模型能给出一段类似“现有版面分析方法多依赖大模型计算量大本方案通过双分支注意力融合在保持精度的同时显著降低参数量”的归纳。如果模型只复述摘要而没有任何归纳说明 SKILL.md 中的“拆解创新点”指令不够明确可以补充要求“将每个创新点写成‘现有技术 问题 本方案 效果’四段式”。5.2 权利要求草拟测试这项测试更敏感。专利权利要求有特定写法模型容易写成技术博客式的描述。测试时要求模型分别给出“独立权利要求”和“从属权利要求”的草拟建议。判断成功的标准是独立权利要求包含必要技术特征从属权利要求增加限定细节。如果模型直接生成抽象描述没有层次说明模板文件里缺少权利要求撰写规则需要补充“先写主体结构再写可选附加特征”的提示。5.3 完整交底书生成测试输入测试论文摘要要求按模板生成完整 Markdown 文件。检查标题层级、章节完整性、内容连贯性。注意观察模型是否把“发明内容”写成了“实验结果复述”。交底书里的发明内容应该说明“是什么结构”和“为什么有效”而不是罗列实验指标。若发现输出偏向论文行文需要在 SKILL.md 里加入“禁止直接复制论文段落需重新组织为专利语言”的约束。5.4 长文档与切片测试论文全文可能几万字超过上下文窗口。常见做法是让模型先读取摘要、方法部分和实验结论忽略相关工作等辅助章节。测试时可以故意输入一篇较长的技术文档观察输出是否中断。如果中断需要把输入切片成多个阶段第一轮提取创新点第二轮根据创新点生成交底书。这个经验在批量任务时尤其重要。5.5 失败判断标准一个能用的 Skill 应该做到输入创新点清晰的论文能输出结构完整的交底书草稿输入信息不足能主动追问不会编造实验数据不会把技术特征揉成一团。如果你的测试出现了相反情况优先检查 SKILL.md 是否被正确加载其次检查模板文件是否完整。6. 接口 API 与批量任务Skill 本身没有独立的 HTTP API但宿主代理普遍提供 CLI 或 SDK 接口可以用脚本批量驱动。下面是批量处理的通用思路准备一个输入目录存放多篇论文摘要循环调用代理 CLI将每篇输出保存到独立文件写入日志和失败重试机制。一个示例 Python 脚本框架如下import subprocess from pathlib import Path input_dir Path(./papers) output_dir Path(./outputs) output_dir.mkdir(exist_okTrue) for paper in input_dir.glob(*.md): output_path output_dir / f{paper.stem}_disclosure.md cmd [ claude, 请使用 patent-drafter Skill 生成专利交底书, --input-file, str(paper), --output-file, str(output_path), ] print(fprocessing {paper.name}) result subprocess.run(cmd, capture_outputTrue, textTrue, timeout300) if result.returncode ! 0: print(ferror: {paper.name}: {result.stderr}) else: print(fdone: {paper.name})在实际项目中注意三点。第一每次调用都是独立的模型请求会消耗 token批量前先估算成本。第二CLI 命令每跑一次都要启动代理如果脚本卡住检查是否是因为模型上下文太长导致超时。第三批量任务建议加入断点续跑例如跳过outputs/下已经生成的同名文件避免重复消耗。如果你需要更工程化的方式可以考虑用 Claude Code SDK、Codex API 或 OpenCode 的 headless 模式把生成逻辑封装成内部服务。但无论怎么封装都要注意限制服务访问范围。内部接口不要直接暴露到公网加上简单的 token 鉴权并且对生成结果做日志审计。batch 任务建议的目录结构project/ ├── papers/ # 输入论文命名规范日期_作者_标题.md ├── outputs/ # 生成的交底书 ├── logs/ # 批量运行日志 └── config.yaml # 模型、超时、重试参数这里仍然要强调Skill 工作流的生成结果只是草稿批量生成的多个交底书更需要人工逐份核对不要直接走向提交流程。7. 资源占用与性能观察讨论资源占用时要把 Skill 本身和底层模型分开来看。Skill 只是一组 Markdown 指令运行时代理加载它的资源开销可以忽略不计。真正的资源消耗来自模型推理如果你使用 Claude、GPT、DeepSeek 等云端 API消耗的是 token 数和网络请求时间如果使用本地模型消耗的是显存、内存和 CPU 算力。本地部署时观察资源占用主流方式是终端里运行nvidia-smi -l 1实时看显存也可以在代理日志里开启 verbose 模式看请求耗时。显存数值取决于模型规模和推理参数不要轻信网上“某某模型固定占多少 G”的说法要以本机实际运行结果为准。就专利撰写这类任务来说输入长度往往远大于输出长度所以真正影响显存和计费的是论文输入部分。性能优化建议如下。先做文本精简论文全文往往包含大量与创新点无关的章节输入前先让模型只提取“要解决的技术问题、技术方案、技术效果”再基于精简结果生成交底书。再控制输出长度交底书不必一次写万字可以分章节生成最后合并。另外批量任务时一定要设置超时和重试因为长文档极容易出现单次请求超时。云端 API 的成本观察也要单独说。如果你每天都批量处理十篇论文最好记录每篇消耗的输入 token 和输出 token换算成费用后评估是否值得。一个更省成本的做法是先在本地用轻量模型做初步结构化只把精炼后的创新点列表交给高端模型生成交底书成本能明显下降。这也是 Skill 工作流的优势流程可控每一步都可以替换模型。8. 专利撰写 Skill 常见问题与排查方法实际跑流程时大概率会遇到下面这些坑按表格排查会更快。问题现象可能原因排查方式解决方案模型没有按 Skill 流程执行Skill 目录路径不对或代理版本不支持检查 Skill 目录是否放在正确位置查看代理启动日志是否识别到 Skill按当前代理官方文档调整目录更新代理版本输出只有论文摘要没有交底书结构SKILL.md 指令不够强或模板文件缺失查看 SKILL.md 是否明确要求按模板输出补强指令明确“必须输出技术领域、背景、发明内容等章节”生成的交底书内容全是实验复述没有区分论文行文和专利行文检查输出是否重新组织语言在 SKILL.md 中增加“禁止直接复制论文段落需按专利逻辑重组”论文过长导致输出截断上下文窗口超限查看请求日志里的 token 数量将输入切分为多轮先提取创新点再生成交底书批量任务中部分文件失败单次请求超时或网络波动查看日志中失败任务的错误信息增加超时时间和重试机制跳过已生成文件模型编造实验数据输入信息不足模型自行补全对比输出中实验数据是否来自原文在 SKILL.md 中强调“缺少数据时提问不编造”本地环境显存不足模型参数过大或上下文过长使用nvidia-smi查看显存占用使用更小模型、量化版本或切换到云端 APIAPI 调用失败或鉴权错误凭证过期或服务未启动检查 API key 和环境变量更新凭证确认服务地址正确Skill 加载后没有效果代理缓存未刷新重启代理检查 Skill 目录名称重启后重新加载确认 SKILL.md 第一行文件名正确排查时记住一个原则先确认 Skill 被真正加载再检查输入质量最后才怀疑模型能力。很多“生成效果差”的问题其实是输入论文信息密度太低模型没有可提炼的内容。9. 最佳实践与使用建议基于上面的流程几个工程化建议值得记录。第一第一次使用先用小参数测试。扔一篇摘要进去看输出结构是否符合模板再逐步扩展到全文。不要一上来就批量跑 30 篇论文否则排查问题时成本很高。第二维护一套最小可运行配置。把 SKILL.md、模板文件、示例输入输出放在同一个目录用 git 管理。团队新成员拿到后能在 10 分钟内跑通后续修改模板也有版本记录。第三输入素材和输出结果分目录管理。输入论文按日期和作者命名输出交底书按技术方向归类。这样后续追溯创新点来源时非常方便也方便专利代理师复核。第四批量任务要加日志和失败重试。不要只在终端里看输出把每次请求的时间、输入 token、输出 token、结果状态写入日志文件这样出现问题时能定位到具体论文。第五涉及内部研发信息的场景要让接口服务只在受控网络内访问。如果担心数据隐私可以选择本地模型方案不把论文内容发送到外部 API。比较敏感的公司应该先走信息安全审批流程。第六也是最重要的合规建议所有交底书必须由发明人逐条确认技术事实再由专利代理师审核法律文本。不要直接使用 AI 生成的权利要求不要提交带有虚假数据或未授权内容的申请。AI 是效率工具不是免责挡箭牌。10. 总结与下一步专利撰写 Skill 最值得尝试的点不在于“一键生成”的神奇效果而在于它把交底书这种结构密集型任务固化成了稳定可复用的工作流。一旦跑通团队里任何人都能把论文快速转换成初稿节省大量整理时间。最先验证的功能建议选创新点提取这一步最便宜、最容易看到效果也能最快暴露 SKILL.md 指令的缺陷。最容易踩的坑是 SKILL.md 放错目录导致模型根本没加载以及长论文被截断导致交底书不完整。后续扩展方向可以考虑把 Skill 和 MCP 结合接上专利检索数据库做新颖性预检增加竞品专利对比生成模块把交底书输出直接渲染成公司内部 OA 流程需要的格式。技术方案本身不复杂真正的价值在于你用起来之后能积累出属于自己团队的专利撰写 Know-how。先按上面的测试流程跑一遍把输出模板改到符合你团队要求再开始批量接入论文数据。 AI编程代理中的专利撰写Skill：从论文到交底书的自动化工作流
专利撰写这个方向最近在 AI 编程代理圈里确实很热。网上常见的“专利撰写 Skill”不是某个独立软件而是一套基于 SKILL.md 结构化指令的工作流包运行在 Claude Code、Codex、Cursor、OpenCode 这类支持 Skill 机制的代码代理里。你把论文摘要、实验数据、技术方案丢进去模型会按预设流程输出一份结构完整的专利交底书草稿包括技术领域、背景技术、发明内容、实施方式、创新点描述甚至权利要求草拟建议。核心价值就一句话把“论文 idea 变成发明专利申请底稿”这件事从手搓变成流程化组装。这类 Skill 真正值得关注的特点也很明确一是可复用一套 SKILL.md 可以在不同项目里反复加载团队分发容易二是输入灵活论文摘要、正文、实验记录、竞品对比都能作为输入三是输出结构化交底书章节固定方便工程师和专利代理师二次加工四是能批量配合脚本可以一次处理多篇论文五是门槛不算高云端 API 方案不需要本地 GPU本地模型方案则需要按显存实测。当然也有明确边界AI 生成的是草稿不是法律意见新创性和保护范围判定仍然需要人工和专业代理师介入。这篇文章会带你走一遍完整落地路径先解释 Skill 机制和 MCP 的区别再讲环境准备、安装部署、一次从论文到交底书的完整功能测试然后给出接口与批量任务的脚本思路最后列出资源占用观察和常见问题排查清单。所有代码和命令都给出可复制的通用模板具体目录和参数按你自己的代理版本调整即可。如果你正在写论文、做横向项目或者在公司里负责专利交底书整理这篇文章可以收藏后边看边操作。1. 专利撰写 Skill 核心能力速览在动手之前先把这套方案的技术画像说清楚避免期望偏差。能力项说明项目类型AI Skill 工作流包本质是带结构指令的文本模板不是独立软件运行环境Claude Code、Codex、Cursor、OpenCode 等支持 SKILL.md 的编程代理主要功能论文 Idea 转专利交底书草稿、创新点提取、权利要求草拟建议输入素材论文摘要、论文全文、实验数据、技术方案描述、竞品对比输出物结构化专利交底书 Markdown 文档通常含技术领域、背景、发明内容、实施方式、创新点等硬件需求取决于底层模型。云端 API 方案不需要本地 GPU本地模型方案按显存和模型版本实测启动方式在代理内加载 Skill 后自然对话或通过 CLI 指定 Skill 执行接口能力Skill 本身不单独提供 HTTP API调用能力跟随宿主代理的 CLI/SDK批量任务支持通过目录遍历加脚本循环逐个处理适合场景高校课题组预研、企业研发交底书整理、技术文档转专利草案合规边界AI 草稿需人工复核不构成法律意见不得提交虚假发明从这张表能看出来Skill 方案的定位不是“替代专利代理师”而是把“结构化整理”这个体力活先做完让人的精力集中在技术事实确认和法理判断上。2. 适用场景与使用边界这类专利撰写 Skill 最适用的场景有三类。第一类是高校课题组学生写完论文后可以用 Skill 快速产出交底书初稿再让导师或技术转移部门补充发明人贡献、实施细节。第二类是企业研发部门研发人员把内部技术方案提交后Skill 能先把背景技术、要解决的技术问题、技术方案逻辑梳理成稿减少专利工程师来回沟通成本。第三类是独立开发者和技术博主如果你手头有论文或开源项目也可以用它快速整理自己的技术思路判断哪些内容可能具备创新点。但它不适合做三件事。第一不适合直接决定“这个 idea 到底能不能授权”。AI 没有检索能力时无法判断现有技术是否已经公开相同方案也不能保证权利要求保护范围合理。第二不适合在没有任何技术事实支撑的情况下编造实验数据。专利交底书必须基于真实研发内容模型只能组织表达不能无中生有。第三不适合处理未获授权的机密材料。如果论文尚未公开或者涉及企业保密信息请在输入前确认知识产权归属和保密协议不要让 AI 服务意外泄露内容。这里必须强调一条合规红线专利相关材料和生成内容都有严格的版权、署名和真实性问题。不要拿侵权论文片段直接喂给模型不要虚构实验数据不要在未授权情况下把他人成果包装成自己的专利。AI 生成的草稿如果后续要提交一定要由发明人逐条核对技术事实再由具备资质的专利代理师完成法律审核。3. Skill 机制与环境准备先解决一个基础问题Skill 到底是什么为什么它比“写一段 prompt”更可靠。Skill 本质上是一个带有 SKILL.md 文件的目录。SKILL.md 用 Markdown 写清楚“这件事该怎么做”包括任务目标、输入要求、处理步骤、输出模板、注意事项。模型加载 Skill 后会把这些指令当作行为准则而不是依赖用户在对话里临时描述。这样做的优势是稳定和可复用同样的输入无论谁运行只要模型能力达标输出结构基本一致。它和 MCP 的区别也要说清楚。MCPModel Context Protocol解决的是“模型能连什么”比如连接数据库、读取文件、调用外部 APISkill 解决的是“模型该怎么干”提供的是任务流程和输出模板。两者可以叠加使用你可以用 MCP 让模型读取专利数据库或检索现有技术再用 Skill 规定交底书的撰写结构。理解这个区别排错时就不会乱。环境准备方面你需要先确认宿主代理的版本。常见方案包括Claude Code需要 Node.js 环境支持项目级和用户级 Skill 目录。Codex CLIOpenAI 官方 CLI支持通过指令目录加载 Skill配置方式取决于版本。Cursor在.cursor/skills下放置 Skill重启后生效。OpenCode支持.opencode/skill或全局配置目录。系统方面Windows、macOS、Linux 都可以。如果你使用云端 API不需要本地 GPU如果你用本地模型则需要准备足够的显存和磁盘空间具体数值以模型官网要求为准。另外因为论文可能很长建议优先选择上下文窗口在 128K 以上的模型否则后续会频繁遇到截断问题。磁盘空间几乎可以忽略Skill 本体只是几个 Markdown 文件。真正占空间的是模型文件或者代理缓存这个要看你的部署方式。4. 安装部署与启动方式下面给出一套通用的 Skill 安装流程。虽然不同代理的目录名略有区别但思路一致把 Skill 目录放到代理能识别的位置然后重启代理。先看目录结构示例。假设你的 Skill 命名为patent-drafterpatent-drafter/ ├── SKILL.md ├── templates/ │ ├── patent_disclosure_template.md │ └── claim_suggestion_template.md └── examples/ ├── input_abstract.md └── output_sample.mdSKILL.md 是核心它告诉模型“你的角色是专利交底书撰写助手必须按以下流程执行”。下面是一个可改写的模板片段--- name: patent-drafter description: 将论文或技术方案转换为结构化专利交底书草稿。 --- # 专利交底书撰写 Skill ## 任务目标 根据用户提供的论文摘要、技术方案或实验记录生成结构化专利交底书。 ## 输入要求 - 必须包含技术领域、背景技术、发明内容、实施方式、创新点。 - 如果用户输入不足先提问补充不要自行编造实验数据。 ## 处理流程 1. 提取核心技术问题。 2. 拆解创新点编号列出。 3. 根据 templates/patent_disclosure_template.md 输出交底书。 4. 最后输出权利要求草拟建议。 ## 输出模板 遵循 templates/patent_disclosure_template.md 的章节结构。实际使用时你需要把模板里的内容替换成你们团队内部交底书模板的要求。有些公司交底书还会要求“技术效果”“替代方案”“附图说明”这些都可以在模板文件里体现。安装到不同代理的命令也差不多。以 Claude Code 为例放在项目级目录# 在项目根目录创建 Skill mkdir -p .claude/skills/patent-drafter/templates mkdir -p .claude/skills/patent-drafter/examples # 将 SKILL.md、templates、examples 放入对应目录 # 重启 Claude Code 后插件会被自动识别Cursor 用户则是把 Skill 放到.cursor/skills/patent-drafter/重启 Cursor 后即可在对话中引用。Codex 和 OpenCode 的目录位置在不同版本有差异更稳妥的做法是查看你当前版本的官方文档避免写错路径。启动方式分两种。一种是在交互界面里直接说“请使用 patent-drafter Skill根据这篇论文生成交底书”另一种是用命令行非交互执行。例如# 示例命令实际路径和参数按项目调整 claude 请使用 patent-drafter Skill 生成专利交底书 \ --input-file docs/paper_abstract.md \ --output-file output/disclosure.md这里要提醒一下不同代理的 CLI 参数命名不一样不存在一份通用的命令行语法。上面的命令是示例用来解释“通过 CLI 指定输入输出”这个思路正式使用时请先跑--help确认参数。5. 功能测试与效果验证部署完成后不要直接拿真实论文去跑先准备一份测试素材。下面是示例输入仅用于验证流程不构成真实研发信息论文标题一种基于双分支注意力机制的轻量文档版面分析方法 摘要本文提出一种轻量级文档版面分析方法。该方法采用双分支结构 一个分支负责全局版面结构感知另一个分支负责局部文本区域分类。 两个分支通过注意力融合模块交互并在推理阶段配合剪枝策略减少计算量。 实验表明在公开版面数据集上达到接近主流模型的精度同时参数量降低40%。跑通一次完整的测试建议按下面几个维度来做。5.1 创新点提取测试测试目的是看模型能不能从论文里拆出可专利化的技术点。输入上面的摘要观察输出是否包含现有技术不足、本方案改进点、技术效果。预期结果是模型能给出一段类似“现有版面分析方法多依赖大模型计算量大本方案通过双分支注意力融合在保持精度的同时显著降低参数量”的归纳。如果模型只复述摘要而没有任何归纳说明 SKILL.md 中的“拆解创新点”指令不够明确可以补充要求“将每个创新点写成‘现有技术 问题 本方案 效果’四段式”。5.2 权利要求草拟测试这项测试更敏感。专利权利要求有特定写法模型容易写成技术博客式的描述。测试时要求模型分别给出“独立权利要求”和“从属权利要求”的草拟建议。判断成功的标准是独立权利要求包含必要技术特征从属权利要求增加限定细节。如果模型直接生成抽象描述没有层次说明模板文件里缺少权利要求撰写规则需要补充“先写主体结构再写可选附加特征”的提示。5.3 完整交底书生成测试输入测试论文摘要要求按模板生成完整 Markdown 文件。检查标题层级、章节完整性、内容连贯性。注意观察模型是否把“发明内容”写成了“实验结果复述”。交底书里的发明内容应该说明“是什么结构”和“为什么有效”而不是罗列实验指标。若发现输出偏向论文行文需要在 SKILL.md 里加入“禁止直接复制论文段落需重新组织为专利语言”的约束。5.4 长文档与切片测试论文全文可能几万字超过上下文窗口。常见做法是让模型先读取摘要、方法部分和实验结论忽略相关工作等辅助章节。测试时可以故意输入一篇较长的技术文档观察输出是否中断。如果中断需要把输入切片成多个阶段第一轮提取创新点第二轮根据创新点生成交底书。这个经验在批量任务时尤其重要。5.5 失败判断标准一个能用的 Skill 应该做到输入创新点清晰的论文能输出结构完整的交底书草稿输入信息不足能主动追问不会编造实验数据不会把技术特征揉成一团。如果你的测试出现了相反情况优先检查 SKILL.md 是否被正确加载其次检查模板文件是否完整。6. 接口 API 与批量任务Skill 本身没有独立的 HTTP API但宿主代理普遍提供 CLI 或 SDK 接口可以用脚本批量驱动。下面是批量处理的通用思路准备一个输入目录存放多篇论文摘要循环调用代理 CLI将每篇输出保存到独立文件写入日志和失败重试机制。一个示例 Python 脚本框架如下import subprocess from pathlib import Path input_dir Path(./papers) output_dir Path(./outputs) output_dir.mkdir(exist_okTrue) for paper in input_dir.glob(*.md): output_path output_dir / f{paper.stem}_disclosure.md cmd [ claude, 请使用 patent-drafter Skill 生成专利交底书, --input-file, str(paper), --output-file, str(output_path), ] print(fprocessing {paper.name}) result subprocess.run(cmd, capture_outputTrue, textTrue, timeout300) if result.returncode ! 0: print(ferror: {paper.name}: {result.stderr}) else: print(fdone: {paper.name})在实际项目中注意三点。第一每次调用都是独立的模型请求会消耗 token批量前先估算成本。第二CLI 命令每跑一次都要启动代理如果脚本卡住检查是否是因为模型上下文太长导致超时。第三批量任务建议加入断点续跑例如跳过outputs/下已经生成的同名文件避免重复消耗。如果你需要更工程化的方式可以考虑用 Claude Code SDK、Codex API 或 OpenCode 的 headless 模式把生成逻辑封装成内部服务。但无论怎么封装都要注意限制服务访问范围。内部接口不要直接暴露到公网加上简单的 token 鉴权并且对生成结果做日志审计。batch 任务建议的目录结构project/ ├── papers/ # 输入论文命名规范日期_作者_标题.md ├── outputs/ # 生成的交底书 ├── logs/ # 批量运行日志 └── config.yaml # 模型、超时、重试参数这里仍然要强调Skill 工作流的生成结果只是草稿批量生成的多个交底书更需要人工逐份核对不要直接走向提交流程。7. 资源占用与性能观察讨论资源占用时要把 Skill 本身和底层模型分开来看。Skill 只是一组 Markdown 指令运行时代理加载它的资源开销可以忽略不计。真正的资源消耗来自模型推理如果你使用 Claude、GPT、DeepSeek 等云端 API消耗的是 token 数和网络请求时间如果使用本地模型消耗的是显存、内存和 CPU 算力。本地部署时观察资源占用主流方式是终端里运行nvidia-smi -l 1实时看显存也可以在代理日志里开启 verbose 模式看请求耗时。显存数值取决于模型规模和推理参数不要轻信网上“某某模型固定占多少 G”的说法要以本机实际运行结果为准。就专利撰写这类任务来说输入长度往往远大于输出长度所以真正影响显存和计费的是论文输入部分。性能优化建议如下。先做文本精简论文全文往往包含大量与创新点无关的章节输入前先让模型只提取“要解决的技术问题、技术方案、技术效果”再基于精简结果生成交底书。再控制输出长度交底书不必一次写万字可以分章节生成最后合并。另外批量任务时一定要设置超时和重试因为长文档极容易出现单次请求超时。云端 API 的成本观察也要单独说。如果你每天都批量处理十篇论文最好记录每篇消耗的输入 token 和输出 token换算成费用后评估是否值得。一个更省成本的做法是先在本地用轻量模型做初步结构化只把精炼后的创新点列表交给高端模型生成交底书成本能明显下降。这也是 Skill 工作流的优势流程可控每一步都可以替换模型。8. 专利撰写 Skill 常见问题与排查方法实际跑流程时大概率会遇到下面这些坑按表格排查会更快。问题现象可能原因排查方式解决方案模型没有按 Skill 流程执行Skill 目录路径不对或代理版本不支持检查 Skill 目录是否放在正确位置查看代理启动日志是否识别到 Skill按当前代理官方文档调整目录更新代理版本输出只有论文摘要没有交底书结构SKILL.md 指令不够强或模板文件缺失查看 SKILL.md 是否明确要求按模板输出补强指令明确“必须输出技术领域、背景、发明内容等章节”生成的交底书内容全是实验复述没有区分论文行文和专利行文检查输出是否重新组织语言在 SKILL.md 中增加“禁止直接复制论文段落需按专利逻辑重组”论文过长导致输出截断上下文窗口超限查看请求日志里的 token 数量将输入切分为多轮先提取创新点再生成交底书批量任务中部分文件失败单次请求超时或网络波动查看日志中失败任务的错误信息增加超时时间和重试机制跳过已生成文件模型编造实验数据输入信息不足模型自行补全对比输出中实验数据是否来自原文在 SKILL.md 中强调“缺少数据时提问不编造”本地环境显存不足模型参数过大或上下文过长使用nvidia-smi查看显存占用使用更小模型、量化版本或切换到云端 APIAPI 调用失败或鉴权错误凭证过期或服务未启动检查 API key 和环境变量更新凭证确认服务地址正确Skill 加载后没有效果代理缓存未刷新重启代理检查 Skill 目录名称重启后重新加载确认 SKILL.md 第一行文件名正确排查时记住一个原则先确认 Skill 被真正加载再检查输入质量最后才怀疑模型能力。很多“生成效果差”的问题其实是输入论文信息密度太低模型没有可提炼的内容。9. 最佳实践与使用建议基于上面的流程几个工程化建议值得记录。第一第一次使用先用小参数测试。扔一篇摘要进去看输出结构是否符合模板再逐步扩展到全文。不要一上来就批量跑 30 篇论文否则排查问题时成本很高。第二维护一套最小可运行配置。把 SKILL.md、模板文件、示例输入输出放在同一个目录用 git 管理。团队新成员拿到后能在 10 分钟内跑通后续修改模板也有版本记录。第三输入素材和输出结果分目录管理。输入论文按日期和作者命名输出交底书按技术方向归类。这样后续追溯创新点来源时非常方便也方便专利代理师复核。第四批量任务要加日志和失败重试。不要只在终端里看输出把每次请求的时间、输入 token、输出 token、结果状态写入日志文件这样出现问题时能定位到具体论文。第五涉及内部研发信息的场景要让接口服务只在受控网络内访问。如果担心数据隐私可以选择本地模型方案不把论文内容发送到外部 API。比较敏感的公司应该先走信息安全审批流程。第六也是最重要的合规建议所有交底书必须由发明人逐条确认技术事实再由专利代理师审核法律文本。不要直接使用 AI 生成的权利要求不要提交带有虚假数据或未授权内容的申请。AI 是效率工具不是免责挡箭牌。10. 总结与下一步专利撰写 Skill 最值得尝试的点不在于“一键生成”的神奇效果而在于它把交底书这种结构密集型任务固化成了稳定可复用的工作流。一旦跑通团队里任何人都能把论文快速转换成初稿节省大量整理时间。最先验证的功能建议选创新点提取这一步最便宜、最容易看到效果也能最快暴露 SKILL.md 指令的缺陷。最容易踩的坑是 SKILL.md 放错目录导致模型根本没加载以及长论文被截断导致交底书不完整。后续扩展方向可以考虑把 Skill 和 MCP 结合接上专利检索数据库做新颖性预检增加竞品专利对比生成模块把交底书输出直接渲染成公司内部 OA 流程需要的格式。技术方案本身不复杂真正的价值在于你用起来之后能积累出属于自己团队的专利撰写 Know-how。先按上面的测试流程跑一遍把输出模板改到符合你团队要求再开始批量接入论文数据。