实战拆解：行业场景优先级与PoC方案设计套件

很多AI项目死得不明不白。复盘下来，九成不是技术不行，是场景选错了。

前面十三讲我们把认知、工具、架构、组织、生命周期都武装了一遍。这一讲落到客户现场最硬的动作：面对一堆混乱的业务需求，你怎么精准锁定"高价值、高可行"的落点，再设计出一套能交付、能复用的PoC方案。

一、场景拆解的核心原则：从业务目标开始，而非从工具开始

场景选错，再强的大模型也救不了项目。

绝大多数AI项目失败，根子不在模型，在"拿着锤子找钉子"。客户说"我们买个Dify搭个知识库吧"，FDE二话不说开干，三个月后业务方根本不用——因为核心痛点不是"知识检索慢"，是"流程审批太慢"。工具对了，问题错了，白干。

正确的逻辑是从业务目标切入，不是从工具切入。 FDE进场第一天要做的，是把客户那句模糊的诉求，翻译成五个可量化维度——降本、增效、提质、控险、增长。这五个词就是场景筛选的"北极星"。

具体动作就一条：把模糊的Mission拆成一系列Agent能跑的任务步骤，在写任何代码之前，先用"Agent编排画布"把初步工作流画出来，跟客户对齐。 画得出流程，说明想得清；画不出，说明还没懂业务。

二、场景优先级四维评分矩阵

不是所有场景都适合进PoC。FDE得有一把量化的尺子，专门筛"技术可行、业务刚需、投入产出比明确"的场景。我们设计了一个四维评分矩阵，每个维度1到5分：

业务价值：痛点是不是真痛。重复性工作多、响应慢、人工成本高，改造后能不能量化提升。比如制造业跟单环节用机器替代，一年能省300万人工，这项评5分。

数据可得性：有没有结构化或半结构化数据、知识库，质量够不够。ERP系统有完整API，评5分；数据全在老师傅的纸质笔记本里，评1分。

流程清晰度：当前业务有没有明确SOP。流程已文档化、标准化，评5分；全凭老师傅经验拍脑袋，评1分。

风险等级（反向评分）：涉及资金外流、客户隐私、法律合规的，评5分（风险高）；内部知识问答这种低风险，评1分。

优先级怎么算？优先级 = (业务价值 × 数据可得性 × 流程清晰度) / 风险等级。 三个正向维度相乘、风险做分母，得分超过30分的场景才进PoC候选池。这个公式的妙处在于，它天然避开两个坑：高价值但数据拿不到的（分母没问题，但数据可得性低，乘积小），和没风险但也没价值的（业务价值低，乘积小）。

三、AI介入点图：从业务泳道到人机边界

场景定了，下一步FDE要画一张"AI介入点图"，说清楚什么环节AI做、什么环节人做、什么环节人机一起做。这是PoC方案设计里最核心的可视化工具，没有之一。

画法用泳道图：横向是业务环节（比如"订单接收→审核→排程→备料→执行→质检→入库→发货"），纵向是参与者（客户、跟单员、AI Agent、系统）。每个环节上标三种标记：

绿色圆角：AI完全接管，不用人工插手。
红色虚线框：AI执行，但高风险操作必须人工审批（比如退款、删单）。
蓝色正方形：必须人工完成，AI只辅助给信息。

FDE必须进一线，否则方案就是纸上谈兵。 谁在做判断？判断依据是什么？数据从哪来？动作在哪执行？哪些系统之间是断的？哪些经验只活在老员工脑子里？这些答案不到现场看，画出来的图全是想当然。同时，FDE要主动向业务方讲清大模型的能力边界，别让人家对AI抱有不切实际的期待。

四、PoC方案设计文档套件

PoC方案不是写一本砖头厚的需求文档，而是一套"轻量、可交付、可验证"的文档。FDE要输出五件核心资产：

FDE场景卡：一张A4纸。字段包括业务目标（动词+量化指标，比如"降跟单耗时80%"）、用户角色（比如"跟单员老王"）、当前流程（一句话+泳道图）、AI介入点（标AI接管和人审环节）、验收指标（EDD四支柱，含技术和业务指标）、风险与应对（比如"幻觉导致报价错，人审兜底"）。

