当前位置：首页 > news >正文

别再做 AI POC 了：用 PSF 与 MVD 逃离“概念验证坟墓”

news 2026/8/15 9:21:09

本文是《企业 AI 落地实战：FDE 从 0 到规模化》第 3/10 篇。
上一篇讲清了 FDE 的责任边界；本篇提供一套可以直接用于 AI 项目立项、方案评审和试点验收的方法：PSF 三重检验 + 两周 MVD。
本文根据范冰《前线部署工程师：人工智能时代的客户价值交付秘籍》开源版 v1.0.6 梳理与解读。

一个 AI 团队抽调了三四名最强工程师，半年后做出了一套演示效果很好的系统。

领导看完点头，技术指标也不差，但项目从第一天起就没人回答一个问题：

这套系统的“好”，到底由谁、用什么标准判断？

没有裁判，没有业务基线，也没有从验证转入生产的条件。项目既不能宣布失败，也不敢扩大投入，最终进入没有截止日期的无限期状态，只能在季度汇报里反复写“持续推进”。

这就是企业 AI 常见的POC 炼狱：系统没死，却永远无法毕业。

逃离它，不能靠再换一个模型，而要在写第一行代码之前完成两件事：

用 PSF 判断问题是否值得解决；
用 MVD 在真实环境里验证价值是否真的发生。

一、POC 为什么会变成“坟墓”？

POC 是 Proof of Concept，即概念验证。它原本只应该回答一个问题：某项关键能力在技术上是否可行。

但很多企业把所有不确定性都塞进了 POC：

业务部门不知道真正想解决什么；
技术团队不知道数据能不能拿到；
采购不知道后续预算从哪里来；
管理层想看到一场足够惊艳的演示；
项目组又不敢写下明确的停止条件。

于是 POC 同时承担需求调研、技术预研、产品设计、预算申请和内部汇报，最后哪个问题也没有真正回答。

典型症状可以归纳成四个“无”：

症状	表面现象	真正风险
无期限	一再追加功能、持续延期	团队无法做取舍
无指标	只说“效果不错”	无法证明价值或决定付费
无裁判	IT、业务、管理层各说各话	验收时标准临时改变
无真实环境	使用样例数据和演示流程	上生产后问题集中爆发

POC 最危险的地方不是失败，而是它让错误项目长期占用最贵的工程资源。

二、PSF 三重检验：这个问题到底值不值得做？

PSF 是 Problem-Solution Fit，即“问题—方案匹配”。

图 1：PSF 不只判断技术能否实现，还要连续通过痛点、经济性与可行性三道门。

它不问“我们的产品能卖给谁”，而是先问：

客户这个具体问题，是否值得、并且能够被我们的能力解决？

一个 AI 场景必须连续通过三道关。

第一关：痛点检验

“提升客服效率”“建设智能数据平台”“用 AI 改造供应链”都不是问题，只是方向。

真正的问题必须落到具体的人、动作和代价：

客服主管每周一要花三个小时，从四套系统中汇总升级工单，导致她没有时间分析投诉根因。

可以用五个要素改写宏大需求：

谁，在什么场景，用什么旧方法，付出了什么代价，希望改变成什么结果。

如果找不到那个正在承受代价的人，项目很可能只是管理层的口号。

第二关：经济性检验

痛点真实，不代表值得用一支 FDE 团队解决。

立项前至少要算四笔账：

这项工作每周消耗多少人时？
一次错误会造成多少成本、损失或风险？
速度或质量改善后，释放的能力可以去做什么？
客户愿意为这项变化支付多少预算？

可以先用一个简化公式估算年度价值：

年度价值 ≈ 节省人时 × 综合时薪 + 避免损失 + 新增收入 − 新增运行成本

这个公式不追求财务级精确，目的是让项目从“AI 看起来很先进”切换到“这件事值多少钱”。

第三关：可行性检验

可行性不只是模型准确率，还包括客户的全部现实约束：

数据在哪里，谁拥有，质量怎样；
权限、法务和安全审查是否允许使用；
哪个系统负责读，结果又要写回哪里；
业务允许多大错误率；
模型拿不准时，谁来人工兜底；
团队能否在预定周期内打通闭环。

一个场景即使理论上能做到 99%，也可能因为数据不可达而无法启动；另一个场景只需要 90% 准确率加人工复核，就能创造足够高的价值。

PSF 的作用，就是把“技术上能不能做”升级为“在这个客户身上，值不值得做、实际上能不能做”。

