239 lines
9.3 KiB
Markdown
239 lines
9.3 KiB
Markdown
# 交底书章节骨架
|
|
|
|
> 阶段四起草前 always read。7 章 + 字数预算 + 必填要素。各章对应 `sections/NN_<名>.md`,NN 影响 docx 目录顺序。
|
|
|
|
## 章节总览
|
|
|
|
| NN | 章节 | 字数预算 | 占比 | 必填要素 |
|
|
|---|---|---|---|---|
|
|
| 01 | 技术领域 | 50-150 | 1% | 一句话 + IPC 大类 |
|
|
| 02 | 背景技术 | 800-1500 | 15% | 现有技术 1/2/3 + 缺陷 + 引证号 |
|
|
| 03 | 发明内容 | 1500-3000 | 25% | 技术问题 / 技术方案 / 有益效果 三段 |
|
|
| 04 | 附图说明 | 100-300 | 2% | 图 1-N 一句话题注 |
|
|
| 05 | 具体实施方式 | 2000-5000 | 45% | ≥1 实施例 + 关键参数取值 + 流程/算法 |
|
|
| 06 | 有益效果 | 300-800 | 8% | 量化数据,不写形容词 |
|
|
| 07 | 权利要求建议 | 300-1000 | 4% | 独权 + 从权草稿(供代理师参考) |
|
|
|
|
总计约 **5000-11000 字**。开发期默认目标 7000-8000 字(中等复杂度发明)。
|
|
|
|
---
|
|
|
|
## §01 技术领域
|
|
|
|
**结构**(就一句):
|
|
|
|
> 本发明涉及 **<领域>** 领域,具体涉及一种 **<细分技术方向>** 的 **<方法/装置/系统>**。
|
|
|
|
**例**:
|
|
> 本发明涉及自然语言处理领域,具体涉及一种基于大语言模型的长文档结构化抽取方法。
|
|
|
|
**雷区**:写成研究背景介绍。这一章只有一句话定位 IPC 分类用,不要展开。
|
|
|
|
---
|
|
|
|
## §02 背景技术
|
|
|
|
**结构**(段 1 行业背景 + 段 2-4 现有技术 1/2/3 + 段 5 总结缺陷):
|
|
|
|
```
|
|
段 1 (100-200 字): 行业/技术大背景 — 这事为什么有人做、市场需求或技术痛点
|
|
段 2 (200-400 字): 现有技术 1 — 引用专利/论文,描述其方案,指出 1-2 个缺陷
|
|
段 3 (200-400 字): 现有技术 2 — 同上
|
|
段 4 (200-400 字): 现有技术 3 — 同上 (≥2 条即可,3 条更稳)
|
|
段 5 (100-200 字): 综合总结现有技术的共性缺陷,导出本发明要解决的技术问题
|
|
```
|
|
|
|
**引证写法**:
|
|
- 专利:`如专利 CN112345678A 公开了一种 XXX 方法,其通过 YYY 实现 ZZZ。但该方法存在 <缺陷 1> 和 <缺陷 2>。`
|
|
- 论文:`Smith 等人在 [文献名, 期刊, 年份] 中提出 XXX,通过 YYY 实现 ZZZ。但该方法 <缺陷>。`
|
|
|
|
**缺陷怎么写**(对应本发明的"区别技术特征"):
|
|
- 性能:精度低 / 时延高 / 资源占用大 / 鲁棒性差
|
|
- 适用:仅适用于某场景 / 需大量标注数据 / 依赖特定硬件
|
|
- 实现:步骤复杂 / 需人工干预 / 难以并行
|
|
|
|
**雷区**:
|
|
- 引证号编造 → 审查员一查就驳;不确定就写 `<TODO 待检索补充>`
|
|
- 缺陷写"效果不好""精度不够"→ 太模糊,要具体到"准确率 < 70%"或"无法处理 > 10K 长度文档"
|
|
- 一段就把现有方案带缺陷讲完 → 现有技术分条列,后续做"区别技术特征"时有靶子
|
|
|
|
---
|
|
|
|
## §03 发明内容
|
|
|
|
**三段式硬结构**:
|
|
|
|
### (一) 技术问题 (100-300 字)
|
|
> 针对上述 <现有技术 N 的缺陷>,本发明所要解决的技术问题是 **<一句话技术问题>**。
|
|
|
|
**雷区**:写成商业问题。"提升用户体验"不是技术问题;"在长文档场景下结构化抽取准确率低于 70%、且无法稳定支持 50K+ token 输入"是技术问题。
|
|
|
|
### (二) 技术方案 (1000-2000 字)
|
|
**这一段是交底书的核心。代理师写独权完全靠它。**
|
|
|
|
```
|
|
本发明的技术方案如下:
|
|
|
|
一种 <方法/装置/系统>,包括以下步骤 / 包括以下模块:
|
|
|
|
步骤 S1 / 模块 1: <名称>,<功能描述>,<具体实现 — 输入/处理/输出>;
|
|
步骤 S2 / 模块 2: <名称>,<功能描述>,<具体实现>;
|
|
...
|
|
步骤 Sn / 模块 n: <名称>,<功能描述>,<具体实现>;
|
|
|
|
其中,<关键创新点的进一步限定 — 通常是 1-2 处区别于现有技术的具体设计>。
|
|
```
|
|
|
|
**必含**:
|
|
- 完整步骤/模块(代理师按这个写独权)
|
|
- 每步的输入 / 处理 / 输出(可复现性)
|
|
- 关键参数的占位(具体值放 §05 实施方式)
|
|
- "其中"后的"进一步限定"= 区别技术特征,这是 separate from 现有技术的关键
|
|
|
|
**雷区**:
|
|
- 写"基于深度学习方法,根据训练结果输出结果"—— 黑盒,代理师拒收
|
|
- 步骤里说"使用合适的方法处理"—— 必须说具体方法名
|
|
- 把实施例细节(具体阈值、具体模型名、具体代码)塞这里 —— 这一节是"方案"层级,实施例放 §05
|
|
|
|
### (三) 有益效果 (200-400 字)
|
|
> 本发明相对于现有技术,具有以下有益效果:
|
|
> 1. <效果 1, 对应技术方案某步骤/某设计>
|
|
> 2. <效果 2, 对应另一步骤/设计>
|
|
> ...
|
|
|
|
每条效果要**回指**到技术方案里的具体步骤/模块,不要空泛说"提升性能"。
|
|
|
|
---
|
|
|
|
## §04 附图说明
|
|
|
|
**结构**(图 N 一句题注):
|
|
|
|
```
|
|
图 1 为本发明实施例的整体流程示意图;
|
|
图 2 为本发明实施例的 <模块 X> 结构示意图;
|
|
图 3 为本发明实施例的 <时序 / 数据流向> 示意图;
|
|
图 4 为本发明实施例的 <对比实验结果> 示意图;
|
|
```
|
|
|
|
**对齐规则**:本节"图 N"编号 = `sections/` 里 `` 出现顺序 = `render_docx.py` 全局自增编号。**不要手写图号**,只写题注顺序,渲染时自动对齐。
|
|
|
|
**附图建议(常见型)**:
|
|
- **必有**:整体流程图(对应技术方案的步骤总览)
|
|
- **建议有**:关键模块结构图、时序图(异步/并发场景)、对比实验图(若 §06 有量化效果)
|
|
|
|
---
|
|
|
|
## §05 具体实施方式
|
|
|
|
**这一章最长(45%)**。代理师按这一章判断"是否充分公开"—— 不充分公开等于无效。
|
|
|
|
**结构**(实施例 1 必有,可加实施例 2/3 展示变体):
|
|
|
|
```
|
|
为使本发明的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本发明进行进一步详细说明。
|
|
|
|
## 实施例 1
|
|
|
|
### 1.1 整体流程
|
|
本实施例提供一种 <名称>,如图 1 所示,包括以下步骤:
|
|
|
|
#### 步骤 S1: <名称>
|
|
<详细描述: 输入是什么 / 处理逻辑 / 关键参数取值 / 输出是什么>
|
|
<必要时给伪代码 / 公式 / 表格>
|
|
|
|
例如,采用 <具体方法/模型>,参数设置如下:
|
|
| 参数 | 取值 | 说明 |
|
|
|---|---|---|
|
|
| <参数 1> | <值> | <为什么取这个值> |
|
|
| ... | ... | ... |
|
|
|
|
#### 步骤 S2: <名称>
|
|
<同上>
|
|
|
|
...
|
|
|
|
### 1.2 关键模块详述 (可选)
|
|
针对 <某关键模块>,如图 2 所示,其内部结构 / 算法细节如下:
|
|
<详细说明>
|
|
|
|
### 1.3 实验/效果验证 (可选,但有数据强烈建议)
|
|
本实施例在 <数据集 / 场景> 上验证,结果如表 X / 图 N 所示:
|
|
<量化结果表 / 对比表>
|
|
|
|
## 实施例 2 (可选 — 展示变体扩大保护范围)
|
|
<同实施例 1 结构,但替换某关键参数 / 步骤 / 模块,说明本发明的扩展性>
|
|
```
|
|
|
|
**必含**:
|
|
- ≥1 个完整实施例(端到端,从输入到输出)
|
|
- 所有关键参数的**具体取值**(不能留 `<TODO>` 进交付物)
|
|
- 关键算法的**伪代码或公式**
|
|
- 实验/效果数据(若 §06 给量化效果,这里要有支撑)
|
|
|
|
**雷区**:
|
|
- "本领域技术人员可以理解 XXX" —— 这话用来兜底某细节简略可以,但不能用来糊弄关键步骤
|
|
- 实施例只描述功能不描述实现 —— 等于没写
|
|
- 多实施例完全重复 —— 没意义,变体要在**关键设计点**上有差异
|
|
|
|
---
|
|
|
|
## §06 有益效果
|
|
|
|
**结构**(每条效果一行,**全部量化**):
|
|
|
|
```
|
|
本发明实现了以下有益效果:
|
|
|
|
1. 准确率方面: 在 <数据集/场景> 上,本发明的准确率达到 <X%>,相比现有技术 (Y%) 提升 <Z 个百分点>;
|
|
2. 性能方面: 在 <硬件 / 输入规模> 条件下,本发明的处理时延为 <X ms>,相比现有技术 <Y ms> 降低 <Z%>;
|
|
3. 资源方面: 本发明的内存占用为 <X GB>,相比现有技术 <Y GB> 降低 <Z%>;
|
|
4. 鲁棒性方面: 在 <边界场景, 如长输入/低质量数据> 下,本发明仍能保持 <X% 准确率>,现有技术降至 <Y%>;
|
|
5. 通用性方面: 本发明在 <场景 A / B / C> 上均可应用,扩展性强;
|
|
```
|
|
|
|
**雷区**:
|
|
- "显著提升性能" / "效果良好" / "用户满意" —— 不可考核词
|
|
- 比例不给绝对值 —— "提升 30%" 不够,要写"从 70% 提升到 91%"
|
|
- 没数据来源 —— §05 实施方式里必须有对应数据支撑;没有就不写这条效果
|
|
|
|
---
|
|
|
|
## §07 权利要求建议 (可选)
|
|
|
|
> 这一章是给**专利代理师**参考的草稿。代理师会重写成最终的权利要求书,但你给的草稿能让代理师抓住保护重点。不写也行,写了价值高。
|
|
|
|
**结构**:
|
|
|
|
```
|
|
本发明建议的权利要求如下,供代理师参考:
|
|
|
|
## 独立权利要求
|
|
|
|
1. 一种 <名称>,其特征在于,包括以下步骤 / 包括:
|
|
- 步骤 S1: <对应 §03 技术方案的步骤,简洁化>;
|
|
- 步骤 S2: <...>;
|
|
- 步骤 Sn: <...>;
|
|
其中,<区别技术特征 — §03 "其中" 段的核心内容>。
|
|
|
|
## 从属权利要求
|
|
|
|
2. 根据权利要求 1 所述的 <名称>,其特征在于,<进一步限定 — 通常是某参数范围 / 某具体实现方式>。
|
|
3. 根据权利要求 1 所述的 <名称>,其特征在于,<进一步限定>。
|
|
4. ...
|
|
|
|
## 装置/系统/介质权利要求 (若适用)
|
|
|
|
5. 一种 <装置/系统>,其特征在于,包括:
|
|
- 模块 1: 用于执行权利要求 1 所述的步骤 S1;
|
|
- 模块 2: 用于执行步骤 S2;
|
|
...
|
|
|
|
6. 一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现权利要求 1 所述方法。
|
|
```
|
|
|
|
**雷区**:
|
|
- 独权写得太窄 —— 把所有实施例细节都堆进去,保护范围被严重压缩;独权只放**必要技术特征**,可选细节进从权
|
|
- 独权写得太宽 —— 没有"其中"段的区别技术特征,等于覆盖了现有技术,会被驳
|
|
- 从权之间互相矛盾 —— 每条从权应该独立可选,不要互相依赖
|