结论先说FDE 不是“高级程序员”也不只是驻场开发。它要同时理解技术、业务和客户现场把 AI 从一个能演示的 Demo推进成业务人员敢用、愿意用、能够持续使用的系统。FDE 的英文是 Forward Deployed Engineer通常译作“前线部署工程师”。如果只用一句话概括它做的是走进真实业务找到值得解决的问题快速做出可验证的方案再推动方案真正被采用。FDE 的工作到底是什么很多人听到 FDE第一反应是“带着电脑去客户公司现场写代码”。但在实际项目中写代码往往不是占比最高的部分。下面用一家制造企业举例。这里的阶段只用于解释工作内容并不是固定项目周期。阶段一理解现场先和老板、车间主任、仓库管理员等角色沟通听他们描述真实问题排产依赖老师傅经验客户询价需要多部门来回确认库存系统和仓库实物经常对不上。这时最重要的不是马上打开开发工具而是弄清楚问题发生在哪里影响了谁为什么一直没有被解决。阶段二筛选值得解决的问题现场通常会出现几十个诉求但不是每个问题都适合用 AI。需要判断问题是否高频现在是否依赖大量人工和个人经验AI 能否带来足够明显的改善问题看起来是技术问题还是流程和管理问题阶段三快速构建并共同验证选定场景后使用现成模型、开发工具和 Agent 框架快速搭出原型让业务人员尽早参与测试。原型的目的不是一次做完而是尽快验证方向、发现边界。阶段四推动系统真正被采用Demo 能跑只是开始。后面还要处理数据权限、安全审查、人工兜底、业务流程调整、效果评测和人员培训。因此在很多 FDE 项目里沟通、判断和推动的重要性并不低于编码。FDE 需要的五种核心能力下面五项是我结合公开岗位信息和项目观察归纳出的工作模型不是行业统一标准。不同公司的 FDE 职责、技术深度和客户协作方式会有所差异。1. 价值判断不是什么都值得做 AI很多企业都会说“我要用 AI”但真正值得优先投入的场景通常需要满足几个条件发生频率高。 高频任务即使只改善一部分也可能产生持续收益。当前人工依赖重。 如果流程依赖反复查询、复制、判断或个别员工经验就有自动化和辅助决策空间。改进足够明显。 “比原来稍好一点”往往不足以推动组织更换流程必须让业务方感受到明确价值。风险和成本可控。 高风险、低频且必须由人工签字确认的任务未必适合作为第一个 AI 项目。例如假设客户询价每天发生几十次目前需要人工查库存、核价格、跨部门确认那么缩短响应时间就可能有直接价值。相反一项低频且存在强制人工审批的工作即使能自动生成内容也不一定值得优先改造。价值判断不是天赋。看过更多真实流程、听过更多业务人员的描述后判断力会逐渐形成。2. 问题重构客户说的方案不一定是真问题客户可能会说“我要一个知识库问答系统。”如果直接照着做最后可能只是上传文档、检索、生成回答。技术上能运行业务上却没人用。继续追问后可能会发现真正的问题是老专家即将退休关键经验没有被整理新人找得到文档却不知道在什么条件下应该做什么判断。表层需求是知识库问答深层问题是经验传承和决策支持。这时方案可能不只是 RAG还需要梳理专家的判断条件、异常分支、审批边界和人工接管机制。一个简单的练习方法是对每个需求连续追问几层“为什么”为什么需要知识库因为新人找不到信息。为什么找不到因为信息分散而且关键判断仍在专家脑中。那真正要解决什么让新人能够在具体场景中做出更可靠的判断。FDE 的关键能力之一就是把客户提出的功能重新翻译成值得解决的业务问题。3. 快速构建重点不是从零写而是正确组合很多 AI 场景没有必要从零开发。Cursor、Claude Code、Copilot 等工具降低了原型构建门槛LangGraph、Dify、CrewAI 等框架也提供了可复用的能力。FDE 的构建能力 选择合适工具 组合现有能力 尽快验证关键假设。需要判断的包括什么时候使用 RAG什么时候只需要结构化检索或规则什么时候需要工作流和 Agent什么时候简单调用模型就足够哪些功能属于最小可行版本哪些应该等方向验证后再做如何让业务人员尽早看到并使用原型而不是等到最后才验收。关键不是“写得多快”而是知道该做什么、暂时不做什么。4. 评测和护栏让 AI 在业务中不轻易翻车Demo 能跑不代表生产环境能用。知识问答偶尔答错可能只会造成困扰自动报价、合同审核或生产决策如果出错代价可能高得多。FDE 至少要处理三件事建立评测集。 在获得授权并完成必要脱敏后覆盖典型场景、边界场景和异常场景而不是只展示几个效果最好的案例。定义能力边界。 同时评估正确性、依据可追溯性、拒答表现、稳定性、延迟、成本和安全性是否放行不能只依赖模型自报“有信心”。设计兜底机制。 保留日志、审核、回退、权限控制和问题追踪能力。评测和护栏不是上线前补一下的附件而是系统设计的一部分。5. 组织推动做完不算完用起来才算系统上线不等于业务采纳。用户可能不信任 AI 输出IT 部门可能卡住安全和权限新系统可能与旧流程冲突管理者也可能看不到继续投入的依据。推动采用通常需要找到真正承受痛点、愿意参与试用的内部推动者从一个低风险、边界清晰的小场景开始让业务人员参与验证而不是只在技术团队内部评测用响应时间、人工工时、错误率、转化率等指标记录实际变化。组织推动不是“搞关系”而是让相关人员理解变化、参与变化并看到变化带来的价值。FDE 和传统岗位有什么不同维度传统开发售前 / 咨询FDE核心动作根据明确需求实现系统分析问题并提出方案连接诊断、原型、上线和采用需求来源多由产品或需求方定义由客户提出并共同澄清深入现场挖掘并重构问题交付标准功能按要求上线方案支持决策和合作业务实际采用并验证效果技术要求强调工程深度和质量强调方案与行业理解深度与广度根据场景取舍业务理解重要但常由上游需求承接非常重要直接决定项目是否有效FDE 并不是替代开发、产品经理或咨询顾问而是把原本分散在多个角色之间的关键环节连接成一个闭环发现问题、定义问题、构建原型、评测质量、推动采用再把经验沉淀为可复用资产。哪些人适合向 FDE 方向发展程序员优势是工程实现和快速构建可以重点补充业务访谈、流程分析和推动协作的能力。产品经理优势是需求拆解和用户思维可以通过 AI 编程和低代码工具增强亲手验证方案的能力。运营或行业从业者优势是熟悉业务和组织关系可以先掌握基础 AI 工具再逐步补齐数据、评测、安全和工程边界。最关键的不是现在的职位名称而是愿不愿意进入真实现场理解一个具体问题并对“最终有没有用起来”负责。可以从三个动作开始在熟悉的行业里选择一个低风险、边界明确的真实流程做一次小规模验证并提前书面明确数据权限、责任边界和成果归属记录问题诊断、方案取舍、评测结果和业务反馈只有获得相关方授权后才将必要内容匿名整理成案例从案例中提炼可复用的方法、模板和工具为下一次项目降低成本。写在最后AI 时代真正稀缺的不只是会调用模型或写代码的人而是能把技术能力翻译成业务人员听得懂的语言再变成他们敢用的系统的人。AI 可以辅助分析、生成代码和执行任务但它很难独立理解一个组织中的利益关系、隐性流程、责任边界和采用阻力。这些仍然需要人进入现场、持续判断和推动。FDE 不是某一家公司的专利。你可以从身边熟悉的企业和流程开始发现一个真实痛点用合适的 AI 能力做出改进再把过程沉淀成案例、经验和信任。这也是“维天说”正在持续实践和记录的方向。本文由“维天说”原创整理。欢迎在评论区交流你对 FDE 和企业 AI 实践的理解。