企业官网建设流程全解析

这次我们来看一个“专利撰写”方向的 Skill 合集。它的核心卖点很直接：把 Claude 这类大模型工具变成专利撰写助手，输入论文、技术文档或者一个 idea，就能批量产出技术交底书、权利要求书初稿、说明书摘要等专利写作环节的关键文档。如果你最近在关注 Claude Skills、GPTs 这类“给大模型配置专属技能”的玩法，那这个项目的思路值得参考。

先说重点：这个项目不是跑本地大模型，不需要 GPU，不需要部署推理服务，它封装的是“提示词 + 结构化流程 + 模板”的教学型技能包。你只需要有 Claude 账号（或者其他支持自定义 Skill 的对话产品），把 Skill 文件放进指定目录，就能让模型按照专利撰写的规范输出内容。对于高校科研人员、企业研发工程师、专利工程师和准备申请软著/专利的团队来说，这套东西的价值在于把“从 idea 到交底书”这个重复劳动变成半自动流程。

按材料看，这个“专利 Skill 合集”覆盖的场景包括：论文自动转专利、idea 快速扩展成技术方案、权利要求书生成、说明书摘要撰写、审查意见答复素材整理等。本文将带你完成以下几件事：理解 Skill 合集的项目结构和运行原理、搭建本地 Skills 配置环境、完成 idea 到交底书的生成测试、掌握论文转专利的操作流程、了解批量处理多个技术方案的脚本化思路，以及遇到 Skill 不生效、输出格式混乱、专利术语不准确等常见问题时的排查方法。

1. 核心能力速览

先给一张规格表，快速判断这个合集是否适合你。

从材料可以看出，这个项目的定位非常清楚：不是帮你写一篇完整、可直接提交的专利全文，而是把专利写作中那些“重复性强、格式要求高、逻辑链条固定”的部分自动化。它的底层逻辑是让大模型按照专利审查指南的思路去拆解技术方案，再按专利文件的格式要求重组输出。

需要注意，任何 AI 辅助专利撰写工具都不能替代专利代理师的专业审核，尤其是权利要求书的保护范围、技术特征的层级关系这些内容，最终提交前必须由专业人士把关。这个项目提供的更多是“初稿加速器”，而不是“终稿保证书”。

2. 适用场景与使用边界

2.1 适合谁用

从材料来看，这套 Skill 合集主要面向以下人群：

• 高校硕博生：论文写完但还没形成专利思路，想快速把创新点转化为专利交底书。
• 企业研发工程师：手头有技术方案但没有专利写作经验，需要先形成一份结构完整的交底书提交给知识产权部门。
• 专利工程师 / 知识产权管理人员：每天处理大量交底书，可以用这套流程做初筛和初步整理，提升处理效率。
• 科研团队负责人：需要把团队多个技术方向批量整理成专利素材，用于项目申报或专利布局。

2.2 能解决什么问题

• 创新点提炼：从一个模糊 idea 或一段技术描述出发，自动拆解技术问题、技术方案、技术效果。
• 格式规范化：按照专利交底书、权利要求书、说明书摘要等常见格式输出。
• 论文转专利初稿：输入论文摘要、正文关键段落，生成符合专利语言习惯的初稿。
• 批量处理：多个 idea 可以用脚本整理成标准输入格式，逐个生成，减少重复工作。

2.3 不适合什么场景

• 编造不存在的技术方案：如果你只有一个想法，却没有具体的实现路径，AI 生成的内容不能作为真实专利提交，因为专利必须公开充分、能够实现。
• 替代专业代理师：权利要求书的保护范围布局、权利要求的引用关系、专利审查意见答复需要专业法律判断，AI 生成的初稿只能作为参考素材。
• 涉及技术秘密的高敏感项目：不要在公司未授权的情况下，把核心技术细节输入到外部 AI 服务中。使用前务必确认信息脱敏和保密边界。
• 需要完整附图、实施例数据、对比实验结果的正式申请文件：AI 不擅长编造实验数据，没有验证的实施例不能直接写入正式申请材料。

2.4 合规与安全提醒

使用这类 Skill 合集时，请先确认三件事：一是你确实拥有该技术方案的合法来源，不侵犯他人专利权；二是输入到 AI 工具的文本不包含未经授权的第三方保密信息；三是最终提交的专利文件要经过专业审核，AI 只负责起草初稿，不拥有法律效力。任何声称“一键自动生成完整专利并直接提交”的工具都存在合规风险，这个项目的价值在于提高写作效率，而不是取代专利法律流程。

3. 环境准备与前置条件

