FDE 具体在做什么
怎么做
FDE 的工作可以按"责任范围"分成五块。以下每一块都是 FDE 亲自动手，不是转交给某个内部团队。
一个粗略的时间感——大部分时间在客户现场写代码、调系统；相当一部分时间跟客户管理层对齐方向、拆问题、做架构决策；剩下的时间把现场学到的模式沉淀回公司产品线、写打法手册、培训客户团队。三个方向缺一不可。如果一个所谓的 FDE 每天几乎所有时间都在写代码，他基本上就是一个驻场外包——差在没有和客户 leadership 对齐的中段，也没有回流产品的尾段。
1. 端到端拥有一次部署
从 discovery（跟客户业务方、工程团队、一线操作员访谈，把模糊需求拆成可实现的场景）开始，经过 scoping（切分优先级、划定不做清单）、系统设计、开发、灰度、切换，一路到生产环境稳定跑通并被业务方持续使用。
中间任何环节的 owner 都是 FDE 自己——出问题不推给"外包"、不推给"售前"、不推给"某个第三方"。
参考 OpenAI 对 FDE 岗位的公开描述，一次 FDE 部署的成功标准被明确定义为三件事：
- Production adoption——系统真的在生产里跑，不是躺在演示环境里的 demo
- Measurable workflow impact——对业务流程的影响可以被业务方量化到（响应时长、错误率、处理量）
- Eval-driven feedback——拿评估集数据反过来指导模型和产品的下一轮迭代
三件事同时做到，才算一次 FDE 部署真的成功。
2. 跟客户 leadership 与业务方直接对话
不是"技术团队 → 项目经理 → 客户"的三层传话。FDE 直接跟客户的技术决策人、业务负责人、一线操作员对齐目标、汇报进度、协商 trade-off。这要求 FDE 具备"能跟 CTO 讨论架构、也能跟一线员工聊清工单"的两栖能力。
日常具体在做的事：
- 识别关键 stakeholder，跟他们建立可以说真话的信任关系
- 在 scope、速度、质量三者之间做取舍——不是所有需求都值得做，也不是所有事情都能一次做到位
- 在 blocker 真正堵住之前，提前发现和拆解（数据接入卡权限、业务方没时间开会、模型某个能力还不够——每一样都要提前动手解决）
3. 直接下场写代码
FDE 不是"设计架构、让别人实现"的 solutions architect。当需要清晰度或推进力的时候，FDE 直接进代码里写。
OpenAI 招聘要求里明确列出的门槛：5+ 年工程经验，能读写前后端生产级代码（Python、JavaScript 或类似 stack），熟悉云基础设施、API、大语言模型。写代码不是可选项，是核心工作。
这也意味着 FDE 团队不需要另外配"实施工程师"或"外包供应商"——决策和实现由同一个人完成，业务→技术之间的翻译损失被压到最低。
4. 把工作沉淀成可复用的资产
一次好的 FDE 部署不止交付一个"能跑的系统"，还会产出：
- 可复用代码模块——下一次同类场景可以从"某处开始"，不用"从头开始"
- 部署 playbook——遇到过的 bug、trade-off、灰度节奏，全都写清楚
- 评估集——这个业务场景里"什么样叫做对"的量化定义，交给客户长期维护
- 决策文档——"为什么做这个不做那个"的判断链，让新来的同事快速接手
用 OpenAI 招聘描述里的原话：把有效模式 "codify into tools, playbooks, or building blocks others can use"——把一次现场的经验，变成下一次现场的起点。
5. 把一线信号回传给产品和研究团队
FDE 是产品团队与真实业务之间的信号回路。
- 哪些需求反复出现？
- 哪个模型能力不够、卡了多少客户？
- 哪种数据集才能做出更好的评估？
- 哪个 UX 假设在真实业务里根本不成立？
这些信号如果只留在客户现场，就浪费了。FDE 的工作之一，是把这些系统化地回传给产品和研究团队，让下一版产品/模型能在真实世界的信号驱动下往前走。
一个更本质的说法——"现场定制不是成本，是产品发现"：许多产品能力其实不是在总部会议室里设计出来的，而是从客户现场长出来、再被工程团队抽象和沉淀的。这跟传统外包最大的差别就在这条回流通道——外包做完就散，FDE 做完才开始。
在 OpenAI，FDE 的日常工作还会与 Product、Research、Partnerships、GRC（治理风控合规）、Security、GTM（市场进入）六个团队协同——因为一次好的部署不只是纯技术问题，还是产品、合规、上市、法律的合力。
跟"售前工程师"、"客户成功"、"外包供应商"根本不同——FDE 是真的在写代码、部署生产、承担线上责任的人。用 OpenAI 招聘描述里的一句话概括：他们以创始人的自主权 + 资深工程师的技术严谨工作（"the autonomy of a founder but the technical rigor of a staff engineer"）。