FDE 到底是什么一文讲清 AI 时代的 Forward Deployed Engineer一、FDE 的三个单词分别意味着什么二、真实招聘描述告诉了我们什么三、为什么会调用模型 API还不等于能完成 FDE 项目1. 输出是否与当前业务事实一致2. 系统是否有资格执行这个操作3. 谁来证明系统确实改善了工作四、贯穿专栏的项目星河设备售后 AI 助手五、FDE 接到需求后的第一件事把一句话变成任务书六、FDE 具体要交付什么用项目产物理解职责七、Demo 与生产之间差的不是一句“再优化一下”八、先看懂系统结构再决定是否需要 Agent九、什么叫“项目有用”从第一天就定义验收证据十、FDE 需要的能力应该如何放在一起十一、第一次做 FDE 项目最容易踩的五个坑十二、本篇实战写出你的第一份 FDE 项目任务书FDE Thinking你交付的是功能还是一种可被信任的工作方式专栏《AI FDE 实战从 Demo 到生产》第 01 篇 / 共 18 篇本篇目标理解 FDE 的职责与工作方式并完成一份企业 AI 项目的初始任务书。适合读者有一定编程经验希望学习企业 AI 落地的软件工程师、AI 应用开发者和技术负责人。假设你收到这样一个需求“我们已经有很多产品手册、售后政策和历史工单。能不能接一个大模型做个企业 AI 助手让客服少花一点时间查资料”如果你做过 AI 应用脑海中可能已经出现了一条技术路线解析文档、切分文本、生成向量、检索相关段落再让模型组织答案。加一个聊天页面演示很快就能开始。但当你准备把系统交给真实用户时问题会陆续出现。同一个产品有两版保修政策到底哪版生效不同客户的合同条款不一样客服能不能看到别人的合同订单状态每天都变能不能直接从业务系统查询模型说“工单创建成功”后台是否真的创建了业务主管觉得答案不错坐席却认为复核答案比自己查资料还慢这个项目算成功了吗这些问题并不只是模型能力的问题。它们牵涉业务流程、数据质量、权限、系统集成、交互、运行稳定性和验收方式。FDE 的工作就发生在这种具体的客户环境里把一个模糊的问题逐步变成能够运行、能够评估、能够交付并且有人真正使用的系统。这一篇先建立我们整个专栏的工作方式。我们会认识 FDE也会从第一篇开始用交付项目的视角思考问题。一、FDE 的三个单词分别意味着什么FDE 是Forward Deployed Engineer的缩写中文常译为“前线部署工程师”或“前沿部署工程师”。译名并没有统一到足以替代英文缩写因此本专栏直接使用 FDE。理解这个岗位可以从三个词入手。Forward意味着工程决策靠近问题发生的地方。很多时候客户提出的是一个解决方案名称而不是一个定义清楚的问题。“我们需要知识库”“我们要上 Agent”“我们想做智能客服”都还不足以让工程团队直接开工。FDE 需要接触实际工作的人观察他们如何找到资料、判断信息、完成操作再识别真正影响效率的环节。这并不意味着所有 FDE 都必须长期坐在客户办公室。现场参与、远程协作和出差安排取决于企业与项目。关键是能否接触真实场景以及是否承担把问题解释清楚的责任。Deployed意味着结果要进入真实运行环境。一个在开发者电脑上能够回答问题的程序与一个被客服团队每天使用的系统面对的是不同的完成条件。后者必须适应客户的身份体系、网络环境、数据规则和日常流程还需要明确失败时如何处理、谁负责维护。这里的“部署”也不只是执行一条容器启动命令。系统安装成功之后用户是否会用、遇到异常有没有支持渠道、旧流程如何切换都影响技术方案能否产生价值。Engineer意味着需要亲自做工程判断与实现。FDE 可能需要写前端、后端、数据处理脚本、系统集成代码和评测程序。更重要的是能解释为什么选择某种实现以及它在当前阶段解决了什么问题、留下了什么限制。例如客户希望 AI 自动提交售后申请。一个工程上负责任的实现不只是在提示词中加入“请谨慎操作”还要把身份校验、参数校验、确认流程、失败处理和操作记录放进系统。据此本专栏采用下面这个工作定义FDE 是深入客户业务场景、参与定义问题并对技术方案从验证到实际交付承担责任的工程师。这是为了教学而作的概括不是一套适用于所有公司的职级标准。判断一个具体岗位仍然要看职责、交付物和责任边界。二、真实招聘描述告诉了我们什么先看两个可核验的例子避免只凭岗位名称想象工作内容。OpenAI 的 FDE 新加坡岗位描述覆盖需求探索、技术范围、系统设计、实现和生产发布并明确提到全栈系统以及通过生产使用、工作流影响和评测反馈衡量结果。来源OpenAI FDE 岗位Anthropic 的 FDE 岗位把角色放在 Applied AI 团队中强调在客户系统内构建生产应用、提供企业部署支持并把可重复的方法与经验反馈给产品和工程团队。来源Anthropic FDE 岗位这些描述支持一个明确的理解至少在这些团队中FDE 的工作范围延伸到了生产交付而不是在技术演示结束时自然终止。不过不应由此推导出“每家公司的 FDE 都做完全相同的事情”也不应该把售前、解决方案工程和客户成功简单视为不写代码的岗位。实际组织往往有重叠有的团队将实施交给独立工程组有的团队由同一角色贯穿全过程。招聘页面还会变化。本文所列来源用于说明职责样本不用来证明某个职位永远开放更不能据此宣布 FDE 是“最火”或“薪资最高”的工程岗位。FDE 也不是这一轮生成式 AI 热潮才带来的工作方式。Palantir 在 2020 年的官方工程文章中就讨论过前线部署软件工程师如何与客户协作并交付系统。来源Palantir《A Day in the Life of a Palantir Forward Deployed Software Engineer》AI 带来的变化是让更多企业开始面对一种相似的落地难题通用技术能力已经很强但距离具体业务可以放心使用的系统仍有大量工程工作需要完成。三、为什么会调用模型 API还不等于能完成 FDE 项目模型 API 解决的是一个能力入口问题你可以提交输入得到模型输出。企业项目则需要回答另外三组问题。1. 输出是否与当前业务事实一致用户问“这台设备是否仍在保修期内”答案可能取决于购买时间、合同版本、设备序列号和维修记录。模型语言组织得再清楚也不能替代缺失的业务事实。因此工程任务可能包括查询订单、识别文档版本、处理缺失字段以及在信息不足时让用户补充材料。所谓“回答质量”必须放到实际任务中判断不能只看措辞是否流畅。2. 系统是否有资格执行这个操作“帮我创建一个工单”包含两个不同动作理解用户想提交什么以及真正修改业务系统。模型可以协助理解意图和整理字段但用户有没有权限、订单是否属于当前客户、是否已经提交过同一请求都应当由可信的应用逻辑与业务系统校验。模型生成了一个工具调用请求不代表该请求天然获得授权。这也是为什么 FDE 必须理解接口、身份与数据模型。没有这些基础再精巧的提示词也无法替代系统边界。3. 谁来证明系统确实改善了工作如果客服查资料原本需要几分钟AI 虽然几秒钟给出答案但客服必须花更久核对项目未必提高了效率。如果模型回答更全面却让工单退回率上升也不能只凭“回答更长”评价成功。我们需要同时观察任务结果、处理时间、人工复核成本和失败情况。技术指标与业务指标应当互相解释延迟为什么重要因为它影响坐席处理任务引用为什么重要因为它降低核验负担。图 2本文使用的教学交付模型。阶段之间允许反复不代表所有企业都采用同一种流程。四、贯穿专栏的项目星河设备售后 AI 助手接下来我们定义一个足够具体又能随着课程逐步扩展的项目。星河设备是一家虚构企业。本文中的公司、产品、订单和目标数值均为教学设定不代表真实客户案例或已经测得的效果。这家公司有一支售后服务团队。客服处理一次请求时通常需要打开产品资料目录、查阅保修政策、查询订单再把问题整理到工单系统中。资料分散命名也不完全一致新人往往需要请资深同事帮助判断。我们准备开发的 Enterprise AI Assistant先服务内部客服逐步支持三类任务任务用户真正要完成的工作系统需要提供什么查政策确认某型号设备申请保修需要哪些材料带版本、来源和适用条件的回答查订单确认指定订单当前是否已发货来自授权业务接口的状态与查询时间准备工单把客户描述整理成可提交的申请可编辑草稿确认后通过受控接口提交这三个任务看起来都可以放进聊天窗口但底层能力不同。查政策依赖文档检索查订单依赖实时业务数据提交工单会产生外部状态变化。用同一种“把资料塞进提示词”的方法处理它们会掩盖重要差异。为了控制第一阶段范围我们只验证一条工作流内部客服提出保修材料问题系统从已审核的授权政策中寻找依据给出回答与来源依据不足时明确说明并引导人工处理。这个阶段不自动判定是否应当赔付不修改订单也不承诺覆盖全部产品型号。工单提交、实时订单和更多系统集成放到后续阶段。范围缩小之后团队才有机会判断在一个清楚的任务上系统是否已经值得使用。五、FDE 接到需求后的第一件事把一句话变成任务书客户说“让客服少花一点时间查资料”还不能直接变成研发排期。至少有六个问题需要回答。谁在什么情况下使用新客服与资深客服的困难未必相同。新人可能不知道关键词资深客服可能只是切换系统太频繁。使用对象不同产品入口与回答方式也会不同。当前流程到底卡在哪里如果真正的问题是政策无人维护增加一个聊天入口可能只会更快地传播过期信息。需要先观察实际任务区分“找不到”“看不懂”“无法判断适用性”和“缺少操作权限”。成功表现是什么减少查询时间、降低漏填材料、减少升级咨询都可能是合理目标但它们需要不同的测量方式。第一版最好围绕一两个主要结果做判断。哪些数据可以使用不只要知道文档存在哪里还要知道谁有权访问、哪个版本有效、更新由谁负责。数据所有者应参与确认工程师不能自己推定所有资料都可以进入模型上下文。哪些行为超出边界回答政策、生成工单草稿、修改保修结论是三种风险与责任不同的能力。边界需要在方案与实现中同时出现。谁来验收和接手最终使用者、业务负责人和运维负责人关心的事情不一样。如果直到上线时才寻找接手人很多运行问题会被错误地当成临时补充需求。我们可以把讨论结果压缩成一份项目任务书。下面的 YAML 只是便于阅读和版本管理的文档示例不是能直接运行的应用配置。project:星河设备售后 AI 助手stage:保修政策问答 PoCprimary_user:内部售后客服business_problem:查找并核对适用政策耗时较多in_scope:-回答指定产品范围内的保修材料问题-显示支持结论的政策片段和文档版本-信息不足时提示补充材料或转人工out_of_scope:-自动批准保修或赔付-修改订单状态-自动向客户发送消息data:source:经业务负责人审核的教学政策文档access:应用根据已验证的用户身份判断权限owner:售后知识维护负责人acceptance:business:比较完成同类任务所需的总时间quality:检查结论是否受到引用证据支持boundary:无依据与无权限时按预期处理operations:失败可追踪且能回到人工流程owners:business_acceptance:售后业务负责人technical_delivery:FDE 与客户技术团队ongoing_operations:上线前明确的系统维护团队写完这份任务书项目才从“做一个 AI”变成了“为一类人改善一条明确的工作流”。即使最终决定不使用大模型这份梳理也仍然有价值。六、FDE 具体要交付什么用项目产物理解职责只说“沟通能力强、技术栈全面”很难指导实际工作。更有效的办法是看每个阶段需要留下什么。阶段需要回答的问题可以检查的交付物需求探索谁遇到什么问题为什么值得解决当前流程图、真实任务样本、约束清单范围定义第一版做到哪里怎样判断有效任务书、范围边界、验收草案技术验证在限定条件下方案是否成立PoC、失败样例、评测记录工程实现怎样让实际用户完成任务应用代码、数据流程、集成接口试点运行真实使用暴露了什么试点反馈、问题分类、运行指标交接复用别人能否维护并复用已验证的方法运行手册、交接记录、可复用组件这些产物不是为了制造文档数量而是为了减少信息只存在某个人脑海中的情况。例如PoC 失败样例应该保留原始问题、当时使用的文档版本、检索结果和预期行为。否则下一次更换提示词后大家只能凭印象争论系统有没有变好。再如交接文档不能只写“执行启动命令即可”。维护者更需要知道文档导入失败如何补跑外部模型接口不可用时用户会看到什么哪种告警需要立即处理发现错误答案后如何定位受影响的资料版本。FDE 对技术结果负责不等于必须一个人完成每件事。身份系统可能由客户 IT 团队维护业务验收必须有业务负责人参与安全评审也可能由专门团队承担。FDE 的重要作用是让这些责任在一条交付链上衔接起来。七、Demo 与生产之间差的不是一句“再优化一下”一个 Demo 可以选择最有代表性的几份资料提前准备好演示问题并由熟悉系统的人操作。它很适合验证方向也适合帮助大家对方案形成共同理解。但生产系统要面对未经挑选的输入用户会写错型号、遗漏订单号、引用旧政策也可能提出根本不在系统范围内的问题。上游接口会超时资料会变更权限也会变化。图 3两种阶段的完成条件不同。该图不表示固定的开发时间或工作量比例。我们可以用四个具体问题检查差距。第一输入换了系统是否还能按边界工作不需要什么问题都回答但需要清楚地区分可回答、应补充信息、应拒绝或应转人工的情况。第二依赖失败用户是否知道下一步一次订单查询超时不能被模型改写为“订单不存在”。系统应该准确表达当前无法确认并提供重试或人工查询入口。第三数据变化答案是否跟着更新新政策上传成功不等于旧索引已经失效。我们需要定义资料更新、重新索引、版本选择与失效处理方式。第四系统交给别人是否还能持续工作如果每次异常都必须联系最初开发者系统还没有建立可靠的运行方式。生产交付包括维护职责和恢复路径。因此PoC 的价值在于验证一个假设生产版本的价值在于持续兑现明确的服务承诺。前者做得成功是继续投资的证据不能自动替代后者的验收。八、先看懂系统结构再决定是否需要 Agent在这个专栏里我们最终会把项目扩展为一个具备知识检索、业务查询和受控操作能力的企业助手。但现在先看职责分配不急着堆框架。图 4目标形态的概念架构后续文章逐步实现。本篇尚未交付这个应用图中的连线表示调用关系不代表所有数据都必须传给模型。这张图里有几个值得记住的决定。用户身份来自可信的登录过程。用户在聊天里输入“我是管理员”不会改变其系统权限。应用根据已经验证的身份获取授权范围再决定允许访问哪些资料与业务对象。文档查询与实时业务查询分别处理。保修政策适合从受控文档中检索订单是否发货应以业务接口返回的当前状态为准。把订单导出后永久放进向量库不能替代实时查询能力。模型提出的操作要经过应用校验。将用户描述整理成工单草稿可以给客服编辑真正写入工单系统之前还要校验必填字段、权限和确认状态。重复点击或重试也不应产生多个相同工单。评测与可观测性贯穿流程。一次错误不一定来自模型可能是文档版本选错也可能是检索遗漏或接口字段映射有误。如果只保存最后一段答案就很难定位问题。记录也应控制敏感内容不能把所有原始客户数据无差别写进日志。至于是否使用 Agent要看任务是否需要模型动态选择下一步。如果流程已经明确为“补全订单号、查询状态、展示结果”固定工作流往往更容易解释、测试与控制。只有当任务需要更灵活的步骤选择而且收益经过验证时再引入相应能力。Anthropic 在《Building effective agents》中也区分了预定义工作流与由模型动态决定步骤的 Agent并建议从满足需求的简单方案开始。这里引用的是架构原则不是把文章中的历史工具列表当作当前推荐清单。来源Anthropic 工程文章九、什么叫“项目有用”从第一天就定义验收证据“客户觉得不错”可以是早期反馈但很难作为唯一验收依据。“回答准确率 95%”看起来具体如果没有说明样本、判断规则与分母也可能毫无意义。对于星河设备的第一阶段我们可以把验收拆成四个维度。图 5验收需要多类证据。任何单一分数都不足以证明系统已经适合上线。业务价值把人工复核时间也算进去。先观察客服使用现有流程完成任务的时间再比较使用 AI 辅助后的总时间。计时应包含查证来源、纠正答案和补充材料而不是只统计模型生成耗时。尽量使用难度相近的任务并记录不同熟练度用户的结果避免把“第二遍做同一道题更熟悉”误判成工具收益。答案质量检查结论和证据之间的关系。一个答案挂着文档链接不代表引用真的支持结论。需要核对关键条件是否遗漏政策版本是否适用以及答案有没有添加资料中不存在的承诺。评测标准应允许不同措辞重点看任务要求是否满足。安全边界单独检查不该完成的任务。在无权限、无依据、缺少关键信息时正确行为可能是拒绝、澄清或转人工。把这些情况混进一个总平均分会让大量普通问答掩盖少量严重失败。运行与采用观察真实工作而不是登录次数。打开过系统不等于使用系统完成了任务。可以观察目标范围内有多少任务使用了助手、多少结果被采纳、多少需要改正以及用户为什么回到旧流程。试点失败也不一定代表模型不够强入口不顺手或证据难以核对同样可能导致弃用。为了让讨论具体下面给出一组教学用的初始目标示例不是行业标准也不是本项目实测结果验收项示例方法与初始目标需要注意的限制有依据的问题独立留出的 30 题中至少 27 题满足任务要求且关键结论有证据小样本只用于早期判断不等于线上质量保证资料不足的问题10 题中至少 9 题明确指出不足并给出合理下一步还要检查是否对本可回答的问题过度拒答权限边界预设的 10 个越权样例全部被拦截通过这 10 题不代表完成安全审计任务处理时间用可比任务比较含复核的总耗时先测基线再约定改善目标同时关注返工和错误成本故障处理模型接口不可用时展示明确状态并保留人工处理入口需要实际演练不能只检查设计文档用于调试提示词的样例与用于最终检验的样例应当分开。独立样例集一旦反复被团队用来调整实现就不再是严格意义上的独立检验需要补充新的任务。对于第一篇你不必立即实现完整评测平台。但必须理解验收条件会反过来决定架构、数据准备和开发顺序。如果验收要求展示政策版本就需要在数据处理时保存版本信息如果需要定位错误回答就需要在实现时建立可追踪的请求标识。等到项目最后一天再补验收往往意味着重新设计系统。十、FDE 需要的能力应该如何放在一起FDE 确实需要较宽的能力范围但这不意味着先学完几十个工具才有资格开始。对我们的项目而言可以把能力分为四组。业务问题拆解。能把“提高效率”变成具体任务识别当前流程中的等待、重复输入和判断成本并与用户确认优先级。这里的成果是一个可验证的问题定义而不是会议记录越长越好。软件工程基础。能构建接口、理解数据库、处理错误、管理配置、编写必要测试并部署服务。这些能力让模型之外的系统行为可控也是后续排查问题的基础。AI 应用工程。能理解模型输入输出、检索、工具调用和评测之间的关系并根据任务选择方案。知道某个框架的名称与能够解释一次失败为什么发生是两件不同的事。交付与协作。能记录技术决定、暴露风险、调整范围并把系统交给他人维护。一次清晰的范围取舍可能比增加一个并不需要的功能更能保护交付。学习顺序应当由项目瓶颈推动。当前系统没有可靠的数据来源就先解决数据问题当前答案有依据但用户不愿使用就观察交互和工作流程。不是每次遇到困难都要更换模型或增加 Agent。我们会在第 06 篇系统展开技术栈。从第 07 篇开始使用同一个项目逐步补齐前后端、集成、RAG、工具调用、评测、部署和运行能力让每项技术都对应一个明确的业务需要。十一、第一次做 FDE 项目最容易踩的五个坑只访谈项目发起人没有观察实际使用者。主管可能关心工单吞吐量客服则最在意是否能快速核对依据。只满足其中一方系统可能通过演示却无法被日常采用。尽早观察几次真实任务比继续增加假想功能更有效。把所有客户要求都当成本期范围。“顺便接一下 CRM”“再加自动发邮件”“以后支持所有部门”每一句都可能引入新的权限、接口和验收问题。将需求记录下来说明对目标和进度的影响再决定本期是否纳入。范围管理是工程工作的一部分。用更复杂的 AI 方案遮盖数据问题。没有权威版本的政策、缺少订单与客户之间的映射不会因为多加一个推理步骤就自动恢复正确。先识别缺失事实再决定是补数据、调整流程还是限制当前能力。将“有人复核”写成万能兜底。复核者需要看到什么依据需要承担多少额外时间能否修改超出权限时如何升级如果这些问题没有答案人机协同只是把不确定性转移给了用户。上线时才讨论维护。维护者应该在试点阶段就参与实际执行一次资料更新、故障定位和人工回退。交接的有效证据是接手团队能够完成操作而不是收到了一份压缩包。十二、本篇实战写出你的第一份 FDE 项目任务书读完一篇岗位介绍很容易真正有用的是改变下一次接到需求时的行动。选择一个你熟悉的业务任务。可以继续使用星河设备也可以选择企业内部制度查询、销售资料准备或工单分类。先不要选“公司所有知识统一智能化”这样过大的目标。用一页文档回答下面的问题谁在什么时刻遇到这个问题写出一名具体用户及其任务。他现在怎样完成任务列出主要步骤并指出最明显的阻碍。第一版只改善哪一步把包含和不包含的能力同时写清楚。需要哪些资料或接口分别由谁维护谁允许访问什么证据能证明方案有效至少写一个任务结果指标与一个边界检查。遇到失败怎么办说明用户下一步、责任人和人工处理路径。谁来验收谁接手运行把角色落实到实际团队。然后准备五条任务样例两条正常问题、一条信息不足的问题、一条权限不允许的问题以及一条上游服务失败的情况。为每条写出你希望系统如何行为。例如正常问题是“XH-200 申请保修需要哪些材料”信息不足的问题是“申请保修要准备什么”但没有说明产品型号或适用政策权限问题是要求访问当前账号无权查看的专属政策服务失败则是文档检索服务或模型接口超时。这五条样例都应围绕第一阶段的政策问答范围设计。最后做一个检查如果把文档中的“AI”“大模型”和“Agent”三个词全部删掉别人还能理解你要改善什么工作吗如果不能问题定义还不够清楚。这份任务书就是本篇的实际交付物。后续文章将不断引用、修订它而不是每次换一个新的演示项目。FDE Thinking你交付的是功能还是一种可被信任的工作方式客户往往通过一个功能表达需求但工程师需要理解这个功能将进入什么流程。“能回答保修问题”只是能力描述。“客服能够查到适用政策、核对证据并在不确定时知道如何继续处理”才更接近一条完整的工作流。两者的差别会影响很多决定是否需要聊天界面是否必须调用模型哪些资料能够进入上下文什么时候应当让人确认什么才算一次成功任务。所以本专栏会反复使用一个问题审视方案这项技术选择究竟让哪位用户更可靠地完成了哪一步工作我们准备用什么证据证明它当你能够同时回答“为什么做”“怎样做”“怎么知道有效”与“交给谁持续运行”你就开始以 FDE 的方式推进一个项目。下一篇我们会讨论《FDE vs SWE vs AI Engineer vs Solution Engineer到底有什么区别》从工作对象、决策范围、交付物与协作关系出发解释这些岗位的差异与重叠。