企业AI场景怎么从一句模糊需求，到一个能上线的AI产品

企业AI落地难，问题往往不是技术本身，而是从一句模糊的“我们想上AI”到真正能上线的产品之间，缺少一套系统性的拆解和设计方法。这篇内容会完整走一遍实操流程：从场景拆解到产品设计，从评估优先级到写PRD，最后落到交付验收。全程用一个贯穿案例——关键零部件外观缺陷检测——把每一步可视化出来。

第一部分　场景拆解——把“提升效率”拆成能设计的东西

1.1　为什么“我们想上AI”和“这个AI能上线”之间总卡住

很多企业提出AI需求时，说法都差不多：“提升客服效率”、“让质检更智能”、“预测供应链风险”。这些话本身没错，但直接拿去做产品设计或技术方案，大概率会走偏——因为它们还不是“场景”，只是“意愿”。

从意愿到能落地的场景，中间差的不是技术方案，是拆解。拆解不到位，项目后期会集中爆发三类问题：产品原型画到一半发现输入输出没定义清楚，需要推倒重来；技术方案选型选错，因为“识别缺陷”这四个字被想当然地等同成了一个具体的技术路线；验收阶段和业务方对不上“怎么算做成了”，项目陷入无休止的“再优化一下”。

下面这5步，是在实际项目里用来做场景拆解的实操清单，每一步都配一个操作要点和常见错误。

第一步：业务动作颗粒度拆解

把“提升效率”拆成“谁在哪个节点做什么判断”。任何一句“提升XX效率”的需求，都要先拆到“人＋动作＋判断”这个颗粒度。具体要问清楚四件事：

• 谁：是一线操作人员，还是班组长/主管——不同角色对判断结果的信任门槛完全不同
• 在哪个节点：流程的哪一个环节触发这个判断，是实时触发还是批量触发
• 做什么判断：是非此即彼的二元判断，还是需要分级、分类的多元判断
• 判断依据是什么：靠肉眼/经验判断，还是要对照标准、图纸、历史数据做量化比对

拆不到这个颗粒度，后面产品原型没法画，技术方案也没法选——同样一句“智能识别”，二元判断和五级分类背后可能对应完全不同的技术路线、不同的数据标注方式、不同的训练成本。

常见错误：访谈业务方的时候只问“现在痛点是什么”，得到的答案往往还停留在“效率低”、“太累”这种感受层面，没有追问到具体的动作和判断节点，导致后续设计只能靠猜。

第二步：输入输出边界定义

数据从哪进来，结果交给谁、以什么形态。明确两头：

• 输入：是图像、文本，还是结构化数据？从哪个系统或设备获取？是实时流式的，还是批量导入的？
• 输出：交付给人，还是交付给下一个系统？是一个分数、一个标签，还是一段解释性文字？拿到结果后下一步具体做什么动作？

这一步经常被跳过，导致做出来的东西“技术上跑通了，但没人知道该怎么用这个结果”——一个模型输出了0.87的置信度分数，如果没有人定义清楚“0.87对应什么业务动作”，这个分数对业务来说毫无意义。

常见错误：只关注输入怎么采集，却没有和下游系统/岗位确认输出的消费方式，等原型画出来才发现下游根本接不住这个格式。

第三步：异常与边界场景清单

正常场景之外，至少要列清楚三类情况：

• 输入质量差怎么办（比如图片模糊、遮挡、数据缺字段、格式错误）
• 模型没把握怎么办（置信度低于阈值时，是拒绝判断、返回“建议人工复核”，还是给出多个候选结果）
• 出错的代价有多大（同样是误判，在低风险场景和高风险场景里，需要的人工复核强度完全不同）

这份清单不是为了“穷尽所有可能性”，而是为了在产品设计阶段就决定“AI在哪些情况下必须让位给人”——这是后面画原型、写PRD时“人工介入点”的直接依据。

常见错误：异常场景清单只在技术团队内部讨论，业务方没有参与——结果技术团队认为“低置信度转人工”已经是很稳妥的兜底，但业务方对“转人工”的频率有自己的容忍上限，两边没对齐就会导致上线后天天吵架。

第四步：数据可得性核查

不是有没有数据，是这批数据能不能支撑这个判断。很多项目卡在这一步却误以为是模型问题。要核查三件事：

