8.58.1 为什么 Demo 与汇报决定 FDE 能否拿单/续约

FDE 的工作链路可以粗略地拆成三段:做出来、看得见、说得清。绝大多数工程师默认第一段最难,但在真实的客户现场,真正决定一个项目能否签下来、能否续约、能否被客户自传播的,往往不是代码本身的复杂度,而是后两段——演示(Demo)与汇报。原因不复杂:客户的决策者一周要看十几家供应商,他们的注意力窗口极短;技术负责人要向自己的老板证明"这件事值得做",手里能拿来当筹码的只有你的那次 Demo 和那份汇报材料。如果 FDE 把价值做出来了却没有讲出来,在客户感知里就等于没做。

一句话锚定:Demo 是客户第一次"用眼睛看见价值"的瞬间,汇报是客户"用文件形式记住价值"的载体,二者共同决定 FDE 的转化率。

从商业逻辑上看,Demo 与汇报的权重有结构性原因。第一,信息不对称:客户对模型的内部细节、数据管道的复杂度没有体感,他们判断"这个团队行不行"的依据,很大程度上来自那次 30 分钟的演示里你讲得清不清楚、演示跑得稳不稳、数字摆得明不明白。第二,决策者错位:真正拍板的人(CXO、业务一号位)通常不是天天跟你开会的那位对接人,你交付的汇报材料要能在没有你在场的情况下,自己替你把话讲完。第三,续约周期:第一次合同结束前的阶段汇报,是续约谈判最重要的筹码,流水账式的"我们做了 20 个需求"几乎一定会被压价,而"我们为你省下了 3200 工时/年、风险事件响应从 48 小时降到 2 小时"这种汇报,才有续约溢价的空间。

实战中常见的失分场景有三类:一是把 Demo 当作功能巡礼,客户听完只知道你做了什么,不知道值多少钱;二是汇报材料只堆"完成事项",没有把"业务结果"翻译成客户老板听得懂的语言;三是 Demo 与生产脱节,演示里展示的精度在客户真实数据上掉到不可用,后续信任崩塌。这三个问题后面都会展开。下面先从 Demo 的本质讲起。

8.58.2 Demo 的本质:用最小成本让客户"看到价值、产生信任"

很多 FDE 把 Demo 理解成"把做好的功能点一遍",这是错位的。Demo 的本质不是功能展示,而是一次低成本的信任建立过程。客户在 Demo 里需要回答自己心里三个问题:这件事真的能做吗(可行性)?做出来对我有什么用(价值)?换别人来能做得一样好吗(团队能力)?一个优秀的 Demo,会在这 20–40 分钟里同时给出这三个答案。

定义:Demo = 真实场景 × 可见价值 × 处理边界 × 不翻车。任何一项缺位,信任就无法建立。

"最小成本"是双向的。对客户而言,他付出的成本是 30–60 分钟注意力加一些内部协调,他要的是高密度信息;对你而言,你付出的成本是为这次演示专门准备的脚本、数据、兜底预案。把这两边的成本曲线想清楚,你就明白为什么 Demo 不能直接拿生产环境临时跑——生产环境的随机性、客户数据的敏感性、网络与算力的波动,都会把这次高价值的信任建立瞬间变成翻车现场。Demo 应该是一个被精心设计、排练过的"剧场版本"。

这里有一个常见的认知陷阱:工程师倾向于相信"真实跑一遍最诚实"。但对 Demo 而言,预先准备的真实比临时跑的真实更有说服力。原因是 Demo 的目标不是证明系统能跑,而是让客户在有限时间内看清价值链路。预先准备意味着你可以挑选有代表性的输入、可以保证网络稳定、可以提前把模型预热、可以把演示路径设计得没有歧义。这并不违反"真实"——你用的依然是真实模型、真实数据样本、真实业务逻辑,你只是把不可控变量排除了。

最后强调一点:Demo 不是一次性事件,而是贯穿销售与交付周期的多次动作。第一次接触的 15 分钟闪电 Demo 用于筛客户;立项评审的 40 分钟完整 Demo 用于拿单;交付过程中的阶段 Demo 用于验证进度与对齐方向;结项的复盘 Demo 用于撬动续约。每个阶段 Demo 的对象、目的、深度都不同,FDE 要有意识地把它当成一个节奏工具来用,而不是被动地等客户提出"给我们演示一下"。

