xwZhang

---
name: patent-writer
description: 中文专利交底书撰写助手。支持两种模式：(1) 方向模式：用户给出技术方向，自动搜索并推荐创新点供选择；(2) 明确想法模式：用户已有明确发明构思，直接进入撰写流程。触发词：写专利、专利撰写、专利交底书、发明点推荐、帮我写个专利。
---

# Patent Writer - 中文专利撰写助手

全流程中文专利交底书撰写，支持从零开始找发明点，或基于明确想法直接撰写。

## 工作流程

```
输入分析 → 现有技术检索 → 创新点提炼 → 大纲规划 → 分节撰写(逐节确认) → 统稿输出 → 概要描述 → 生成docx
```

**注意：** 架构图在撰写完"2.1 发明内容"后生成，概要描述在专利交底书完成后撰写。

---

## 第一步：输入分析

判断用户输入类型：

### 模式A：方向模式
用户只给出技术方向，如：
- "我想写一篇根因定位的专利"
- "帮我找个大模型推理加速方向的专利点"

**执行流程：**
1. 使用 `research-lit` 或 `arxiv` skill 搜索该方向最新论文和技术
2. 分析现有技术问题和空白
3. 推荐 3-5 个创新方向
4. 用户选择后，进入第二步

### 模式B：明确想法模式
用户已有明确发明构思，如：
- "我想写一个多模态数据融合的根因分析智能体的专利"
- "帮我写个基于AST的代码分块方法的专利"

**执行流程：**
1. 确认技术方案核心要点
2. 直接进入第二步

---

## 第二步：现有技术检索

**目标：** 确保技术背景真实、有据可查

### 检索来源
1. **学术论文**：使用 `arxiv` skill 搜索 arXiv 论文
2. **技术文献**：使用 `research-lit` skill 搜索相关文献
3. **网页搜索**：使用 `web_search` 搜索技术博客、专利公开等

### 检索策略
- 使用中英文关键词各搜索一次
- 限定时间范围（近2-3年为主）
- 记录论文标题、作者、年份、核心贡献

**重要：** 必须使用真实检索工具，不可编造论文信息。

---

## 第三步：创新点提炼

**目标：** 明确技术方案的核心创新和保护范围

输出内容包括：技术问题、技术方案概述、核心创新点（3-5个）、权利要求层次规划。

确认后进入大纲规划阶段。

---

## 第四步：大纲规划

**目标：** 按模板生成大纲，分配字数

参见 `references/template.md` 获取完整大纲模板。

### 字数分配（总计约16000字）

| 章节 | 字数 |
|------|------|
| 缩略语定义 | ~150字 |
| 技术背景 | ~2000字 |
| 发明内容 | ~1000字 |
| 具体实施方式 | ~8000字 |
| 系统流程 | ~2000字 |
| 有益效果 | ~1200字 |
| 创新点与权利要求 | ~1300字 |

**关键要求：** 必须确保总字数达到16000字左右，各章节字数不得大幅低于目标。字数统计以中文字符为准，不含标点符号、空格、markdown格式符号。

**关于实施示例：** 不单独成节，而是在各关键技术点讲解完后，紧跟简短示例说明。例如，在"轨迹语义解析方法"小节末尾，用2-3句话演示关键步骤。

---

## 第五步：分节撰写

**目标：** 逐节撰写，每节确认后继续

### 执行方式

1. 按大纲顺序，每次撰写一节
2. 撰写完成后展示给用户确认
3. 用户确认后进入下一节
4. 如用户提出修改，修改后再次确认

### 写作风格要求（重要）

**格式要求：**
- 采用自然段落写作，避免过多的分条列举
- 每个自然段应内容充实，通常5-10句话
- 减少 markdown 格式痕迹，输出应是流畅的技术文档
- 段落之间应有逻辑衔接，使用过渡句

**语言要求：**
- 技术文档风格，客观准确，语言正式规范
- 使用完整的句子和段落，避免碎片化表达
- 句号应在自然段落的末尾或完整句子之后，避免突兀出现
- 术语首次出现时给出定义，后续使用保持一致
- 禁止口语化表达，参见 `references/writing-guide.md`

**具体实施方式的特殊要求：**

"具体实施方式"是专利的核心部分，必须做到真正"具体"。写作时应遵循以下原则：

1. **技术细节充分展开**：每个技术点都要深入阐述其实现原理、数据结构、算法步骤、关键参数等。不能只说"采用XX方法"，必须说明该方法的具体实现。

