请来 FDE 之后，企业负责人每个节点该做什么

本文目录

问“请 FDE 具体帮我做什么”的负责人，要的通常是一份工作清单。清单确实存在——我们把 FDE（前线部署工程师）在企业里做的事归成五类：找出值得解决的问题（场景诊断）、把 AI 接进企业的数据和系统（系统集成）、明确评测标准与安全边界（评测治理）、盯着真实使用情况持续迭代（运营迭代）、把系统交还给企业（能力转移）。每一类都有具体的动作，也有看得见、能验收的交付物。

但清单是按“他做什么”组织的。对管理者来说，更顺手的是按“项目怎么走”组织：从签约之前到交接之后，每个节点你要准备什么、拍什么板、拿什么验收。这篇就按这条时间线讲。FDE 是什么、什么样的企业需要它，我们上一篇已经讲过，这里不重复。五类工作在实际项目里重叠推进，没有严格的先后顺序；下面的时间节点只表示它们在哪段最集中。

签约之前：四件事先有眉目

FDE 不会替企业把一切都做完。项目能走多远，从签约前就决定了——有四件事得先有眉目，没有一件是技术问题：

• 一位能拍板的业务负责人。指标、政策、风险接受度都要有人定，不能每次开会再议；
• 脱敏后的真实样例和基本的数据访问。没有真实输入，评测就是空转；
• 一线员工参与试用和反馈。他们最清楚流程在哪里断；
• 明确的定制边界。哪些能力进核心产品、哪些只是一次性探索，项目开始就说好，防止交付变成无限定制。

这四件事不落实，后面的阶段会逐一卡壳：业务负责人缺席，第一周的诊断就没人拍板；样例和数据不到位，原型阶段就无从谈起；一线不参与，上线后员工为什么绕开系统，没人说得清；边界不说清，第 9 周该交接了还在谈新需求。

全景：6–8 周怎么走，之后怎么办

签约之后，项目大致按这个节奏推进：

阶段	时间	FDE 主要工作	企业看到什么
诊断与基线	第 1–2 周	访谈、记录基线、选定任务	流程现状图、指标定义
原型验证	第 3–4 周	真实样例、打通最短链路	可运行原型、问题清单
生产化	第 5–6 周	权限、评测、接管机制、部署	评测集、验收阈值
灰度上线	第 7–8 周	灰度、监控、首轮迭代	生产数据、运行报告
运营与交接	第 9 周起	按周迭代、培训、转移	手册、内部接管能力

系统越复杂、要接的系统越多，周期就越长；只做诊断验证的项目，前两周就够。企业可以拿这张表对齐进度，也可以拿它判断 FDE 团队是不是真的在推进：每个节点的“企业看到什么”就是当期该收到的交付物，FDE 汇报的进度对应不上，你就停下来问清楚。下面按节点展开，每个节点说清管理者该确认什么。

第 1–2 周：先别谈技术，谈流程

FDE 进场后的第一件事，往往是先把“哪里值得做”搞清楚，代码要等想明白再动手。

他先访谈业务负责人和一线员工，把“我们想要一个智能客服”这类愿望还原成当前的真实流程：谁在处理、每天多少量、卡在哪一步。接着记录现状基线：处理时长、错误率、人工成本。这些数字是之后判断改进有没有意义的尺子。再按“高频、可衡量、可人工接管”筛选任务，把数据还不齐备、错误成本太高的候选任务排除掉。最后和业务负责人一起定义成功指标：质量、时效、成本、人工介入率。

这一阶段企业拿到的是：流程现状图、基线数据、场景优先级清单、指标定义表。

举个例子（假设场景，不是真实客户项目）。一家制造企业想用 AI 处理质量异常，FDE 进场第一周不写代码，先跟着质量员记录异常报告怎么流转。假设现场每周有 40 张异常单，每张平均要翻三个系统、问两个人才能凑齐证据，光“找证据”每周就吃掉几十个小时。数字只是为说明问题而设，真实项目以现场记录为准。基线一旦清楚，“值不值得做”就从感觉问题变成了可以坐下来谈的账。这条流程怎么拆，我们单独写过质量异常处理怎么接入 AI？从问题报告到跟进落实。

这个节点要拍板的，其实是三件事：基线数字认不认、任务优先级认不认、指标定义认不认。都认了，项目才算真正开始；不认的地方当场改，别等原型做出来再返工。

第 3–4 周：原型期，把链路打通

任务选定之后，FDE 的工作是把模型接进企业的真实环境。外贸询盘是另一个假设场景：客户邮件进到公共邮箱，业务员每天要逐封判断真假、补全信息、起草回复。FDE 把这一步做成工作流，从邮箱和 CRM 读取询盘，AI 提取关键字段、起草回复，业务员确认后写回 CRM，跟进记录自动归档。字段映射和权限都在配置里，换 CRM、加邮箱都不动主流程（完整拆解见客户询盘如何进入 AI 辅助的销售跟进流程）。