8.58.3 好的 AI Demo 的要素

把无数次现场 Demo 复盘后,可以提炼出五个共同的要素,缺一不可。

真实场景。Demo 必须落在客户自己业务的一个具体场景里,而不是一个通用 demo 库。同样是做合同审查,制造业客户的痛点是采购合同条款风险,金融客户关注的是合规口径,互联网客户在意的是结算条款——演示用同一套通用合同库跑给所有人看,客户第一反应就是"这跟我不沾边"。真实场景的判断标准很简单:如果客户看完 Demo 第一句话是"对,我们就是这个场景",那就对了;如果是"这个我们能改吗",那就是没对上。

真实数据。这是 AI Demo 与传统软件 Demo 最大的区别。传统软件 demo 用什么数据无所谓,因为逻辑是确定的;AI Demo 用什么数据直接决定结果可信度。最佳实践是从客户现场脱敏后取一小批真实样本(20–50 条),让模型在演示中真跑一遍。如果做不到真实脱敏数据,至少要用与客户分布接近的合成数据,并明确告知客户数据来源。最差的做法是用网上找的明星样例(比如拿一段已经广为流传的 GPT 回答当演示输出),客户一眼能识破,信任瞬间归零。

可见价值。Demo 里必须有一个"价值时刻"——客户能直观看到 AI 帮他省了多少时间、避了多少风险、多赚了多少钱。这个时刻通常是一个对比:左边是人工处理的耗时与结果,右边是 AI 处理的耗时与结果,中间用数字标注差异。可见价值的关键是量化到客户能感知的单位——不是"提升了 30% 准确率",而是"一份合同从 45 分钟降到 6 分钟,一年 8000 份合同省下 5200 工时"。

处理边界。好的 Demo 不会假装 AI 万能。恰恰相反,主动展示 AI 处理不了的边界、降级到人工的判断、需要人复核的环节,反而能极大增强信任。客户的潜意识里"AI 一定会出错",你不承认,他就怀疑你在藏;你大方承认并给出兜底机制,他会觉得你专业。处理边界的展示要具体:"长尾罕见条款识别准确率掉到 60%,我们会自动标记并转人工复核,平均处理时长仍可控在 15 分钟内"。

不翻车。这是底线要素。Demo 翻车的代价是毁灭性的——客户不会记得你前 25 分钟讲得多好,只会记得最后 5 分钟模型胡言乱语、界面卡死、网络断开。不翻车靠的不是运气,而是后面会讲的兜底设计。FDE 圈子里有一个不成文的共识:一个翻车 Demo 抹掉三个月的客户经营。

五要素口诀:场景真、数据真、价值显、边界明、不翻车。

8.58.4 Demo 设计流程

一次成功的现场 Demo 是设计出来的,不是即兴发挥的。设计流程通常分五步:选场景 → 写脚本 → 备数据 → 排练 → 兜底。

第一步:选场景。这是整个流程里最关键、却最容易被工程师忽视的一步。选场景的原则是"客户痛点最痛、AI 能力最稳、演示路径最短"三者的交集。不要贪心在一个 Demo 里展示所有能力,30 分钟里塞 5 个场景,每个都只能蜻蜓点水,客户记住的反而为零。一个完整 Demo 通常聚焦 1–2 个核心场景,另准备 1 个延伸场景作为问答时的"弹药"。

第二步:写脚本。Demo 必须有逐字逐句的脚本,包括开场白、每一步操作的解说词、价值点的强调语、过渡句、收尾。脚本要按"客户视角"写,而不是"功能视角"——客户不在乎你点了哪个按钮,在乎的是这件事为什么对他重要。脚本里要预先标注价值时刻的位置,提醒自己在这里停顿、强调、留出客户反应的时间。

第三步:备数据。准备两份数据:一份是主线数据,即演示里要用的、跑过验证的样本,确保输出符合预期;一份是弹性数据,即客户可能临时要求换场景时能立刻调用的备选样本。所有数据都要脱敏,所有样本都要提前跑过至少三遍,记录每次的输出,确认稳定性。AI Demo 的数据准备比传统软件严苛得多,因为模型对输入敏感,边缘样本可能直接触发意外输出。