2. **数学公式与形式化定义**：对于复杂算法，应给出数学公式表达；对于核心数据结构，应给出形式化定义。这是技术深度的重要体现。

3. **避免流水账式描述**：不要只罗列步骤名称，要解释每个步骤的原理、为什么要这样设计、有哪些技术考量。

4. **包含技术参数和边界条件**：如适用，应给出具体的技术参数（阈值、权重、时间复杂度等）和边界条件的处理方式。

5. **举例说明**：对复杂的技术方案，应在技术点讲解后紧跟简短示例说明其工作过程。

6. **字数保障**：具体实施方式部分约8000字，是专利最核心的部分，必须写得充分、详尽。

### 架构图生成时机

在撰写完"2.1 发明内容"章节后，暂停撰写，生成技术架构图。架构图用于直观展示系统组成和模块关系。参见 `references/architecture-guide.md` 获取架构图绘制指南。生成后继续撰写后续章节。

### 撰写要点

参见 `references/writing-guide.md` 获取撰写规范。

---

## 第六步：统稿输出

**目标：** 整合全文，格式化输出

### 执行内容

1. 汇总所有章节
2. 检查前后一致性
3. 生成缩略语表（如有）
4. 统一格式和编号
5. 统计总字数，确保达到16000字左右

---

## 第七步：概要描述

**目标：** 基于已完成的专利交底书，生成概要描述

**时机：** 在专利交底书完成并统稿后进行。

参见 `references/proposal-summary-template.md` 获取完整模板。

### 输出内容

概要描述是对专利交底书的高度概括，用于初评和立项。内容来源于已完成的交底书，但需要用更精炼的语言重新组织。

全文约1500-2000字。

输出文件：概要描述.md + 概要描述.docx

---

## 第八步：生成 DOCX 文件

**目标：** 将 Markdown 文稿转换为格式化的 Word 文档

### 执行步骤

1. 确认最终文稿
2. 使用 pandoc 将 Markdown 转为 docx
3. 输出专利交底书和概要描述的 docx 文件

### 输出格式

```
✅ 文件已生成：

专利交底书：
- Markdown：{项目目录}/专利交底书.md
- Word文档：{项目目录}/专利交底书.docx

概要描述：
- Markdown：{项目目录}/概要描述.md
- Word文档：{项目目录}/概要描述.docx

架构图：{项目目录}/figures/architecture.svg

文件位置：/Users/zxw/.openclaw/workspace/patents/{项目名称}/
```

---

## Resources

### references/
- `template.md` - 专利大纲模板，包含完整结构和字数分配
- `writing-guide.md` - 撰写规范，包含语言风格、技术描述要点、技术深度要求等
- `architecture-guide.md` - 架构图绘制指南
- `template.docx` - Word 参考模板，定义标题、正文等样式
- `proposal-summary-template.md` - 概要描述模板
- `proposal-summary-example.md` - 概要描述示例

### scripts/
- `md2docx.sh` - Markdown 转 docx 脚本
FILE:package.json
{
  "name": "patent-writer",
  "version": "1.0.0",
  "description": "中文专利交底书撰写助手。支持方向模式和明确想法模式，自动检索现有技术、提炼创新点、生成结构化技能文件。",
  "author": "your-name",
  "repository": "https://github.com/your-repo/patent-writer",
  "keywords": ["patent", "写作", "专利", "AI"],
  "dependencies": {
    "system": ["pandoc"]
  },
  "optionalDependencies": {
    "skills": ["arxiv", "research-lit"]
  }
}
FILE:references/architecture-guide.md
# 架构图绘制指南

架构图是专利交底书的重要组成部分，用于直观展示系统的组成结构和模块关系。一份专业的架构图能够帮助审查员快速理解技术方案，提升专利的可读性和说服力。

## 一、图表类型选择

根据技术方案的特点，选择合适的图表类型：

### 1.1 系统架构图

适用于展示系统的整体组成和层次结构。

**特点：**
- 分层展示，通常从上到下或从左到右
- 展示模块、子系统、组件的组成关系
- 使用矩形框表示模块，箭头或连线表示关系

**适用场景：**
- 展示"系统包括哪些模块"
- 展示"模块之间的层次关系"
- 展示"系统的整体架构"

### 1.2 数据流图

适用于展示数据在系统中的流动和处理过程。

**特点：**
- 以数据流为主线
- 展示数据的输入、处理、输出过程
- 使用圆形或椭圆表示处理节点，箭头表示数据流向

**适用场景：**
- 展示"数据如何在系统中流转"
- 展示"数据处理的具体步骤"
- 展示"输入到输出的转换过程"