• 历史数据是否覆盖了第三步列出的异常场景，还是只有“正常样本”——只有正常样本训出来的模型，一旦遇到没见过的异常类型，几乎不可能给出可靠判断
• 数据的标注颗粒度是否和第一步定义的判断颗粒度一致——历史数据如果只标注了“合格/不合格”，但业务要的是“缺陷等级1-5”，这批数据不能直接拿来用，需要重新标注或补充采集
• 数据获取的稳定性：是一次性的历史存量数据，还是能够持续产生新数据用于后续迭代——持续迭代能力决定了产品上线后能不能“越用越准”

这一步建议做一次简单的数据审计，把“需要的数据类型—现有数据情况—缺口—补齐方式”列成一张表，作为立项评估的输入。

常见错误：只问技术部门“有没有数据”，得到“有”的答复就直接立项——却没有确认这批数据的标注颗粒度、覆盖范围，结果模型训练到一半发现能用的数据量远小于预期。

第五步：验收标准量化

在动工之前，就要写清楚验收线，而不是等上线后才讨论：

• 准确率/召回率的具体数字，并且分别对应清楚业务后果（漏检和误检哪个代价更大，直接决定了模型调优的方向）
• 响应时间上限（实时场景和批量场景的容忍度完全不同）
• 人工复核的比例上限——超过这个比例，说明AI没有真正给业务减负，这个数字要在立项时就和业务方达成一致
• 成本红线（调用成本、部署成本，以及后续的数据标注和迭代成本）

验收标准写清楚之后，要反过来检查一遍：这些指标在第四步的数据条件下，是不是一个现实的目标，而不是拍脑袋定的“越高越好”。

常见错误：验收标准只写“准确率要高”，没有具体数字，也没有区分误判类型的代价——项目做完之后，业务方和技术团队各执一词，谁也说不清到底算不算达标。

1.2　贯穿案例：用“零部件外观缺陷检测”走一遍5步拆解

业务动作颗粒度：质检员在总装下线工位，对外观进行“合格 / 轻微缺陷可放行 / 严重缺陷需返修”的三级判断，判断依据是外观标准图册中的11类缺陷定义。

输入输出边界：输入为产线工位相机拍摄的近距离图像（实时流），输出为缺陷等级标签＋缺陷位置标注框＋对应标准条款编号，结果推送到质检员终端，质检员据此决定放行或转返修工位。

异常边界场景：图像因反光/遮挡导致质量不足时，系统直接标注“图像质量不足，请人工复检”；模型判断为“严重缺陷”但置信度低于阈值时，强制转人工复核，不允许自动触发返修流程。

数据可得性核查：现有质检记录只标注了“合格/不合格”二元结果，不满足三级判断需要，需要补充标注缺陷等级和位置框，预计需要新增标注约3-4周。

验收标准量化：严重缺陷漏检率需低于0.5%（漏检代价高于误检），单张图像处理时间需低于800毫秒（对应产线节拍），人工复核比例上限设定为15%。

1.3　两个行业的场景颗粒度对照——同一套方法，不同的现实约束

同样是“外观/状态检测”这一类场景，商业航天和汽车制造在拆解到第一步“业务动作颗粒度”时，会因为行业特性出现明显不同的现实约束，这也是为什么后面案例篇要分行业单独展开的原因。

拆解维度	商业航天场景的现实约束	汽车制造场景的现实约束
业务动作颗粒度	小批量、单件价值高，判断往往是多级分类而非二元判断，且允许的判断耗时相对较长	大批量、节拍严格，判断多为二元或少级分类，判断耗时必须匹配产线节拍秒级要求
异常边界场景	异常样本天然稀少（小批量生产），需要格外关注“数据荒漠型”一票否决的判断	异常样本相对易积累，但异常种类随车型/工艺变化快，模型需要更频繁的迭代周期
验收标准	漏检代价通常远高于误检代价，验收标准往往向“零漏检”倾斜，人工复核比例可以设置得更高	漏检和误检代价需要结合具体缺陷类型分别设定，验收标准更强调综合成本和节拍达成率

这张对照表说明的道理是：方法论骨架是通用的，但每一步拆解出来的具体数字和取舍方向，必须回到行业现实里去定，不能跨行业照搬同一套阈值和验收标准。

第二部分　认知对齐——先跟业务方讲清楚AI的边界