第四步:排练。FDE 圈子里有一个共识:Demo 至少完整排练三遍。第一遍自己排,熟悉节奏与时间;第二遍拉同事扮演客户排,测试交互与问答;第三遍穿正式场合装束、用客户现场的设备条件(比如客户的投影、客户的网络)排,排除环境差异。排练时要用秒表计时,每个环节卡死时长,避免后面挤掉问答时间。

第五步:兜底。这是设计流程里技术含量最高的一步。兜底分三层:网络兜底(准备 4G/5G 热点、离线版本)、模型兜底(准备降级到更稳定的小模型或缓存结果)、流程兜底(模型出问题时如何自然过渡到下一环节)。兜底的核心不是"假装没问题",而是"出问题时客户感知不到"。一个准备充分的 FDE,会在客户临时提出"换一个我们自己的样本试试"时,从容切换而不掉链子,这种从容本身就是信任的来源。

Demo 设计五步法:选场景(单点穿透)→ 写脚本(逐字版)→ 备数据(主线+弹性)→ 排练(三遍+秒表)→ 兜底(网络/模型/流程三层)。

8.58.5 给不同对象的 Demo

客户现场从来不是一个统一受众,Demo 的对象不同,讲法必须不同。强行用一套讲法对所有角色,往往会陷入"老板觉得听不懂、业务觉得太技术、IT 觉得太浅"的三输局面。

面向 CXO(决策层)的 Demo:核心讲价值与战略。CXO 的注意力窗口通常只有 10 分钟,如果前 10 分钟没让他看到"这对我公司的营收/成本/风险有什么影响",后面再精彩他也不会听下去。Demo 要前置价值结论(开头 3 分钟直接给出"一年省 5000 万/风险事件减少 80%"),技术细节全部砍掉,界面演示只展示价值时刻,架构图只放一张"我们如何嵌入你现有体系"的高层图。CXO 最关心的是风险与可控性,所以要主动讲清"我们如何不绑架你的核心系统、出问题怎么退回原状态"。

面向业务一号位(运营/产品/业务负责人)的 Demo:核心讲效果与流程改造。业务负责人不关心模型多先进,只关心"用了这个东西之后,我的团队工作流要怎么变、KPI 怎么改、人要不要裁/招"。Demo 要落到具体岗位:"过去客服组长每天花 2 小时抽检工单,现在 AI 自动分类,组长只看 AI 标记的 5% 高风险工单,抽检时间从 2 小时降到 20 分钟,而且覆盖率从 10% 提升到 100%"。业务负责人最关心的是落地阻力,所以要主动讲清"哪些环节需要人配合、培训成本多大、上线后前三个月的过渡方案"。

面向 IT/技术负责人的 Demo:核心讲架构与可维护性。技术负责人天然怀疑供应商,他们想确认"这东西部署起来麻不麻烦、出问题我们能不能自己排查、会不会拖垮现有系统、数据安不安全"。Demo 要展示完整的架构图、部署模式(SaaS/私有化/混合)、监控接口、日志规范、数据流向、安全合规。技术细节要扎实,不要怕讲深,他们要的就是这种"被认真对待"的感觉。技术负责人是隐性决策者,他们一句"这东西部署有坑"足以否决整个项目。

实战中常见的情况是三类受众同时在场,这时 Demo 要做"分层叙事":开场 5 分钟讲价值(给 CXO),中间 15 分钟讲效果与流程(给业务),结尾 10 分钟讲架构与落地(给 IT),问答环节按提问对象灵活切换语言。这种分层结构对 FDE 的功底要求很高,但是真正能拿单的 Demo 几乎都是这种结构。

一份 Demo,三种语言:CXO 听价值、业务听流程、IT 听架构,分层叙事而非统一播报。

8.58.6 现场 Demo 翻车的防范

Demo 翻车是 FDE 最痛的失分场景,防范要从四个维度系统做:网络、模型、数据、预案。

网络翻车。客户现场的网络环境千差万别,有的客户内网严格白名单、有的 WiFi 极不稳定、有的对模型 API 出口完全封禁。防范清单:提前一周问清客户的网络条件(内网/外网、出口白名单、是否需要 VPN);Demo 设备准备 4G/5G 备用热点,且提前测过热点能否连到模型服务;准备一份完全离线的 Demo 版本(本地小模型或预录视频),即使网络全断也能讲完。绝对不要假定"应该能联网"。

