把 FDE 送进企业之后：谁救火，谁背责，谁赚钱？

“我觉得 80% 的程序员不会喜欢这样的工作，因为它确实意味着长时间出差。”神策数据联合创始人兼 CTO 曹犟在谈到 FDE 时说道。 “现场”是 FDE 价值的根源，但这种工作方式一点也不性感。为了在神策内部孵化 OmniGrowth 产品，曹犟和团队长期出差，和客户高层、技术负责人、业务负责人反复讨论，也要直接坐到一线“投手”旁边，一起吃饭、工作。刚开始，他们甚至听不懂对方大量业务黑话，只能把自己当成实习生，重新接受一遍业务培训，先学会客户怎么工作，再谈 AI 怎么改造工作。(更多交付 FDE 项目经验分享，可点击查看曹犟在极客时间上线的系列 文字专栏 "和 视频课 "。) 同样的趋势也发生在百度智能云的 FDE 团队身上，百度云服务交付团队负责人何震江带领的 FDE 团队，大约 50%-60% 的工作时间花在出差上。“出差不是目的，但往往是必要条件。”他说道，一旦需求理解不到位，后面做的很多事情都会白费。 何震江团队日常强调“短平快”：上午与客户沟通一两个小时，快速了解业务场景与痛点，然后把模糊需求迅速翻译成 AI 能够理解的需求文档，然后下午做出 Demo 初稿，直接给客户看。 这次 FDE 热潮的核心，并非办公地点的改变，真正关键的是 AI 产品进入企业之后，传统售前、产品、研发、交付和售后的边界都在被重新压缩和定义。 多线程、频繁救火和“翻译” 何震江用三个关键词概括了 FDE 的日常状态：多线程、频繁救火和“翻译”。 项目评估期，一名 FDE 并行跟进三四个项目；到了签约后的深度交付期，两个项目往往已经接近上限。FDE 们一天四五场会并不罕见，但这些会议不是例行听汇报，而是业务架构确认、技术选型评审和风险对齐，每一场都要推动客户做出具体决策。 与传统交付不同，FDE 往往从售前阶段就介入，会有很多第一次面对的问题，流程失效是必然的，而 FDE 的频繁“救火”都是解决方案层面的。咨询公司可以只给方案不管落地成败，FDE 不行，“救”的是从方案到落地之间的所有断层，承诺的就必须真正实现。 而“翻译”是何震江认为 FDE 最核心的日常工作。这里的“翻译”是指把客户“我要智能化”这样的表达，拆成具体的问题，比如哪个场景、哪个模型完成、调用哪些数据、效果衡量指标等。 这也是 FDE 和传统交付最容易被混淆、又最本质的区别之一。客户提出的需求通常并不能直接变成技术任务。老板、IT 负责人、业务主管和一线员工，对“问题是什么”经常有完全不同的答案：老板希望得到一套 Agent，IT 部门首先担心系统安全和稳定，业务负责人关心效率和结果，一线员工则可能认为现有流程根本不是管理者描述的那样。 因此，有高管在安排好业务主管对接后，会反复提醒 FDE 团队“不能只听这位主管的”，因为主管和一线员工对同一个流程的理解、痛点和实操方式并不一致。如果只把一位关键人的意见当成事实，最终做出来的系统很可能在会议室里正确、到了业务现场却无法使用。 所以，FDE 进场之后的第一项工作往往不是开发，而是访谈、观察、追问和拆解。客户可能一次提出几十个场景，FDE 不能照单全收，而要从可行性、价值、重要性和 ROI 中筛选出少数 MVP。何震江所在团队通常会用一到两周筛出几个重点场景；曹犟也强调，最合适的起点往往是“最重要、能够端到端打通、范围尽可能窄”的问题。 接下来，Demo 成为一个重要的沟通工具。曹犟特别指出，Demo 的价值不是为了让客户点头，而是为了让客户能够“对着它说不”。 他解释道，传统瀑布式项目里，需求沟通结束后，客户可能两三个月才能看到大致可用的东西，但那时再发现方向偏了的话，修改成本会很高。AI 降低了原型开发成本后，FDE 就可以把“被否定”提前：先快速做出一个接近真实工作流的东西，让用户坐在旁边直接操作，然后听他指出“我不是这么干的”“这里不对”“这一步实际还有审批”等。这些否定本身，就是最有价值的需求输入。 因此，能不能听懂客户没有说出来的东西，能不能把模糊的业务语言转成技术结构，又能不能把技术限制重新翻译成客户可以理解和决策的业务选项，成为一个 FDE 更难复制的能力。 另外，FDE 也在试图把传统交付的终点继续向后推，但终点后推也意味着，FDE 在上线后仍然不能撤场，而这正是压力的来源之一。 传统交付的终点通常比较明确：系统上线、功能验收、签字回款。而在曹犟看来，AI 系统最理想的交付物不是一个静态的软件版本，而是一条“效果持续上升的曲线”。比如，系统上线时的效果可能只有 80%，但随着模型变化、知识完善、用户反馈和评估集迭代，效果会提升到 90%，甚至更高。 这就要求 FDE 在项目里承担的责任比传统“部署完成”更多。上线前，要处理数据隐私、安全、合规、回滚和模型不可用等风险；上线后，要逐步把系统交给客户，帮助客户真正用起来，并让客户最终具备一定的自主迭代能力。FDE 不能永远驻场，否则“客户依赖 FDE 个人”最终会重新滑向维保和人力外包。 实际上，整个环节中，客户情绪也是 FDE 的压力来源之一。很多 AI 项目都曾跑偏或失败，因此客户对 AI 项目的焦虑通常比对传统项目更高。同时，AI 场景往往受到企业高层关注，项目层面的客户也会因此承受压力，并把压力传递给 FDE。现在的 FDE 除了专业能力，还需要情商：既要安抚客户情绪，也要保持专业判断，不能让整个项目被情绪带着走。 “压力大并不是 FDE 独有的问题，而是整个 AI 交付行业都面临的问题。不过，如果压力出现在方案设计阶段，总好过系统上线后发生事故。”何震江说道。 出了错，谁负责？FDE 必须在事故之前回答这个问题 那实践中，如果 FDE 部署的 Agent 出了错，谁来承担责任？业内对此的答案很一致：责任不能等事故发生后再切割，而要在项目一开始就设计。 何震江所在团队会在评估阶段形成方案建议书，把技术选型、风险点和责任分工提前列出：哪些由 FDE 负责，哪些由客户负责，哪些需要第三方供应商配合；如果 FDE 建议方案 A、客户坚持方案 B，也要留下决策和风险记录。如果 FDE 建议方案 A、客户坚持方案 B，会形成一份决策存档，让后续每一步调整都能回溯到最初的判断依据，为了让专业判断能够形成完整闭环。 曹犟进一步把 AI 系统错误进行拆解，比如系统回答不准确，先要判断是模型能力问题还是上下文问题；如果是上下文问题，还要区分客户数据本身错误，还是数据正确但 FDE 构建知识库和上下文时出错。不同原因对应不同责任，无法一句“供应商全包”或“验收后与我无关”解决。 责任表、合同条款只是最后一道兜底，更重要的是把责任问题转化为产品和技术设计。机制越完整，真正发生事故后需要争论“到底是谁的错”的空间就越小。 尤其在金融、政企等强监管场景里，这类治理能力甚至可能比功能数量更重要。客户关心的不是供应商有 100 个功能还是 90 个功能，而是谁能把审批、审计、存档、回滚和兜底做清楚。AI 时代，治理本身正在成为产品的一部分，也是 FDE 能够进入高价值客户现场的入场券。 但到底是“外包”还是真 FDE？ FDE 这个岗位在国内常被开玩笑说，大多数只是给外包、售前实施换了一个名字。这个说法未必适用所有公司，却揭示出一个现实：FDE 目