3、需求文档的通用结构：背景、目标、范围、定义、流程、规范、验收标准

说实话，我见过太多标注需求翻车的案例了。

需求文档写得像天书，标注团队看不懂，开发团队懒得看，最后项目延期、数据返工，大家互相甩锅。我自己就踩过这个坑——有一次写了个20页的文档，结果标注同学只看了第一页，后面全凭感觉做。嗯，从那以后，我彻底改了写文档的习惯。

今天聊聊我总结的一套通用结构。一共7个模块，按顺序写，基本不会漏东西。

3.1 背景：为什么要做这件事？

背景部分，说白了就是讲清楚「我们为什么要标注这批数据」。别小看这一段，它决定了团队对项目的理解深度。

我个人习惯写三句话：

• 当前业务遇到了什么问题？
• 为什么需要AI来解决？
• 标注数据在其中扮演什么角色？

我曾经见过一个项目，背景写了整整两页公司战略，标注同学看完一脸懵。记住，背景不是写论文，别扯太远。

3.2 目标：做到什么程度算成功？

目标要可量化。别写「提高模型准确率」这种废话，要写「标注数据用于训练后，模型在测试集上的F1值达到0.85以上」。

我一般会列3-5个关键指标：

• 数据量目标：比如「完成10万条有效标注」
• 质量目标：比如「标注准确率不低于95%」
• 时间目标：比如「2周内交付第一批数据」

3.3 范围：做什么，不做什么？

范围这块最容易出问题。我见过最典型的场景：标注团队把不该标的数据标了，该标的反而漏了。

范围要写清楚两件事：

• 包含：哪些数据类型、哪些场景、哪些标签类别
• 不包含：哪些数据不处理、哪些边界情况跳过

维度	包含	不包含
数据类型	中文文本、长度≤500字	英文文本、图片、音频
场景	售前咨询、售后投诉	闲聊、广告、垃圾信息
标签	20个标准意图类别	情感标签、实体标签

我曾经接手过一个项目，范围没写清楚，标注同学把「退货流程」和「退款流程」当成同一个标签标了。后来模型上线，这两个意图完全混淆，返工花了整整一周。血的教训啊。

3.4 定义：每个术语到底什么意思？

定义部分，就是给所有专业术语一个明确的解释。别觉得大家都知道，标注同学可能来自不同背景。

我建议用表格来写定义：

术语	定义	示例
意图	用户表达的核心诉求	「我想退货」→ 退货意图
实体	意图中的关键信息	「订单号：12345」→ 实体
边界情况	模糊、歧义、多意图的样本	「能退吗？能换吗？」→ 多意图

3.5 流程：标注工作怎么流转？

流程部分，我一般画一个简单的流程图。不用太复杂，标注团队能看懂就行。

流程里要写清楚：

• 谁负责分配数据？
• 标注员每天领多少条？
• 质检比例是多少？（我一般建议10%-20%）
• 返工流程怎么走？

3.6 规范：具体怎么标？

规范是文档里最长的部分，也是标注同学最常翻的部分。我建议按标签类别来写，每个标签给出：

• 标注规则（一句话说清楚）
• 正例（2-3个）
• 反例（1-2个）
• 边界情况处理方式

规范部分，我建议用代码块来展示一些复杂的标注规则。比如正则表达式：

# 退货意图关键词匹配规则
退货关键词 = ["退货", "退款", "退换", "不要了", "退回"]
if any(keyword in user_input for keyword in 退货关键词):
    label = "退货意图"
else:
    label = "其他意图"

3.7 验收标准：怎么判断标注合格？

验收标准是文档的收尾，也是最重要的部分。没有验收标准，标注质量就是一笔糊涂账。

我一般写三个维度：

• 准确率：随机抽检，准确率≥95%才算通过
• 一致性：不同标注员对同一条数据的标注结果，一致率≥90%
• 覆盖率：所有标签类别都有足够样本，每个类别不少于100条

好了，以上就是需求文档的7个模块。你想想看，如果每个项目都按这个结构写，标注团队还会看不懂吗？开发团队还会抱怨吗？

下一章，我会聊聊「如何用示例数据让标注需求更清晰」。嗯，那个更有意思。