FDE进入客户现场，真正重要的不是写代码，而是做好这10件事

这两年，FDE（Forward Deployed Engineer，前沿部署工程师）正在成为 AI 落地领域一个越来越受关注的角色。

与传统软件工程师主要在公司内部开发产品不同，FDE需要走进客户现场，直接面对客户的业务问题，将 AI 技术、软件工程和行业知识结合起来，帮助客户真正把 AI 用起来，并产生可以衡量的业务价值。

这件事听起来并不复杂，但真正做起来，挑战远比想象中大。

客户说想要一个 AI 助手，背后可能是业务流程效率低；客户要求开发一个智能体，背后可能是多个系统之间的数据无法打通；客户希望部署大模型，真正想解决的却可能是人员成本高、业务响应慢、知识无法复用等经营问题。

FDE最重要的能力，不是接到需求后迅速开始写代码，而是能够在复杂的客户环境中，找到真正的问题，并把问题转化为可以落地、可以验证、可以持续运行的解决方案。

那么，FDE进入客户现场，究竟应该做什么？

结合FDE的工作特点，我认为有十件事尤其重要。

一、搞清楚客户的业务：先理解业务，再谈AI

FDE进入客户现场的第一件事，不是安装开发环境，也不是向客户演示最新的大模型，而是了解客户究竟在做什么生意。

客户属于什么行业？核心业务流程是什么？收入从哪里来？成本主要花在哪里？哪些环节依赖大量人工？哪些工作重复性高、规则相对明确？哪些业务问题已经影响到经营效率？

这些问题看似与技术无关，却决定了AI应用能否产生实际价值。

例如，在制造企业，客户可能希望使用AI分析生产数据、辅助质量检测、自动生成生产报告；在金融企业，客户可能更关心知识检索、材料审核和风险分析；在网络安全企业，客户可能需要自动化告警研判、漏洞分析和代码审计。

同样是AI技术，在不同业务环境中的应用方式完全不同。

因此，FDE需要先建立一张客户业务地图，理解企业的业务链条、核心岗位、关键流程和主要痛点。

先理解客户如何创造价值，才能知道AI应该在哪里创造价值。

二、找到真正的痛点：不要把客户提出的需求直接当成问题

客户提出的需求，往往只是问题的表象。

例如，客户说：“我们需要一个企业知识库。”

这可能意味着员工找不到制度文件，也可能意味着新员工培训成本太高，还可能意味着业务专家的经验无法复制。

如果FDE直接开始搭建RAG系统，最后可能做出了一个可以回答问题的知识库，却没有解决客户真正关心的问题。

因此，FDE需要继续追问：

• 这个问题发生在哪个业务环节？

• 目前是如何处理的？

• 每次需要多少时间、多少人参与？

• 问题发生的频率有多高？

• 当前方案为什么不能解决？

• 如果问题得到解决，客户最希望看到什么变化？

通过这些问题，将模糊的需求拆解成明确的问题。

例如，把“建设企业知识库”进一步明确为“让售后工程师在三分钟内找到正确的设备维修方案，减少重复咨询和专家介入”。

前者是一个技术项目，后者才是一个可以验证的业务目标。

FDE不能只做需求的接收者，更要成为业务问题的发现者。

三、识别高价值场景：找到最值得优先解决的问题

客户的问题通常很多，但并不是所有问题都适合优先使用AI解决。

FDE需要对候选场景进行筛选，综合考虑业务价值、技术可行性、数据条件、实施成本和风险。

可以重点关注四类场景：

第一，重复性高。大量工作依靠人工反复执行，流程相对固定。

第二，耗时长。员工需要在多个系统之间切换、查找资料、整理信息或编写报告。

第三，知识密集。工作依赖专家经验、行业知识或大量历史文档。

第四，结果可验证。能够通过处理时间、准确率、成本或业务完成率衡量效果。

例如，自动整理会议纪要、生成标准化报告、检索内部知识、辅助代码审计，往往更容易找到清晰的验证指标。

相反，对于数据严重缺失、流程高度混乱、业务责任不明确的场景，即使模型能力很强，也未必适合立即启动。

FDE需要帮助客户明确：哪些事情应该马上做，哪些事情需要先补齐数据和流程，哪些事情暂时不值得投入。

好的FDE不是把所有问题都交给AI，而是帮助客户找到最值得用AI解决的问题。

四、摸清数据和系统：确认AI落地的真实条件

业务场景确定之后，就需要检查客户是否具备实施条件。

