FDE:不是交付系统和PPT,是交付一个被解决的问题

问题通常不在执行，而在开头就没对齐：这一单，到底在交什么。

FDE 回答的就是这个问题。全称 Forward Deployed Engineer，中文一般译作前沿部署工程师，起源于 Palantir，现在 OpenAI、Anthropic、腾讯云等公司都在用。它不是把一套软件远程卖过去，而是派一个小队驻场，嵌进业务侧，对业务结果负责。交付物也因此不同：传统实施、咨询、外包交的是功能、方案或人天，FDE 交的是“一个具体问题被解决掉”这件事本身。做法上，它靠 MVD 最小可行部署、评估集先行、边跑边迭代，而不是先写几十页方案、再开发、最后上线验收。

这套打法适用的范围，比“AI 项目”四个字听起来更宽，也更窄。形态上，它可以是一套集团办公系统，也可以只是一个脚本；边界上，做多大取决于问题本身和双方约定的边界，不取决于“AI”这两个字听起来有多大。

一、FDE 和传统项目到底差在哪

很多项目一上来就吵需求、排功能、谈报价。吵的是范围，根子上是没对齐“这单在交什么”。FDE 的立场很直接：验收不看功能清单勾没勾完，看业务指标有没有达成、一线有没有真的在用、撤场后客户能不能自己接着跑。三方的差别摆在一起更清楚。

表格上半部分讲的是怎么做，最后一行讲的是做完以后谁负责。这一行最容易被跳过，却决定了整套方法的重心：如果验收要看到“客户能自己接着跑”，撤场就不能是项目终点，能力移交和评估资产也就不能等到最后再补。这也解释了为什么 FDE 要在项目一开始就谈指标、谈采纳、谈交接——它们不是验收会上才出现的话题，而是排期和报价的一部分。

二、FDE 怎么开展项目

五个阶段，可以理解成五道防线：每一道都在把还没验证过的东西挡住，不让它进入下一步。整个闭环是：问题锁定 → 评估基线先行 → MVD 快速部署 → 影子并行 → 生产嵌入 → 能力移交与资产沉淀。单场景试点一般 4–8 周，规模化、多场景会拉长到 3–6 个月。每一步都有明确的退出物，进不进下一步，看结果不看日历。

阶段 1：进场诊断与场景筛选（1–2 周，最关键）

进场第一周，最值的动作往往不是开会，而是跟着一线的人跑一遍流程。管理层、业务主管、一线操作员、IT / 安全 / 数据负责人要分别聊，但真正暴露问题的，常常是现场那些没写进 SOP 的东西：一张绕开系统的 Excel、一条记在老员工脑子里的经验、一段没人愿意碰的异常兜底流程。

场景要筛。按价值、数据可得性、可度量、风险、可复制打分，优先选范围窄、端到端闭环、指标清晰、有历史样本的，不做大而全。约束也要在这时候摊开：权限、数据合规、模型风险（幻觉、误判代价）、SLA、审批流程，越早摆上桌越省事。

然后是 FDE 的标志性动作:评估集先行。由业务专家标注黄金测试集、正负样本和疑难边界案例，在写代码之前就把验收标尺定好。顺序很关键：标尺在前，功能在后，才不会变成上线后凭感觉判断好坏。

输出是场景选择报告、业务目标卡、评估数据集、风险清单和 ROI 基线。一句话，先确认这一阶段解决什么问题、做到什么程度、哪些事暂时不做。否则试点还没验证，功能已经越加越多，等验收时，双方说的“做完了”可能根本不是一回事。

阶段 2：MVD 最小可行部署（几天到 2 周）

MVD 常被当成 Demo，两者差在环境。Demo 跑通就行；MVD 要跑在客户真实数据环境里，能接入现有系统，还能产出可核验的业务结果。它是最小版本，但不是演示版本。

