AI 需求拆解与 PRD：从业务痛点到 AI 方案

从业务痛点出发，而不是从 AI 能力出发

最常见的失败路径：看完新模型发布会，就想“能不能给产品加个 AI 功能”。正确的路径刚好相反——先有痛得真实的业务问题，再判断 AI 是不是最优解。

立项前先过痛点三问：

1. 这个痛点今天靠什么解决？成本、耗时多少？（有基线才能算收益）
2. AI 能力是否命中痛点的核心环节？（替换整个流程，还是只做其中一步）
3. 如果 AI 输出错了 10%，用户能容忍吗？（决定兜底方案要做多重）

产品决策提示：不做“炫技型功能”。一个用规则就能解决 80% 场景的问题，不值得上模型；反过来，规则永远做不好的长尾理解、生成类任务，才是 AI 的主场。

需求拆解：从痛点到 AI 任务

拆解四步法：

1. 还原业务流程：画出用户完整作业路径，标出最耗时、最易错的环节。
2. 定位 AI 切入点：判断哪些环节属于“理解、生成、归类、抽取”类任务——这些是模型擅长的；涉及精确计算、强实时、强确定性的环节要谨慎。
3. 定义输入输出：用户给什么（文本、图片、结构化数据），产品要产出什么（建议、草稿、结论）。
4. 确定人机分工（HITL）：全自动、人工确认后生效，还是仅提供建议。

业务痛点	拆解后的 AI 任务	人机分工
客服每天重复回答 60% 相似问题	意图识别 + 知识库检索 + 答案生成	高置信度自动回复，低置信度转人工
运营写商品文案费时	多风格文案生成 + 按平台改写	AI 出草稿，运营挑选修改后发布
合同关键条款人工核对易漏	条款抽取 + 风险点比对	AI 标红提示，法务做最终判断

AI 功能 PRD 与传统 PRD 的三大差异

维度	传统 PRD	AI 功能 PRD
功能确定性	输入确定则输出确定	同一输入可能有不同输出，效果随数据与版本波动
验收标准	功能跑通即可验收	需要概率性验收：定义指标阈值与评估集，达标才上线
失败处理	Bug 修复即可	必须预写兜底方案：识别不了的输入怎么办、错误输出如何拦截

一份合格的 AI PRD 必须多写三块：

• 能力边界：明确“能做什么、不做什么、什么场景会失效”。写清不支持的语言、长度上限、领域范围——边界写得越清楚，上线后的争议越少。
• 概率性验收：用评估集说话——多少条测试样本、目标准确率多少、bad case 比例控制在多少；同时定义灰度策略（先放 10% 流量观察再全量）。
• 兜底方案：每个 AI 环节都要有 Plan B——模型低置信度时降级为模板回复、规则引擎或人工接管，绝不能让错误输出直接抵达用户的关键决策环节。

产品决策提示：AI PRD 里最值钱的一页是“边界与兜底”。它决定了上线后是你管理预期，还是用户投诉替你定义效果。

需求评审要点

评审会上替项目把住四道关：

1. 价值关：痛点是否真实、发生频次如何、收益怎么量化？
2. 可行性关：现有模型能力能否覆盖，还是需要微调、自训？数据从哪来？
3. 验收关：评估集、指标阈值、灰度方案是否明确？
4. 风险关：最坏情况是什么？兜底与回滚方案是什么？合规与数据安全有没有过审？

产品决策提示：评审最常漏的是验收与兜底。一个没有评估集的 AI 需求，等于把“效果好坏”的裁判权交给了上线后的用户投诉。

本节要点

• AI 需求从业务痛点出发，先过“痛点三问”，不做规则就能解决的炫技功能。
• 需求拆解四步：还原流程 → 定位 AI 切入点 → 定义输入输出 → 确定人机分工。
• AI PRD 必写三块：能力边界、概率性验收（评估集 + 阈值 + 灰度）、兜底方案。
• 需求评审把住价值、可行性、验收、风险四道关，其中验收与兜底最容易被漏。