这是一篇系列实战笔记的第三篇。前面写过FDEForward Deployed Engineer前场部署工程师的角色定位也聊过怎么去梳理客户需求这次想认真聊聊一个几乎所有FDE都会遇到的诡异现象Demodemo演示的时候全场叫好领导点头客户当场说“就这个了”结果一上线系统崩的崩、慢的慢、错的一塌糊涂。很多同学把这个问题归结为“运气不好”或者“客户环境太烂”但以我带过十几个落地项目的经验来看Demo翻车在生产的概率并不低根子基本都在我们自己身上。这篇就把我踩过的、以及带人踩过的坑全部倒出来。适合正在做FDE、解决方案工程师、售前技术支持或者天天打POC的兄弟参考。内容不搞虚的全部是能直接拿去用的排查思路和改法。1. 先搞清楚FDE和Demo之间的关系1.1 FDE到底在做什么FDE这个角色在国内还不是特别普及很多人容易把它理解成“高级售前”或者“会写代码的实施工程师”。实际上Forward Deployed Engineer干的活更像是一个“翻译”加“桥梁”你要能听懂客户业务里那些乱七八糟的痛点又能把它们翻译成一套技术方案并且亲手把这套方案在客户的真实环境里跑起来。这个角色的核心考核指标不是代码量也不是架构多优美而是“方案到底有没有在客户现场真正被用起来”。所以FDE的工作流天然就跟Demo强绑定前期要拿Demo去验证可行性中期要拿Demo去对齐预期后期要拿Demo去佐证交付结果。换句话说Demo是FDE手里的第一把武器但也是第一颗雷。我见过太多FDE把大量时间花在“怎么让Demo更炫”上动效拉满、数据化图表、一键生成报告演示效果确实炸裂。但问题在于Demo本质上是一个“被精心编排过的表演”而生产环境是一套“无人编排的现实”。两者之间的鸿沟才是FDE真正要花力气去填的地方。1.2 Demo在FDE工作流中的位置正常一个FDE主导的落地项目会走这么几个阶段需求调研、方案设计、Demo验证、试点运行、全面推广。每个阶段都有对应的Demo产物比如概念验证时的原型Demo、方案汇报时的效果Demo、培训时的操作Demo。但很多团队犯了一个同样的错误把Demo当成了终点而不是过程中的一个节点。客户看完Demo说OK大家就默认方案没问题了然后直接进入部署。可Demo验证的只是“这个功能在理想条件下能不能跑通”压根没有验证“这个功能在真实条件下扛不扛得住”。说得难听一点Demo是给你看的生产是给你用的用的过程中什么破事都有可能发生。1.3 为什么说“Demo好看”是一种陷阱说个扎心的现实越是好看的Demo上线后出问题的概率反而越高。原因很简单好看意味着精心设计精心设计意味着对数据、环境、路径做了大量隐性假设。比如Demo里永远只有几百条数据比如演示账号提前配好了所有权限再比如演示流程是固定的三步你怎么点它都对。这些假设在演示现场是加分项到了生产环境就是连环雷。这不是说Demo不应该做漂亮而是说FDE要分清楚Demo的“漂亮”是给决策者看的但你自己心里必须清楚这个漂亮背后藏了多少没有验证的环节。所以从做Demo的第一天起就要用一个“上线思维”去做而不是只想怎么炫技。这也是这篇最核心的观点Demo不是交付物但它必须被当成交付物来对待。2. 一上线就出问题问题到底出在哪2.1 环境不一致本机能跑服务器不能跑这是最经典也最普遍的坑。本地开发机跑Demo一切正常打包放到客户服务器上立刻各种报错。以前我遇到一个情况开发同学用的Python版本是3.10客户生产机器上是3.7结果第三方库直接装不上还有一次是Windows上跑得好好的一放到Linux服务器上所有路径分隔符全崩。这种问题跟代码本身关系不大纯粹是环境差异导致的。最常见的差异有操作系统版本、运行时版本、依赖库版本、系统时区、字符集编码、文件权限、开放端口。说句难听的本地环境是你自己养出来的“温室大棚”生产环境是野外森林温室里的苗移栽出去必然要掉层皮。解法也很明确从第一天起就要用容器化技术把环境锁死在同一个镜像里。Docker这类工具不是给后面部署用的而是给FDE自己用的。你在本地跑Demo的时候就应该用容器跑而不是直接在宿主机上跑这样才能确保你演示的那个环境跟后面上线生产的那个环境是一致的。这个问题我后面在落地方法里会细讲。2.2 数据太干净样例数据和真实数据是两种物种很多Demo里用的都是精心挑选的样例数据字段全、空值少、格式统一。但真实生产数据长什么样呢字段缺失、格式混乱、重复值爆炸、编码乱掉甚至同一个字段里一个值是字符串一个值是数字。你的系统在样例数据上跑得丝般顺滑一接真实数据就各种报错这几乎是铁律。我这里特别想提醒一句数据问题不是上线之后才出现的而是从数据接入那一刻就开始了。所以FDE在做方案的时候第一件要做的事就是跟客户要一份真实数据样本哪怕是一个月的历史数据导出来也行。如果客户说“数据保密没法给”那就要求在他们内网环境里搭一套隔离的联调环境让Demo程序直接连测试库。只有让程序从一开始就“吃”真实形状的数据才能提早暴露出字段映射、类型转换、清洗逻辑这些坑。2.3 演示路径和真实路径脱节演示的时候我们通常走的是核心路径就是最能体现产品价值的那些操作流。但真实用户在系统里的操作路径是非常发散的他们会乱点、会输入非法字符、会上传超大文件、会频繁点击保存按钮、会在网络中断的时候疯狂刷新。有一次我做运维系统的Demo流程是先选服务器、再下发脚本、再展示执行结果一气呵成。上线之后客户说“下发脚本之后一直转圈”排查了半天才发现真实网络环境下客户侧到服务器之间的链路非常不稳定脚本下发后反馈消息丢了系统又没有做超时重试直接就卡死在等待状态。Demo的时候因为是在同一个机房环境演示网络延迟可以忽略不计这个问题根本不会出现。所以演示路径只能证明业务流程是通的不能证明整个系统的健壮性。FDE要在演示之外额外梳理所有的异常分支、边界情况和用户误操作场景把这些都当成必须处理的正常逻辑。2.4 性能压力一上来就现原形Demo用户量小数据量小并发几乎为零所以性能问题很难在Demo阶段暴露。但真实上线后哪怕只有几十个人同时用都可能把没做索引的慢查询暴露出来如果赶上报表模块每天凌晨跑批任务CPU直接飙满整个系统卡到没法用。这种事情我见得太多了。有一次做数据可视化大屏Demo演示时时序数据库查询秒开客户都觉得惊艳。结果上线第二天数据量从1万涨到200万同一个查询接口直接10秒起步大屏上的图半天刷不出来。后来一查问题出在查询语句里对一个大字段做了全表扫描这个在初期数据量小的时候感知不到数据一多就立刻崩盘。所以FDE在做方案设计和Demo验证的时候至少要问清楚三个数字正式上线后大约有多少用户、多少数据量、多少并发请求。哪怕客户给不出精确数字也要按一个“比预期大一两个数量级”的规模去做技术选型和性能测试。别等到上线那天才做压测到那时候你连调整参数的时间都没有。2.5 外部依赖和权限在演示时被“提前解决”很多Demo能跑通是因为FDE在后台偷偷把外部依赖和权限全部打通了。比如调用第三方短信接口的账号已经申请好了比如文件存储的bucket已经建好了比如数据库账号已经是最高权限。但这些“提前解决”的工作在上线时全都要暴露出来。我就遇到过Demo里调用的地图服务是开发环境的key客户验收时用的内网域名根本访问不了外网服务结果地图模块上线即白屏。还有一次更离谱Demo用的是我们公司内部私有仓库的Maven依赖客户环境拉不到这个仓库构建直接失败。这里分享一个实战经验在做Demo之前把所有要用到的外部服务列一张清单逐个标注“当前用的什么账号”“生产环境应该用什么账号”“有没有网络隔离”“证书有没有到有效期”。这张清单看起来很简单但能帮你挡住90%的相关坑。3. 把Demo变成可落地的方案工作方法3.1 从第一天就把Demo当交付物来做很多FDE做Demo的时候默认“反正是演示先把效果做出来后面再重构”。这种思路隐患极大因为绝大多数情况下根本没有“后面”。Demo演完之后紧接着就是试点试点紧接着就是生产你的Demo代码会一路被带到生产环境里如果它本身是个一次性脚本那上线之后就全是窟窿。我自己现在做Demo的原则是所有代码结构、配置管理、日志规范、异常处理都要按照正式交付的标准来写。Demo可以只实现核心功能但质量不能缩水。尤其是异常处理很多Demo代码里根本没有try-catch一报错就输出整个堆栈这在演示现场可能还能接受到了生产环境就是事故。3.2 用容器和配置管理锁死环境差异解决环境不一致问题最直接的办法是强制使用容器化。我这里说的不是让你一上来就搞K8s那个对很多客户来说太重了除非客户明确要求。而是说至少要把你的整个应用做成一个Docker镜像镜像里面把操作系统、运行时、依赖库、环境变量全部固化下来。具体做法是写一份Dockerfile把应用代码打进去然后在本机用这个镜像跑Demo。演示完把同一个镜像交给客户或者推到客户内网的镜像仓库里。这样不管客户底层是什么机器跑起来的效果都跟你演示时一致。如果客户暂时没有容器环境那就把所有依赖、启动命令、参数配置写清楚做成一个自动化部署脚本尽量不要依赖人工操作来装环境。同时配置管理也很重要。我把配置分成两类一类是代码里的默认配置另一类是部署时从环境变量注入的覆盖配置。Demo跑的时候用默认配置生产环境通过环境变量把数据库地址、密钥、域名这些替换掉。这样既能保证不影响代码逻辑又能灵活适应不同环境。3.3 用真实数据的脱敏副本做演示数据是最容易翻车的地方所以一定要改变“拿假数据演示”的习惯。我现在的标准做法是优先从客户真实业务库里导出一份脱敏的数据子集作为Demo的底库。这样做有两个好处一是数据形态和真实场景一致字段长度、空值比例、数据分布都是真实的跑出来的效果自然更有说服力二是在导数据的过程中FDE自己也能先发现很多数据质量问题提前把清洗规则定好。如果客户对数据安全要求严格不愿意提供完整数据那就找他们要一批脱敏后的抽样数据或者在内网搭环境把他们的测试库映射上一份。退一万步说实在不行也要用程序自动生成一批“脏数据”随机插入空值、重复值、超长文本、特殊字符模拟真实数据的混乱程度。用这种数据跑一遍Demo效果比拿干净数据的说服力强十倍客户看了也会觉得你是真的懂他们的业务。3.4 把演示脚本一条条翻译成用户真实操作路径演示脚本本身就是一份很好的测试用例但它的覆盖率太低了。我建议FDE在Demo定稿之后专门花半天时间把演示脚本摊开把用户真实会做的操作都列出来进行对照。比如演示脚本里是“选择角色、点击权限配置、生成权限报告”那真实用户可能会做的是“新增一个角色、给角色分配用户、修改角色权限、再重新生成报告”。这个过程中你会找到一个关键点用户很少会按照你设计的顺序一步到位地操作。他们会来回切换会在界面上停留、会刷新、会导出不认识的字段。这些操作在Demo里没走但上线后一定会发生。所以真正的做法是把演示脚本当作核心链路额外再搭建一套“冒烟测试清单”里面全部是不按套路出牌的用例在上线前用这些用例过一遍系统。3.5 上线前补可观测性不要等出事再装很多人觉得监控和日志是运维的事上线前再配就行但实际上如果FDE从做Demo的时候就开始打日志、加埋点后面排查问题的效率会高很多。Demo阶段不一定要完整的监控平台但至少要做到每个关键操作都有日志日志里带请求ID报错的时候能快速定位到具体是哪个环境、哪个服务、哪个参数。有一个真实案例我印象很深客户反馈“导入功能一直失败”但是界面上没有任何提示后台日志也干干净净。后来排查发现日志打印级别是ERROR而异常被捕获后没有打日志只是返回了一个空的失败信息导致问题完全不可见。这就是典型的“可观测性从设计阶段就没有考虑进功能里”。所以从Demo阶段开始FDE就要坚持写高质量的日志谁在什么时间做了什么操作、结果是什么、失败的上下文是什么这些信息都是上线后救命的。3.6 内部预演让Demo先被自己人打爆上线前一定要组织一场“内部破坏性预演”让项目组的开发、测试、甚至非项目组的同事来使用这个系统。不要给任何操作指南就让他们自由操作想办法把系统搞挂。自由操作时大家会乱输入、乱上传、乱点而这些行为恰恰是模拟真实用户的最佳手段。我组织预演的时候还会故意重置环境再跑一遍部署流程看看从零到能用的整个过程是不是顺利。很多问题都是这样“试”出来的比如某个配置项忘了改某个服务没有设置开机自启某个脚本没有对重复执行做幂等处理等等。这些东西如果不上线前试一下上线当晚你就要熬夜救火。4. 一个MCP服务Demo的翻车复盘4.1 项目背景与演示目标拿最近一个比较有代表性的案例来讲。客户要做一个内部知识库的智能问答助手希望通过MCPModel Context Protocol服务把大模型能力接入他们自己的业务系统实现基于内部文档的问答和推理。这是一个很典型的FDE项目业务场景清楚技术路线也算主流前期调研也做得比较扎实。Demo阶段我们搭了一个MCP服务把知识库文档做了切片和向量化然后通过大模型接口做检索增强问答。演示的时候效果非常好问什么答什么引用来源也标得很清楚客户CEO当场拍板要试点。当时我们犯了一个典型错误Demo环境和生产准备没有分开我们就在自己团队内网的开发环境里演示觉得后续上线就是把同样的代码部署一遍。4.2 上线后发生了什么试点第一天就翻了车。客户反馈说问答助手能响应但回答变得非常慢平均每条要十几秒而且有些问题明明文档里有答案它却回答“没有找到相关内容”。更严重的是服务运行不到两个小时就出现了大量超时连整个对话页面都打不开。一开始我们还以为是客户网络的问题因为内网访问大模型API确实有延迟。后来看了一下监控发现问题并不仅仅是网络而是我们的MCP服务在启动时一次性把所有向量索引加载到了内存里文档数量不大的时候还好客户的文档规模是十万级启动直接吃了好几个G内存配置的小机器根本扛不住。4.3 排查思路和定位过程当时排查的顺序是先看进程是否存活确定不是崩溃再看CPU和内存发现内存占用非常高接着看日志发现大量的超时和连接池满最后用压测工具模拟并发请求发现只要同时来5个请求服务的响应时间就从3秒涨到30秒。这个过程中最值得反思的一点是我们压根没有在Demo阶段做任何性能相关验证只验证了“能不能答出来”没有验证“能扛多大的并发”“内存占用是多少”“检索的耗时有多久”。如果当时用真实数据量的一份子集做一次简单的压测这些问题都会在演示前暴露出来。4.4 修复动作和复盘结论后来我们做了三步修复把向量索引从内存加载改成持久化的向量数据库并加上缓存对知识库做分批分片处理避免启动时全量加载在MCP服务和大模型API之间加了异步队列和超时重试避免慢请求把服务拖死。改完之后再用十万级文档压测响应时间稳定在三秒左右内存占用也降到了原来的三分之一。复盘的时候我们列了一条很硬核的经验FDE做技术选型时不要只看“Demo效果最好”的方案还要看“生产环境扛不扛得住”的方案。像向量检索Demo阶段用内存数组就够了但生产就必须考虑持久化和扩展性。早点把生产规模纳入技术选型判断后面省下的不是一点半点的时间。5. FDE落地实战避坑清单5.1 上线前检查清单这些坑踩多了之后我整理了一份上线前检查清单每次项目落地前都会过一遍在这里分享出来供大家直接抄作业。检查项详细内容是否通过环境一致性所有服务是否已容器化镜像是否和Demo完全一致配置管理数据库、密钥、域名是否通过环境变量注入生产配置是否单独维护数据真实性是否用真实的脱敏数据做过全流程验证依赖清单外部API、SDK、证书、私有仓库是否逐一确认在生产环境可达性能基线是否用不低于生产量级的数据做过压测确认响应时间和吞吐量异常分支是否覆盖超时、重试、断网、并发、非法输入等真实操作场景可观测性日志是否完整是否有错误追踪是否有关键指标监控和告警权限边界演示时的最高权限是否已收紧为生产环境的最小权限部署回滚是否有一键部署脚本是否有回滚到上一版本的方案安全合规是否确认数据隐私、网络隔离、账号管理符合客户要求这份清单不一定适合所有项目但至少能覆盖掉80%的常见问题。FDE在项目中期就可以拿着清单去逐项过一遍千万别等到上线前一天才来查。5.2 常用工具与技术栈推荐FDE不需要像后端研发那样把技术栈吃得很深但有些工具是必须熟练的Docker和Docker Compose是基本盘因为要解决环境一致性问题一个自动化部署工具比如Ansible写点简单的playbook就能省很多时间熟悉一门脚本语言比如Python或Bash能处理很多临时数据问题。监控方面不一定非要上大平台初期可以用Prometheus加Grafana搭一套轻量级的重点是能看指标、能告警。日志收集可以用Loki或者简单的ELK关键是能把多个服务器的日志集中起来。如果你做的是MCP服务这类AI相关的项目还要特别注意LLM相关的延迟和token消耗监控这块往往容易被忽略。选型的原则是“宁可简单不要花哨”。客户环境越复杂你的方案就要越简单否则出了问题你自己都很难排查。之前见过有人用K8s部署一个只有一个服务的应用结果集群本身出了问题应用也跟着挂这种就是典型的过度设计。5.3 几条独家心得最后说几条比较个人化的经验。第一做Demo的时候一定要把“演示者”和“开发者”两个身份分开。开发者模式是认真的、仔细的、细致的演示者模式是快速的、顺畅的、抓住重点的。你脑子里要同时存在两个版本的系统一个是演示用的糖衣版一个是生产用的实心版。千万不能把糖衣和实心混在一起。第二客户说“可以”的时候不要高兴太早要追问一句“那我们可以开始小范围试运行吗”。只有真正进入试运行你才知道你的Demo到底行不行。我见过太多项目在“客户满意”的这个状态下停滞了很久结果客户其实一直没有真正用起来等到下一次汇报时才发现一堆问题。第三把每次上线后出的问题都记录下来定期复盘。我自己的习惯是给每个项目单独开一个Markdown文档叫“事故记录”里面写清楚时间、现象、原因、修复方案、如何预防。这些记录累积起来就是你最宝贵的案例库下次再遇到类似问题翻一下就能省几个小时。说实话做FDE这行最大的成就感不是Demo被夸而是你亲手做的方案在客户环境里稳定跑了一个季度、半年、一年。那是一种“真的落地了”的踏实感。而要想获得这种踏实感就必须在自己能做决定的地方做到极致Demo要好看但对生产环境要诚实。环境锁死、数据用真、路径走全、能力测透这四件事做好了上线翻车率能降一大半。最后再分享一个小技巧每次上线前问自己一个问题——如果明天客户老板第一个打开系统会不会觉得卡会不会觉得不准会不会觉得难看如果心里没底就再回去把对应环节加固一遍。这比什么口号都实用。