要打通的通常有三段。数据链路要对接 ERP / MES / WMS / OA / 知识库，做清洗、权限隔离、脱敏，以及 RAG 或本体构建；工作流要编排 Agent、工具调用、规则加模型混合、异常分支和人工兜底节点；集成适配要处理单点登录、审计日志、告警，还要和原有工单系统联动。原则始终是不推翻现有系统，而是嵌进去。做完之后，用阶段 1 建好的评估集做内部盲测，看准确率、召回、幻觉率、耗时，再回来调 prompt、检索和规则阈值。

这也是它和传统项目最大的差异：原型本身就是共识的载体。争论会从“你想要什么”变成“这个东西哪里不对”，几十页 PRD 的扯皮就这样省掉了。

阶段 3：影子并行验证（2–4 周）

影子并行阶段不接管生产。系统和人工并行跑，系统输出但不自动生效，业务人员照常判断，两边结果放在一起对照。

要记的东西很具体：系统输出、人工复核结果、漏判误判、边界失败 case。FDE 小队和业务专家每周复盘，回标坏样本、补规则、优化 prompt 或微调；同时盯着模型稳定性、数据漂移、响应延迟和安全审计。达标只是及格线。还要过安全评审和变更审批，才能进准生产。

阶段 4：正式嵌入上线与持续运营

上线不是一次性放开。权限分三段走：先建议模式，系统给建议、人工审核后执行；再条件自动模式；最后只在高置信场景做全自动化。每放开一段，都留了一个可以收回来的位置。流程也要跟着立起来。异常怎么处理、升级路径怎么走、谁来复核、数据怎么回流，这些要写成业务 SOP；业务内部要养出自己的超级用户；上线后建指标看板，做周度效果复盘和月度价值复盘。

阶段 5：撤场、能力移交与资产沉淀（FDE 独有的一环）

FDE 撤场不是交付结束，而是把一个能自己运转的东西留在客户手里。

移交清单包括运维手册、评估集、组件源码、提示词库和知识库工程包。接着要给内部 IT 和业务种子做深度培训：怎么改评估用例、怎么加规则、怎么排查幻觉、怎么新增同类子场景。最后，客户侧的通用组件、行业模板和踩过的坑，要回流给上游产品侧，供后续其他 FDE 项目复用。

还得补一句实操原则：阶段可以回退。进了企业环境才发现文件读不到，就先处理数据和授权；实际使用者说规则不适用，就重新确认、修改后再测。分阶段的意义是尽早暴露问题，不是把项目切段之后，前面的事就再也不能动。

三、FDE 要交付什么

交付物分四类，顺序就是优先级。

最前面永远是业务结果。它指目标场景稳定产出的业务成果：自动单据匹配、异常预警、质量根因检索、工单摘要、物料齐套校验、设备故障预判，也包括人在回路的决策输出、复核记录和异常工单流。这是买单方真正要的东西，其余三类都为它服务。

往下是工程与系统。生产可用的 Agent / AI 应用、RAG 知识库、数据管道、与现有 IT 打通的集成接口；权限体系、审计日志、安全控制、数据脱敏方案；能看延迟、成功率、调用量、幻觉率和数据漂移告警的监控看板；还有部署脚本、环境配置和回滚方案。这一类的衡量标准只有一句：能不能在约定条件下持续运行，在开发电脑上成功一次不算数。

第三类是评估与证据资产，也是 FDE 区别于普通 AI Demo 的地方。一份黄金评估数据集，覆盖正常、边界、疑难、负面 case，标准答案由业务专家签字确认；一份基线报告加迭代全链路评测报告，看准确率、召回、精确率、误报率、漏报率、幻觉率、人工复核率；再加上影子对照实验记录、错误案例库、根因台账，以及合规、隐私、风险评估报告。少了这一类，三个月后系统是好是坏都说不清。

