FDE 的未来：让 AI 成为组织生产力

最近在整理一场关于 FDE（Forward Deployed Engineer，前沿部署工程师）的分享时，我反复思考一个问题：我们到底是在帮助企业多用一种工具，还是在帮助企业形成一种新的生产方式？

这两件事看起来接近，交付的东西却可能完全不同。

前者可以是开通账号、部署平台、搭建几个应用。后者则要回答：谁来做事，怎样协作，如何判断结果，以及这套方式能不能持续运转。

我想把自己的理解浓缩为两句话：

AI不是工具也不是技术；AI就是组织和业务的生产力要素，和人一样；AI的转型必须从组织和人的认知改变开始。

FDE 的核心，就是六个字：降本、增效、提产。

这里的“不是”，不是否认 AI 的技术属性，而是强调：企业不能只把 AI 当成一种工具或技术来采购和使用。

“和人一样”，说的是 AI 应当被纳入组织的分工、协作和生产过程，不是说它拥有与人相同的判断能力，更不是把最终责任交给 AI。

以下是我结合这场分享形成的个人理解，重点讨论企业 AI 落地中的 FDE，以及我期待它未来承担的角色。

从“给我一个工具”，到“让它参与工作”

假设我们给一个销售团队开通了 AI 账号，大家可以用它润色邮件、整理会议纪要、生成方案初稿。

这些事情当然有价值。但只做到这里，我更愿意称之为个人效率改善，而不是组织已经完成了 AI 转型。

因为工作怎么分配、资料在哪里、谁负责确认、结果如何流转，可能都没有变化。一个人生成得更快，下一环节仍然需要等待；一个人整理得更好，其他人仍然不知道如何复用。

个人使用了 AI，不代表组织已经具备了 AI 生产力。

把 AI 当工具时，我们首先关心的是它有什么功能、怎样操作。把 AI 纳入生产过程时，问题会变成：这项任务适合由谁完成？AI 能参与到哪一步？它需要哪些信息和权限？结果由谁检查？遇到例外交给谁？

同样是生成一份销售方案，前一种方式是让员工自行复制资料、输入提示词、检查回答；后一种方式则要把客户需求、产品知识、报价规则、审核要求和后续动作连接起来，让 AI 在明确边界内参与整个任务。

微软在 2025 年《Work Trend Index》报告中提出了由人与智能体组成团队、围绕目标重新组织工作的设想。这个视角给我的启发，不是给 AI 安排一个虚拟职位，而是重新考虑人与 AI 应该怎样分工。

所以我并不执着于一定要把 AI 称为“数字员工”。名字可以不同，关键是它有没有进入真实的工作关系：有输入、有任务、有边界、有验收，也有出错后的接管方式。

转型首先改变的，是组织和人的认知

这场分享里反复出现的一个要求，是让企业负责人进入转型小组，让业务负责人亲自参与，并在每周复盘中讲清楚自己的变化，而不是把所有事情交给技术团队或外部服务商。

我理解，这不是要求老板亲自研究模型，也不是认为 IT 部门不重要，而是因为组织变化需要有人作决定。

哪些流程可以调整，哪些信息可以共享，哪些职责需要重新划分，谁来投入时间，谁来接受新的考核方式，这些问题不能只靠技术人员解决。

AI 转型可以由技术推动，但不能只有技术部门对结果负责。

老板需要改变的，是把它当成一次软件采购的认知。买了平台、听了培训，不等于已经获得新的生产能力。

业务负责人需要改变的，是“这是 IT 的项目，做好了我再来用”的认知。业务目标、例外情况和验收标准，不能全部留给外部人员猜测。

员工需要改变的，也不只是操作习惯。原来用“我亲手完成了多少步骤”体现价值，未来可以更多地用“我组织资源完成了什么结果”体现价值。

但我认为，这种改变不能只靠要求员工提高认识。组织也需要回答一个现实问题：员工节省了时间之后，会获得什么？

如果节省时间只意味着不断追加任务，如果愿意分享经验的人反而失去认可，那么组织很难期待大家持续投入。岗位成长、成果认可和收益分配，也应该进入转型讨论。

因此，我所说的“从认知改变开始”，不是先开几轮概念培训，再等待所有人想明白，而是在一件真实业务里，让大家看到新的做法、参与新的分工，并一起验证结果。

降本、增效、提产，必须分别说清楚

我认为，FDE 最终要把复杂的技术语言，翻译成企业能够判断的经营结果。

这六个字不是一句宣传口号，而应该成为选择场景、设计方案和验收成果的依据。

降本：降低合格产出的总成本

降本不应该被简单理解为裁员，也不应该只计算模型调用费。

我更关心的是：完成同样一笔合格业务，整体消耗有没有下降？

重复录入、反复沟通、资料查找、人工核对、返工和异常处理，都可以进入成本分析。新增的模型费用、系统维护、人工审核和错误纠正，也必须一起计算。

