第三章：需求文档的通用结构
写一份数据标注需求文档，说白了就是给标注团队画一张「施工图」。我见过太多项目，需求文档写得像天书，标注员看了直挠头。今天我就把这份通用结构拆开揉碎了讲给你听。
3.1 标题与版本管理
标题这事，看着简单，坑却不少。我习惯用这个格式：[项目名称]_[数据类型]_[版本号]_[日期]。举个例子：智能驾驶_车道线标注_v2.3_20240115。
版本管理这块，我吃过亏。有一次项目进行到一半，发现需求文档和实际标注标准对不上。查了半天，原来是有人改了文档没更新版本号。从那以后，我定了个规矩：
- 主版本号：标注规范有重大调整时更新
- 次版本号：增加新标注类型或细则微调
- 修订号：修正错别字、格式问题
3.2 项目背景与目标
这部分是给新人看的。你想想看，标注员如果不知道这批数据要用来干嘛，他很难理解为什么某些细节要抠那么死。
我一般会写清楚三件事：
- 业务场景：数据最终用在哪个产品里？比如「用于商场导购机器人的行人检测」
- 模型目标：要训练什么能力？「识别行人的朝向和动作」
- 数据用途：训练集？测试集？还是验证集？
记得有一次，一个标注团队把「车辆检测」的数据标成了「车辆识别」。两个任务看着像，但标注粒度完全不同。检测只需要框出车辆位置，识别却要标出车型、颜色。你看，背景没讲清楚，后面全白干。
3.3 数据规模与类型
这部分要量化，别含糊。我见过有人写「大量图片」，这等于没写。正确的写法是：
| 数据维度 | 具体要求 |
|---|---|
| 总量 | 10,000张图片 |
| 分辨率 | 1920×1080，不低于1280×720 |
| 格式 | JPG/PNG，RGB三通道 |
| 场景分布 | 白天60%、夜晚30%、黄昏10% |
| 标注比例 | 训练集70%、验证集20%、测试集10% |
为什么要写这么细？因为数据分布直接影响模型效果。我曾经遇到一个项目，客户说「随便标标就行」，结果模型在夜间场景下完全失效。后来一查，标注数据里90%都是白天场景。
3.4 标注规范与细则
这是需求文档的核心，也是最容易出问题的地方。我把它分成三个层次：
3.4.1 标注对象定义
每个要标注的东西，都得有明确的定义。比如「行人」：
- 包括站着、走着、跑着的人
- 不包括骑自行车的人（归为「骑行者」）
- 不包括海报、广告牌上的人像
- 被遮挡超过50%的不标
3.4.2 标注规则
规则要细到「什么情况怎么处理」。我习惯用表格列出来：
| 场景 | 标注方式 |
|---|---|
| 目标被部分遮挡 | 标注可见部分，框紧贴边缘 |
| 目标在图像边缘 | 标注完整框，超出部分不处理 |
| 多个目标重叠 | 分别标注，不合并 |
| 目标模糊不清 | 跳过不标，记录在备注中 |
3.4.3 标注工具操作说明
嗯，这里要注意。工具操作要写清楚，比如「按B键开始标注，按E键结束」。我曾经见过标注员用错了快捷键，导致标注框大小全乱了。
3.5 质量验收标准
验收标准是需求文档的「法律条款」。我一般设三个等级：
- 通过：准确率≥95%，召回率≥90%
- 返工：准确率在85%-95%之间
- 作废：准确率低于85%
具体怎么算？我举个例子：
准确率 = 正确标注数 / 总标注数 × 100%
召回率 = 正确标注数 / 应标注总数 × 100%你想想看，如果只要求准确率，标注员可能只标简单的，难的都跳过。所以召回率也得卡死。
另外，我还会加一条「抽检规则」：
- 每批次抽检10%的数据
- 抽检不合格，整批次返工
- 连续两批次不合格，暂停项目，重新培训
3.6 交付物格式
最后这部分，要写清楚「交什么、怎么交」。我见过最坑的交付，是标注员把结果存在自己电脑里，项目结束了人都找不到了。
标准交付物包括：
- 标注文件：JSON/XML格式，包含标注框坐标、类别、属性
- 原始数据：按原目录结构打包
- 数据清单：Excel表格，列出所有文件及标注状态
- 质量报告：抽检结果、问题统计
文件命名也要统一。我习惯用：[项目ID]_[批次号]_[序号].[扩展名]。比如 P202401_A01_001.json。
好了，以上就是需求文档的通用结构。说白了，就是让看文档的人能「拿着就能干，干完能验收」。你写的时候，多想想标注员会怎么理解，多想想验收时怎么检查。这样写出来的文档，才真正有用。