场景拆解可以由产品经理主导完成，但拆解出来的场景要不要做、怎么做，业务方必须全程参与判断。参与判断的前提，是业务方和产品经理对AI的能力边界有一个共同的、准确的认识——如果这一步没做，后面所有环节都可能因为期望值错位而返工。

常见误区	正确认知
AI能“理解”业务原理	AI学到的是历史数据里的表面统计规律，不具备真正的机理理解——换一个没见过的工况或参数组合，规律可能完全失效，甚至给出错误方向的建议
AI可以自主做关键决策	AI的输出本身存在不确定性，凡是涉及安全或大额成本的决策，必须保留人工最终确认环节，不能让AI直接触发不可逆动作
只要有历史数据就能拿来训练	得是高质量、有明确标注、并且覆盖正常和异常工况的数据，否则模型只会学到噪音，遇到没见过的情况完全无法判断
AI模型训练一次就能一直用	产品结构、工艺条件、使用环境一旦发生变化，模型精度会漂移，需要重新训练或调整，这意味着AI产品天然需要一套持续迭代机制，而不是“交付即结束”
AI能解决所有技术难题	有些强非线性、安全余量窄的问题，现阶段更适合用物理模型仿真加专家经验来把关，硬套AI反而会引入新的、更难排查的风险
只要上了AI就能替代人工	AI是辅助工具，核心的责任和创造性空间还是要靠人来扛——AI可以先出一版草稿或建议，但“算不算数”、“要不要采纳”，责任主体始终是人

说到底，AI的作用是把重复性高、规则明确、耗时费力的活儿接过去，让人专心去做那些真正需要创造力、需要拍板、需要担责任的事。这句话建议直接写进每一份AI产品PRD的开头，作为整个团队的共识起点。

2.2　认知没对齐，后面所有环节都会返工

在实际项目中，认知没对齐最常见的后果不是“做不出来”，而是做出来之后业务方不满意——原因往往不是技术不达标，而是业务方一开始对AI的预期就是错的。比如业务方默认“AI判断的结果就应该是最终结果”，看到系统频繁提示“建议人工复核”，就认为项目失败了；而实际上，第三部分安全合规评估如果打分较低，本来就应该保留较高比例的人工复核，这是设计上的合理选择，而不是产品不成熟的表现。

因此，认知对齐环节的产出物应该是一份简短的《AI能力边界共识说明》，在立项之前由业务方和产品/技术团队共同签字确认，明确写清楚这个项目“AI能做到什么程度”、“哪些判断始终由人来做”，作为后续验收争议的依据。

第三部分　场景挖掘与优先级评估——从想法到分数

3.1　场景挖掘的三个要素

很多AI产品做失败，不是设计得不好，而是从一开始场景就没挖对。挖掘场景要抓三个要素：

• 场景在哪里：业务链条上凡是“重复、耗时、易错”的环节，都可能藏着AI应用的机会——不是凭空想“哪里能用AI”，而是先找“哪里最累、最容易出错”
• 谁来提：一定是一线业务人员提出，不是产品经理或技术团队闭门造场景——他们最清楚痛点在哪，也是未来AI工具真正的使用者，场景是否“真实存在”要由他们确认
• 怎么挖：用结构化访谈或问卷的方式，引导业务人员填写需求卡，写清楚现在怎么做、花多少时间、痛点是什么、希望达到什么效果、数据从哪儿来、还有什么顾虑

《AI场景业务需求卡》参考模板

字段	内容说明
场景名称	简要命名
使用人数及频率	涉及多少岗位、多长时间用一次
当前谁在做？花多少时间？	描述现状
最烦人的地方是什么？	核心痛点
希望AI帮做什么？	期望功能
AI需要访问哪些信息？	数据需求
希望AI输出什么？	产出形式
什么时候用？	使用环节
怎么算成功？	量化目标
数据在哪里？	数据来源
有什么担心？	风险顾虑

这张需求卡建议由产品经理带着业务人员一起填，而不是发下去让业务人员自己填——很多字段（比如“数据在哪里”）业务人员未必清楚该怎么描述，需要产品经理用追问的方式引导出来。

3.2　三维度量化评估模型——别拍脑袋