这个项目不像本地 ComfyUI 或 TTS 服务那样需要安装 CUDA、显卡驱动，它的环境准备更简单，但也有一些关键点需要提前确认。

3.1 软件与账号准备

• 一个支持 Skills 功能的 AI 对话服务：目前 Claude 的 Skills 功能比较有代表性，你需要有可用的账号。
• 文件管理工具：用来整理 Skill 目录，日常的记事本或 VS Code 都可以。
• Python 3.10+（可选）：如果你希望做批量任务脚本，需要本地 Python 环境；如果只用交互式对话，可以不装。
• 浏览器：用来访问对话服务的 Web 界面。

3.2 理解 Skill 目录结构

从项目材料来看，“Skill”本质上是将一套指令、模板和示例打包成文件夹，放入模型服务指定的技能目录后，模型会在处理相关任务时自动加载这些技能。一个标准 Skill 文件夹通常包含：

skill-name/ ├── SKILL.md # 技能主配置，包含技能说明、角色定义、工作流程 ├── templates/ # 输出模板，例如交底书模板、权利要求书模板 ├── examples/ # 示例输入输出 ├── references/ # 专利法、审查指南等参考材料 └── scripts/ # 可选，处理输入、格式化输出的脚本

SKILL.md 是核心文件，它决定了模型在调用这个技能时的行为。你需要确认目标服务支持该格式的 Skill 定义，或者根据你使用的工具格式进行转换。

3.3 输入素材准备

专利撰写质量高度依赖输入信息的完整度。测试前先准备以下素材：

• idea / 技术方案描述：最好能明确说出“解决什么问题、用什么方法、和现有方案有什么区别”。
• 论文摘要和正文：如果做论文转专利，准备论文的摘要、引言、方法、实验结果部分。
• 关键词和领域背景：帮助模型理解技术上下文。

4. 安装部署与启动方式

这部分以 Claude Skills 为例，给出通用配置流程。如果你使用其他支持自定义技能的模型服务，目录结构和配置格式请以官方文档为准。

4.1 创建 Skills 目录并放入文件

先确认你的技能目录路径。以 Claude 桌面版或支持 Skills 的版本为例，通常在用户配置目录下有一个claude/skills或类似路径。以下是通用操作流程：

# 进入你的模型服务配置目录，比如 ~/.claude/ cd ~/.claude/ # 创建 skills 目录 mkdir -p skills # 将专利 Skill 合集解压后放入该目录 # 例如： # skills/patent-drafting/SKILL.md # skills/patent-drafting/templates/...

放入后，可以用ls检查目录结构：

find skills/patent-drafting -type f | head -20

如果一切正常，你会看到类似下面的文件列表：

skills/patent-drafting/SKILL.md skills/patent-drafting/templates/claim_template.md skills/patent-drafting/templates/disclosure_template.md skills/patent-drafting/examples/example_idea_to_disclosure.md skills/patent-drafting/references/patent_law_notes.md

4.2 SKILL.md 配置示例

SKILL.md 是触发技能的配置核心。其通用格式如下，实际内容需要根据你的工具版本调整：

--- name: patent-drafting description: 用于辅助专利交底书、权利要求书和说明书摘要撰写的技能，输入 idea 或论文即可生成结构化专利初稿。 --- # 专利撰写助手 ## 角色 你是一名资深专利代理师，熟悉中国专利法、专利审查指南和专利撰写规范。 ## 工作流程 1. 接收用户输入的 idea、技术方案或论文文本。 2. 提取关键信息：技术领域、背景技术、技术问题、技术方案、技术效果。 3. 按照用户指定的输出格式生成专利初稿。 4. 标注信息不完整的部分，提醒用户补充。 ## 输入要求 - 明确技术问题。 - 提供技术方案的关键步骤或结构组成。 - 如有对比方案，说明区别。 ## 输出模板 使用 templates 目录下的模板文件。

这个配置的作用不是增加什么黑科技，而是给模型一个稳定的“工作记忆”：你的角色、输入要求、输出流程、质量维度都写清楚了，模型在处理任务时就有据可依。

4.3 在对话中引用 Skill

不同服务对 Skill 的引用方式不同。在支持 @ 引用技能的服务中，你可以在提示词中直接写：

请使用专利撰写Skill，将以下idea生成一份技术交底书： idea：一种基于边缘计算的设备状态监测方法，通过在设备端部署轻量级模型...

模型会自动加载 patent-drafting 技能，并按照 SKILL.md 中定义的角色和工作流来处理任务。如果服务不支持自动加载，你可能需要把 SKILL.md 的内容以系统指令的方式手动粘贴到对话中。

