2. AI产品功能与算法的本质区别
2.1 为什么边界划分是AI产品PRD的第一道分水岭
在AI产品PRD撰写中，最常见且代价最高的错误，是将确定性功能与概率性算法混为一谈。开发团队拿到需求后，无法判断该用规则引擎还是训练模型，测试团队无法制定验收标准，业务方对效果预期产生错位。本章从本质出发，厘清两者的定义、特征与核心划分原则，并贯穿一个完整案例——智能客服工单自动分配系统。
常见陷阱：许多产品经理在PRD中笼统地写“系统自动识别工单类型并分配部门”，没有区分哪些是规则匹配（确定性），哪些是模型预测（概率性），导致开发时反复返工、验收时标准模糊。
2.2 功能定义——确定性逻辑
功能的本质是输入→输出的确定映射：给定相同的输入，系统必然产生相同的输出。逻辑可穷举、可测试、可追溯。
| 维度 | 特征 | 工单案例 |
|---|---|---|
| 映射关系 | 输入A → 输出B，100%确定 | 标题含“系统崩溃” → 紧急度=P0 |
| 可穷举性 | 所有输入分支可枚举 | 关键词表可完整列出 |
| 可测试性 | 每条规则可单点验证 | 输入测试标题→验证紧急度标签 |
| 可追溯性 | 输出原因可精确回溯 | 因为匹配规则#3，所以输出P0 |
| 异常边界 | 未匹配规则时走默认分支 | 无关键词匹配 → 紧急度=P2 |
产品经理自检清单：如果该需求可以完整写出“IF…THEN…”规则树，且规则总数在可管理范围（通常不超过50条），则应定义为确定性功能。
2.3 算法定义——概率性模型
算法的本质是输入→输出概率分布：给定相同的输入，模型输出为概率最高的结果，但无法保证100%正确。逻辑不可穷举，需通过统计指标评估。
| 维度 | 特征 | 工单案例 |
|---|---|---|
| 映射关系 | 输入A → 输出B的概率为P(B|A) | 文本“账号异常” → 技术部 87% |
| 可穷举性 | 不可穷举，依赖数据分布 | 无法预写所有文本变体 |
| 可测试性 | 需统计验证（准确率/召回率） | 测试集整体准确率 ≥ 85% |
| 可追溯性 | 输出依据为模型权重，非刚性规则 | 特征贡献度排序，不可精确归因 |
| 异常边界 | 低置信度时需兜底策略 | 置信度 < 60% → 转人工处理 |
关键认知：算法需求在PRD中不能写“模型必须正确分类”，而应写“模型在测试集上准确率≥X%，召回率≥Y%”。概率性意味着——永远存在错误率。
2.4 边界划分的核心原则
- 确定性优先原则：能用规则解决的问题，绝不引入模型。规则更稳定、可测试、无数据漂移风险。
- 可解释性原则：业务方需要“为什么是这个结果”的场景（如工单审核、风控决策），优先使用确定性功能。
- 可测试性原则：功能必须可单点穷举测试；算法必须可统计评估。验收方式不同，PRD中必须分别定义。
- 兜底清晰原则：算法覆盖不到的场景（低置信度、冷启动、边缘case），必须有确定性兜底逻辑。
- 演进路径原则：先从确定性规则起步，积累数据后再用算法替代部分规则，PRD应预留迭代接口。
实战口诀：“能写死的不要学，能穷举的不要猜，能解释的不要黑箱。”
2.5 边界划分决策流（内联SVG）
2.6 用户场景与业务问题
案例背景：某企业客服系统每天收到2000+工单，需要自动分配到技术部、财务部、人事部、运维部。产品经理在PRD中写了一句“系统自动识别工单类型并分配部门”，开发团队无从下手。
- 业务方期望：“分配准确率100%，不能出错，否则客户投诉。” —— 这是典型的确定性幻觉。
- 实际约束：工单文本表达多样，存在大量同义表述、错别字、中英混写，纯粹用规则无法覆盖所有变体。
- 产品经理困惑：到底哪些部分可以写死规则，哪些部分必须用算法模型？
业务问题拆解结果：
- 紧急度判定（P0/P1/P2）：基于关键词规则，确定性功能 → 可写死
- 部门分配（技术/财务/人事/运维）：基于文本语义，概率性算法 → 需要模型
- 置信度低于阈值的工单 → 转人工分配，确定性兜底
2.7 用户访谈与需求拆解
针对工单分配场景，产品经理分别访谈了客服主管、一线客服和开发工程师，提取关键信息：
| 访谈对象 | 核心信息 | 边界归属 |
|---|---|---|
| 客服主管 | “系统崩溃”“数据丢失”必须P0，这是硬性规定 | 确定性规则 |
| 一线客服 | “账号异常”“无法登录”经常被分错部门 | 需要算法模型 |
| 开发工程师 | 规则写多了维护成本高，但模型需要标注数据 | 混合策略 |
| 客服主管 | “实在分不清的工单，转给我来人工分” | 确定性兜底 |
需求拆解输出：
- 确定性部分：紧急度规则表（12条关键词规则）、默认P2兜底、低置信度转人工阈值
- 概率性部分：部门分类模型（4分类）、最低置信度0.6、冷启动阶段先用规则覆盖
- 边界定义：PRD中分别标注“功能需求”和“算法需求”，验收标准不混用
2.8 方案表达——PRD中的边界描述
同一份PRD中，功能需求和算法需求必须使用不同的描述模板：
确定性功能描述示例（紧急度判定）：
功能名称: 工单紧急度自动判定
输入: 工单标题 (string)
输出: 紧急度标签 (枚举: P0/P1/P2)
规则引擎:
Rule_01: IF 标题包含"系统崩溃" OR "数据库宕机" → P0
Rule_02: IF 标题包含"数据丢失" OR "数据损坏" → P0
Rule_03: IF 标题包含"功能异常" OR "页面报错" OR "接口超时" → P1
Rule_04: IF 标题包含"操作疑问" OR "使用咨询" OR "建议反馈" → P2
Default: 未匹配任何规则 → P2
验收标准: 输入100条测试用例，规则匹配率100%，准确率100%概率性算法描述示例（部门分配）：
算法名称: 工单部门分配模型
输入: 工单标题 + 工单描述 (text)
输出: 部门标签 (枚举: 技术部/财务部/人事部/运维部) + 置信度 (float)
模型要求: 基于BERT微调的文本分类模型
评估指标:
- 准确率 (Accuracy) ≥ 0.85
- 加权F1-score ≥ 0.82
- 单次推理延迟 < 200ms (P99)
兜底策略: 当 max(置信度) < 0.60 时，工单转入"待人工分配"队列
验收标准: 在1000条标注测试集上，准确率≥85%，F1≥0.82
表达要点：功能需求用“规则表+测试用例”表达；算法需求用“模型规格+评估指标+兜底策略”表达。两者在同一PRD中分节撰写，互不混淆。
2.9 指标验证与验收标准
功能和算法的验收标准在验证方法和指标类型上有本质差异：
| 验收维度 | 确定性功能 | 概率性算法 |
|---|---|---|
| 验证方法 | 穷举测试用例，逐条验证 | 在标注测试集上统计评估 |
| 核心指标 | 正确率 = 100%，无歧义 | 准确率、召回率、F1-score、AUC |
| 异常处理 | 默认分支覆盖所有未匹配场景 | 置信度阈值 + 兜底队列 |
| 回归测试 | 规则变更后全量回归 | 模型迭代后在固定测试集重测 |
| 验收通过条件 | 全部测试用例通过 | 指标达到PRD中约定的阈值 |
验收红线：永远不要用“功能测试”的方法去验收算法（如：输入10条测试用例要求全部正确），也永远不要用“统计指标”去验收功能（如：功能准确率达到95%就算通过——那5%的错误就是线上事故）。
2.10 交付物模板——功能与算法边界定义表
以下模板可作为PRD中“功能与算法边界定义”章节的标准化表格，直接填入项目需求：
| 需求编号 | 需求名称 | 类型 | 确定性描述/规则 | 算法指标/兜底策略 | 验收方式 |
|---|---|---|---|---|---|
| REQ-01 | 工单紧急度判定 | 功能 | 12条关键词规则表 | 无 | 100条用例全量通过 |
| REQ-02 | 工单部门分配 | 算法 | 无 | Acc≥0.85, F1≥0.82, 置信度<0.60转人工 | 1000条测试集统计验证 |
| REQ-03 | 低置信度转人工 | 功能 | 置信度<0.60时自动转人工队列 | 无 | 模拟低置信度输入，验证转单逻辑 |
| REQ-04 | 工单历史数据标注 | 算法 | 无 | 标注一致性≥0.90 (Kappa系数) | 抽检200条计算一致性 |
模板使用说明：
- 每个需求必须明确标注“功能”或“算法”类型，不得同时勾选两者
- “确定性描述/规则”列只填写规则表、逻辑分支、默认值等硬性描述
- “算法指标/兜底策略”列只填写模型评估指标、置信度阈值、兜底逻辑
- 验收方式必须与类型匹配：功能用“全量用例通过”，算法用“统计指标达标”
2.11 本章核心交付检查清单
产品经理在完成本章学习后，应能在PRD中完成以下输出：
- ✅ 为每个需求明确标注“功能”或“算法”类型
- ✅ 功能需求附带完整的规则表或逻辑分支描述
- ✅ 算法需求附带评估指标、置信度阈值、兜底策略
- ✅ 验收标准与需求类型严格对齐，不混用
- ✅ 使用“功能与算法边界定义表”作为PRD的标准交付物