本文是《企业 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即“问题—方案匹配”。图 1PSF 不只判断技术能否实现还要连续通过痛点、经济性与可行性三道门。它不问“我们的产品能卖给谁”而是先问客户这个具体问题是否值得、并且能够被我们的能力解决一个 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 式成熟平台、但已经具备基本模型与工程能力的团队。时间核心动作必须产出第 12 天对齐用户、痛点、基线与裁判一页问题定义、业务基线、毕业指标第 35 天接入真实数据并暴露问题数据字典、质量报告、权限边界第 68 天打通一个端到端闭环可运行流程、人工兜底与回滚方案第 9 天让真实用户完成真实任务使用记录、失败样例、阻塞清单第 10 天由业务负责人现场验收付费、迭代或停止的明确决定两周结束时团队不应该只演示“系统能做什么”而应回答五个问题真实用户是否完成了目标任务与旧方法相比时间、质量、成本或风险改变了多少哪些错误可以接受哪些必须人工接管要进入生产还缺哪些工程条件客户是否愿意为下一阶段投入预算与人员七、把“毕业”和“停止”同时写进方案一份健康的验证方案必须同时存在两个出口。毕业条件指标达到双方预先确认的阈值业务负责人认可结果真实用户愿意继续使用数据、权限和集成路径已经验证下一阶段范围、预算和负责人明确。停止条件没有明确业务负责人客户始终拒绝提供可用的真实数据需求持续扩张无法形成单一切口经济价值不足以覆盖长期成本关键合规或系统条件在可预见时间内无法满足。停止不是交付失败而是避免把整个团队埋进错误问题。八、立项前最后检查三类高危项目如果以下三种信号出现两种以上应暂停开工没有业务土地所有者。项目只有 IT 对接没有愿意对业务结果负责的人只许看不给碰。客户要求证明效果却不提供任何真实数据宇宙级需求。第一次会议就要求覆盖全公司、全流程、全场景。最后把项目名称从“建设智能平台”改写为一句可以验收的话在两周内让某类真实用户使用真实数据完成一个高频任务并把某项业务指标从基线 A 改善到目标 B。如果这句话写不出来项目还不该开始。下一篇我们从“选对问题”继续向前一步第一批 AI 客户应该怎么选为什么一个大合同可能是需求蝗虫而一个预算中等、愿意共创的客户反而能成为真正的灯塔AI 工具补给站https://pay.ldxp.cn/shop/5XW5R5KP参考与说明本文主要依据范冰《前线部署工程师》开源版 v1.0.6 第 2 章、8.5 节及附录 C 梳理PSF、MVD、Palantir AIP 训练营和 N 公司案例的数字与判断均来自原书及其列明的公开资料其中 N 公司数字已按原书说明做模糊化处理企业项目的数据条件、周期与业务阈值差异很大文中的两周模板是项目评审框架不是对所有场景的固定工期承诺如需转载、商业改编或用于付费内容请遵守原书版权声明并取得相应授权。