需求文档的核心价值：为什么需要需求文档、需求文档在项目中的角色、好文档与坏文档的对比

说实话，我见过太多团队一上来就开干，连个像样的需求文档都没有。结果呢？标注到一半，甲方说「不对，我要的不是这个意思」。嗯，这种坑我踩过不止一次。

今天我们就聊聊需求文档到底值不值得花时间去写。我的答案是：值得，而且必须写。

一、为什么需要需求文档？

先问个问题：你做过「传话游戏」吗？第一个人说一句话，传到第十个人，意思全变了。数据标注项目也是这样。

产品经理脑子里想的是A，口头传达给项目经理变成B，项目经理写个邮件变成C，标注组长理解成D，最后标注员做出来的是E。你想想看，这中间差了多少个版本？

需求文档就是用来「锁死」这个传递过程的。它把所有人的理解统一到一个纸面上。

我在项目中遇到过最典型的情况：客户说「识别图片中的车辆」，标注员以为要标所有车辆，包括远处的、模糊的、遮挡的。但客户其实只想要「清晰可见、占画面比例超过10%的车辆」。你看，一句话没说清楚，几千张图白标了。

二、需求文档在项目中的角色

需求文档不是写完了就扔一边的。它在项目不同阶段扮演不同角色。我习惯把它分成三个角色来看：

项目阶段	需求文档的角色	具体作用
启动阶段	「合同」	明确甲方、乙方、标注团队三方的责任边界
执行阶段	「操作手册」	标注员遇到歧义时，翻文档找答案
验收阶段	「裁判标准」	判断标注结果是否合格的唯一依据

说白了，需求文档就是项目的「宪法」。所有争议，最终都要回到文档上来解决。

我记得有一次，客户说标注结果「不合格」。我问他哪里不合格？他说「感觉不对」。我说「感觉」不是标准，咱们翻翻需求文档，哪一条没满足？结果他哑口无言。你看，文档就是你的护身符。

三、好文档与坏文档的对比

光说「要写好文档」没用，得知道什么样的文档算好。我直接拿两个例子对比，你一看就明白。

坏文档长什么样？

我曾经接手过一个项目，需求文档就两页纸。里面写着：「标注所有行人」。就这六个字，没了。

结果呢？标注员开始疯狂提问：

• 骑自行车的人算不算行人？
• 只露半个身子的人标不标？
• 海报上的人像要不要标？
• 婴儿车里的小孩算不算？

你看，六个字引发了几十个问题。项目进度直接拖慢一倍。

好文档长什么样？

我后来自己写了一份需求文档模板，核心就三条原则：

1. 说清楚「标什么」：给出正例和反例
2. 说清楚「怎么标」：标注工具、标注方式、坐标格式
3. 说清楚「边界在哪」：什么情况不标、什么情况算异常

举个例子，同样是「标注行人」，好文档会这样写：

【标注目标】行人（Pedestrian）
- 定义：真实世界中的人，包括站立、行走、奔跑状态
- 包含：成人、儿童、推婴儿车的人
- 不包含：骑自行车/电动车的人（归为「骑手」类）
- 不包含：海报、广告牌上的人像
- 不包含：只露出小于1/3身体的人（如只露一只手）

【标注方式】
- 使用矩形框，紧贴目标主体
- 框的上边界：头顶上方2像素
- 框的下边界：脚底下方2像素
- 框的左右边界：身体最外侧

【特殊情况】
- 遮挡超过50%：不标
- 距离过远（高度<20像素）：不标
- 多人重叠：分别标注，框可以重叠

你看，这样写出来，标注员基本不用再问问题。我做过统计，好文档能让标注效率提升至少40%，返工率降低70%。

四、好文档与坏文档的对比表

最后我整理一个对比表，方便你对照检查自己的文档：

维度	坏文档	好文档
目标定义	「标注车辆」	「标注四轮及以上机动车，不含自行车、三轮车」
边界说明	「遮挡严重的不要」	「遮挡面积超过50%的不要，遮挡面积在30%-50%之间的标注为『部分遮挡』」
示例提供	无示例	提供5张正例图、5张反例图、3张边界案例图
版本管理	「最终版_v3_真的最终版.docx」	「需求文档_v2.1_2024-03-15.pdf」
更新机制	口头通知「改一下」	邮件通知+文档更新日志+全员确认

嗯，总结一下。需求文档不是写给领导看的，也不是为了应付流程。它是项目能不能顺利交付的「命根子」。我见过太多项目死在「我以为你知道」这句话上。别让这种悲剧发生在你身上。

下一章，我会具体讲讲需求文档的结构该怎么搭，每个模块写什么内容。到时候我会拿我实际写过的文档做拆解，保证你看了就能用。