### 1.3 模块交互图

适用于展示模块之间的调用和交互关系。

**特点：**
- 类似UML时序图或协作图
- 展示模块之间的消息传递和方法调用
- 使用箭头标注调用关系和数据传递

**适用场景：**
- 展示"模块之间如何协作"
- 展示"处理流程中的模块调用顺序"
- 展示"接口和协议设计"

## 二、绘图规范

### 2.1 整体风格

专利文档的架构图应遵循以下风格原则：

**配色方案：**
- 主色调：黑色、深灰色（#333333）
- 辅助色：浅灰色（#666666、#999999）
- 强调色：可选一种彩色用于突出重点（如蓝色#1976D2、绿色#388E3C）
- 背景：纯白色（#FFFFFF）
- 避免使用过多颜色，建议不超过3种主色

**线条规范：**
- 边框线条：1.5-2px，实线
- 连接线：1-1.5px，实线或虚线
- 箭头：三角形，大小适中，填充色与线条一致
- 圆角：模块框使用圆角矩形，圆角半径4-8px

**字体规范：**
- 字体：Arial、Helvetica或黑体
- 标题字号：14-16pt，加粗
- 正文字号：10-12pt，常规
- 标注字号：8-10pt，常规或斜体
- 避免在图中使用过多文字

**尺寸规范：**
- 画布宽度：800-1000px
- 画布高度：根据内容自适应，通常400-600px
- 模块尺寸：宽度100-150px，高度50-80px
- 模块间距：至少40px

### 2.2 模块绘制

**矩形模块：**
- 使用圆角矩形
- 填充色：浅色（如#F5F5F5、#E3F2FD）
- 边框：深灰色或彩色
- 模块名称居中显示
- 可在模块下方添加简短说明

**分组模块：**
- 使用虚线矩形框住相关模块
- 框内添加分组标签（如"数据层"、"处理层"）
- 分组标签置于左上角或顶部居中

**层次结构：**
- 从上到下：输入层→处理层→输出层
- 从左到右：数据源→处理模块→结果输出
- 层次之间使用间隔线或背景色区分

### 2.3 连线与箭头

**连线类型：**
- 实线：表示数据流或调用关系
- 虚线：表示依赖关系或可选路径
- 粗实线：表示主要数据流
- 双向箭头：表示双向数据传递

**箭头方向：**
- 数据流图：箭头指向数据流动方向
- 调用关系图：箭头指向被调用模块
- 层次结构图：箭头通常向下或向右

**连线标签：**
- 在连线旁添加简短标签说明数据类型
- 标签使用小字号，斜体
- 避免连线交叉，必要时调整布局

## 三、绘制工具与输出格式

### 3.1 推荐工具

**专业绘图工具：**
- draw.io（免费在线工具，支持导出多种格式）
- ProcessOn（国内在线工具，协作方便）
- Lucidchart（专业图表工具）
- Visio（Microsoft Office套件）

**代码生成工具：**
- Graphviz/DOT语言（适合自动生成）
- Mermaid（Markdown内嵌图表）
- PlantUML（UML图表生成）

**注意：** 本skill当前使用SVG手绘方式，输出矢量格式。后续可集成专业工具生成更精美的图表。

### 3.2 输出格式

**首选格式：SVG（可缩放矢量图形）**

优点：
- 矢量格式，无损缩放
- 文件小，易于嵌入文档
- 可用文本编辑器修改
- pandoc可直接嵌入docx

**备选格式：**
- PNG：位图格式，分辨率需≥300dpi
- PDF：矢量格式，适合打印
- EMF：Windows矢量格式，适合Word

### 3.3 文件命名与存储

```
{项目目录}/figures/
├── architecture.svg      # 系统架构图（必需）
├── dataflow.svg          # 数据流图（可选）
├── module-interaction.svg # 模块交互图（可选）
└── algorithm.svg         # 算法流程图（可选）
```

## 四、绘制检查清单

绘制完成后，检查以下要点：

**内容完整性：**
- [ ] 所有核心模块都已包含
- [ ] 模块名称准确、简洁
- [ ] 关键连线都已标注
- [ ] 输入输出清晰标明

**视觉美观性：**
- [ ] 布局平衡，无过多空白
- [ ] 模块大小一致或符合层次
- [ ] 连线无交叉或交叉最少
- [ ] 文字可读，无遮挡

**技术准确性：**
- [ ] 模块划分与技术描述一致
- [ ] 数据流向正确
- [ ] 接口标注准确
- [ ] 层次关系清晰

