FDE 交付实战营

Appearance

第四章 数据诊断与 demo ​

4.4 MVP 与 MVA ​

承前：demo 内循环转完，客户高管会上有人问了一个尖锐的问题："我们这是在做一个 MVP 吗？"会议室里安静了三秒——因为"最小可行产品"这个词每个人理解都不一样。这一节就来把这个概念拆开：对 Agent 交付而言，比 MVP 更早出现的是 MVA（最小可行 Agent），而 MVA 的第一承重柱不是模型，是数据链路。想清楚 MVP/MVA/POC/试点的关系，你就知道每个阶段该交付什么、该验证什么假设。

4.4.1 MVP 的本义与它在企业交付里的水土不服 ​

MVP（Minimum Viable Product）出自精益创业：用最小功能集快速验证"用户要不要"。它隐含的假设是——产品是独立存在的，用户是开放市场上的匿名个体。

企业交付的环境恰好相反：客户是唯一的、具名的、政治复杂的组织。给青禾做一个"最小可行产品"，问题马上冒出来：对副总裁可行（指标动了）不等于对运营可行（工作流改了）、也不等于对 IT 可行（安全审计过了）。在企业里，"可行"不是用户要不要，是三方关切的交集。 所以 FDE 圈子里衍生出了自己的概念：MVA。

4.4.2 MVA：最小可行 Agent ​

MVA（Minimum Viable Agent）的定义：范围最窄、但决策链路完整、可以在真实环境里跑出可归因结果的 Agent。

拿沙盘对照：青禾召回用例的 MVA 长这样——

MVA 边界
────────────────────────────────────
范围    1 家门店 / 沉睡会员召回 / 7 天周期
输入    试点门店订单数据（真实，已过诊断过滤）
能力    分群 → 生成触达文案 → 提交人工审核
输出    触达名单 + trace 全程日志
不可用   自动发送 / 全门店 / 多渠道 / 无人值守
────────────────────────────────────

MVA 与 demo 的区别：demo 是演给客户看的，MVA 是交给客户用的。运营经理在 MVA 里真的用审核工作台放行了一批触达名单——从这一刻起，系统进入真实使用，反馈不再来自会议，来自使用行为。这是信任曲线的真正拐点。

MVA 的验收不是"功能都好"，而是三条更硬的标准：有人每天真的在用（使用率）、trace 能解释每一个决策（可审计性）、错误能被抓住且在收敛（bad case 进入回归）。

4.4.3 数据链路是 MVA 的第一承重柱 ​

这一节最重要的一张图。传统软件的 MVA 承重结构里，应用逻辑是第一支柱，数据是配套；Agent 的 MVA 反过来：

        传统软件 MVP                Agent MVA
   ┌─────────────────┐      ┌─────────────────────┐
   │   应用逻辑        │      │  数据链路 ★第一承重柱  │
   │  ★第一承重柱      │      │  (口径/映射/清洗/回测)  │
   ├─────────────────┤      ├─────────────────────┤
   │   数据存储        │      │  Agent 编排           │
   ├─────────────────┤      ├─────────────────────┤
   │   基础设施        │      │  模型调用(可替换层)     │
   └─────────────────┘      └─────────────────────┘

为什么数据链路是第一承重柱？因为 Agent 的每一个动作都踩在数据语义上：分群靠口径、触达靠会员数据、效果靠回测指标。模型层是最容易替换的（下个月出更强模型，编排层换个调用就行），数据链路是最难替换的（双轨 ID 映射表用了半年，全组织都对它产生依赖）。所以 Agent 交付的早期投入要压在数据链路上——这正是本课程 W4-W5（数据诊断 + 本体语义层）占据两周篇幅的原因，也是米兰案例里"AI 部分 5 天，数据定义几周十几场会"的结构性解释。

4.4.4 POC、试点、正式项目：三个不同的游戏 ​

企业 AI 采购有清晰的阶段序列，每阶段的验证目标、退出条件、失败代价完全不同：

阶段验证什么时长退出条件失败代价
POC（概念验证）技术上可行吗2-4 周一次成功的演示小：预算几十万，没过就散
试点（Pilot）在真实环境有效吗1-3 个月预设指标达标（对照组）中：内部信誉损失，预算打水漂
正式项目规模化 + 组织接得住6-18 个月SOW 全量验收 + 运维移交大：乙方尾款、甲方战略延期

