视觉工程师眼中的 PRD：产品需求文档是什么、怎么写

视觉工程师眼中的 PRD：产品需求文档是什么、怎么写

PRD 英文全称：Product Requirements Document，中文译作「产品需求文档」。 本文面向视觉/算法工程师：讲清 PRD 是什么、它在需求文档体系中的位置、为什么视觉工作尤其依赖它、写它要遵守哪些原则，并附一份可直接抄作业的评审清单。

一、从一次「翻车」说起

产品经理在群里发来一句话：「帮我把产线照片里的缺陷都识别出来，越快越好，周五上线。」

视觉工程师脑子里瞬间冒出一串问题：什么缺陷？划痕、脏污还是裂纹？漏检和误检哪个更不能接受？0.5 秒还是 5 秒出结果？训练数据从哪来？谁标注？标多少张？

这就是没有 PRD 的日常：每个人都在「我以为」。返工、扯皮、延期，大多源于需求没有被写下来、写清楚、写可验证。PRD 存在的意义，就是把「我以为」变成「我们约定」。

二、PRD 是什么

PRD，全称 Product Requirements Document，产品需求文档。 它是面向一个产品、版本或特性，系统回答「为谁解决什么问题、产品需要具备哪些能力、做到什么程度才算完成」的正式文档，是产品、研发、设计、测试、数据多方协作的共同契约。

要理解 PRD，需要把它放进需求文档的三层结构中：

文档	英文全称	回答的问题	主要读者
BRD	Business Requirements Document，商业需求文档	为什么值得做（商业价值、投入产出）	决策层、投资人
MRD	Market Requirements Document，市场需求文档	做给谁、市场要什么（用户群、竞品、定位）	市场、产品团队
PRD	Product Requirements Document，产品需求文档	具体做成什么样、怎么算做好	研发、设计、测试、数据

一句话概括：BRD 管「该不该做」，MRD 管「做给谁」，PRD 管「做什么、怎么做才算做对」。

容易混淆的还有 SRS（Software Requirements Specification，软件需求规格说明书）：SRS 偏向技术契约与系统行为规格，PRD 偏向用户价值与产品视角。小团队里两者常被合并，但意识上要区分——PRD 不该越界写技术实现。

三、为什么视觉工程师要格外重视 PRD

视觉/算法类产品天然「难说清楚」，一份含糊的需求在这里代价尤其大：

1. 效果是概率性的。 没有 100% 准确的模型，「识别准确」必须落到 mAP、Precision/Recall、误检率（FPR）、漏检率（FNR）、FPS、P99 时延等可测指标上。
2. 效果强依赖场景。 光照、角度、遮挡、分辨率、相机参数都会改变结果。PRD 不写清场景边界，训练集就是无源之水。
3. 强依赖数据。 标注规范、数据量级、正负样本分布、评测集冻结规则，直接决定可行性与成本。
4. 受硬件硬约束。 端侧算力、内存、功耗决定模型规模和帧率上限，这些必须在动工前成为白纸黑字。
5. 成本显性化。 从 95% 到 98% 的精度，标注成本可能差一个数量级。

对视觉工程师而言，一份合格的 PRD 就是三份合同：指标合同（做到多少分）+ 场景合同（在什么条件下）+ 数据合同（用什么数据证明）。

四、PRD 的核心结构

一份严谨的 PRD 通常包含以下模块：

1. 背景与问题——现状、痛点、数据支撑，「为什么是现在」。
2. 目标——一句话目标 + 可量化的成功指标。
3. 目标用户与场景——谁在什么场景下使用，典型的物理/拍摄条件。
4. 用户故事——「作为 <角色>，我希望 <能力>，以便 <价值>」。
5. 功能需求——输入 → 处理 → 输出，逐条编号（REQ-01、REQ-02…），含交互流程与状态。
6. 非功能需求——视觉产品最核心的部分，一张性能指标表：

指标	定义	达标线	评测条件
mAP@0.5	全类别平均精度	≥ 95%	评测集 V1（10 万张，白天场景）
误检率 FPR	无目标被判为有的比例	≤ 1%	负样本集 N1
漏检率 FNR	有目标但未检出的比例	≤ 3%	评测集 V1
单帧时延	端到端推理	P99 ≤ 80 ms	部署机型
帧率	视频流处理	≥ 15 FPS	部署机型