如果生成一份材料更便宜了，却需要更多人花时间检查和返工，就不能只拿生成环节证明降本成功。

同样，释放了一部分工时，也不等于已经减少了现金支出。它需要进一步转化为减少加班、避免额外扩编，或者承接更多有效工作，价值才算真正兑现。

增效：缩短从需求到结果的完整周期

增效不能只看 AI 回答得有多快，也不能只看某个人操作得有多快。

假设方案初稿从半天缩短到了几分钟，但仍然需要排队两天才能审核，那么整体交付周期并没有按生成速度同比缩短。

我更愿意关注从客户提出需求，到拿到可用结果，中间经过了多久，有多少时间花在等待、交接和返工上。

这也是为什么 FDE 不能只在旧流程里加一个 AI 节点。有时真正需要改变的，是不必要的交接、重复确认和信息重复传递。

让一个环节更快，是局部优化；让整个任务更顺畅，才是组织层面的增效。

提产：增加能够被验收的有效产出

提产不是生成更多文字、更多代码、更多图片，也不是创建更多智能体。

它应该意味着，在明确的资源和时间条件下，组织能够完成更多符合要求的业务结果。

对于制造业务，可以是合格产出和履约能力；对于销售团队，可以是能够有效承接和推进的客户机会；对于软件交付，可以是经过验证、能够上线和维护的需求成果。

当然，处理了更多机会不等于已经增加收入，产能增加也不等于一定有足够订单。不能把中间指标直接写成最终经营收益。

降本看成本，增效看周期，提产看有效产出。三个维度可以关联，但不能把同一份工时节省重复包装成三份收益。

也没有必要要求每个试点同时显著改善三个指标。先找到主要目标，再观察其他指标是否受到损害，比同时喊三个口号更有意义。

质量、权限边界和可追溯性，是评价这些改善的前提，不是可以随意牺牲的代价。

FDE 为什么必须走进业务现场

这场分享很强调技术人员走向客户现场。我认同的，不只是“去驻场”这个动作，而是接触真实工作的方法。

坐在会议室里，我们容易听到抽象需求：销售想提高效率，采购想降低成本，交付想减少延期。

但这些还不足以决定应该做什么。

分享中销售与售前协作的例子，给我的启发很直接：客户觉得方案出得慢，问题可能并不只是写作速度，而是销售等售前、售前等研发，各自还有其他任务，信息在来回传递中不断损耗。

如果没有看到这个过程，很容易交付一个“方案生成助手”，却没有解决真正的等待。

所以，我期待 FDE 到现场后先看任务怎样发生：一张单据经过哪些人，什么信息总是缺失，哪个判断依赖某位老员工，哪一步反复返工，谁有权决定流程调整。

这里的现场不只是一间办公室或一座工厂，也可以是能够接触真实操作、真实数据和真实反馈的线上协作环境。关键不是每天坐在哪里，而是不能只依赖经过多次转述的需求。

FDE 要靠近的不是客户的办公地点，而是问题发生的位置。

在选择切入点时，我也更倾向于找到与核心业务结果有关、范围可控的任务。不是说辅助场景没有价值，而是不能把一批容易展示的小应用，当作核心业务已经改变的证明。

真正要交付的，是一套能够运行的新工作方式

为了说明这个区别，下面以订单处理为例。这是一个示意场景，不是对分享中某个客户成果的复述，也不代表实测效果。

假设客户通过邮件或文件发来订单，业务人员需要整理信息、核对产品、确认价格、查询库存，再协调交期并录入系统。

只做工具交付，可以是增加一个订单识别功能。它识别完内容，后面的工作仍然由人逐项接力。

以组织生产力为目标，我会进一步考虑：哪些信息可以自动归集，哪些规则可以直接校验，哪些情况必须升级处理，以及确认后的结果如何进入后续业务。

例如，AI 负责整理非结构化订单和识别缺失信息；产品、价格和库存以业务系统中的有效数据为依据；确定的校验交给明确规则；涉及特殊报价、信用条件和交期承诺时，由获得授权的人确认。

完成确认后，系统记录处理结果、人工修改和异常原因，为下一次任务提供可复用的依据。

这里不是让 AI 替企业作出所有承诺，而是重新安排信息处理、规则执行和人工判断之间的关系。

实际验收时，也不应该只问“识别准不准”，还要看整笔订单需要多少人工操作，处理周期是否缩短，错误和返工是否减少，团队在相同条件下能否承接更多合格订单。

如果原来的流程本身不合理，就应该先讨论如何调整，而不是原封不动地把每一步都换成智能体。

当然，流程重构也不能成为随意取消控制措施的理由。必要的审批、审核和职责分离，应当在新方案里保留或得到等效保障。

我的判断是：好的 FDE 交付，不只是把原来的事情做得更快，还要判断哪些事情已经不必照原来的方式做。

不替客户包办，不等于不做工程交付

