我理解的 FDE（Forward Deployed Engineer）不是一个“什么需求都现场改”的角色。它更像工程与产品之间的连接点：进入真实环境，找出影响交付的约束，做出可运行的方案，再把重复出现的问题反馈为产品能力。
这是我对岗位的思考，并不是声称所有企业都用同一种 FDE 工作方式。
先弄清楚现场真正的约束
在企业 AI 项目里，演示可以只关注一条理想路径；现场还要考虑组织权限、历史系统、数据质量、人工审批、失败恢复和运维责任。用户说“让 Agent 自动处理工单”，背后可能是多套系统的身份无法对应、知识文档版本不一致，或者没有人愿意为自动写入的错误负责。
因此现场工作的起点不是直接写提示词，而是画清楚流程：谁发起、读哪些数据、哪些步骤可以自动执行、哪个节点需要确认、失败后谁接手。把这些问题问明白，往往比迅速拼出一个演示更能减少返工。
区分客户特例与产品共性
现场总会有特殊流程。若每个客户都复制一套分支，短期看起来交付很快，长期会让升级、测试和安全修复变得困难。我倾向于把变化分成三类：
- 稳定共性：身份映射、权限、审计、检索、工作流状态和观测能力，应该进入共享产品。
- 可配置差异：表单字段、审批路径、知识源和工具映射，适合通过受控配置表达。
- 真正的特例：需要明确期限、负责人和退出条件，避免临时逻辑永久留在核心链路。
这不是为了抽象而抽象。判断标准是：第二个相似场景出现时，团队能否复用已有能力，并且不破坏第一个场景。
交付要留下能继续运行的东西
一个现场方案的完成标准不应只是一场演示。至少还需要运行手册、权限说明、关键指标、失败处理路径、回滚方式和交接对象。对于 Agent / RAG 系统，我尤其关心引用能否核对、工具调用能否重试、人工确认是否留痕，以及效果能否用真实样本持续评估。
FDE 的价值既在“向前”——让产品进入复杂现场，也在“向后”——把现场学到的约束带回研发。最好的交付，不是下一次还要靠同一个人救火，而是产品本身因此变得更可靠。
从一次客户请求提炼产品信号
假设现场提出“回答必须显示引用页码”。直接为这家客户在页面上拼一个页码字段，可能只解决了表面问题。真正的约束可能是：解析时丢失页码、切块时没有继承来源、引用链接无法定位原文件。FDE 要沿链路追到缺失点，再判断它是不是所有知识问答场景都需要的能力。
如果多个场景都需要可靠引用，就值得形成统一的文档定位模型和验收用例；如果只是某份特殊格式文件解析失败，则先做适配并给出退出条件。判断依据不该只是“有人提了这个需求”，而是问题是否重复出现、修复后是否降低未来交付成本，以及产品团队能否长期维护。
验收不能只看演示顺利
现场验收最好有双方认可的样本和边界：哪些问题应答、哪些应拒答、哪些动作要人工确认；数据更新后多久可见；失败时能否恢复；日志与文档归谁维护。对于 RAG，至少抽样核对引用与原文；对于 Agent，设计重复请求、接口超时和权限撤销的场景。没有这些反例，演示里的一次成功很容易被误解成系统性的可靠。
交付后还应观察问题是否转移。例如为了提高答案正确率加入重排器，延迟是否超出一线人员愿意等待的范围？为了接入新系统增加一套客户专属逻辑，后续升级是否需要单独发版？FDE 需要把这些成本显式带回产品讨论，而不是把现场“能跑”当成工作的终点。