**格式规范性：**
- [ ] 配色方案一致
- [ ] 字体字号统一
- [ ] 线条粗细适中
- [ ] 输出格式正确（SVG）

## 五、示例模板

### 5.1 三层架构图模板

```
┌─────────────────────────────────────┐
│            输入层                    │
│  [数据源1]  [数据源2]  [数据源3]      │
└──────────────┬──────────────────────┘
               ↓
┌─────────────────────────────────────┐
│            处理层                    │
│  ┌─────────┐  ┌─────────┐           │
│  │ 模块A   │→│ 模块B   │            │
│  └─────────┘  └─────────┘           │
│       ↓            ↓                 │
│  ┌─────────┐  ┌─────────┐           │
│  │ 模块C   │←│ 模块D   │            │
│  └─────────┘  └─────────┘           │
└──────────────┬──────────────────────┘
               ↓
┌─────────────────────────────────────┐
│            输出层                    │
│       [输出结果]                      │
└─────────────────────────────────────┘
```

### 5.2 数据流图模板

```
[输入数据] → (处理1) → [中间数据] → (处理2) → [输出结果]
                ↓
           [辅助数据]
```

---

**提示：** 实际绘制时，应根据技术方案的具体特点调整图表类型和内容，确保图表能够准确、清晰地传达技术方案的精髓。
FILE:references/proposal-summary-example.md
# 专利提案概要描述示例

---

## 提案名称

一种基于云原生架构的推理编排中间件系统及方法

---

## 一、技术领域

云平台

---

## 二、六个维度的优点和价值描述

### （1）潜在市场

随着大语言模型在各行业的深度融合，企业级私有云环境对构建自主可控、高效稳定的AI推理平台的需求日益迫切。本方案主要面向拥有私有化部署需求的大中型企业、金融机构、政府部门及科研单位。这些组织在应用AI时，普遍面临多业务线共享昂贵计算资源、保障数据安全与服务隔离的挑战。本技术填补了通用云管平台在AI推理领域专业调度能力的空白，为这个持续增长的市场提供了一个标准化的中间件解决方案，应用前景广阔。

### （2）解决问题的价值

本方案的核心价值在于，将传统粗放式的AI推理资源管理，转变为精细化、自动化的服务编排。它解决了多租户环境下因资源抢占导致的服务质量抖动问题，通过突破单卡显存瓶颈，使得处理长文本、高分辨率任务成为可能。同时，高效的多模型管理能力，极大地促进了模型在不同业务场景的复用与迭代。最终，本方案帮助企业构建了一个稳定、高效、可预测的AI基础设施底座，显著提升了AI服务的整体投资回报率。

### （3）节省成本

本方案通过多种机制实现显著的成本节约。首先，智能化的调度与资源复用技术，大幅提升了GPU等昂贵硬件的利用率，减少了企业所需的物理服务器采购数量。其次，全自动的AIOps闭环控制，降低了对顶尖运维专家的依赖，减少了日常排障和性能调优的人力开支。此外，通过支持多业务共享基础设施，避免了为每个新应用重复建设推理环境的巨大投入，从而在硬件、人力和运维三个维度上全面降低了企业的TCO（总拥有成本）。

### （4）先进性

本方案的先进性体现在其体系化的设计理念。它没有停留在单一算法或工具的优化，而是借鉴了成熟的网络架构思想，首次将"控制面"与"数据面"分离的理念系统性地引入大模型推理领域。通过将推理过程解构为"预填充"和"解码"两个独立阶段并进行差异化调度，实现了对异构资源的深度优化。其内置的AIOps闭环调优机制，使系统具备了自我演进的能力，从被动响应升级为主动治理，代表了AI基础设施管理的前沿方向。

### （5）创新性

本方案包含多项关键技术创新。首先，独创的"多LoRA适配器池与热插拔管理"机制，通过类似内存插槽的设计，解决了多模型服务场景下频繁切换的巨大开销。其次，"长序列KV缓存分层与一致性管理"架构，通过软硬件协同，巧妙地突破了物理显存的容量限制，是应对超长上下文推理的独创方案。最后，将"动态批处理"与"并行策略"进行联动编排，实现了吞吐量与时延双重目标的动态自适应优化，具有显著的原创性。

### （6）可实现性

该技术方案具备高度的可实现性。其架构设计遵循云原生领域的成熟范式，如Sidecar代理、守护进程等，易于在现有的虚拟化或容器化环境中部署。方案设计的各模块功能界限清晰，可分阶段实施，支持从旁路接入逐步演进至全面接管，降低了项目落地风险。此外，它不依赖于特定的硬件或需要深度修改的操作系统内核，具有良好的通用性和兼容性，确保了在主流私有云技术栈上的平滑集成与稳定运行。

