结论先说：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 能力做出改进，再把过程沉淀成案例、经验和信任。
这也是“维天说”正在持续实践和记录的方向。
本文来自「维天说」，全平台同名。
我会持续分享普通人能用上的 AI 工具、内容工作流和真实实践，欢迎联系我，一起交流 AI。