模型翻车。AI Demo 的模型不确定性是最大变量。同样的输入在不同时间、不同负载下可能给出不同输出,这是工程师最熟悉但客户最不能接受的"翻车"。防范清单:演示前 30 分钟跑一遍主线数据,确认输出符合脚本;主线数据预先跑过至少三次,记录每次输出,挑选最稳定的一组;关键演示环节使用缓存结果(实际跑过一次后把结果存下来,Demo 时调用结果而非实时调用模型),把不确定性降到零;万一实时跑出意外结果,准备一句过渡话术("这是一个有意思的边界情况,我们稍后在问答环节详细讨论"),迅速切回主线。

数据翻车。客户临时要求换他们自己的真实数据跑,这是 Demo 里最容易翻车的瞬间。客户自带数据可能涉及敏感信息(脱敏不充分)、可能落在模型训练分布之外(罕见格式)、可能触发模型的安全过滤(合规口径)。防范清单:Demo 前主动邀请客户带 2–3 个真实样本,提前一天送达脱敏处理,纳入弹性数据集;如果客户现场临时给数据,先快速评估数据类型(只接文本不接图像、只接结构化不接非结构化),不接的样本用话术拒绝("这类样本我们需要先做合规检查,会后给您专门跑一份");所有客户数据演示完后当场删除,体现专业度。

预案翻车。预案不是"如果出问题怎么办"的口头讨论,而是一份写在文档里的应急剧本。每个 Demo 都要准备一份"翻车剧本":网络断 → 切热点 → 还不行 → 切离线版本;模型异常 → 切缓存结果 → 还不行 → 跳过该环节,先讲价值与架构,会后补跑;客户提问超出准备范围 → 用"这是个好问题,我们专门安排一次技术交流深入讨论"过渡。翻车剧本的关键不是消灭翻车,而是让翻车在客户感知里消失。

翻车防范的四道墙:网络(离线版本兜底)、模型(缓存结果降不确定性)、数据(提前邀请样本)、预案(翻车剧本)。

8.58.7 汇报艺术:周报/阶段汇报/结项汇报的结构

汇报是把交付结果固化为客户感知的载体。FDE 的汇报通常分三类:周报、阶段汇报、结项汇报,三者的目的、读者、结构都不同,用一套模板套所有场合,是新手最常见的错误。

周报:目的是让客户对接人与项目组保持同步,读者是 PMO 与业务对接人,长度控制在一页内,核心结构是"本周进展 + 下周计划 + 风险与求助"。周报最大的反模式是流水账,把每天做的事堆上去,客户读完不知道进展是否符合预期。正确做法是周报只讲三件事:本周交付了什么(可验收的产出,不是"开了一个会")、下周计划交付什么(具体到可验证的产出)、有什么风险需要客户配合(点名需要的决策或资源)。每一项都要可追踪、可回溯。

阶段汇报:通常在每个里程碑(立项、PoC、试点、推广)结束时进行,读者扩展到业务一号位与技术负责人,长度可以是 10–20 页 PPT,核心结构是"目标回顾 + 阶段成果 + 数据验证 + 风险与决策点 + 下阶段计划"。阶段汇报最关键的部分不是"我们做了什么",而是"数据验证了什么"——必须有量化指标证明阶段目标达成。例如 PoC 阶段汇报的核心数据是"准确率 X%、覆盖率 Y%、人工介入率 Z%、单条处理成本 W 元",并附上测试集来源与评测方法,让数据可复现、可挑战。阶段汇报一定要预留 1–2 个明确的"决策点",即需要客户拍板的事项,把汇报变成推进项目的机会,而不是单向通报。

结项汇报:这是 FDE 交付周期里最重要的一次汇报,直接关系验收与续约。读者包括 CXO、业务一号位、技术负责人、采购,长度可以是 20–40 页,核心结构是"业务价值回顾 + 技术成果 + 数据对比 + 客户证言 + 续约建议"。结项汇报的核心是把所有技术成果翻译成业务语言:"模型准确率 92%"对 CXO 无意义,"年节省 5200 工时、折合 320 万元人力成本、风险事件响应从 48 小时降到 2 小时、监管处罚风险下降 70%"才是 CXO 听得懂的话。结项汇报必须有"前后对比"——上线前的基线数据 vs 上线后的实际数据,用同一口径,可审计。结项汇报的最后两页永远是续约建议:下一阶段可做的方向、预算预估、预期收益,把汇报变成下一单的起点。