---

## 三、初评推荐情况

### （1）评审专家

亓开元、冯振、徐冠群

### （2）初评得分

96

### （3）专家评价

我们认为，本技术方案为企业私有云环境中的大模型推理服务，提供了一套体系化的工程解决方案。它超越了零散的单点优化，构建了完整的闭环编排框架。控制面与数据面的分离设计，兼顾了全局调度的可扩展性与单次请求的低时延。其中，针对预填充与解码阶段的分离调度、面向长序列的分层缓存以及LoRA动态管理等创新点，均精准地切中了当前行业在资源效率与服务稳定性方面的核心痛痛点。方案强调的非侵入式集成与AIOps闭环理念，使其具备很强的工程实践价值。我们评估，该系统能有效降低企业构建共享式、高性能大模型服务平台的门槛，是AI基础设施领域一次有价值的探索和前进。
FILE:references/proposal-summary-template.md
# 专利提案概要描述模板

---

## 提案名称

{专利名称}

---

## 一、技术领域

从以下类型中选择一项：

**硬件类：** 硬件、固件、电源、机构设计、信号、EMC&Safety、测试、PCB/PCBA、FPGA、人工智能、存储硬件

**软件类：** AI、HPC、安全、存储软件、大数据、管理软件、虚拟化、云平台

---

## 二、六个维度的优点和价值描述

### （1）潜在市场

目标行业、客户群体、市场空白、应用前景（约150-200字）

### （2）解决问题的价值

核心问题、解决方案思路、关键效果、最终价值（约150-200字）

### （3）节省成本

成本节约的具体机制和效果（约150-200字）

### （4）先进性

设计理念的先进性、与现有技术对比、技术发展方向（约150-200字）

### （5）创新性

2-4个关键技术创新点及其技术特征（约200-250字）

### （6）可实现性

技术成熟度、实施路径、兼容性、落地风险（约150-200字）

---

## 三、初评推荐情况

### （1）评审专家

{专家姓名1}、{专家姓名2}、{专家姓名3}

### （2）初评得分

{分数}/100

### （3）专家评价

整体评价、创新点认可、工程价值、应用前景（约200-300字）

---

**全文约1500-2000字**

完整示例见：`references/proposal-summary-example.md`
FILE:references/template.md
# 专利交底书大纲模板

**全篇字数要求：约16000字**

---

## 二、缩略语和关键术语定义（约150字，5-6个）

格式：
- **缩略语**：完整英文表述（中文译文）

示例：
- **AST**：Abstract Syntax Tree（抽象语法树）
- **RAG**：Retrieval-Augmented Generation（检索增强生成）

---

## 三、正文（约16000字）

### 1、相关技术背景以及最接近的现有技术（约2000字）

#### 1.1 技术背景
- 所属技术领域介绍
- 技术发展现状
- 应用场景说明

#### 1.2 现有技术方案
- 主流技术路线1
- 主流技术路线2
- 其他相关技术

#### 1.3 现有技术的问题与不足
- 问题1：{描述}
- 问题2：{描述}
- 问题3：{描述}

综上所述，{总结现有技术的核心痛点}。

---

### 2、本发明技术方案的详细阐述（约13500字）

#### 2.1 发明内容（约1000字）

**发明目标：** {解决什么问题}

**核心模块：**
- 模块1：{名称} - {职责简述}
- 模块2：{名称} - {职责简述}
- 模块3：{名称} - {职责简述}
- 模块4：{名称} - {职责简述}（可选）

**技术效果：** {简要说明本发明的技术优势}

#### 2.2 具体实施方式（约8000字）

**2.2.1 方法原理/核心思想**（约1200字）
- 技术方案的总体思路
- 核心算法/方法原理
- 关键技术假设

**2.2.2 整体流程详述**（约1400字）
- 步骤1：{名称} - {描述}
- 步骤2：{名称} - {描述}
- 步骤3：{名称} - {描述}
- ...
- 数据流和控制流说明

**2.2.3 关键技术点1**（约1200字）
根据实际内容命名，如：
- 类型定义与适配策略
- 数据结构设计
- 算法优化方法

**2.2.4 关键技术点2**（约1200字）
根据实际内容命名，如：
- 遍历与识别机制
- 匹配与筛选策略
- 决策与推理逻辑