需求卡收上来一堆，不可能都做。这里最容易犯的错，是产品经理凭经验或者“业务方声音大小”来排优先级。更靠谱的做法是拆成三个维度分别打分，谁最懂这块，就让谁来评：

维度	权重	谁来打分/ 判断什么
业务价值	50%	业务部门自评：效率提升、成本节约、质量风险改善、战略价值——这是产品经理拍不了板的分，必须让一线业务人员和主管部门评
技术可行性	30%	技术部门评：数据就绪度、技术成熟度、系统集成难度
安全合规	20%	质量部门＋信息安全部门评：数据安全合规、模型可靠性、结果可解释性

为什么综合得分要用相乘，不用相加？三个维度算综合分的时候，建议用相乘而不是相加——只要有一个维度得分太低，综合得分就该被明显拉低，而不能被别的维度的高分拉平均补回来。理由很直接：

• 业务价值低的场景，技术再成熟、合规再没问题，做出来也没有意义
• 技术可行性低的场景，业务价值再高，现阶段做不了，只能先放一放
• 安全合规不过关的场景，价值和技术都没问题，但踩了红线照样不能做

这三条背后是同一个原则：AI项目的资源投入应该向“三边都过关”的场景倾斜，而不是向“某一边特别突出”的场景倾斜。

贯穿案例：一次三维度打分

以“零部件外观缺陷检测”为例：业务价值维度，因为该工位人力成本高、误判会导致批量返修，业务部门评为4分；技术可行性维度，因为图像质量整体可控、算法路线成熟，但历史标注需要补充，技术部门评为3分；安全合规维度，因为已设计强制人工复核环节、结果可解释（缺陷位置框可追溯），质量部门评为4分。三维度相乘后的综合分处于中高区间，归入“试点探索”象限——先做小范围试点，解决标注数据补齐的问题，再决定是否推广。

计算公式与两个场景的对比示例

综合得分＝业务价值分×技术可行性分×安全合规分，取值范围随评分体系设定的满分不同而不同——以每个维度满分5分为例，三维度相乘后的最高分是125分。下面用两个候选场景做对比，说明相乘计分法如何拉开区分度：

候选场景	业务价值	技术可行性	安全合规	综合得分
零部件外观缺陷检测	4	3	4	48
某高风险自动停机场景	5	4	1	20

注意第二行：业务价值和技术可行性都打了高分（5分、4分），如果用相加计分（5+4+1=10，满分15），看起来还算中等偏上；但相乘计分（5×4×1=20，满分125）会把安全合规这个致命短板的影响直接放大，综合得分远低于第一个场景，准确反映出“这个场景现在不该做”的真实结论。这正是相乘计分法比相加计分法更能保护决策质量的地方。

3.3　一票否决清单

以下三类场景，不进入打分流程，直接排除，不用纠结评估分数：

• 后果关键型：AI的错误判断可能直接导致人员伤亡或重大任务失败
• 数据荒漠型：因为保密或物理条件限制，拿不到足量且标注准确的训练数据
• 黑盒禁忌型：业务要求每一个结论都必须有明确、可解释的物理或逻辑依据，模型给不出可解释的中间过程

一票否决清单的作用，是在评估流程一开始就过滤掉“无论打分多高都不该做”的场景，避免团队在这些场景上浪费评估精力。

3.4　四象限决策

综合得分算出来之后，按象限归类，决定资源怎么投：

综合得分区间	分类	处理方式
高分区间	优先推进	价值高、难度低，立即立项，集中资源快速产出
中高分但有短板	试点探索	价值高但存在数据或技术障碍，先设试点解决关键问题，再评估是否推广
中等分数	按需尝试	价值一般或可行性中等，有余力时作为能力培养项目
低分	暂缓舍弃	价值低或难度极大，暂不投入资源

3.5　评估打分怎么落地——组织一次打分工作坊

三维度评估模型如果只停留在“表格发下去、各部门自己填”，很容易出现打分口径不一致、部门之间互相不服气的问题。建议按以下方式组织一次线下打分工作坊，把评估变成一个有共识的过程，而不是一次填表任务：