4.4 验证启动是否成功

如何判断 Skill 已经被正确加载？可以问一个和技能强相关的问题，例如：

请说明专利撰写技能的工作流程，以及它能输出哪些类型的文件。

如果输出里提到了“技术交底书、权利要求书、说明书摘要”等技能内容，说明 Skill 已经生效。如果输出的是普通对话回复，说明 Skill 没有被加载，需要检查目录路径、文件名命名和配置格式。

5. 功能测试与效果验证

Skill 配置好后，建议按顺序测试三个核心场景：idea 到技术交底书、论文转专利、权利要求书生成。每个测试都要带上输入示例、操作流程和判断标准。

5.1 测试一：idea 到技术交底书

测试目的：验证 Skill 能否从一个模糊 idea 生成结构化交底书。

输入示例：

请将以下 idea 生成一份技术交底书： idea：一种基于手机摄像头的食品新鲜度检测方法，不需要额外硬件，用户用手机拍照就能判断蔬果是否新鲜。

操作步骤：

1. 在对话中输入上述指令。
2. 观察模型是否调用了专利撰写技能。
3. 检查输出是否包含技术领域、背景技术、技术问题、技术方案、技术效果等标准章节。
4. 重点检查技术方案部分是否足够具体，有没有给出可行的实现路径。

判断成功的标准：

• 输出包含交底书标准章节。
• 技术方案部分描述了至少 2 到 3 个关键步骤或模块。
• 模型指出了信息不完整的地方，例如缺少具体算法、缺少对比实验。

常见失败原因：

• 输入过于笼统，没有提供任何实现细节，导致模型只能生成泛泛的框架。
• Skill 未加载，输出回到了普通对话模式，这时候需要检查技能调用方式。

5.2 测试二：论文转专利

测试目的：验证论文摘要或正文能否被转换为专利语言风格的初稿。

输入示例：

请阅读以下论文摘要，将其转换为专利交底书的背景技术和技术方案部分： 论文题目：基于深度学习的低光照图像增强方法 摘要：本文提出一种基于改进Retinex理论的低光照图像增强方法，通过联合优化光照分量和反射分量...

操作步骤：

1. 提供论文摘要，最好附上方法部分的关键段落。
2. 要求模型只在限定范围内生成交底书章节。
3. 对照原论文检查是否有技术特征遗漏。
4. 检查专利语言是否符合规范，比如“其特征在于”“所述”等表达的使用。

判断成功的标准：

• 背景技术部分能清晰说明现有技术的不足，而不是简单复制论文的“引言”。
• 技术方案部分描述了方法的关键步骤，并且步骤之间有逻辑关联。
• 没有照搬论文中的实验数据来冒充专利实施例。

常见失败原因：

• 论文内容未提供关键技术细节，模型只能根据标题和摘要猜测。
• 专利术语使用不当，例如把深度学习模型的“训练集”直接写成专利中的“实施例”，需要人工调整。

5.3 测试三：权利要求书生成

测试目的：验证 Skill 能否生成格式正确、层次清楚的权利要求书初稿。

输入示例：

根据以下技术方案，生成独立权利要求1和从属权利要求2-4： 技术方案：一种基于注意力机制的文本情感分析方法，包括以下步骤： 1. 获取待分析文本，对文本进行预处理... 2. 使用预训练语言模型提取文本特征... 3. 通过注意力机制加权融合文本特征... 4. 根据融合特征输出情感分类结果...

操作步骤：

1. 输入技术方案步骤。
2. 检查独立权利要求是否包含全部必要技术特征。
3. 检查从属权利要求的引用关系和附加技术特征是否合理。
4. 看模型是否对不确定性内容进行标注。

判断成功的标准：

• 独立权利要求包含了解决技术问题所必需的步骤。
• 从属权利要求的引用关系正确，格式符合“根据权利要求1所述的...”。
• 没有引入方案中不存在的技术特征。

常见失败原因：

• 技术方案本身太简单，模型生成的权利要求保护范围过大或过小。
• 模型把可选方案写成了必要技术特征，导致独立权利要求保护范围不当。这里需要人工判断调整。

5.4 测试四：质量复核

生成的初稿不能直接提交，你需要做四步复核：

1. 技术真实性：方案是否真的能实现，有没有虚构的算法或实验数据。
2. 信息完整性：是否有明显缺失的技术特征，例如缺少通信接口、数据结构定义、具体参数范围。
3. 专利语言规范性：是否用了口语化表达，例如“这个模块可以...”应改为“所述模块用于...”。
4. 保护范围合理性：独立权利要求是否太宽或太窄，和现有技术的区别是否清楚。