原型期不追求完整产品，目标是用真实样例打通最短链路：数据能不能读到、模型输出像不像样、人工确认点放在哪。数据在哪、边界在哪，要先盘清楚：知识库、ERP、工单、邮件、表格，哪些能直接读、哪些要申请权限、哪些必须脱敏；什么内容可以进模型，什么只能留在内部处理。然后写连接器，把检索、提取、规则校验、人工确认、写回系统串成一条工作流。还有一条容易忽略的原则——AI 要嵌进员工已经在用的工具里，别另起一个谁也不进的新界面。

原型期结束，企业手里会多出四样东西：可运行的工作流、连接与权限配置、失败回退机制、使用文档。

这个节点，管理者别盯着原型“像不像成品”，要看三件事：原型是不是用真实数据跑的，一线员工有没有上手试过，失败回退有没有演示过。

这类工作里，连接稳不稳比模型聪明不聪明更值得看：数据源变了会不会静默出错，接口失败能不能回退，员工点了确认之后状态有没有真正写回系统。FDE 写的大部分代码，就是这些连接业务和模型的胶水。

第 5–8 周：上线前后，评测和迭代一起做

企业 AI 和传统软件最大的区别，是不能只按功能清单验收。同一项任务有多个正确答案，有些输出读起来合理，却引用了过期政策。

第 5–6 周进入生产化阶段。FDE 收集真实（脱敏）样例，建立评测集和失败样例库，再和业务方一起定阈值：质量、时效、成本、人工介入率达到什么标准算合格。还要设计人工接管和审批机制——哪些动作必须人点头，人没回应时系统默认不执行。权限压到最小，操作留痕。阶段验收要对照的是：评测用例集、验收阈值表、回退条件、运行日志。

定阈值这件事，业务方不能只当听众。质量、时效、成本互相拉扯，哪个优先，只有业务负责人能拍板。签约前说的那位“能拍板的人”，到这里就派上用场了。

以异常订单处理为例（同样是假设场景）。FDE 会和业务负责人一起列清楚：哪些情况允许自动分单，哪些必须暂停转人工，暂停之后怎么回到流程（异常订单处理如何实现 AI、规则和人工协作）。评测不是上线之后才补的仪表盘，而是系统学习真实业务的依据，这一点我们在生产运行监控那篇里展开过。

第 7–8 周灰度上线，运营迭代其实已经开始。FDE 会观察员工到底用没用、在哪里绕开；分析失败记录和人工修改的样本。员工改了什么，是下一版设计最重要的依据，每一处修改都指向下一版要解决的问题。然后按周迭代：调整提示、修正规则、更新知识库，同时盯着成本、延迟和失败率，每次版本变化都跑一遍回归评测。企业拿到的是：运行报告、问题回归清单、迭代记录。

员工绕开系统，通常不是抵触，而是系统在某一步更麻烦。“为什么绕开”是需求来源。人工确认点放在哪、放几个，我们单独写过一篇（企业 AI 工作流怎么设计人工确认点？不要每一步都审批）。

这个阶段最容易出问题的，是管理者把“上线”当成终点。上线只是迭代的开始：阈值谁有权改、运行报告谁在看、员工反馈有没有进下一版，都要有人盯。

第 9 周起：交接，把系统交还企业

FDE 的交付物必须包含企业能接管的系统和知识。人一走系统就没人能维护，这种交付不算完成。

他会培训业务负责人和内部工程师，写运行手册和评测标准，把知识更新的流程讲清楚，再交接源码、配置和技能包（可版本化的规则与知识配置），和企业约定上线后的维护边界：谁改知识、谁改流程、谁响应故障。最后留在企业手里的，是操作手册、知识转移文档、可复用组件清单。

前提是企业有一位流程负责人（AI 工作流上线后，为什么需要明确业务责任人）。“越来越依赖驻场工程师是交付失败的信号”，这个判断上一篇讲过，这里不展开。交接之后，按周迭代由内部团队接手，FDE 从做系统变成看系统。

整条时间线走完，怎么验收

验收按结果，不按人天。前面每个节点确认的是“走没走对”，下面这几条确认的是“留没留下东西”。时间线走到这里，可以对照：

• 首个工作流从确认到上线用了多久；
• 完成率、人工介入率、成本是否达到约定阈值；
• 员工有没有真的在用，系统上线后他们改了什么；
• 交接后内部团队能不能自己改知识、跑评测、发版本；
• 项目沉淀了什么可复用的组件和方法。

企业买的是工作流价值，Agent 数量和人天只是计价单位，这个判断我们在“一个 Agent 多少钱？”里说过。

回到开头的问题。问“请 FDE 具体帮我做什么”，可以要一份清单，也可以要一张时间表：签约前把四件事备齐，第 1–2 周认基线，第 3–4 周看原型，第 5–8 周盯阈值和灰度，第 9 周起验证内部能不能接管。五类工作（场景诊断、系统集成、评测治理、运营迭代、能力转移）主要落在这些节点上，彼此重叠推进。我们自己的交付也按同样的节奏推进：先挑一个高频流程，再诊断、实施、治理运营，最后把系统交还企业。企业真正值得采购的，是把业务问题推进到生产、再把生产经验带回产品的能力，职位名称叫什么并不重要。