三、别只做访谈：用“影子工作法”找到真实流程

用户说出来的流程，和他真正执行的流程，经常不是同一个。

正式流程写着“在业务系统中完成审核”，实际动作可能是：

从系统导出数据；
在个人 Excel 中重新计算；
发到微信群找资深同事确认；
再回系统填写一个形式上的结果。

这些绕路不是噪声，而是线索。

FDE 可以采用“影子工作法”：跟着真实用户过完一段真实工作时间，不急着提方案，只观察以下内容：

他依次打开哪些系统；
哪些字段要反复复制；
哪个环节等待最久；
出错时大家找谁；
哪份“非官方数据”反而最受信任；
哪些规则从未写进文档。

需求访谈容易得到“想要什么”，影子工作法更容易发现“为什么现在做不好”。

四、MVD：验证的不是功能，而是一次完整价值

MVD 是 Minimum Viable Deployment，即最小可行部署。

它与 MVP、传统 POC 的差异如下：

方法	核心问题	使用环境	最终裁判
POC	某项技术是否可行	常为样例环境	技术团队
MVP	市场是否需要这个产品	真实市场	用户增长与反馈
MVD	方案能否在这个客户身上产生价值	客户真实环境	业务负责人和业务指标

MVD 有三条不能妥协的军规：真实数据、缩小范围、限定周期。

1. 必须使用真实数据

演示数据会主动躲开所有难题：空值、重复、版本冲突、错误编码、隐性权限和历史流程遗留。

如果客户不愿提供任何可验证的真实数据，即使模型演示再漂亮，也不应把结果视为可生产化证据。

2. 缩小范围，不缩小价值

错误做法是把“大而全平台”砍掉七成功能，交付一个什么都能做一点、什么都不能闭环的阉割版。

正确做法是换一个维度缩小：

不做全公司的智能客服，只做退换货这一类工单；
不做全集团供应链优化，只处理一条产线的排产冲突；
不做企业数据分析平台，只生成区域经理每天必须看的异常日报。

切口可以小，但必须端到端进入真实工作。

3. 用周而不是月设置死线

截止时间的价值不只是“快”，而是迫使双方承认什么才是核心。

凡是无法在几周内对业务结果产生影响的功能，都不应该进入第一轮验证。

没有成熟平台的团队，可以采用“两周冲刺”版 MVD；已有连接器、部署模板和场景底座的团队，则可以继续压缩。

五、N 公司如何把“大平台”砍成一份异常日报

原书记录了一个匿名中国 AI 创业团队 N 公司的案例。

它面对三个客户线索：预算最大的券商、影响力很强但数据受限的医院，以及一家拥有 3000 家门店的区域零售集团。

团队没有选择合同最大的客户，而是选择了问题最具体、数据可触及、业务负责人愿意投入的零售集团。

进场后，两名工程师和一名行业顾问前两周没有写产品代码，而是跟着区域经理巡店。他们发现一个关键事实：

区域经理并不信任公司系统里的正式报表，真正使用的是门店店长每天手填的表格。

最初的“智能数据分析平台”因此被砍掉，MVD 被收窄为一个动作：

每天早上 8 点，把 3000 家门店前一天的销售异动、库存异常和投诉激增，整理成三分钟内读完的日报，推送到区域经理已有的工作渠道。

它同时满足三条军规：真实数据、单一高价值切口、六周死线。

按原书披露的匿名案例口径，第 90 天，日报自然打开率稳定在 85% 以上。这个数字比“系统创建了多少账号”更有意义，因为它说明用户不需要被催促，已经把系统变成工作习惯。

这个案例最值得复制的不是 85%，而是团队敢于砍掉“大平台”的决策纪律。

六、可直接使用的两周 MVD 模板

图 2：两周 MVD 用真实数据完成一次端到端价值闭环，并以业务结果而非功能演示验收。

下面这份模板适合没有 Palantir 式成熟平台、但已经具备基本模型与工程能力的团队。

时间	核心动作	必须产出
第 1～2 天	对齐用户、痛点、基线与裁判	一页问题定义、业务基线、毕业指标
第 3～5 天	接入真实数据并暴露问题	数据字典、质量报告、权限边界
第 6～8 天	打通一个端到端闭环	可运行流程、人工兜底与回滚方案
第 9 天	让真实用户完成真实任务	使用记录、失败样例、阻塞清单
第 10 天	由业务负责人现场验收	付费、迭代或停止的明确决定