每个指标必须带三个要素：数值 + 条件 + 数据集，缺一不可测。

1. 数据需求——来源、量级、标注规范、正负样本分布、评测集冻结规则。
2. 验收标准——可执行、可复现的验收用例。
3. 非目标（Non-goals）与边界——本期不做什么、不支持什么场景，是防蔓延的护栏。
4. 里程碑、依赖与风险、变更记录。

五、撰写原则

写 PRD 不是「把想法打出来」，而是把想法翻译成可协作、可验证的约定。十条原则：

1. 以问题为中心，不以方案为中心。 PRD 写 What 与 Why，把 How 留给工程师；只写必须满足的约束（算力预算、时延上限），不写「用 YOLO 还是 Transformer」。
2. 可量化、可验证（SMART）。 反例：「识别更准一点」。正例：「在评测集 V1 上，mAP@0.5 由 91% 提升至 ≥ 95%，且 FPS 不低于 15。」每个需求都要能被测试回答「过还是不过」。
3. 单一主线。 一份 PRD 解决一个核心问题；需求过多就拆版本，大杂烩文档没人读得完。
4. 场景闭环。 正常流、异常流、边界流都要写。视觉产品务必写负场景：画面无人怎么办、目标密集怎么办、夜间/雨雾怎么办。
5. 消除歧义。 术语先行定义（「缺陷」到底指什么？）；统一命名；把「尽量、大约、较快」换成数值或明确表述。
6. 图文并茂。 原型图、流程图、状态机、时序图，一张图胜过三段文字。
7. 优先级明确。 用 MoSCoW（Must / Should / Could / Won't）或 P0–P2 分级，为资源取舍提供依据。
8. 定义「完成」。 验收标准 + DoD（Definition of Done）；评审通过不等于需求结束。
9. 可追踪、可变更。 需求编号唯一，变更走记录；「群里 @ 一下」不算改需求。
10. 人人读得懂。 一个新人花半小时就能明白：做什么、为什么、怎么验收。

六、视觉工程师拿到 PRD 的评审十问

1. 指标是否带条件与数据集？没有评测集的指标可测吗？
2. 训练数据来源、量级、标注规范是否明确？
3. 算力、内存、时延、功耗预算是否给全？
4. 负样本与异常场景是否覆盖？
5. 类别严重不平衡时，评测口径（整体 mAP 还是按类别单独考核）是否约定？
6. 精度优先还是召回优先？置信度阈值如何设定？
7. 上线后的 badcase 回流与模型迭代机制是否写明？
8. 验收标准能否在目标硬件上实测复现？
9. 输入输出格式、与现有系统的接口是否定义？
10. 数据合规与标注周期等风险是否标注？

七、常见误区

• 把 PRD 写成技术方案——替工程师做架构决策，既压缩创新空间，也容易外行指导内行。
• 指标拍脑袋——不核算标注与算力成本，「99%」与「95%」的成本可能差一个数量级。
• 只写正场景——上线第一周，投诉全来自「画面里没人」。
• 验收标准不可测——「用户满意即可」等于没有验收。
• 需求蔓延——评审后不断追加、无变更记录，工期必然失控。
• 场景外推——拿 A 场景数据承诺 B 场景效果，验收时才发现根本没有数据。

八、一个最小示例

REQ-VI-001 产线缺陷检测

• 用户故事：作为质检员，我希望系统自动检出划痕/脏污/裂纹三类缺陷，以便替代人工目检。
• 输入：1920×1080 JPEG，相机位固定。
• 输出：缺陷类别 + 边界框 + 置信度。
• 指标：mAP@0.5 ≥ 92%（三类缺陷评测集 V1：正样本 2000 张、负样本 8000 张）；误检率 ≤ 2%；单图 P99 ≤ 300 ms（产线 PC）。
• 非目标：本期不支持缺陷严重度分级与位置追溯。

结语

PRD 不是流水账，而是共识的载体。对视觉工程师而言，一份严谨的 PRD 意味着：在写下第一行代码之前，所有人已经就「什么是好、什么算完成」达成一致。

把「我以为」变成「我们约定」——这就是 PRD 的全部意义。