AI应用不是独立存在的。它可能依赖企业内部文档、数据库、业务系统、API接口、历史工单、操作日志以及其他数据资源。

FDE需要重点摸清四件事：

• 数据在哪里： 数据分散在哪些系统，是否存在重复、缺失或过期问题？

• 数据能否使用： 数据格式是否统一，权限是否允许访问，质量能否满足业务要求？

• 系统能否连接： 是否提供API、数据库接口或其他集成方式？

• 环境是否允许： 客户使用公有云、私有化部署还是本地模型？网络、算力、安全和合规方面有哪些限制？

例如，客户希望AI自动处理售后工单，但工单分散在不同系统中，历史数据格式不统一，设备信息与维修记录也无法关联。

这种情况下，问题可能不在模型，而在数据治理和系统集成。

如果前期没有识别这些问题，项目很容易陷入不断调试模型、反复修改提示词，却始终无法达到预期效果的困境。

FDE需要在正式开发前，形成一份清晰的技术现状与实施条件清单。

五、建立客户信任：让业务人员愿意与你合作

FDE进入客户现场，面对的不只是技术问题，还有人与人之间的协作问题。

业务部门可能担心AI影响岗位，IT部门可能担心系统安全，管理层关心投入产出，一线员工则可能担心增加额外工作。

如果FDE只会讨论模型参数、技术架构和开发框架，就很难真正推动项目。

建立信任，首先要理解不同角色的关切，并用他们能够理解的语言沟通。

与管理层沟通，要讲业务价值、成本和风险；与业务人员沟通，要讲具体工作如何改变；与IT部门沟通，要讲系统集成、运维和安全；与一线员工沟通，则要让他们看到AI如何减少重复劳动，而不是简单地增加一道操作流程。

更重要的是，FDE不能轻易承诺做不到的事情。

不确定的技术问题，要明确验证方式；暂时无法解决的问题，要说明限制；需要客户配合的事项，要提前讲清楚。

客户信任不是靠一次精彩演示建立的，而是靠持续兑现承诺积累起来的。

六、快速做出原型：用最小可行方案验证价值

在理解业务、摸清数据之后，FDE应该尽快把想法变成可以运行的原型。

这里的关键是MVP，即最小可行产品。

不要一开始就追求完整的平台、复杂的智能体架构或覆盖所有业务流程的大型项目，而是选择一个边界明确的场景，尽可能用最小的投入验证核心假设。

例如，客户希望通过AI提升代码审计效率，可以先选取一个具体项目，验证AI能否识别某类安全漏洞、减少人工初筛时间，并通过人工复核评估结果质量。

客户希望建设销售助手，可以先围绕产品资料查询和客户问题解答进行验证，而不是立即打通全部CRM、ERP和营销系统。

原型阶段需要明确三个问题：

1. 技术上能否实现？

2. 业务上是否真正有用？

3. 结果是否达到客户可以接受的标准？

原型不一定漂亮，但必须能够验证关键假设。

FDE需要用实际运行的结果推动决策，而不是用一份越来越厚的方案代替项目进展。

七、持续迭代：把客户反馈变成产品改进

原型运行起来，并不意味着任务完成。

AI应用与传统软件有一个重要区别：即使系统能够正常运行，输出结果也可能不稳定，实际效果还会受到数据质量、模型能力、上下文、工具调用和业务规则等因素影响。

FDE需要与客户一起测试真实任务，收集失败案例，分析问题原因，并持续迭代。

例如，AI生成的报告不符合企业格式，可能需要调整模板和输出约束；知识检索结果不准确，可能需要优化文档切分、元数据和检索策略；智能体调用工具失败，可能需要改进参数校验、异常处理和权限设计。

每次迭代都应尽量回答三个问题：

• 发现了什么问题？

• 为什么出现这个问题？

• 本次修改是否真正改善了结果？

对于重要场景，还应该建立测试集和评估指标，避免只凭个别成功案例判断效果。

FDE的价值不在于一次性展示AI有多聪明，而在于通过持续迭代，让AI在客户的真实业务中越来越可靠。

八、把安全和风险控制放在前面：不要等出问题再补救

AI进入企业生产环境，必须考虑安全问题。

特别是涉及客户数据、企业内部知识、业务系统和自动化执行权限的场景，安全不是上线前的附加工作，而是方案设计的一部分。

FDE至少需要关注以下方面：

• 数据访问是否符合客户授权和最小权限原则。

• 敏感信息是否可能泄露给外部模型或未经授权的用户。

• 提示词注入是否可能诱导AI泄露信息或执行危险操作。