• 会前：产品经理把每个候选场景的需求卡整理成一页纸摘要，提前发给业务、技术、质量、信息安全四方参会人
• 会中第一步：业务部门当场打业务价值分，并口头说明打分理由，其他方只听不打断，避免相互施压
• 会中第二步：技术部门打技术可行性分，重点说明数据就绪度的缺口，这一步经常会反过来修正业务部门原本的分数预期
• 会中第三步：质量和信息安全部门共同打安全合规分，遇到分歧取从严原则（取较低分），不取平均分
• 会后：产品经理汇总三维度分数，核对一票否决清单，计算综合得分并归入四象限，形成书面评估结论，发给全体参会人确认

这个工作坊建议控制在一次会议评估3-5个场景以内，场景太多会导致讨论流于表面，打分失去区分度。

第四部分　产品原型设计——从“值得做”到画出来

评估通过之后才轮到画原型。AI产品原型和传统功能原型最大的区别，是必须显式设计三类状态，而不是只画“正常路径”，否则开发拿到原型后会默认“没画的情况就不用管”，留下大量隐患。

4.1　输入输出边界怎么画

• 输入来源要在原型里标注清楚：是用户主动上传，还是系统自动采集；是单次触发，还是持续流式输入
• 输出呈现形态要具体到界面元素：是一个数值、一个标签徽标，还是一段可展开的解释文字；每种呈现形态都要在原型里画出实际的界面样式，而不是用文字描述代替
• 输出之后的下一步动作要在原型里体现出流转路径：用户点击“确认”、“复核”、“驳回”之后分别跳转到哪个页面

4.2　异常态设计：分三类分别处理

输入异常：原型里要画出输入质量不足时的提示界面，比如图像模糊/遮挡时，明确提示“图像质量不足，请重新采集”，而不是让系统直接进入判断流程给出一个不可靠的结果。

模型异常（低置信度）：原型里要画出置信度低于阈值时的界面状态：是显示“建议人工复核”标签，还是直接屏蔽自动判断结果、只显示原始输入等待人工处理。这个界面状态的设计，直接依据第三部分安全合规维度的评分结果——评分越低，越应该倾向于“屏蔽自动结果”而不是“弱提示＋放行”。

系统异常：原型里要画出模型服务超时、不可用时的降级界面：是切换到人工处理流程，还是暂存任务并提示用户稍后重试，避免用户端出现空白页或报错卡死的体验。

4.3　人工介入点的三种模式

原型里要明确标出每一个判断节点属于以下哪一种模式，三种模式的界面设计和交互流程完全不同：

• 纯自动模式：AI判断结果直接生效，不需要人工确认——只适用于评估阶段安全合规打分很高、出错代价很低的场景
• 建议＋人工确认模式：AI给出判断和依据，人工点击确认或修改后才生效——大多数中等风险场景适用这种模式
• 强制人工判断模式：AI只提供辅助信息（比如标注可疑区域），最终判断完全由人工做出，AI不给出结论性建议——适用于评估阶段被列入高风险或一票否决边缘的场景

4.4　贯穿案例：缺陷检测产品的关键原型页面

质检工位终端主界面：实时显示当前工位图像流，右侧面板显示AI判断结果（缺陷等级标签＋标注框＋对应标准条款编号），底部为“确认放行 / 转人工复核 / 转返修”三个操作按钮——对应“建议＋人工确认”模式。

低置信度状态：当模型置信度低于设定阈值时，右侧面板不显示具体缺陷等级，改为显示“系统判断把握不足，请人工判定”，标注框依然显示以辅助人工定位，但不给出结论性等级——对应“强制人工判断”模式。

图像质量异常状态：当采集图像因反光或遮挡无法有效判断时，界面直接提示“图像质量不足，请调整角度重新采集”，不进入判断流程。

系统异常状态：当AI服务不可用时，终端自动切换为“纯人工判定模式”，界面提示“智能辅助暂不可用，当前为人工判定”，避免质检流程中断。

第五部分　AI产品的PRD——比传统PRD多写什么

传统PRD写清楚功能逻辑、交互流程、验收标准就够了。AI产品的PRD要多写以下几块，缺了任何一块，开发和测试都没法验收，测试团队也不知道该按什么标准判断“这个功能对不对”。

5.1　置信度阈值

PRD里要写清楚：什么分数以上直接输出结果，什么分数以下必须转人工；阈值具体是多少，依据是什么（通常依据第一部分“验收标准量化”里确定的漏检/误检容忍度反推）；阈值是否分场景、分缺陷类型设置不同的值。

5.2　兜底逻辑

