3. AI项目需求工程与产品化定义
AI项目失败的原因，很少是模型不够先进，更多是需求没有工程化。业务方说“我们要一个智能客服”，这句话不是需求，而是愿望。需求工程的任务，是把这个愿望拆解成可交付、可验收、可估算的AI产品定义。本节围绕从业务问题到产品需求文档（PRD）的完整链路展开，重点讲清楚四件事：需求拆解、成功指标定义、范围界定、风险识别。
一、从业务问题到AI任务：需求拆解的三层结构
需求拆解不是把一句话拆成十句话，而是把业务语言翻译成AI可执行的任务语言。建议采用三层结构：业务目标层、用户任务层、AI能力层。
以“降低客服人力成本”为例。业务目标层是“将一线人工客服工单量降低30%”。用户任务层要回答：谁在什么场景下完成什么任务？例如“客户在App内咨询订单物流状态时，希望10秒内得到准确答复”。AI能力层则要落到具体技术任务：意图识别、知识检索、答案生成、置信度判断、转人工决策。这三层必须逐层对齐，任何一层缺失都会导致需求悬空。
拆解时有一个实用技巧：对每个AI能力，追问“输入是什么、输出是什么、输出错了会怎样”。如果答不上来，说明这个能力还没有被定义清楚，不能进入开发排期。
二、成功指标：从业务KPI到模型指标的双向映射
AI项目的成功指标必须同时覆盖业务价值和模型质量，并且建立双向映射关系。只谈业务KPI，团队不知道模型要优化什么；只谈模型指标，业务方不知道价值在哪里。
业务侧常用指标包括：任务完成率、人工转接率、平均处理时长、单次交互成本、用户满意度（CSAT）。模型侧常用指标包括：意图识别准确率/召回率、检索命中率（Recall@k）、答案忠实度、幻觉率、拒答率。两者之间要有明确的换算或约束关系。例如：若意图识别准确率低于92%，人工转接率就很难降到目标值以下；若检索Recall@5低于85%，答案忠实度再高也无法覆盖长尾问题。
定义指标时要注意三点：第一，每个指标必须有明确的计算口径和数据来源；第二，必须设定基线值和目标值，基线来自当前人工流程或旧系统；第三，必须指定观测周期和责任人。没有基线的指标只是口号。
三、范围界定：用“必须做/可以做/不做”划清边界
AI项目最容易失控的地方是范围蔓延。范围界定不是写一句“本期不做多轮对话”，而是要把边界落到具体场景、数据、渠道和用户群上。
推荐使用MoSCoW方法：Must have（必须做）、Should have（应该做）、Could have（可以做）、Won't have（本期不做）。对每个条目，要写清楚判断依据。例如：
- 必须做：订单物流查询意图识别，覆盖App和Web两个渠道，支持中文。
- 应该做：退换货政策问答，但仅限标准政策，不含例外审批。
- 可以做：多轮追问澄清，若排期允许则纳入。
- 本期不做：语音客服、跨语言支持、与CRM写操作集成。
范围界定的另一个关键动作是明确“不做什么”的替代方案。例如本期不做语音，那语音咨询仍然走人工；本期不做写操作，那退款申请仍由人工在后台完成。这样业务方才能接受边界，而不是觉得功能被砍了。
四、风险识别：AI项目特有的四类风险
AI项目除了常规的进度和资源风险，还有四类特有风险需要提前识别：
- 数据风险：训练/检索数据不足、标注质量差、数据分布与线上不一致。应对方式是尽早做数据可用性评估，明确数据缺口和补齐计划。
- 模型风险：幻觉、偏见、对长尾问题表现差、模型漂移。应对方式是设定质量门禁、建立人工兜底和持续评测机制。
- 集成风险：与现有系统接口不兼容、延迟超标、权限控制缺失。应对方式是在需求阶段就画出系统交互边界，明确接口协议和SLA。
- 合规与伦理风险：用户隐私、数据跨境、生成内容合规。应对方式是提前做合规评审，明确数据脱敏和日志留存策略。
风险识别不是列一张清单就结束，而是要为每个高风险项定义触发条件、缓解措施和责任人。例如“若检索Recall@5连续两周低于80%，则触发数据补充和检索策略调优”。
五、产品需求文档（PRD）的AI特化结构
AI项目的PRD不能照搬传统软件PRD。传统PRD写清楚功能流程即可，AI PRD还必须写清楚模型行为边界、数据依赖、评测方案和兜底策略。一份可交付的AI PRD至少应包含以下部分：
| 章节 | 核心内容 | AI特化要求 |
|---|---|---|
| 背景与目标 | 业务问题、目标用户、业务KPI | 明确AI在流程中的角色和边界 |
| 用户任务与场景 | 典型任务、触发条件、期望结果 | 区分AI可处理与需转人工的场景 |
| AI能力定义 | 输入、输出、置信度、拒答策略 | 定义模型行为契约，而非仅功能描述 |
| 数据需求 | 数据来源、字段、标注要求、更新频率 | 明确训练/检索/评测数据的分工 |
| 成功指标 | 业务指标+模型指标+基线/目标 | 指标必须可观测、可归因 |
| 范围与排期 | Must/Should/Could/Won't | 明确不做的替代方案 |
| 风险与兜底 | 风险项、触发条件、缓解措施 | 必须包含人工兜底和降级策略 |
| 评测与验收 | 评测集、评测方法、验收标准 | 离线评测+线上灰度+人工抽检 |
下面这张图展示了从业务问题到AI PRD的需求工程链路，以及各环节的关键输出和风险控制点。
六、一个可复用的需求拆解示例
假设业务方提出：“我们希望在内部知识库上做一个AI问答助手，减少员工找资料的时间。”按照本节方法，可以这样拆解：
- 业务目标：将员工查找内部文档的平均耗时从8分钟降到2分钟以内，减少重复提问工单量20%。
- 用户任务：员工用自然语言提问，系统返回答案并附来源文档链接；若置信度低，则提示“未找到可靠答案”并引导至相关文档目录。
- AI能力：查询改写、向量检索、答案生成、来源引用、置信度判断、拒答。
- 成功指标：检索Recall@5≥85%，答案忠实度≥90%，拒答准确率≥80%，用户采纳率≥70%。
- 范围：Must——中文问答、来源引用、拒答；Won't——多轮对话、写操作、跨语言。
- 风险：知识库文档过期导致答案错误；权限控制不严导致越权访问；模型幻觉生成不存在的政策条款。
这份拆解可以直接作为PRD的骨架。关键不在于格式多漂亮，而在于每个条目都能被验证、被排期、被验收。
需求工程与产品化定义的最终产出，是一份让业务方、算法团队、工程团队、合规团队都能对齐的PRD。它不需要写满所有技术细节，但必须把边界、指标、风险和验收标准写清楚。做到这一点，AI项目才真正从“想法”变成了“可交付的产品”。