**2.2.5 关键技术点3**（约1200字）
根据实际内容命名，如：
- 元数据与存储结构
- 缓存与索引机制
- 接口与协议设计

**2.2.6 其他技术细节**（约1000字，可选）
- 根据内容需要增删条目
- 辅助技术、边界条件处理等
- 在各技术点后紧跟简短示例说明

**注：** 实施示例不单独成节，而是在各关键技术点讲解完后，紧跟2-3句话的简短示例说明。对于复杂算法应给出数学公式，对于核心数据结构应给出形式化定义。

#### 2.3 技术实现系统流程（约2000字）

**系统组成：**
- 子系统/模块1：{功能描述}
- 子系统/模块2：{功能描述}
- ...

**数据流转：**
1. 输入阶段：{描述}
2. 处理阶段：{描述}
3. 输出阶段：{描述}

**处理过程：**
- 详细说明各阶段的数据处理逻辑

#### 2.4 本发明有益效果（约1200字）

- **效果1**：{标题} - {具体说明}
- **效果2**：{标题} - {具体说明}
- **效果3**：{标题} - {具体说明}
- **效果4**：{标题} - {具体说明}（可选）
- **效果5**：{标题} - {具体说明}（可选）

#### 2.5 技术关键点与保护点（约1300字）

**2.5.1 主要创新点**（约500字）

本发明的主要创新点如下：

1. **{创新点1}**
   {简要描述}

2. **{创新点2}**
   {简要描述}

3. **{创新点3}**
   {简要描述}

4. **{创新点4}**（可选）
   {简要描述}

**2.5.2 权利要求**（约800字）

**权利要求1：**（独立权利要求-方法）
一种{方法名称}，其特征在于，包括以下步骤：
a. {步骤1}；
b. {步骤2}；
c. {步骤3}；
d. {步骤4}；
e. {步骤5}。

**权利要求2-X：**（从属权利要求-方法细节）
根据权利要求1所述的方法，其特征在于，{进一步限定}。

**权利要求Y：**（独立权利要求-系统）
一种用于实现上述方法的系统，其特征在于，包括：
- {模块1}：用于{功能}；
- {模块2}：用于{功能}；
- {模块3}：用于{功能}；
- {模块4}：用于{功能}；
- {模块5}：用于{功能}。

**权利要求Y+1-Z：**（从属权利要求-系统细节）
根据权利要求Y所述的系统，其特征在于，{进一步限定}。

---

## 撰写注意事项

1. **语言风格**：技术文档风格，客观准确，避免口语化
2. **术语一致**：全文使用统一术语，首次出现时给出定义
3. **逻辑清晰**：层次分明，因果关系明确
4. **内容充实**：每个技术点要有具体实现细节，不可泛泛而谈
5. **避免绝对**：使用"优选"、"可以"、"一种实施方式"等表述
FILE:references/writing-guide.md
# 专利撰写规范

## 一、整体风格要求

### 1.1 自然段落优先

专利文档应采用自然段落写作，而非分条列举。每个自然段落应当内容充实、逻辑完整，通常包含5-10句话。段落之间应有过渡句衔接，形成流畅的技术叙述。

**错误示例（避免）：**
```
本发明的优点包括：
- 优点1：效率高
- 优点2：成本低
- 优点3：易维护
```

**正确示例：**
```
本发明具有多方面的技术优势。首先，在效率方面，通过采用优化的算法设计和并行处理机制，系统能够在毫秒级响应时间内完成复杂的数据分析任务。其次，在成本控制方面，本发明的架构设计充分利用了现有硬件资源，避免了对昂贵专用设备的依赖，显著降低了部署和运维成本。此外，本发明的模块化设计使得系统具备良好的可维护性，各功能模块可独立升级和替换，减少了系统停机时间。
```

### 1.2 语言正式规范（重要）

专利文档是法律技术文件，语言必须正式、准确、专业。避免口语化、随意化的表达。

**禁止使用的口语化表达：**
- "试想，如果..." → 改为"假设..."
- "这类数据会..." → 改为"该类数据将..."
- "可以想见" → 改为"可以理解"或直接删除
- "我们会发现" → 改为"可以发现"或直接陈述
- "也就是说" → 改为"换言之"或"即"
- "说白了" → 禁止使用
- "打个比方" → 改为"类比而言"
- "其实" → 禁止使用
- "显然" → 谨慎使用，仅在确实显然的情况下
- "不难看出" → 改为直接陈述结论