FDE 要分清自己在哪个阶段，因为每个阶段的动作逻辑不同：POC 允许 hack（它就是要快速验证），试点不允许（试点是生产的预演）；POC 的成功标准是"让客户说哇"，试点的成功标准是"让指标说话"；正式项目阶段，评估、变更管理、知识转移全面上位，demo 级的敏捷要收敛成有 SLA 的工程纪律。

常见的悲剧是阶段错位：客户把 POC 当正式项目用（数据没治理、评估没建，直接全门店上线），或者乙方把试点当 POC 做（ hack 满地、没对照组、效果说不清）。FDE 的职责之一就是在阶段边界上做"守门员"——SOW 里明确写出本项目属于哪个阶段、下一阶段的进入条件是什么。

4.4.5 沙盘：青禾的阶段设计 ​

把这套框架套回青禾，第一期 SOW 的阶段结构就清晰了：

W1-W2  诊断      →  诊断报告（D2）
W3     需求/SOW  →  范围、口径、里程碑
W4     数据+demo →  MVA v0（1 店，链路通）
W5     语义层    →  指标/会员本体注册
W6     安全质询  →  权限、脱敏、审计
W7-W8  试点扩展  →  20 店试点 + 对照组（指标验证）
W9-W10 生产硬化  →  正式项目：SLA、监控、评估回归

注意 W4 的 MVA 只是试点阶段的前奏，指标验证（+1.5pp 复购）挂在 W8 的对照组回测上——MVA 阶段不承诺指标结果，只承诺链路和可审计性。这个阶段化承诺写进 SOW，双方对"什么时候验什么"有共同预期，是后期不扯皮的根基。

4.4.6 从 MVA 长到 MVP：成长而不是重建 ​

MVA 稳定后向 MVP 演进的路径，是加宽而不是重构：门店从 1 到 20、渠道从短信到 App 推送、人群从沉睡到半沉睡、自动化程度从人审全部到低风险自动放行。每一步加宽都伴随一次评估回归（第 7 章）——MVA 阶段攒下的 bad case 评估集，此时就是护栏。

一个自检问题判断你是否在做正确的演进："这次加宽之后，系统里有没有任何一部分是 MVA 时代要推倒重来的？"如果有，说明 MVA 的地基（数据链路、口径注册、trace 结构）没打对，先回去补地基——在错误地基上加宽，宽到全门店时爆破的代价是 MVA 时代的一百倍。

4.4.7 交付物形态：MVA 阶段你实际交出什么 ​

把 MVA 从概念落到交付物清单。MVA 阶段（W4-W6）结束时，你实际交给客户的是六样东西，每样都可验收：

MVA 交付包
────────────────────────────────────────────
1 数据诊断报告        问题五段式 + 决策留痕（4.1）
2 指标口径注册        语义层条目 + SQL + owner（3.4）
3 MVA 系统本体        1 店链路：接入/分群/审核/模拟触达
4 trace 与日志        全程可回放，含 bad case 归档
5 评估集 v0           demo 暴露的 bad case 转回归用例
6 运营 SOP 草案       一线怎么用、出错怎么处理、何时升级

第 6 项最常被漏。MVA 的"V"（viable）不仅指系统可行，指这套系统在客户组织里可持续运转——运营经理每天什么时候打开审核台、驳回一条建议后发生什么、发现 Agent 异常打给谁，这些要写成 SOP 草案陪 MVA 一起交付。没有 SOP 的 MVA 会在你休假的一周里荒废：没人知道出错该怎么办，使用率断崖，两周后再也没有人登录。

这六样交付物同时也是 MVA 到试点的升级条件清单——试点立项评审时，逐项检查六件套的成熟度：诊断报告的决策都闭环了吗？口径注册的 owner 签字了吗？SOP 跑过一整周吗？六件套的完成度，就是"可不可以扩到 20 店"的答案，比任何主观判断都可靠。

4.4.8 要点总结 ​

  • MVP 假设开放市场与匿名用户；企业交付的"可行"是副总裁、运营、IT 三方关切的交集，因此需要 MVA 这个专门概念。
  • MVA = 范围最窄、决策链路完整、跑出可归因结果；验收三标准：真有人在用、trace 可解释、错误在收敛。
  • 数据链路是 Agent MVA 的第一承重柱：模型层易替换，数据链路难替换，早期投入要压在口径、映射、清洗、回测上。
  • POC 验证技术、试点验证效果、正式项目验证组织承接力；FDE 是阶段边界的守门员，SOW 要写明本阶段性质与下一阶段进入条件。
  • MVA 到 MVP 的演进是加宽不是重构：若加宽需要推倒 MVA 的某部分，说明地基没打对，先补地基。

参考资料 ​