第三章：AI产品需求文档的通用结构
说实话，我刚入行那会儿，最头疼的就是需求文档的结构。每个团队有每个团队的写法，有的像天书，有的像流水账。后来我带团队做AI产品，踩了不少坑，才慢慢总结出一套通用结构。
我个人习惯把这套结构叫做「八块拼图」。为什么叫拼图？因为每一块都不可或缺，拼在一起才能看清产品的全貌。你想想看，少了一块，整个画面就不完整了。
3.1 文档头：产品的身份证
文档头，说白了就是给这份文档一个身份。我见过太多文档，翻到第三页还不知道这是哪个项目的。嗯，这里要注意，文档头要包含以下信息：
- 项目名称：别用内部代号，用业务方看得懂的名字
- 文档编号：方便追溯，比如 AI-PRD-2024-001
- 文档状态：草稿、评审中、已定稿、已废弃
- 负责人：写清楚谁对这个文档负责
核心要点：文档头是给所有人看的，包括三个月后的你自己。我曾经翻出一个半年前的文档，看到「项目名称：新模型」，当时就懵了——哪个新模型？
3.2 版本记录：别让历史成为谜团
版本记录这块，我建议用表格来管理。为什么？因为清晰。我曾经在一个项目里，因为版本记录没写好，导致开发同学用错了旧版本的模型指标，白白浪费了两周时间。
| 版本号 | 日期 | 修改人 | 修改内容 |
|---|---|---|---|
| V1.0 | 2024-01-15 | 张三 | 初稿创建 |
| V1.1 | 2024-01-20 | 李四 | 更新模型评估指标，增加A/B测试方案 |
| V2.0 | 2024-02-01 | 王五 | 重构数据需求部分，新增数据标注规范 |
小技巧：每次修改都写清楚「为什么改」，而不是「改了啥」。比如「更新评估指标」不如「因业务方要求增加召回率指标」来得有用。
3.3 背景与目标：讲清楚为什么要做
这一块，我见过太多人写得像在写论文。其实不用那么复杂。你只要回答三个问题：
- 现在有什么问题？（现状痛点）
- 为什么现在要解决？（时机分析）
- 解决了能带来什么价值？（预期收益）
举个例子，我之前做智能客服项目，背景部分是这样写的：
现状：人工客服日均处理3000单，平均响应时间45秒，用户满意度78%
痛点：高峰期排队严重，用户等待时间超过3分钟
时机：NLP技术成熟，开源模型效果已超过传统方案
价值：预计将响应时间缩短至5秒以内，满意度提升至90%以上你看，一目了然。不需要长篇大论，数据说话就够了。
3.4 用户故事：从用户视角看产品
用户故事这块，我建议用「作为...，我想要...，以便...」的格式。这是我从敏捷开发里学来的，用在AI产品上特别合适。
为什么会这样？因为AI产品很多时候是「黑盒」，用户不关心你用了什么模型，只关心能不能解决他的问题。
- 作为客服主管，我想要系统自动识别用户情绪，以便优先处理愤怒用户的工单
- 作为运营人员，我想要模型给出推荐理由，以便向用户解释为什么推荐这个商品
- 作为数据标注员，我想要系统自动校验标注结果，以便减少人工复核的工作量
避坑指南：我曾经犯过一个错误，把用户故事写成了功能列表。比如「模型需要支持多分类」，这不是用户故事，这是技术实现。用户故事一定要从用户视角出发。
3.5 数据需求：AI产品的燃料
数据需求这块，我把它分成三个层次：
- 数据来源：数据从哪来？内部系统、第三方API、还是需要人工采集？
- 数据格式：结构化数据还是非结构化数据？文本、图片、还是语音？
- 数据质量：标注规范是什么？数据清洗规则是什么？
我记得有一次，项目都快上线了，才发现训练数据里有30%的标注错误。嗯，从那以后，我要求每个项目都必须写清楚数据质量验收标准。
数据需求示例：
- 来源：用户行为日志（Hive表）
- 格式：JSON，包含user_id、action、timestamp、device_type
- 规模：日均100万条，连续采集30天
- 质量要求：缺失率<5%，异常值需标记并说明原因3.6 模型需求：核心算法的说明书
模型需求这块，很多人容易写成技术方案。其实需求文档里，你只需要说清楚「要什么」，而不是「怎么做」。
我个人习惯用这个模板：
- 任务类型：分类、回归、聚类、还是序列生成？
- 输入输出：模型接收什么，输出什么？
- 性能要求：准确率、召回率、延迟、吞吐量等指标
- 约束条件：模型大小、推理时间、硬件资源等限制
核心要点：模型需求要写「可验证」的指标。比如「模型准确率不低于95%」，而不是「模型效果要好」。好是什么标准？没法验证。
3.7 评估标准：怎么才算成功
评估标准这块，我建议分两个维度：
- 离线评估：在测试集上的表现，比如准确率、F1值、AUC等
- 在线评估：上线后的业务指标，比如点击率、转化率、用户满意度等
你想想看，离线指标再好，上线后业务效果不行，那也没用。我见过一个推荐模型，离线AUC高达0.98，上线后用户点击率反而下降了。为什么？因为离线数据有偏差。
| 评估维度 | 指标 | 目标值 | 验收方式 |
|---|---|---|---|
| 离线评估 | 准确率 | ≥95% | 测试集验证 |
| 离线评估 | 推理延迟 | ≤100ms | 压力测试 |
| 在线评估 | 用户满意度 | ≥85% | A/B测试 |
| 在线评估 | 业务转化率 | 提升10% | 灰度发布对比 |
3.8 风险与合规：别给自己挖坑
最后一块，也是很多人容易忽略的一块——风险与合规。做AI产品，数据隐私、算法公平性、模型可解释性，这些都是绕不开的话题。
我建议从这几个角度去思考：
- 数据风险：用户数据是否涉及隐私？是否需要脱敏处理？
- 模型风险：是否存在偏见？是否会对特定群体不公平？
- 合规风险：是否符合相关法规？比如个人信息保护法、数据安全法
- 业务风险：模型出错会有什么后果？有没有兜底方案？
避坑指南：我曾经在一个金融风控项目里，因为没考虑模型的可解释性，导致业务方不敢用。后来花了两个月补可解释性方案，项目延期了。所以，风险与合规这块，越早考虑越好。
好了，以上就是AI产品需求文档的通用结构。说白了，这八块内容就像盖房子的地基、框架、水电、装修——缺一不可。你按照这个结构去写，至少不会漏掉关键信息。
下一章，我会详细讲讲每一块怎么写，以及常见的坑有哪些。到时候我会拿实际案例来拆解，保证你听完就能用。