企业AI落地实战系列 · 方法论合辑

从一句模糊需求，到一个能上线的AI产品

场景拆解与产品设计全流程实操

这篇是系列的方法论基础篇，把“场景怎么拆”和“产品怎么设计”两件事完整打通。全文按实际项目的推进顺序展开：先拆场景、再对齐认知、再评估优先级、再画原型、再写PRD、再定交互规范、最后交付验收。中间穿插一个贯穿案例——“关键零部件外观缺陷检测”，用来把每一步落到具体的画面上，而不是停留在方法层面。这个案例是为了讲解方法而构造的通用场景，不对应任何具体客户或项目。

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

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

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

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

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

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

把“提升效率”拆成“谁在哪个节点做什么判断”

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

●谁：是一线操作人员，还是班组长/主管——不同角色对判断结果的信任门槛完全不同

●在哪个节点：流程的哪一个环节触发这个判断，是实时触发还是批量触发

●做什么判断：是非此即彼的二元判断，还是需要分级、分类的多元判断

●判断依据是什么：靠肉眼/经验判断，还是要对照标准、图纸、历史数据做量化比对

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

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

数据从哪进来，结果交给谁、以什么形态

明确两头：

●输入：是图像、文本，还是结构化数据？从哪个系统或设备获取？是实时流式的，还是批量导入的？

●输出：交付给人，还是交付给下一个系统？是一个分数、一个标签，还是一段解释性文字？拿到结果后下一步具体做什么动作？

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

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

覆盖率要求、失败怎么办、人工介入点

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

●输入质量差怎么办（比如图片模糊、遮挡、数据缺字段、格式错误）

●模型没把握怎么办（置信度低于阈值时，是拒绝判断、返回“建议人工复核”，还是给出多个候选结果）

●出错的代价有多大（同样是误判，在低风险场景和高风险场景里，需要的人工复核强度完全不同）

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

第四步：数据可得性核查

不是有没有数据，是这批数据能不能支撑这个判断

很多项目卡在这一步却误以为是模型问题。要核查三件事：

●历史数据是否覆盖了第三步列出的异常场景，还是只有“正常样本”——只有正常样本训出来的模型，一旦遇到没见过的异常类型，几乎不可能给出可靠判断

●数据的标注颗粒度是否和第一步定义的判断颗粒度一致——历史数据如果只标注了“合格/不合格”，但业务要的是“缺陷等级1-5”，这批数据不能直接拿来用，需要重新标注或补充采集

●数据获取的稳定性：是一次性的历史存量数据，还是能够持续产生新数据用于后续迭代——持续迭代能力决定了产品上线后能不能“越用越准”

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

第五步：验收标准量化

怎么算“做成了”

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

●准确率/召回率的具体数字，并且分别对应清楚业务后果（漏检和误检哪个代价更大，直接决定了模型调优的方向）

●响应时间上限（实时场景和批量场景的容忍度完全不同）

●人工复核的比例上限——超过这个比例，说明AI没有真正给业务减负，这个数字要在立项时就和业务方达成一致

●成本红线（调用成本、部署成本，以及后续的数据标注和迭代成本）

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

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

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

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

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

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

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

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

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

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

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

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

3.1　场景挖掘的三个要素

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

●场景在哪里：业务链条上凡是“重复、耗时、易错”的环节，都可能藏着AI应用的机会——不是凭空想“哪里能用AI”，而是先找“哪里最累、最容易出错”

●谁来提：一定是一线业务人员提出，不是产品经理或技术团队闭门造场景——他们最清楚痛点在哪，也是未来AI工具真正的使用者，场景是否“真实存在”要由他们确认

●怎么挖：用结构化访谈或问卷的方式，引导业务人员填写需求卡，写清楚现在怎么做、花多少时间、痛点是什么、希望达到什么效果、数据从哪儿来、还有什么顾虑

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

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

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

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

为什么综合得分要用相乘，不用相加

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

●业务价值低的场景，技术再成熟、合规再没问题，做出来也没有意义

●技术可行性低的场景，业务价值再高，现阶段做不了，只能先放一放

●安全合规不过关的场景，价值和技术都没问题，但踩了红线照样不能做

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

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

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

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

注意第二行：业务价值和技术可行性都打了高分（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产品的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的验收标准最终对应交互规范的一致性检查清单。任何一份交付物修改，都要检查是否需要联动更新其他文档。

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

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

第九部分　关键术语速查

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

第十部分　高频问题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. 交互规范是否跨场景统一，而不是每个功能各自为政