PRD里要写清楚模型不可用、超时、返回异常时的具体降级路径，包括：降级触发条件（比如连续几次超时触发降级）、降级后的用户提示文案、降级期间的数据是否需要事后补跑模型重新判断。

5.3　人工复核流程

PRD里要写清楚：复核由谁做、在系统的哪个环节触发、复核的操作界面长什么样、复核结果如何记录、复核数据是否以及如何反哺模型后续迭代——这一条经常被漏写，导致复核变成了“一次性人工劳动”，没有反哺到模型优化上，浪费了最有价值的迭代数据。

5.4　可解释性要求

PRD里要写清楚结果要不要展示依据（比如引用了哪些历史数据、匹配了哪条标准条款、模型关注的图像区域），这一条直接对应第三部分“安全合规”维度里的可解释性打分——打分越低（即业务对可解释性要求越高），PRD里就越要具体设计“依据展示”的界面元素，而不能只展示一个结论。

5.5　AI产品PRD必备章节清单

章节	必须包含的内容
场景背景	对应第一部分的拆解结果：业务动作颗粒度、输入输出边界
功能范围	正常路径＋三类异常态＋三种人工介入模式的完整覆盖说明
置信度与阈值	阈值数值、设定依据、是否分场景分级
兜底与降级	触发条件、降级路径、用户提示文案
人工复核机制	复核角色、操作界面、结果记录方式、反哺迭代路径
可解释性设计	是否展示依据、展示什么依据、展示形式
验收标准	准确率/召回率数字、响应时间、人工复核比例上限、成本红线

5.6　一份精简PRD大纲模板

下面是一份可以直接复用的AI产品PRD大纲，按顺序填写，填不出来的章节说明前面某一步（拆解、评估、原型）还没做扎实，需要退回去补课，而不是在PRD阶段现编。

1. 场景背景与业务价值（引用需求卡和评估打分结论）
2. AI能力边界共识（引用认知对齐环节的共识说明）
3. 功能范围与用户角色
4. 正常路径详细流程（对应原型主界面）
5. 异常态详细流程：输入异常 / 模型异常 / 系统异常（对应原型异常态设计）
6. 人工介入点与介入模式说明（纯自动 / 建议确认 / 强制人工）
7. 置信度阈值与设定依据
8. 兜底与降级策略
9. 人工复核机制与迭代反哺路径
10. 可解释性设计要求
11. 验收标准（准确率/响应时间/人工复核比例/成本红线）
12. 交互一致性遵循说明（引用第六部分交互规范）

第六部分　交互一致性设计——让AI功能“看起来像一个产品”

AI功能最容易做成“一堆零散功能的拼凑”，靠交互一致性才能让用户感觉这是一个完整产品，而不是每次都要重新适应一套新的规则。这一部分尤其重要——当企业内的AI场景从1个扩展到10个、20个时，如果每个场景各自为政地设计交互，用户的学习成本会线性上升，团队内部也会有平台就变成“重复造轮子”。

6.1　多轮对话状态管理

用户上一轮说过或操作过的信息，这一轮要不要记得住、记多久，全系统要用统一规则，不能有的功能记得住、有的功能记不住。建议在设计规范里明确：状态保留的时长、跨会话是否保留、用户如何主动清除上下文。

6.2　结果解释的统一呈现规则

同样是“低置信度”，在所有功能里的提示语、视觉样式、颜色语义要统一，不要一个功能用红色文字强提醒、另一个功能却悄悄不提——不一致的提示体验会让用户对AI结果的信任度产生场景化的割裂，某个功能建立起来的信任感无法迁移到另一个功能上。

6.3　错误恢复路径

用户发现AI给出错误结果之后，撤销、反馈、转人工这几个操作的入口位置，在全系统内要保持一致的位置和交互方式——这样用户不需要在每个功能里重新学习“出错了该怎么办”。

6.4　交互一致性检查清单

• 低置信度提示的文案、颜色、图标在所有功能里是否统一
• “转人工”入口的位置、按钮样式在所有功能里是否统一
• 结果依据的展示方式（引用来源、标注框、匹配规则）在所有功能里是否统一
• 多轮对话上下文的保留规则是否有书面文档，是否所有功能都遵循
• 错误反馈入口是否统一收集到同一个渠道，便于后续统一分析和迭代