• Agent调用工具时，是否存在越权访问和高风险操作。

• AI生成的内容是否需要人工审核，错误结果会造成什么影响。

• 系统是否具备日志记录、异常告警、审计和回滚机制。

对于转账、删除数据、修改生产配置、执行高风险命令等操作，不应仅依靠模型自行判断，可以通过权限隔离、人工确认和执行前校验建立约束。

同时，要明确AI的责任边界：哪些任务可以自动执行，哪些只能提供建议，哪些必须由人来最终确认。

一个无法控制风险的AI方案，即使演示效果再好，也很难成为企业可信赖的生产力工具。

九、推动真正上线：从技术演示走向业务闭环

很多AI项目的问题，不是做不出原型，而是原型始终停留在演示环境中。

演示时数据准备充分、流程简单、操作人员熟悉系统；进入真实业务后，却可能遇到权限不足、接口异常、网络限制、用户不愿使用以及各种边界情况。

因此，FDE必须推动方案进入真实工作流程。

这包括完成必要的系统集成、权限配置、部署验证、异常处理、监控告警、用户培训和运维交接。

更重要的是，明确谁会使用这个系统、在什么场景下使用、原有流程需要如何调整，以及发生问题后由谁负责处理。

例如，AI生成报告之后，是否需要业务人员审核？审核后的结果如何回写业务系统？如果模型无法回答，任务由谁接手？系统升级后，如何确保原有能力不退化？

这些问题如果没有解决，AI就很难真正融入企业日常工作。

FDE的目标不是交付一个可以运行的程序，而是帮助客户建立一套能够持续运转的业务机制。

十、衡量业务结果，并把经验沉淀下来

项目上线后，FDE还需要回答一个关键问题：客户到底获得了什么价值？

不能只看模型调用量、Token消耗量、智能体数量和系统访问量。这些指标能够反映使用情况，却不能直接证明业务价值。

更值得关注的是业务结果，例如：

• 原来需要两小时完成的工作，现在需要多长时间？

• 原来需要多少人工参与，现在减少了多少重复操作？

• AI处理任务的准确率、完成率和返工率分别是多少？

• 系统运行成本、人工审核成本和维护成本是多少？

• 员工是否真正愿意使用，业务流程是否因此发生改善？

项目开始前就应确定基线和目标，上线后持续进行对比。涉及效率提升时，还要区分AI带来的改善与业务量、人员配置等其他因素的影响。

与此同时，FDE还应该把项目过程中的经验沉淀下来，包括提示词、Skills、工具接口、业务规则、测试用例、异常处理方法、部署手册和行业解决方案。

如果每次进入新客户现场，都要从头调研、从头开发、从头踩坑，那么交付效率就很难持续提高。

如果能够将一次项目中的有效经验转化为可复用的组件、流程和行业模板，下一次交付就可能更快、更稳定，成本也更低。

这也是FDE从个人能力走向团队能力、从项目交付走向规模化复制的关键。

结语：FDE不是去客户现场写代码，而是去现场解决问题

把以上十件事串起来，可以看到一条完整的FDE工作链路：

理解业务 → 发现痛点 → 筛选场景 → 盘点数据与系统 → 建立信任 → 快速验证 → 持续迭代 → 控制风险 → 推动上线 → 衡量价值并沉淀经验。

这十件事并不意味着必须机械地按照顺序完成。实际项目中，FDE需要根据客户情况反复验证、调整和推进，但这条主线能够帮助FDE避免陷入单纯的技术交付。

我认为，FDE真正需要建立的是三种能力。

第一，业务理解能力。能够听懂客户的语言，理解业务流程，找到真正值得解决的问题。

第二，工程落地能力。能够把模型、数据、工具、系统和业务流程连接起来，做出真正可用的解决方案。

第三，价值交付能力。能够推动客户采用方案，验证实际效果，并将经验沉淀为可复制的能力。

AI时代，写代码的门槛正在发生变化，模型和开发工具也在快速进步。但客户的业务问题不会因此自动消失，复杂的组织协作、数据治理、系统集成和生产环境问题，同样不会因为模型变得更聪明而自然解决。

未来优秀的FDE，不只是一个懂AI的工程师，而是一个能够走进业务、解决问题、交付结果，并帮助企业真正用好AI的人。

从这个角度看，FDE的核心竞争力，不是每天写了多少行代码，而是能够让多少真实的业务问题得到解决，让多少AI能力真正转化为生产力。

这才是FDE进入客户现场最应该做的事。

更多AI资讯，请扫码关注Aiker World社区公众号