三类汇报三种结构:周报(一页/进展-计划-风险)、阶段(里程碑/数据验证-决策点)、结项(价值翻译-前后对比-续约建议)。

8.58.8 数据可视化与故事化

数字本身没有说服力,数字被讲成故事才有。FDE 的汇报材料里,数据可视化与故事化是核心技艺,直接决定客户老板能不能在 30 秒内 get 到价值。

可视化的三个原则。第一,一图一结论:每张图只表达一个核心结论,标题就是这个结论(比如"上线后月均工单处理量提升 3.2 倍"),而不是"工单处理量趋势图"。第二,对比优先:单看一个数字没有感觉,必须有对比基线——上线前 vs 上线后、AI 处理 vs 人工处理、本部门 vs 同行业 benchmark。第三,去掉装饰:工程师做图常见错误是堆 3D、彩虹色、动态特效,客户老板看了反而分心。专业汇报的图永远是克制的——一个主色、清晰的标签、必要的注释。

故事化的核心是把数字翻译成场景。"准确率 92%"是一个数字,"客服每天处理 500 单,过去每单平均 8 分钟,现在 AI 处理 80% 工单,客服只看高价值的 20%,每天节省 6.4 小时,客户首响时间从 15 分钟降到 2 分钟"是一个故事。故事的公式是:现状痛点 × AI 介入 × 量化结果 × 客户感知,四要素缺一不可。FDE 要刻意训练这种"把模型指标翻译成业务故事"的能力,这是技术与商业之间的翻译术。

客户证言是故事化的最高级武器。任何数字都不如客户内部一个真实使用者的一句话有说服力。结项汇报里放一段业务一线员工的真实反馈("用了这个系统之后,我下班时间从晚上 9 点提前到了 6 点"),价值胜过十张图表。客户证言的收集要贯穿整个项目周期,不要等到结项才临时去找——每次阶段汇报、每次现场支持,都要主动收集并记录用户原话,经对方同意后纳入材料。

数据故事化公式:现状痛点 × AI 介入 × 量化结果 × 客户感知 = 客户老板能记住的价值。

8.58.9 用 AI 辅助做 Demo 与汇报

FDE 既是 AI 落地的执行者,也是 AI 的重度使用者。在 Demo 与汇报这件事上,AI 可以在多个环节显著提效,但前提是用对地方。

Demo 准备阶段。用大模型生成 Demo 脚本的初稿(给定场景、对象、时长,生成可读性很高的脚本框架);用模型对脚本做"客户视角"审视,让它扮演 CXO/业务/IT 三类角色给脚本提意见;用模型批量生成弹性数据(给定主线数据格式,生成 50 条分布相近的合成样本);用模型预先评估客户自带数据可能触发的边界(让模型扮演严苛客户,挑出哪些样本可能让演示翻车)。

汇报材料阶段。用模型把技术指标翻译成业务语言(给定"准确率 92%、延迟 200ms",让它生成三种业务侧表述);用模型对汇报材料做结构与逻辑审视(让它扮演客户老板,指出哪些地方听不懂、哪些数字没说服力);用模型生成可视化的初稿代码(给定数据,生成 matplotlib/echarts 的图表代码)。注意:模型生成的材料必须人工校验,尤其是数字与事实——AI 在数字上的幻觉是不可忽视的风险,所有量化结论都要回溯到真实测试集与业务数据。

现场演示阶段。这是 AI 辅助最需要克制的环节。绝对不要在客户现场让模型实时生成 Demo 输出(理由前面讲过,不确定性太大)。但可以用 AI 做"问答弹药"——客户提问后,FDE 在内部快速用模型生成可能回答的角度,再人工组织语言回复。这种"AI 后台、人工前台"的模式既保证了响应速度,又保证了输出可控。

复盘阶段。Demo 与汇报结束后,把全程录音转文字,用模型做复盘分析:客户的关注点分布、提问中的真实顾虑、哪些环节节奏失控、哪些价值点没讲透。这种基于真实录音的复盘,比 FDE 主观回忆准得多,是迭代演示能力的高效路径。