第七部分　交付物清单与验收

产品经理走完这一整条链路，最终要交出以下几样东西。这些交付物不是孤立的文档，而是相互引用、层层支撑的一套体系——需求卡是评估打分表的输入，评估结果决定原型里人工介入点的位置，原型的异常态设计对应PRD的兜底逻辑章节，PRD的验收标准最终对应交互规范的一致性检查清单。任何一份交付物修改，都要检查是否需要联动更新其他文档。

交付物	说明与上下游关系
需求卡	场景挖掘阶段产出，业务部门共同确认，作为评估打分表的输入
评估打分表	三维度得分＋一票否决核查＋四象限归类，作为立项依据，决定原型中人工介入点的严格程度
产品原型	含正常态、三类异常态、三种人工介入模式的完整交互流程，作为PRD撰写的界面依据
PRD	含置信度阈值、兜底逻辑、人工复核流程、可解释性设计的AI专用PRD，作为开发和测试的验收依据
交互规范	多轮对话状态、结果解释方式、错误恢复路径的统一规则，跨场景复用，减少重复设计成本
验收标准	准确率/响应时间/人工复核比例/成本红线的具体数字，上线前后用于对照检查

第八部分　常见误区与避坑指南

把前七部分的内容走完一遍之后，再回头看整个流程中最容易踩的坑，汇总如下，供实际项目对照自查。

所在阶段	常见误区
场景拆解阶段	只问“痛点是什么”，没有追问到具体的人、节点、判断依据，导致后续设计只能凭猜测
场景拆解阶段	验收标准没有具体数字，或者没有区分误判类型的代价，导致上线后各执一词
认知对齐阶段	跳过认知对齐环节直接立项，业务方对AI能力的预期和实际能力不符，上线后满意度低
评估阶段	评估打分只由技术团队或产品经理完成，业务价值和安全合规两个维度没有让真正懂行的部门参与打分
评估阶段	综合得分用相加代替相乘，导致某个致命短板被别的高分维度掩盖
原型设计阶段	原型只画正常路径，异常态和人工介入点留到开发阶段“临时决定”，导致返工
PRD撰写阶段	置信度阈值、兜底逻辑等章节缺失，测试团队不知道按什么标准判断功能是否合格
交互设计阶段	不同场景各自设计交互规则，随着场景数量增加，用户学习成本和团队维护成本同步上升
交付验收阶段	各交付物之间没有联动更新机制，评估打分表和最终原型的假设已经不一致却没有人发现

第九部分　关键术语速查

这套方法论里反复出现几个术语，建议团队内部统一口径使用，避免同一个词在不同部门有不同理解。

术语	含义
置信度	模型对自己判断结果的把握程度，通常是0到1之间的数值，不代表判断一定正确，只代表模型认为自己正确的可能性
阈值	用来划分“直接采信AI结果”和“转人工处理”的置信度分界线，由业务代价倒推设定，不是技术团队单方面决定
召回率	该被发现的问题里，实际被发现的比例——漏检率越低，召回率越高
准确率	AI给出判断的结果里，实际正确的比例——和召回率往往是需要权衡取舍的一对指标
兜底/降级	当AI服务不可用或异常时，系统退回到一个更保守但可用状态的机制，目的是避免流程中断
可解释性	AI结果能否给出人类可以理解和核实的依据，而不是只给一个不可追溯的结论
数据就绪度	现有数据在覆盖范围、标注质量、颗粒度上，能否直接支撑目标判断的程度
一票否决	无论其他维度得分多高，只要触及后果关键型、数据荒漠型、黑盒禁忌型之一，就直接排除的判断规则

第十部分　高频问题FAQ

Q：需求卡收集上来发现同一个痛点被三个部门分别提了一遍，怎么处理？

A：先按“业务动作颗粒度”合并——很多时候看起来是同一个痛点，拆到具体的人和判断节点后其实是不同场景，不能简单合并成一个大而化之的项目；确实是同一个动作的，合并成一份需求卡，标注涉及的多个部门。

Q：业务部门坚持给自己的场景打高分，怎么保证打分客观？

A：工作坊现场要求业务部门口头说明打分理由，并提前给出量化依据（比如具体的人天节省数、历史故障次数），而不是接受“我们觉得很重要”这种没有依据的表述；技术和安全维度不受业务部门打分影响，能起到制衡作用。