**应使用的正式表达：**
- "本实施方式中"而非"在这个实施方式里"
- "该技术方案"而非"这个技术方案"
- "所述方法"而非"上面说的方法"
- "配置为"而非"用来"
- "响应于"而非"当...的时候"
- "基于"而非"根据"（在技术因果关系描述中）

**句式规范：**
- 使用完整的主谓宾结构，避免省略主语
- 多用陈述句，少用反问句或感叹句
- 被动语态在描述技术过程时可适当使用
- 长句应层次分明，可适当使用分号分隔并列成分

### 1.3 减少 Markdown 痕迹

输出的文档应是一份流畅的技术文档，而非带有明显 markdown 格式标记的草稿。

**应避免的格式：**
- 过多的 `**加粗**` 标记
- 不必要的标题层级嵌套
- 在正文中使用代码块
- 频繁的分条列举

---

## 二、各章节撰写要点

### 2.1 技术背景

技术背景部分应采用叙述性写作，介绍技术领域的发展脉络、现有方案的主要思路及其局限性。避免简单的罗列，而是形成有逻辑的技术演进叙述。

**字数要求：** 约2000字

**内容要点：**
- 技术领域概述（用1-2个自然段介绍所属领域的重要性和发展背景）
- 现有技术方案详述（每种方案用完整的段落阐述其原理和特点）
- 现有技术的问题分析（系统分析现有技术的不足，为引出本发明做铺垫）

### 2.2 发明内容

发明内容是对技术方案的概述，应简明扼要地说明发明目标、核心模块和技术效果。采用自然段落写作，每个模块的职责用完整的句子描述。

**字数要求：** 约1000字

### 2.3 具体实施方式（重点）

具体实施方式是专利的核心部分，必须做到真正"具体"。这是审查员判断专利是否充分公开的主要依据。

**字数要求：** 约8000字

**核心原则：让读者能够实现**

具体实施方式的写作目标是让本领域技术人员能够根据描述实现该技术方案。因此，不能只停留在概念层面的描述，必须深入到技术细节。

**技术深度要求（重要）：**

为体现技术方案的严谨性和可实现性，具体实施方式应在必要时包含以下要素。注意：公式和形式化定义应适度使用，不要为了形式化而形式化。

**1. 数学公式（适度使用）**

仅当技术方案涉及复杂算法、优化计算、概率模型时，才需要给出数学公式。简单的过程描述无需公式化。

**适用场景：**
- 优化算法的目标函数
- 概率模型的条件概率计算
- 复杂的数据变换公式

**不适用场景：**
- 简单的数据处理流程
- 可以用自然语言清楚表达的逻辑
- 非数学核心的技术方案

**示例（适度）：**
```
触发条件的推断基于意图分类。设用户请求的语义向量为v，任务类型集合为T，
系统计算v与各类别原型向量的相似度，选择相似度最高的类别作为意图类型。
对于相似度计算，采用余弦相似度函数。
```

**示例（过度，应避免）：**
```
设框架F的技能规范为R_F = {r_1, r_2, ..., r_n}，其中每条规则r_i定义了一个约束条件...
（这种简单概念不需要形式化定义）
```

**2. 数据结构定义（必要时使用）**

当技术方案涉及复杂的数据结构、需要精确说明字段关系时，可以给出形式化定义。

**适用场景：**
- 核心数据结构有多个嵌套层次
- 字段之间有复杂的约束关系
- 需要精确说明数据格式

**不适用场景：**
- 简单的字段列表
- 可以用自然语言描述清楚的数据

**示例（适度）：**
```
技能中间表示包含以下字段：skill_id（唯一标识符）、name（技能名称）、
trigger（触发条件）、steps（执行步骤列表）、inputs（输入参数列表）、
outputs（输出参数列表）、dependencies（依赖声明列表）。
每个参数包含名称、类型、是否必填、描述等属性。
```

**3. 算法步骤描述（优先自然语言）**

对于核心算法的处理步骤，应优先使用自然语言描述，清晰说明每个步骤做什么、为什么这样做。

**适用场景：**
- 算法逻辑复杂，需要精确说明
- 涉及数学计算的处理过程

**不适用场景：**
- 简单的流程步骤
- 可以用自然语言清楚表达的逻辑

**核心原则：自然语言优先，形式化辅助。**

**必须包含的内容：**

1. **方法原理的深入阐述**：不仅说明"采用什么方法"，还要解释"为什么采用这种方法"，说明方法的理论基础、设计考量、与其他方法的对比优势。

2. **数据结构和关键参数**：定义核心数据结构，说明各字段的含义和取值范围；给出关键参数的建议值或取值范围，并解释选择依据。