分享中有一个很鲜明的带教要求：现场人员不要把所有工作接过来代做，而要让客户自己操作、自己汇报、自己复盘。

我理解这个要求背后的目的，是避免一种结果：外部团队在时一切正常，一旦离开，企业又回到原来的工作方式。

但这里必须区分一种具体的带教策略，与 FDE 岗位本身的定义。

Anthropic 的公开 Forward Deployed Engineer 岗位说明，明确要求在客户系统中构建生产应用、交付技术成果，并将可重复的部署经验反馈给产品和工程团队。工程能力和实际交付，并没有被排除在这个角色之外。

因此，我不会把分享里的做法直接概括成“FDE 不应该写代码”或“FDE 只需要改变认知”。

该做的工程必须做，但不能让客户永远只做旁观者。

接口、数据处理、权限、评测、上线和运行保障，需要相应的专业能力。与此同时，业务团队应当掌握任务如何发起、结果如何验收、知识怎样维护、异常怎样处理。

不是每个业务人员都要变成开发者，也不是每个问题都必须由客户自己修复。但哪些能力留在企业内部，哪些继续由专业团队支持，应该从一开始就讲清楚。

我期待的 FDE，不是依靠客户永远不会使用系统来体现价值，而是帮助客户逐步掌握新的生产方式，再共同解决更复杂的问题。

能力留在组织里，转型才可能持续

这场分享还谈到统一任务、知识管理、工作台和过程记录。这部分让我进一步意识到，组织生产力不能只依附于某个特别会用 AI 的人。

一个人知道最好的提示词，不等于团队有稳定能力；一个人能够快速生成方案，也不等于其他人可以可靠复用。

我更关心的是，一项工作完成之后，有什么留了下来。

客户需求有没有进入可查找的记录？被确认的业务规则有没有沉淀？出现过的异常有没有形成处理经验？人工修改过的结果，有没有经过审核后用于改进下一次任务？

这些内容，应当成为组织可以持续维护的工作资产，而不是散落在个人聊天记录中的偶然成果。

但我也不认为，这就意味着所有企业都必须替换现有系统，建设一个包办全部工作的超级平台。

我所理解的统一，首先是任务、上下文、知识和执行记录能够衔接。已有的业务系统仍然可以承担各自的职责。

同样，记录积累得更多，不等于模型会自动变得更聪明。知识需要更新，规则需要维护，改进需要经过评测，旧经验是否仍然适用也需要有人判断。

组织能力的积累，不是文件越来越多，而是下一次完成同类任务时，更少依赖临时解释和个人救火。

我对 FDE 的未来定义

结合前面的理解，我愿意给企业 AI 场景中的 FDE 一个面向未来的个人定义：

深入业务现场，以可验证的经营改善为目标，把 AI 融入组织分工与业务流程，并将交付成果沉淀为可持续、可复用能力的工程实践者。

再简化一点，我会把它理解为：面向业务结果的组织生产力工程师。

这不是一个新的官方职位名称，而是我认为这个角色值得走向的方向。

它不只是咨询，因为不能停在建议和方案上；不只是培训，因为不能只证明大家学会了操作；也不应该满足于功能交付，因为还要与业务团队共同验证实际工作是否改善。

这里并不是说传统开发、实施和咨询不关心结果，而是我期待 FDE 把这些原本容易分开的责任，连接得更紧密。

从这个角度看，我认为未来 FDE 的价值会更多体现在三个地方：看清真正的问题，组织人和 AI 共同完成任务，以及把一次成功变成可以重复实现的能力。

这也不意味着每个 FDE 都要独自精通业务、管理、数据和全部工程技术。复杂项目仍然需要团队。重要的是有人持续连接这些工作，而不是把需求、开发、使用和收益割裂成互不负责的几段。

对商业模式，我同样更看重价值是否被验证，而不是一定采用哪种收费方式。按处理单量收费，不天然等于按经营结果收费；按项目收费，也不天然意味着不对效果负责。

我更愿意先把基线、指标、测量周期和责任范围说清楚。哪些改善来自方案，哪些受订单规模、市场环境或客户执行影响，需要共同判断。没有这些前提，所谓“按结果付费”也可能只是一句新话术。

FDE 应当对自己能够影响的交付质量和改善过程负责，但不应该用无法兑现的经营承诺换取项目。

我期待的，不是企业多装一个 AI

以后再看一个 FDE 项目，我最想问的，不是接了多少模型、做了多少应用，也不是现场演示有多惊艳。

我更想知道：企业有没有改变做事的方法？人和 AI 有没有形成可持续的分工？交付离开演示环境后，能不能继续运行？成本、效率和有效产出，究竟改善了什么？

认知改变只是起点，组织调整是过程，业务结果才是检验。

我期待的 FDE，不是给旧的工作方式贴上 AI 标签，而是让企业真正获得一种新的生产能力。

让 AI 进入组织和业务，让改变最终落到六个字上：降本、增效、提产。