Q：一票否决清单里的“数据荒漠型”，多少样本算“不足”？

A：没有一个放之四海而皆准的数字，需要结合具体判断的复杂度——原则是：能否覆盖到目标判断颗粒度里的主要分类，如果某个关键类别的样本个位数，基本可以判定为不足，需要先做数据补齐或替代方案，而不是直接进入模型训练。

Q：置信度阈值定多少合适，有没有通用标准？

A：没有通用标准，阈值要从第一部分“验收标准量化”里的漏检/误检容忍度倒推，而不是先定一个阈值再看效果——建议先用历史数据做离线测试，画出阈值和漏检率/误检率的关系曲线，再结合业务能接受的人工复核比例反选阈值。

Q：异常态设计要覆盖到什么程度才算够？

A：以第一部分列出的异常边界场景清单为准，做到清单里的每一类都有对应的界面状态和处理逻辑；不需要无限穷举，但清单本身要业务方和技术方共同确认过，确认“够用”而不是产品经理自己觉得够用。

Q：人工复核比例超过验收标准上限，说明什么，该怎么办？

A：通常说明置信度阈值设置偏保守，或者模型在某类场景上的判断能力不足——先看复核结果里“AI判断被推翻”的比例，如果这个比例很低，说明可以适当调高阈值减少不必要的人工复核；如果这个比例高，说明模型本身需要针对性优化，而不是简单调阈值。

Q：同一套评估模型，能不能直接套用到所有行业？

A：评估的三个维度和相乘的计分逻辑是通用的，但每个二级指标的评分标准（比如“年节省多少人天算5分”）必须结合具体行业和企业规模重新校准，不能把一个行业的评分表直接套到另一个行业上使用。

Q：交付物清单里的文档，谁来负责后续维护更新？

A：建议由产品经理统一牵头维护，但每一份文档的“权威确认方”不同——需求卡由业务部门确认，评估打分表由参与评分的各部门确认，PRD由产品和技术共同确认；产品经理的职责是保证联动更新，而不是单方面决定内容。

附录　空白评估打分表模板（可直接复用）

这张表可以直接打印或者复制到共享文档里，用于第三部分5的打分工作坊现场填写，每次评估会议建议使用一张新表，评估结束后连同需求卡一起归档。

场景名称	业务价值（业务部门）	技术可行性（技术部门）	安全合规（质量/安全）	综合得分（相乘）	四象限归类

填写提示：先核对一票否决清单，命中任意一条的场景直接标注“否决”，不再打分；其余场景按三个维度分别打分后相乘计算综合得分，再对照四象限表归类。

第十一部分　结尾——这套方法论和后面案例文章的关系

这篇把场景拆解、认知对齐、优先级评估、原型设计、PRD撰写、交互一致性、交付验收这一整条链路完整走了一遍，是整个系列的方法论骨架。后面讲商业航天和汽车制造的具体案例时，都会按这套流程重新走一遍，用真实的行业背景和技术选型把每一步填满——拆解的5步会对应到具体的行业场景，评估的三维度会给出具体的行业打分，原型和PRD会展示具体的界面和技术方案。方法论在这篇里立住了，后面的案例篇才有可以对照的坐标系。

全流程自查清单：在启动一个新的AI场景之前，可以对照下面11条快速自查，任何一条答不上来，说明对应部分需要回头补课：

1. 场景是否已经拆到“人＋节点＋判断”的颗粒度，而不是停留在一句话意愿层面
2. 输入来源、输出形态、下游动作是否已经明确到具体系统或岗位
3. 异常边界场景清单是否覆盖了输入异常、模型异常、系统异常三类
4. 数据可得性是否核查过标注颗粒度，而不是只确认“有没有数据”
5. 验收标准是否写出了具体数字，而不是“越高越好”这类模糊表述
6. 业务方是否已经和团队对齐了AI能力边界的共识说明
7. 需求卡是否由业务人员参与填写，而不是产品经理闭门代填
8. 三维度评估是否由对应的部门分别打分，并核对过一票否决清单
9. 原型是否画出了三种人工介入模式，而不是只有正常路径
10. PRD是否包含置信度阈值、兜底逻辑、人工复核、可解释性这四块AI专属内容
11. 交互规范是否跨场景统一，而不是每个功能各自为政