FDE 交付实战营

Appearance

第四章 数据诊断与 demo ​

4.3 demo 内循环 ​

承前：数据诊断做完了，问题清单挂上了决策，现在客户要看"东西"。W4 的下半场是 demo——注意，不是上线前的彩排，而是签单后的第一个可运行证明。这一节讲 demo 内循环的四条军规：范围窄但链路完整、用真实数据、主动暴露 bad case、先让 AI 模拟客户走查。Demo 做得好，信任提前三个月建立；做得差，项目从第二个月开始还债。

4.3.1 demo 的真实目的：证明的不是模型，是链路 ​

先校准认知：企业客户在 W4 要看 demo，他心里的问题不是"大模型行不行"（这个他自己试过 ChatGPT），而是：

  1. 你们的方案在我的数据上能不能跑？（可行性）
  2. 链路断在哪一环？（风险点位）
  3. 我的人用得起来吗？（组织接受度）

所以 demo 的设计目标不是展示模型多聪明，而是证明链路通、暴露链路险。一个能对 20 家试点门店的真实订单数据回答"这周哪些沉睡会员被触达了、效果如何"的窄 demo，价值远超一个什么都能聊的通用问答机器人。前者让副总裁看到了从数据到动作的闭环，后者只会引来"能不能顺便做个报表"式的范围蔓延。

4.3.2 军规一：范围窄，但链路完整 ​

demo 的范围要比第一期用例再窄一档，但每一环都要真：

Demo 范围：1 家门店 × 沉睡会员召回 × 7 天数据
                    │
  ┌────────────────┴─────────────────┐
  │ 数据接入(真实) → 口径计算(真实SQL)  │
  │   → Agent分群(真实调用)            │
  │     → 人工审核界面(可点击)           │
  │       → 模拟触达(沙箱通道)          │
  │         → trace日志(全程可回放)      │
  └──────────────────────────────────┘

七个环节一个不缺，哪怕每个环节都只有最小实现。反例是"demo 特供"：数据是手工造的 CSV、分群是写死的列表、审核界面是截图——这种 demo 在演示时很顺，客户一旦要求"换一家店试试"就当场崩盘，而客户一定会这么问。链路完整的最小 demo 换店只要改一个参数；数据造假的 demo 换店等于重做。

4.3.3 军规二：用真实数据 ​

真实数据是 demo 的诚信基础，也是它最大的风险源——真实数据里有 4.2 节的所有坑。处理原则：

  • 脏数据可以过滤，不可以编造：双轨 ID 映射不全的会员就先排除，在 demo 里注明"受 ID 覆盖率影响，本 demo 排除 13% 订单"——这句话本身就是加分项，它证明你诊断过、你知道边界在哪。
  • 敏感数据必须脱敏：手机号、姓名在 demo 环境脱敏展示，脱敏规则写进 demo 说明。这一条做扎实，W6 的数据安全质询会好过很多。
  • 不现场算就别假装实时：如果指标计算是 T+1 的，demo 就演示 T+1 的数据，别用缓存冒充实时——被识破一次，后面所有演示的信任都打折。

4.3.4 军规三：主动暴露 bad case ​

这是最反直觉的一条军规：demo 要自己先讲系统的失败案例。

新手的本能是 demo 只演好的。但企业客户里坐着的都是见过供应商翻车的人，他们对"完美 demo"的默认解读是"演得太顺了，肯定有问题"。你主动暴露 bad case，收获的是三样东西：

  • 可信度：你承认 Agent 把"投诉过慎触"的会员错误拉进了召回名单（因为标签备注模式），同时展示 trace 日志如何定位到这个错误——这一幕比十次成功演示更能证明系统是可审计的；
  • 预期管理：客户提前知道系统会犯错、知道错在哪一类，上线后遇到同类错误就是"已知问题"而不是"重大事故"；
  • 评估接口的亮相：你顺势展示了 bad case 如何进入评估集、如何变成回归测试用例——这是把"系统会犯错"转化为"错误被管理"的关键一跳，也是 Agent 工程区别于传统软件工程的核心卖点。

实操上准备一页"已知问题与对策"幻灯片，demo 中段主动讲，别等客户问。

4.3.5 军规四：先让 AI 模拟客户走查 ​

demo 前最后一道工序：让另一个 AI 扮演客户方各角色，对你的 demo 做压力走查。

做法很朴素：开一个新会话，给模型角色设定（"你是青禾的运营经理，对 AI 不信任，用过三套失败的报表系统，你的问题是……"），让它对你的 demo 讲解稿和演示流程提问、挑刺、要求换场景。再设一个 IT 负责人角色，专问安全与权限；一个 CFO 角色，专问成本。