6. 接口 API 与批量任务

从项目材料来看，这个 Skill 合集本身更多是面向交互式对话设计，但如果你希望将专利撰写能力集成到自己的脚本或内部工具中，可以通过模型服务提供的 API 来实现批量处理。下面给出一套通用的批量任务设计思路，需要按你实际使用的模型服务调整。

6.1 批量输入预处理

批量处理的核心是先把多个 idea 或论文片段整理成结构化的输入文件。下面是一个通用的 Python 脚本示例，用于从多个文本文件中构建批量任务输入：

# -*- coding: utf-8 -*- import json import os def build_batch_input(input_dir, output_file): """ 将 input_dir 下的每个 .txt 文件转换为批量任务输入 JSON。 文件名作为任务 id，内容作为输入文本。 """ tasks = [] for filename in os.listdir(input_dir): if not filename.endswith(".txt"): continue file_path = os.path.join(input_dir, filename) with open(file_path, "r", encoding="utf-8") as f: content = f.read().strip() if not content: continue tasks.append({ "custom_id": filename.replace(".txt", ""), "content": content, "task_type": "idea_to_disclosure" }) with open(output_file, "w", encoding="utf-8") as f: json.dump(tasks, f, ensure_ascii=False, indent=2) print(f"批量任务已生成：{output_file}，共 {len(tasks)} 个任务。") if __name__ == "__main__": # 用法：将多个 txt 放到 ./ideas 目录，然后运行脚本 build_batch_input("./ideas", "./batch_tasks.json")

生成的batch_tasks.json结构如下：

[ { "custom_id": "idea_edge_ai", "content": "一种基于边缘计算的设备状态监测方法...", "task_type": "idea_to_disclosure" }, { "custom_id": "idea_vision_sorting", "content": "一种基于视觉识别的垃圾自动分类装置...", "task_type": "idea_to_disclosure" } ]

6.2 批量调用模型 API

如果你有模型服务的 API Key，可以写一个批量调用脚本，逐条调用对话接口，并将结果保存到指定目录。以下是通用模板：

# -*- coding: utf-8 -*- import json import time import requests API_URL = "https://api.example.com/v1/messages" # 替换为实际 API 地址 API_KEY = "your-api-key" # 从环境变量读取，不要硬编码 def generate_patent_draft(task): """ 调用模型服务生成专利初稿。 实际参数需要按你使用的服务调整。 """ headers = { "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json" } # 这里需要根据实际模型服务的接口格式来修改 payload = { "model": "your-model-name", "max_tokens": 4000, "messages": [ { "role": "system", "content": "你是一名资深专利代理师，请按照专利撰写技能的要求处理用户输入。" }, { "role": "user", "content": f"请将以下 idea 生成技术交底书：\n{task['content']}" } ] } try: resp = requests.post(API_URL, json=payload, headers=headers, timeout=120) resp.raise_for_status() result = resp.json() return result["choices"][0]["message"]["content"] except Exception as e: return f"ERROR: {e}" if __name__ == "__main__": with open("./batch_tasks.json", "r", encoding="utf-8") as f: tasks = json.load(f) for task in tasks: print(f"正在处理任务：{task['custom_id']}") output = generate_patent_draft(task) with open(f"./outputs/{task['custom_id']}.md", "w", encoding="utf-8") as f: f.write(output) # 避免请求过于密集，加入延时 time.sleep(2) print("所有批量任务处理完成。")

批量任务设计时要考虑三点：第一，API Key 不要写死在代码里，通过环境变量读取；第二，每个任务建议加上独立日志，方便定位失败原因；第三，模型输出可能包含错误或不完整内容，建议在输出后增加一个_review标记文件，提醒人工复核。

6.3 批量结果核对

批量生成完成后，建议增加一个结果核对表，标记每个任务的状态：

# 检查哪些任务没有正常生成 ls ./outputs/*.md | wc -l # 检查哪些文件包含错误标记 grep -l "ERROR" ./outputs/*.md

这样能快速筛选出需要重新生成或需要人工处理的任务。

7. Token 消耗与效果优化策略

这个项目虽然不需要显卡显存，但它在运行时的“资源”同样需要关注——上下文窗口和 Token 消耗。专利撰写任务往往涉及长文本输入和长文本输出，很容易触达模型上下文上限。

7.1 长文本分段策略

如果输入是一整篇论文，不建议一次性塞给模型。更稳妥的做法是分段处理：