AI 辅助 Demo 与汇报的铁律:准备阶段重度使用、现场阶段克制使用、所有数字必须人工校验。

8.58.10 反模式:炫技无价值、Demo 与生产脱节、汇报流水账

把前面的反面教训集中收口,FDE 在 Demo 与汇报上最常见的三大反模式如下。

反模式一:炫技无价值。Demo 里花大量时间展示模型多聪明、Prompt 多精巧、架构多先进,客户听完只记得"这玩意儿很厉害",但完全不知道对自己有什么用。这种反模式的根源是工程师视角——把 Demo 当成技术秀场,而非价值秀场。纠正方法是 Demo 前强制问自己一个问题:"客户听完这次 Demo,能向他的老板用一句话说清我们带来了什么价值吗?"如果说不清,这个 Demo 就是失败的,无论技术多惊艳。

反模式二:Demo 与生产脱节。这是最危险的反模式,因为它会带来短期拿单、长期崩盘的后果。表现形式是 Demo 里展示的精度、效果、性能,在客户真实环境上完全跑不出来——Demo 用的是精心挑选的样本,生产用的是长尾分布;Demo 用的是最强模型,交付用的是降级模型;Demo 跑在干净数据上,生产跑在噪声数据上。客户一旦发现 Demo 与生产脱节,信任会从 100 直接归零,而且会向同行业扩散,FDE 的口碑就此毁掉。纠正方法是 Demo 的所有承诺必须有"生产可达性"背书:每个 Demo 展示的指标,都要附上"这是测试集结果,生产环境预期会因数据分布差异降到 X%,我们会在试点阶段用您的真实数据复测"。

反模式三:汇报流水账。周报写成工作日志,阶段汇报变成功能清单,结项汇报堆砌"完成了 N 个需求、召开了 M 次会议"。客户读完不知道这次合作到底带来了什么价值,续约谈判时自然没有筹码。流水账汇报的根源是工程师不擅长价值翻译,只会罗列做了什么,不会讲产生了什么。纠正方法是每次写汇报前先问:"如果客户老板只看一页 PPT,这一页该写什么?"答案永远是业务价值(节省多少成本、降低多少风险、创造多少收入),而不是工作清单。所有"做了什么"的内容都要压缩到附录,正文只留"产生了什么价值"。

三大反模式的共同病灶:工程师视角 > 客户视角。纠正的总原则:每一次 Demo、每一份汇报,都要先回答"这对客户意味着什么",再回答"我们做了什么"。

本专题小结

Demo 与汇报是 FDE 能力的"对外接口",决定了交付成果能否被客户感知、能否转化为商业价值。本专题的核心要点:Demo 的本质是用最小成本建立信任,而非功能展示;好的 AI Demo 必须满足场景真、数据真、价值显、边界明、不翻车五要素;Demo 设计遵循选场景→写脚本→备数据→排练→兜底五步法;面向 CXO/业务/IT 三类对象要用三种语言分层叙事;翻车防范要从网络、模型、数据、预案四维系统做;周报、阶段汇报、结项汇报各有不同结构与目的,套用模板是新手大忌;数据可视化要遵循一图一结论、对比优先、去掉装饰三原则,故事化的公式是现状痛点 × AI 介入 × 量化结果 × 客户感知;AI 可以在准备与复盘阶段重度辅助,但现场演示必须克制,所有数字必须人工校验;最后要警惕炫技无价值、Demo 与生产脱节、汇报流水账三大反模式,根源都是工程师视角压过了客户视角。一句话收束:FDE 把价值做出来只是 50 分,把价值讲出来才是 100 分。

本专题来源

本专题内容综合自 FDE/FDSE 一线交付实践、AI 项目驻场交付方法论(CDEF 框架的 Engineer 与 Feedback 阶段)、Palantir/Databricks/OpenAI 等前沿部署工程师团队的 Demo 与客户沟通经验,以及《FDE 工程师完全指南》《CDEF 方法论》等系列文档中关于客户现场沟通、价值翻译、汇报结构的论述。所有量化案例(5200 工时、320 万元、首响时间从 15 分钟降到 2 分钟等)为基于真实行业场景的典型数值,用于说明价值翻译方法,非特定客户真实数据。