夜雨聆风
过去一段时间，FDE（Forward Deployed Engineer）逐渐成为AI和技术领域的高频词。有人将它理解为驻场开发，有人认为它是售前、实施与客户成功的重新组合，也有人疑惑，在 AI 已经能够生成代码的今天，企业为什么反而需要一种既懂技术、又要理解业务的复合型角色。
这些问题背后，其实指向同一个现实。许多企业已经购买了模型、搭建了Open Claw（小龙虾）、Hermes（爱马仕） 和各类 Agent，演示效果也足够出色，但一旦进入真实工作流，使用率和业务结果往往不及预期。问题通常不在模型本身，而在模型与组织之间缺少必要的连接。
企业现场的数据可能散落在不同系统，关键流程依赖大量人工判断，历史代码缺少文档，一线员工与管理者对成功的定义也未必一致。此时，生成代码只是工作中的一小部分。更困难的是把分散在表格、系统、代码仓库、会议纪要和员工经验中的信息重新组织起来，形成一套能够运行、验证和持续演进的解决方案。
FDE 的价值，正是建立这条连接。
FDE 的直译是前线部署工程师，但「部署」并不能完整概括这个角色。它更接近一名进入客户真实工作流的技术合伙人，需要理解业务目标和组织约束，也需要完成系统设计、代码实现、测试验证与上线迭代。
FDE 与传统驻场开发的差异主要体现在责任边界，与办公地点无关。驻场开发通常根据明确需求完成交付，FDE 则需要进一步判断需求背后的问题：这项需求究竟属于单一客户的特殊情况，还是某类客户共同面对的困难；应该通过定制代码解决，还是可以沉淀为产品能力；交付完成之后，客户是否真正使用，结果是否达到预期。
因此，FDE 有时会被称为 Forward Deployed CTO。这个称呼强调的是责任范围。在一个具体项目中，他需要同时面对技术方案、数据边界、交付节奏、验收标准和后续演进。客户问题很少会整齐地落入某个部门的职责范围，需要有人将这些问题连接起来。
在大型项目中一些团队还会设置 FDPM（Forward Deployed Product Manager）。FDE 更关注技术实现、测试验证、产品反馈和能力复用，FDPM 则投入更多时间理解业务、建立信任、推动决策并管理客户体验。两者分别承担技术落地与业务推进，能够避免所有责任集中在一个人身上。
FDE 的兴起反映出一种更清晰的行业认知，模型、产品与结果是三个不同层次，高成本定制也不再是走进客户现场的唯一方式。
企业最终购买的是更短的交付周期、更稳定的服务、更少的重复劳动、更快的决策，或者过去无法形成的新收入。聊天框和模型 API 只是入口，模型能力只有进入具体工作流，才可能转化为这些结果。
模型公司可以持续提升模型能力，但当它进入数百个行业、数千种流程和大量历史系统时，问题就从模型训练转向了业务理解、数据接入、流程改造、测试验证和结果交付。任何一家模型公司都很难仅靠扩大人员规模覆盖所有行业细节。
行业应用公司则拥有另一类优势。他们了解具体场景中的高频问题，掌握客户的历史交互、数据结构和工作流，也更清楚哪些环节看似低效却不能轻易改变。FDE 由此成为模型能力、行业软件与企业现场之间的连接者。
这项工作包含两个方向。一方面，FDE 要让 AI 在客户现场真正运行；另一方面，他要把现场形成的经验带回产品，使一次交付能够改善下一次交付。后者构成了 FDE 与传统实施之间最重要的区别。
传统项目通常按照需求、开发、验收的线性路径推进。需求完成后，项目即告结束，至于功能为什么产生、是否只对一家客户有效、其他客户是否存在相同问题，未必会继续追踪。FDE 面对的则是一套持续变化的组织系统，交付只是学习与迭代的起点。
很多企业最初找到 FDE 时，提出的诉求都很具体。希望研发团队更快交付，或者希望业务人员更容易使用数据。这些诉求当然真实，但它们通常只描述了最容易被看见的现象。FDE 需要沿着任务继续向下走，找到本质问题，发现真实需求。
案例一：软件服务公司的软件工程团队
一家软件服务公司的软件工程团队希望引入 Coding Agent，最初目标是提高编码效率。代码生成速度很容易观察，效率也最容易在演示中呈现，因此项目很自然地从这里开始。
但一个真实的软件需求需要经历需求澄清、业务设计、系统设计、编码、测试、部署、线上验证和缺陷修复。Coding Agent 可以快速生成结构完整的实现，却不了解客户行业中的专有规则，不知道一段历史代码为何不能修改，也难以识别普通字段背后的业务约束。只优化编码环节，无法保证整条研发链路获得同样的效率提升。
团队内部的使用效果也会迅速拉开差距。有人能够借助 AI 获得约 70% 的效率提升，有人只能获得约 30%，也有人由于缺少任务边界和项目上下文，反而投入更多时间返工。提示词技巧只能解决一部分问题，更大的影响来自工程师能否提供正确上下文、合理拆分任务、设置验证标准，并在关键节点主动接管判断。
FDE 进入这类团队后，需要了解代码库、文档完整度、技术栈、测试资产、发布方式和成员的实际使用习惯，再把高效个体的经验转化为团队规则。业务知识如何治理，哪些代码允许修改，哪些测试必须执行，什么变更需要人工复核，什么情况下应当回滚，都可以沉淀为 Skills、模板、知识检索和评测集。
这个项目表面上是在部署 Coding Agent，真正需要建立的却是团队使用 AI 的工程体系。FDE 的工作也由工具交付延伸到了流程治理和组织能力建设。
案例二：制造业的数据应用
以制造业的数据应用为例，工程师需要从数千个指标中定位设备问题，同时查阅系统说明书、厂家手册、零部件生产时间、维修记录、大修记录和运行时序数据。客户最初提出的需求，可能只是改善数据可视化。
如果仅按需求表面推进，项目很容易停留在更快的查询和更灵活的图表。然而进入实际排故流程后会发现，原始数据不足以识别许多隐性问题。系统需要融合不同数据源，补充特征，结合厂家算法，并理解特定部件在不同工况下的异常标准。
在这一过程中，一位工程师使用 Excel 建立的简单数学分析模型，可能比图表本身更有价值。它承载的是长期排故经验。过去，这类经验往往留在个人电脑或员工记忆中，随着转岗和人员变化逐渐消失。FDE 可以将其拆解为可复用的数据探索方法，再结合 Agent 完成手册检索、数据抽取、相似工况查找和辅助分析。
至此，一个客户现场形成的方法，才有机会演变为产品能力。
这种机制避免了两个极端。产品不必脱离客户现场闭门设计，客户也不会用大量零散需求把产品拖入不可维护的定制。FDE 在两者之间完成双向翻译：从“希望更快找到数据”中识别排故流程缺少的上下文，也从“需求过于定制”中辨别哪些部分可以抽象为同类客户共享的能力。
FDE 的核心能力是问题建模，沟通只是完成建模的必要手段。只有准确理解客户的真实需求，技术方案才不会停留在功能清单上。
FDE 不只适用于以 AI 为核心产品的公司。传统企业软件、工业软件和金融软件同样需要这种角色，甚至由于业务知识不公开、系统割裂、流程复杂和历史负担沉重，对 FDE 的需求可能更强。
AI Native 方法在这些场景中的价值，主要体现在降低过去难以承担的连接成本。让旧系统突然拥有某种「智能」并不能解决系统割裂的问题。一个企业可能同时使用多套 ERP，客户成功数据、销售通话、邮件和文件分别存放在不同系统。若要推动销售转型，数据接入、权限梳理和业务口径统一应该先于模型接入。
复杂工作流也不应被整体交给模型。确定性规则和数学计算适合处理可验证的部分，模型更适合检索、判断、解释和生成，关键环节仍需保留人工审核与异常兜底。AI Native 的关键，在于重新设计人、模型和确定性系统之间的分工。
这与电力进入工厂后的变化类似。如果只把蒸汽机替换成电动机，却保持原有工厂布局、生产流程和管理方式不变，效率提升必然有限。AI 的引入同样要求组织重新审视流程，简单替换某个工具远远不够。
企业应用 AI 的目标也不应局限于减少人力。更值得关注的问题是，当组织获得大量低成本的认知与执行能力后，可以开展哪些过去无力承担的工作。例如服务此前覆盖不到的客户，为每个账户生成过去成本过高的分析报告，或者重新利用长期沉淀却无法检索的行业经验。
降本是明确的价值，新增价值则可能决定企业长期的竞争空间。FDE 需要同时识别这两类机会。
第二章的软件工程团队案例，正是词元无限 FDE 重点解决的问题。很多客户已经开始使用 Coding Agent，但效果高度依赖少数工程师的个人经验。代码生成得更快之后，业务知识缺失、项目上下文分散、测试不足、人工审核海量代码、重复实现和架构越界等问题也会更快暴露。
词元无限 FDE 会进入客户的真实研发流程，和团队一起梳理需求、代码、测试、发布与缺陷修复之间的连接，识别影响 AI Coding 效果的关键约束。成熟工程师如何拆任务、如何管理上下文、哪些测试必须执行、什么变更需要人工复核，这些经验会逐步沉淀为项目规则、Skills、以及建立 Harness Engineering和 Loop Engineering，让更多成员能够稳定复用。
这项工作也会帮助客户更好地使用词元无限的四类 Agent。它们分别承担不同环节，共同组成一条可控、可测、可审的研发闭环。
产品 | 在研发闭环中的作用 |
DeepMap Agent | 建立项目知识地图，梳理代码结构、调用关系、关键上下文和历史经验 |
InfCode Agent | 根据需求与项目上下文完成代码生成、多文件修改和重构 |
InfTest Agent | 生成并执行单元测试、接口测试和回归用例，让功能结果能够被验证 |
CodeReview Agent | 识别重复实现、过度兜底、架构越界、安全与规范风险 |
FDE 的工作不会停留在产品配置和使用培训。面对目标尚不清晰的探索类任务，FDE 会与客户一起梳理业务场景、数据条件和可行边界，通过快速原型和真实任务验证，判断一个方向是否值得继续投入。面对目标明确但技术链路复杂的方案攻坚类任务，FDE 会深入代码、系统和交付流程，定位关键阻塞，组织多个 Agent 并行处理，再通过测试和评测推动方案闭环。
这套工作方式更接近 AI Native。FDE 负责进入现场，理解业务目标、梳理项目上下文并确定验证标准，再通过 Loop Engineering 组织 Sub Agents、Skills 和 CLI，完成测试排查、根因分类、修复记录与循环验证。经过验证的方法会继续沉淀为 Skills 和工作流，下一次遇到相似任务时可以直接复用。
下面这张图展示了 Loop Engineering 在一次工程测试任务中的运行方式。为了保护客户信息，图片中的系统名称、业务细节和部分处理分支已经被移除，展示的是脱敏并精简后的流程。
在这个流程中，Loop Engineering 会调度多个 Sub Agents 并行执行测试和排查，再调用专用 Skills 完成根因分析与分类。修复阶段通过 CLI 和 Skills 处理脚本、数据与代码问题，同时把过程记录到本地和飞书文档。完成修改后，Loop Engineering 会重新执行测试并进入下一轮，直到结果满足验证标准。
词元无限 FDE 最终交付的是一组 Agent，以及一套能够在客户团队中持续运行的方法。它帮助软件工程团队解决 AI Coding 的落地问题，也承担新场景探索和复杂方案攻坚，再把现场形成的经验带回产品与工程体系。
回到文章开头，许多企业已经拥有模型、搭建了Open Claw（小龙虾）、Hermes（爱马仕） 和各类 Agent，真正进入工作流之后，却仍然难以形成稳定使用。工具已经具备足够强的能力，企业还需要一条从业务现场通向技术系统，再从项目经验返回产品与团队的完整路径。
FDE 站在这条路径的前端。他需要听懂客户提出的功能需求，也要继续识别流程、数据、知识和协作方式中的真实约束。一个方案能否上线只是基础，用户是否愿意使用、业务结果是否发生变化、同类问题能否更快解决，这些问题共同构成了 FDE 的工作结果。
AI 的能力仍会快速变化，今天有效的模型和工具可能很快被下一代产品替代。更加持久的资产，是团队逐步积累的项目上下文、业务规则、验证标准和解决问题的方法。当这些经验进入 DeepMap、以及构建Skills、并且建立 Harness Engineering 和 Loop Engineering，它们就从个人经验变成了可以被调用、验证和持续改进的能力。
这也让 FDE 同时面向两个时间尺度。眼前，他要推动当前问题得到解决，让客户真正获得结果。更长的周期里，他要把现场经验沉淀下来，让下一次交付拥有更好的起点。
衡量一个 FDE 项目是否成功，除了看功能有没有交付，还要看客户团队是否获得了重复解决同类问题的能力。一次任务结束后，知识能够留下，流程能够复用，Agent 能够在更完整的上下文中继续工作，项目的价值才会越过单次交付的边界。
模型会继续变强，真正稀缺的，是那些愿意进入现场、理解复杂性，并对最终结果负责的人。
这正是 FDE 在 AI Native 时代的价值。