1. 先输入论文摘要和引言，生成背景技术部分。
2. 再输入方法部分，生成技术方案部分。
3. 最后输入实验部分，整理技术效果和实施例素材。

这样分步生成的优点是：每一段的输入输出都在可控长度内，模型能够更集中地处理当前章节，输出质量也比一次性生成完整文档更高。

7.2 控制输出长度

权利要求书、说明书摘要等输出内容有固定格式，可以通过提示词明确长度要求。例如：

• “权利要求书初稿，独立权利要求控制在 300 字以内。”
• “说明书摘要不超过 300 字，包含技术领域、技术方案、技术效果三部分。”

7.3 模板复用

如果同一个技术领域有多个 idea，建议先让模型基于第一个 idea 生成一份“标准模板”，后续任务在模板基础上替换技术特征。这样既能保持一致的语言风格，也能减少重复的格式化指令。

7.4 小成本验证

首次测试时，先用一个简单 idea 跑通流程，确认输出格式和语言风格符合要求后，再扩展到批量任务。如果一开始就塞入大量复杂任务，可能会消耗大量 Token 却得不到理想效果。

8. 常见问题与排查方法

9. 最佳实践与使用建议

9.1 先做技术方案整理，再让 AI 生成

这个项目效果好不好，最关键的因素不是你用的模型多强，而是你的输入多完整。建议在让 AI 生成专利初稿之前，先人工整理一份技术方案要点，包括以下内容：

• 技术问题：现有技术存在什么缺陷。
• 技术方案：解决该问题的关键技术手段，最好量化到步骤级。
• 技术效果：与现有技术对比的优势。
• 可替代方案：除主要方案外，还有哪些实现路径。

9.2 分步生成，逐段审核

专利撰写不是一次对话能完成的。建议按照“技术方案整理 -> 技术交底书 -> 权利要求书 -> 说明书摘要 -> 实施例补充”的顺序分步生成，每个步骤单独审核，避免错误累积。

9.3 建立自己的专利写作模板库

不同技术领域的专利写法差异很大。算法类、硬件类、材料类、软件流程类的交底书侧重点不同。建议使用一段时间后，把好的输出结果沉淀为模板，补充到 Skill 合集的 templates 目录中，形成属于你自己的领域适配模板。

9.4 关注合规与保密

在将技术内容输入 AI 工具前，务必确认：该技术方案是否可以对外披露；公司或实验室是否有保密规定；输入内容是否涉及第三方未公开信息。对于重要专利，建议使用支持私有部署的模型服务，或使用经过脱敏处理的描述进行测试。

9.5 不要跳过人工复核

AI 生成的专利初稿可以帮助你解决“格式怎么搭、逻辑怎么理”的问题，但以下内容必须人工确认：权利要求的保护范围是否合适、技术特征是否有遗漏、实施例是否真实可信、是否与现有技术构成实质区别。专利权是排他性权利，撰写质量直接影响保护力度，不能完全依赖 AI 生成结果。

10. 总结与下一步

这个专利 Skill 合集最值得尝试的地方，是它把专利写作中“结构化程度高、重复性强”的部分变成了半自动流程。它的部署门槛很低，不需要 GPU 和复杂的本地环境，核心工作在于配置好 Skill 指令、整理好输入素材、设计好人工复核流程。

最先应该验证的是“idea 到技术交底书”这个基础流程。拿一个你手头真实的技术方案，按照本文第 5 节的测试方法跑一遍，重点看三件事：输出结构是否符合专利交底书格式、技术方案部分是否具体可执行、模型是否主动指出信息缺失的地方。这三项过关，再扩展测试论文转专利和权利要求书生成。

最容易踩的坑有两个：一是输入信息太少，期望 AI 从一个模糊概念直接生成完整专利，结果得到一堆正确的废话；二是不做人工复核，把 AI 生成的初稿当作最终稿提交，导致专利权保护范围出问题。这两个坑都可以通过“先整理技术方案、再分步生成、最后逐段审核”的流程规避。

后续可以继续尝试的方向包括：把批量脚本和模型 API 打通，形成一套内部专利交底书自助生成平台；将 Skill 合集中的模板按技术领域做细分，沉淀出算法类、硬件类、材料类等专属模板；结合专利检索工具，在生成交底书前先检索现有技术，辅助判断创新点的新颖性。

这套 Skill 的定位是“专利写作加速器”，不是“专利提交全自动生产线”。把它用好的关键，是你自己对技术方案的理解深度，AI 负责把理解转化为结构清晰的初稿，你负责把关技术真实性和法律合规边界。