最后一类是知识与能力资产。业务流程图谱、场景本体、行业术语库、隐性经验沉淀文档；可复用的组件包，包括通用检索组件、校验规则模板、提示词模板和评估脚本；内部超级用户手册、运维 SOP、自助迭代指南；复盘文档里的失败边界、避坑清单和同类场景快速启动模板。它决定这次投入能不能在同企业其他场景、其他客户身上复制。

四类里面，边界最容易被含糊过去。“做一个办公助手”这种说法不能直接拿去开发——它没说清覆盖哪些任务、输出到什么程度、谁来判断可用。边界至少写清三件事：做到什么、不包含什么、满足哪些前提才能做。

拿会议纪要举例。约定的是根据材料生成初稿，就不能顺手承诺自动替人决定负责人、自动审批或发正式通知。读取和写回也要分开约定：允许查一张表，不等于允许改表里的数据，技术上连得起来，业务上是两套权限、两种责任。需求一变，比如加个入口、改成企业环境部署、要求源码交付，工作、验收条件、周期和费用都要重新评估，再确认新范围。

四、怎么衡量成败

评估的顺序是固定的：先看业务结果，再看用户真实采纳，最后看组织能不能自持续。任何一级塌了，前一级的数字都会失去意义。

第一级是业务量化指标，要在项目启动前锁定基线，写进评估集。指标大致四类：效率看单任务耗时下降比例、人工操作次数、跨系统查询次数、工单处理周期；质量看自动处理通过率、准确率、召回、误报率、漏报率、幻觉率、复核驳回率；风险看合规抽检通过率、敏感信息泄露风险和异常响应时长；价值看返工损失、停机时长、库存资金节约、人力工时节约，以及可核算的 ROI。

拿财务回款匹配来说，基线是人工匹配 15 分钟一单；目标是自动匹配率 ≥95%，剩下 5% 人工兜底，整体工时下降 70%，误匹配率 <0.5%。这些数字在写代码之前就和业务方签好，验收时才有得对。

第二级是用户采纳与流程融入，也是项目死得最多的地方。指标达标不等于项目成功。先看真实使用率：目标岗位员工主动调用的比例、系统产出被采纳执行的比例——采纳率和准确率是两件事。再看有没有旁路回归：员工是不是又退回 Excel 和老办法，绕开了系统。这个信号一旦出现，指标再漂亮也要当失败处理。此外还有负面反馈频次、培训后的自助操作频次，以及异常工单有没有按 SOP 真正闭环，而不是堆在那里没人管。Demo 准确率 98%，一线不敢采信，这就是一个失败的 FDE 项目。

第三级是组织自可持续能力，也是长期成败的标尺。撤场之后，客户团队能不能自己新增样本、调规则、排查幻觉、加同类子场景；评估机制还转不转，有没有人维护评估集、定期重测模型效果；这次沉淀的组件和模板，能不能在同企业其他场景快速落地；业务团队有没有形成“用评估集验证 AI 效果”的习惯，而不是继续凭感觉判断好坏。

有几个坑要单独列为否决项：幻觉造成业务决策损失，在质量判定、资金、安全这类高风险场景一票否决；数据漂移后没有监控和回测，效果缓慢劣化却没人发现；只交付系统、不交付评估集，以后说不清系统好还是不好。

五、百万级项目，钱花在哪、坑在哪

这一节要说的不是“AI 办公助手能做什么”，而是一个真实订单里的取舍：问题怎么定的、钱花在哪、技术上哪些刻意不选、验收为什么非跟到成品文件。

项目要处理的是四件事：找内部资料、整理会议纪要、写公文和 PPT、设提醒。它们都不难，但每次都得从零开始，产出质量取决于写的人当天状态。这类工作最容易被一句“做个助手”糊过去，因为“助手”没说清覆盖哪些任务、输出到什么程度、谁来判断可用。