这个走查的价值不在 AI 提的问题多高明，而在逼你提前把回答外化：很多"到时候再说"的问题，被 AI 角色问出来之后你才发现自己没有答案——比如"会员拒绝触达之后多久从名单移除？"这类细节，现场被问到现编，是 demo 翻车的经典姿势。走查后把没答上来的问题补成 FAQ，带上 demo 现场。

顺带说，这一招也是 FDE 团队内部的常规排练手段——用 AI 当陪练的成本，比同事排练低一个数量级，而且 AI 角色不会累、可以反复来。

4.3.6 demo 内循环：一个四步迭代环 ​

四条军规串起来，构成 demo 的内循环：

   ┌── 1 定窄范围(链路完整) ──────────┐
   │                                  ↓
   4 AI 走查补FAQ ← 3 主动暴露bad case │
   ↑                                  │
   └──── 2 真实数据跑通 ←─────────────┘
        (发现问题→回诊断清单→修复→再跑)

注意环里第 2 步到诊断清单的回流箭头：demo 用真实数据跑，必然撞出新的脏数据问题，撞出来的问题进诊断报告，而不是进"临时 hack"——hack 进了代码，就成了 W9 生产硬化时要爆破的暗堡。

这个循环每转一圈，demo 的可信度上一个台阶。青禾沙盘里这个循环转了三轮：第一轮撞出时间格式解析错误（进标准化层修复），第二轮撞出"半沉睡"分群口径问题（回口径会议），第三轮才稳定。三轮两周，比"一把做完美 demo"的幻觉路线快得多。

4.3.7 demo 之后的三个动作 ​

demo 演示完不是结束，紧接着做三件事，把 demo 的势能接住：

  1. 48 小时内发纪要：demo 里承诺的、暴露的、待定的，逐条记录发客户确认——口头共识的半衰期只有一周；
  2. bad case 清单进评估集：demo 暴露的每个错误都变成回归用例，第 7 章的评估驱动开发由此起手；
  3. 收集客户方的"换场景"请求：客户看完 demo 提的每个"能不能试试 XX"都记下来——那是第二期用例优先级表的原始素材。

4.3.8 demo 现场的危机手册 ​

最后给一份 demo 现场的"翻车急救包"——每个 FDE 都会在某一次 demo 上翻车，区别在于有没有预案：

Agent 当场给出错误答案：不要慌着辩解。最佳动作是当着大家的面打开 trace，一起看错误发生在哪一步——这恰好是你演示"可审计性"的机会。话术："这个问题问得好，我们看下它是怎么得出这个结论的。"边看边讲，错误变成教学素材。

演示环境突然连不上客户数据源：所以 demo 环境要有本地缓存快照，且开场第一句话就说明"今天用的是 T-1 数据快照，生产链路每日刷新"——既是实话，也是断网保险。

客户问"能不能顺便做 XX"：标准答案是"记下来，进二期评估清单"，不是"可以啊"，也不是"不行"。当场答应会烧掉你 3.2 节辛苦建立的取舍成果。

高管临时要求看"幻觉率"或"准确率"：这是第 7 章评估驱动开发的预告场景。如果没有现成评估集，如实说"评估集正在建设，下个里程碑给出可复核的数字"，永远不要现场编一个准确率。

时间被砍半：砍掉功能演示，保住链路演示 + bad case 环节。功能可以后续单独演示，链路和诚信的印象只有一次机会。

把这张手册和你的 demo 讲解稿放在同一个文件夹里。它们共同的底层原则只有一句：demo 的失败可以修复，demo 的失信不能。 所有现场动作的目标都是维护"这个团队诚实且可控"的印象，功能层面的瑕疵反而是最不值得为之冒险的东西。

4.3.9 要点总结 ​

  • demo 的目的不是证明模型聪明，是证明链路通、暴露链路险；窄而完整的链路，优于宽而掺假的覆盖。
  • 四条军规：范围窄但链路完整（每一环都真）、真实数据（可过滤不可编造，敏感脱敏）、主动暴露 bad case（可信度 + 预期管理 + 评估接口亮相）、AI 模拟客户走查（把"到时候再说"逼成 FAQ）。
  • demo 是循环不是冲刺：真实数据撞出的新问题回流诊断清单，禁止临时 hack。
  • demo 后 48 小时动作：纪要确认、bad case 进评估集、换场景请求进二期素材——势能不接住就是白演。

参考资料 ​