2. AI产品基础认知
说实话，我见过太多AI项目翻车了。
不是技术不行，是需求没想明白。团队花三个月训练模型，结果业务方说“这不是我要的”。嗯，这种痛，经历过一次就够了。
这一章，我们就聊聊怎么把业务痛点翻译成AI产品需求。说白了，就是让技术团队和业务团队能说同一种语言。
2.1 业务痛点：AI产品的起点
每个AI产品，都源于一个真实的业务痛点。但痛点不是“我们想用AI”，而是“我们遇到了什么具体问题”。
核心原则：痛点必须可量化、可验证、可追溯。
举个例子。我在做智能客服项目时，业务方一开始说“客户投诉太多”。这太模糊了。我追问下去，才发现真实痛点是：
- 人工客服平均响应时间8分钟，客户满意度下降12%
- 70%的咨询是重复问题，浪费人力
- 夜间无人值守，客户流失率高达15%
你看，这才是能指导产品设计的痛点。
2.2 从痛点推导核心目标
有了痛点，下一步就是定义核心目标。我个人习惯用“SMART原则”来框定：
| 维度 | 说明 | 示例 |
|---|---|---|
| Specific（具体） | 目标不能模糊 | “将响应时间缩短到30秒内” |
| Measurable（可衡量） | 有明确指标 | “自动解决率≥60%” |
| Achievable（可实现） | 技术可行 | “基于现有FAQ数据训练” |
| Relevant（相关） | 对齐业务 | “直接降低客服成本” |
| Time-bound（有时限） | 有deadline | “3个月内上线MVP” |
我的经验：目标不要超过3个。超过3个，团队就会失焦。我曾经在一个项目里定了5个目标，结果每个都做成了半吊子。
2.3 用户故事：让需求“活”起来
用户故事是敏捷开发里的经典工具。但用在AI产品里，需要做些调整。
标准格式是：
作为 [用户角色]
我想要 [功能/能力]
以便 [业务价值]但AI产品有个特点——模型的行为不是100%确定的。所以我会加一条“异常处理”：
作为 [用户角色]
我想要 [功能/能力]
以便 [业务价值]
当 [异常情况] 时，系统应该 [兜底方案]举个例子，我们做智能质检系统时，用户故事是这样写的：
- 角色：质检主管
- 想要：自动识别客服对话中的违规话术
- 以便：将质检覆盖率从5%提升到100%
- 异常：当模型置信度低于80%时，转人工复核
注意：AI产品的用户故事一定要写“置信度阈值”和“人工兜底”。这是很多团队踩坑的地方——模型不是万能的。
2.4 需求优先级：别什么都想做
资源永远有限。我建议用“价值-复杂度”矩阵来排优先级：
优先级排序建议：
- P0（必须做）：高价值低复杂度，先拿结果
- P1（应该做）：高价值高复杂度，规划资源
- P2（可以做）：低价值低复杂度，见缝插针
- P3（不做）：低价值高复杂度，直接砍掉
避坑指南：我曾经把一个“多轮对话”功能排到了P0，结果团队花了4个月，效果还不好。后来发现用户根本不需要那么复杂的对话，一个简单的FAQ机器人就够了。所以，先做简单的，验证价值，再迭代。
2.5 需求文档的结构模板
最后，分享一个我常用的AI产品需求文档模板。你直接套用就行：
# AI产品需求文档
## 1. 背景与痛点
- 当前业务现状
- 量化数据支撑
- 用户反馈摘要
## 2. 核心目标
- 目标1（指标+时限）
- 目标2（指标+时限）
- 目标3（指标+时限）
## 3. 用户故事
- 故事1：角色 + 功能 + 价值 + 异常处理
- 故事2：角色 + 功能 + 价值 + 异常处理
## 4. 数据需求
- 训练数据来源
- 数据量要求
- 标注规范
## 5. 评估标准
- 离线指标（准确率、召回率等）
- 在线指标（用户满意度、转化率等）
- 人工兜底策略
## 6. 风险与假设
- 技术风险
- 数据风险
- 业务风险这个模板我用了好几年，基本没大改过。核心就是：把业务语言翻译成技术语言，同时留好兜底方案。