真正的风险落在初稿上。员工提交材料和整理要求，系统出初稿，人要接着核对决定、待办和待确认事项。这一步不能省：模型很容易把“可以考虑”写成“已经决定”，也会给没说清的负责人补上一个名字。前者改变了结论的性质，后者是无中生有，放进公文和会议纪要都会出事。

所以这个项目要交的不是“一个会写东西的助手”，而是一份核对点被明确标出来的初稿：哪些是已定、哪些待定、哪些负责人还空着，必须一眼能看见。范围一旦扩到集团千人规模，问题也就从“能不能写”变成“能不能在真实企业环境里稳定地写、被核对、被接手”。

技术上做了什么、刻意保留了什么

模型网关是把 AI 调用集中管理的一层：过滤敏感内容、检查部门额度、只调允许的模型，再记录费用和处理过程。但网关管的是调用。文件加密保存、访问入口限制、操作记录留存，仍要分别处理；部署进企业环境，也不等于所有模型都在本地离线跑，资料经过哪里要逐项确认。先按问题里的词找相关材料，再交给模型组织回答。这套做法够不够用，要拿真实问题去试；查不到的时候，先分清是正文没读到、用词不匹配，还是检索方式不合适，再决定改哪一层。

职责也分得很清。模型负责理解材料、组织初稿；程序按固定规则检查计算结果、字段和任务状态。AI 可以帮我们更快地把工具做出来，但工具运行时不一定需要调 AI,一个脚本能解决的痛点，就按脚本的范围交付。

真实联调还卡在企业开通账号上。企业微信、飞书的打通依赖企业侧开通，代码写好和接入条件就绪是两件事，账号和外部通道的开通周期，必须提前排进计划。

验收要跟到用户真正拿到的那个文件

项目开始前做过一次真实 AI 调用并发测试：30 路流式请求同时跑，这一轮全部成功，首字响应 p95 约 7 秒。换句话说，这轮里约 95% 的请求在约 7 秒或更短时间内开始回复。它能说明的只有一件事：所测条件下，调用能起来、能开始回。它证明不了千人容量，也不能把“开始出字”当成“整份文件完成”——后面可能中断，文件可能还没生成好。失败处理是约定好的：还没开始输出就失败，可以切备用模型；彻底失败就保存草稿。但这不意味着做到一半还能换个模型原地接着跑。验收必须打开用户真正拿到的成品：调用成功、文件生成成功、业务结果可用，这三件事要分开验证。文件名登记进系统，不代表正文已经可检索；扫描件或加密文件的问题，也不是换个模型能补回来的。

交付的两笔账

交付账上，小范围云端服务和集团部署、源码交付，承诺的工作本来就不同。报价要列清软件、接入、部署和交接的范围，把维护与 AI 运行费用放进同一个使用周期里比。

业务账上，工程工作多可以解释报价怎么形成，但值不值得买，要看企业实际少做了多少重复工作。200 人稳定使用，扣掉人工核对，每人每天净省 15 分钟，一天就是 50 小时；按 220 个工作日，一年约 11000 小时；假设每小时综合成本 100 元，名义上对应 110 万元工时价值。

这不是本项目的实测收益，也不等于省下同等现金。员工是不是真用了、省下的时间有没有用于更多交付、有没有减少返工和加班，都得继续核对。两笔账合起来，其实就是第一节那张表的最后一行：验收要看到客户能自己接着跑，报价和交付范围就得按这个标准拆开写。

传统实施交功能文档加上线，验收看功能清单。FDE 交的是可核验的业务结果、评估证据和可复制的能力，验收看指标、采纳度和自可持续性。用影子对照加黄金评估集，把 AI 这种不确定系统的验收标准化，是这套方法最实在的部分。从一个脚本到集团系统，分阶段是为了先验证再投入，定边界是为了让双方都清楚这一期交到哪。需求扩大就重新评估，小工具够用就把它交稳。FDE 的专业判断，最后就落在这些选择上：哪些事现在不做、每一步留什么检查物、什么时候该回退、什么时候该停。