3. **算法的详细步骤**：对于核心算法，应给出完整的处理步骤；每个步骤应说明输入、处理逻辑、输出。

4. **边界条件和异常处理**：说明系统如何处理边界情况，说明异常情况的检测和处理机制，给出错误恢复策略。

5. **技术点示例说明**：在关键技术点讲解完后，紧跟简短示例说明，示例控制在2-3句话，说明输入输出和关键步骤，不单独成节，融入各小节末尾。

**写作禁忌：**

1. 避免空洞的描述：错误示例"采用智能算法进行优化"；正确示例"采用基于梯度下降的优化算法，学习率设置为0.01，迭代次数上限为1000次，当损失函数的变化小于0.0001时提前终止迭代"。

2. 避免流水账：不要只罗列步骤名称，要解释每个步骤的原理、为什么要这样设计。

3. 避免缺少技术细节：如果提到"缓存机制"，应说明缓存的数据结构、更新策略、失效条件；如果提到"优化算法"，应说明算法的具体类型、参数设置、收敛条件。

### 2.4 系统流程

系统流程部分从系统层面描述技术方案的实现，包括系统组成、数据流转、处理过程。

**字数要求：** 约2000字

### 2.5 有益效果

有益效果部分应具体说明本发明带来的技术优势，每个效果应给出具体的量化指标或对比分析。

**字数要求：** 约1200字

### 2.6 权利要求

权利要求是专利的法律边界，应准确界定保护范围。独立权利要求应包含所有必要技术特征，范围适中；从属权利要求逐层限定，形成层次分明的保护体系；方法权利要求和系统权利要求应相互呼应。

**字数要求：** 约1300字

---

## 三、语言表达规范

### 3.1 术语使用

- 术语首次出现时给出完整定义
- 全文使用统一的术语，避免同义词混用
- 缩略语在首次使用时给出全称

### 3.2 语气和表述

- 使用客观的技术性语言，避免主观评价
- 使用"本发明"、"本实施方式"等标准表述
- 避免绝对化表述，使用"优选地"、"在一种实施方式中"等

---

## 四、字数保障要求

专利交底书全文约16000字，这是专利充分公开的基本要求。各章节字数分配如下：

| 章节 | 目标字数 | 最低字数 |
|------|---------|---------|
| 缩略语定义 | 150字 | 100字 |
| 技术背景 | 2000字 | 1500字 |
| 发明内容 | 1000字 | 800字 |
| 具体实施方式 | 8000字 | 6000字 |
| 系统流程 | 2000字 | 1500字 |
| 有益效果 | 1200字 | 1000字 |
| 创新点与权利要求 | 1300字 | 1000字 |

**重要：** 撰写完成后应统计各章节字数，确保达到目标要求。字数统计以中文字符为准，不含标点符号、空格、markdown格式符号。如字数不足，应补充技术细节而非填充无关内容。
FILE:scripts/md2docx.sh
#!/bin/bash
# md2docx.sh - Markdown to DOCX converter for patent documents
# Usage: ./md2docx.sh <input.md> [output.docx]

set -e

SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
SKILL_DIR="$(dirname "$SCRIPT_DIR")"
REFERENCES_DIR="$SKILL_DIR/references"

if [ $# -lt 1 ]; then
    echo "Usage: $0 <input.md> [output.docx]"
    exit 1
fi

INPUT_MD="$1"
OUTPUT_DOCX="-${INPUT_MD%.md.docx}"

# Check input file exists
if [ ! -f "$INPUT_MD" ]; then
    echo "❌ Error: Input file not found: $INPUT_MD"
    exit 1
fi

# Build pandoc command
PANDOC_CMD="pandoc \"$INPUT_MD\" -o \"$OUTPUT_DOCX\""

# Add reference template if exists
TEMPLATE="$REFERENCES_DIR/template.docx"
if [ -f "$TEMPLATE" ]; then
    PANDOC_CMD="$PANDOC_CMD --reference-doc=\"$TEMPLATE\""
fi

# Add TOC
PANDOC_CMD="$PANDOC_CMD --toc --toc-depth=3"

# Execute
echo "📄 Converting: $INPUT_MD → $OUTPUT_DOCX"
eval $PANDOC_CMD

if [ -f "$OUTPUT_DOCX" ]; then
    echo "✅ Success: $OUTPUT_DOCX"
    # Show file size
    SIZE=$(ls -lh "$OUTPUT_DOCX" | awk '{print $5}')
    echo "   Size: $SIZE"
else
    echo "❌ Conversion failed"
    exit 1
fi