技术架构图：分层展技术栈。展现层（企微/钉钉/Web）、智能层（Dify/LangGraph编排的Agent和RAG管道）、数据层（向量库、关系库、知识库）、系统层（ERP/CRM/OA等存量系统）。每个组件标注工具名和版本，比如"Dify v0.8.0 + DeepSeek-R1 + Milvus"。

评估指标卡：技术指标和业务指标分层。技术看准确率、召回率、工具调用准确率；业务看用户采纳率、人工接管率、错误逃逸率。每个指标给量化阈值和告警规则，比如"采纳率低于70%触发告警"。

Demo脚本：面向客户的演示稿，3到5个核心场景。每个场景写清"用户输入→Agent思考→Agent输出→人工审核节点（如有）"。特别要含边界场景和失败场景，比如"用户需求模糊时，Agent会不会主动追问"。

上线门禁清单：五个检查项——权限检查（RBAC矩阵完整）、数据脱敏（敏感信息被正则替换）、审计日志（每次操作可追溯）、人审机制（高风险被拦截）、回滚方案（Dify版本能否5分钟回退）。

五、PoC验证的核心流程：四步落地法

PoC的本质是验证假设，不是交付产品。 花小钱验证"行不行"，比花大钱踩大坑划算太多。

第一步：明确目标。 先想清要验证什么、达到什么算成功。目标必须可衡量。"看看这个模型行不行"是废话，"验证LLM能从合同里准确提取违约金条款、准确率≥80%"才是目标。

第二步：搭建环境。 测试环境要尽可能模拟生产。企业做私有化部署，就别用公共云测；测电商订单并发，就模拟真实用户频率和数据量。环境失真，结论失真。

第三步：执行验证。 聚焦核心目标，不追求功能完备。只测跟目标相关的，防止范围蔓延。核心围绕四件事：功能验证（对照需求清单跑用例）、性能压测（模拟高并发）、安全渗透（扫漏洞）、集成兼容（验单点登录和数据管道对接）。

第四步：分析结果，做出决策。 对照预设成功标准，看数据，下结论。通过就推进，失败就调整重验或直接终止，部分通过就沟通后改方案再验。别含糊，别"感觉还行"。

六、常见误区与避坑指南

误区一：过度追求完美，忽视"最小可行"。 有人做PoC总想"把所有功能都测一遍"，周期拉长、成本飙升，核心目标反而模糊。正确做法是减法原则，非核心果断砍，能验证"行不行"就够了。

误区二：测试环境失真，结果不可信。 测试环境存储IOPS只有生产的十分之一，却拿这环境的性能数据判断生产能满足需求，上线必崩。正确做法是硬件、网络、数据量都尽量贴近生产。

误区三：没有明确的成功标准，凭感觉判断。 只说"验证系统好用"，没有"响应≤50ms""准确率≥85%"这种量化线，最后团队吵成一团，决策不了。正确做法是提前定量化成功标准，按数据说话。

七、课堂实训：从场景拆解到PoC方案设计

两人一组，完成四件事：

第一，选一个真实或模拟场景（比如"某制造企业跟单流程优化"或"某电商客服工单分流"），用四维评分矩阵算优先级得分。
第二，画AI介入点图，标清AI接管和人审环节。
第三，输出一套完整PoC方案设计套件，含场景卡、技术架构图、评估指标卡、Demo脚本、上线门禁清单。
第四，模拟一次"客户在场，我在改"的现场迭代：给一个客户反馈，5分钟内改Agent的System Prompt或Skill，演示修改后效果。

完成后，产出《行业场景优先级评分表》和《PoC方案设计套件模板》，作为后续项目交付的可复用资产。

第十四讲到这里。你手里已经有了从场景筛选到PoC方案设计的完整武器：四维矩阵定优先级、介入点图划人机边界、五件文档套件直接可交付、四步法验证假设、三条避坑指南少走弯路。下一讲，也是本系列最后一讲，我们进交付闭环——30天落地路线图与价值路演，把PoC真正变成可交付、可复用的业务成果。