OpenAI FDE 面试：AI 交付、Eval、客户问题与系统设计

💡 核心要点 (Key Takeaways)

• OpenAI FDE 的官方定位是「端到端 own 前沿模型的生产部署」：own discovery、technical scoping、system design、build 和 production rollout，成功标准是 production adoption、可测量的 workflow impact 和 eval-driven feedback——面试全程都在考这条交付闭环，不是单点技术。
• 流程信号：公开候选人样本里 OpenAI FDE 流程约 2-3 周（个别样本 2 周、个别约 3 周）、比 Palantir 风格更紧凑，常见骨架是 Recruiter Screen → HM/Intro → 技术轮（Coding + AI 系统/交付设计）→ take-home + 视频 walkthrough / 现场 defend → 交付场景轮 → BQ/HM 收尾；take-home + 视频 defend 是 AI 实验室的强信号环节（不同团队可能不同，以实际邀请为准）。
• Eval 是 OpenAI FDE 的分水岭：官方 JD 明确「eval-driven feedback 改变产品和模型路线图」，面试要能讲清怎么定义客户特定的 benchmark、acceptance criteria 和 launch readiness，而不只是「跑个 demo 看效果」。
• 数据与权限是企业 AI 交付的硬门槛：客户 VPC、PII、行业合规（医疗、法律等 regulated 领域）直接决定架构，面试要能说出权限过滤发生在哪一层、脱敏规则怎么定、数据不可信时怎么降级。
• 7 / 14 / 30 天路线：7 天保交付场景 + eval 表达下限，14 天补 LLM workflow 与数据权限，30 天加 take-home 视频脚本、专项追问和完整 mock。

这篇适合谁：OpenAI FDE 角色定位

这篇写给准备 OpenAI FDE（Forward Deployed Engineer）面试、但还没搞清楚「AI 实验室的 FDE 和 Palantir 的 FDE 差在哪」的候选人。先给结论（基于官方 JD）：OpenAI FDE 的核心职责是「端到端 own 前沿模型在生产环境的复杂部署」——own discovery、technical scoping、system design、build 和 production rollout，直接和客户工程团队与领域团队协作。成功标准官方写得很清楚：production adoption（客户真的在用）、measurable workflow impact（可测量的业务影响）、eval-driven feedback（评估驱动的反馈，能改变产品和模型路线图）。作为 FDE 面试，OpenAI 的侧重点是「AI 交付闭环 + eval 方法学」，和 Palantir 侧重 decomposition / learning 不同；岗位侧的轮次结构和角色差异见 FDE 角色页、SWE 角色页 和 AI Engineer 角色页，公司整体面试信号见 OpenAI 公司攻略。

• 端到端 own（官方确认）：JD 明确 FDE「own the technical solution end to end, from customer discovery and workflow scoping through architecture, hands-on implementation, evaluation, production deployment, adoption, and handoff」。面试里这意味着每个环节都可能被追问，你必须是整条链路的 owner，而不是只负责其中一段。
• 领域化 FDE 方向（官方确认）：OpenAI 的 FDE 有明确的方向划分——Healthcare（payers、providers、health systems）、Legal（律所与法律团队）、以及面向政府客户的 Forward Deployed Engineer - Gov 方向。不同方向的 JD 强调的合规约束不同，面试前看清楚你面的方向，把对应的合规语言准备到位。
• 硬性经验要求（官方确认）：JD 要求 5+ 年工程或技术交付经验（含客户面向工作）、能在快速变化和模糊环境中 scope 并交付复杂系统、Python/JavaScript 全栈生产级代码、建过或部署过 LLM / 生成式系统并理解模型行为如何影响产品体验。注意最后一条：「理解模型行为如何影响产品体验」是 FDE 和纯 SWE 的分界，面试里要主动讲。

流程信号：OpenAI FDE 面试每一轮考什么

先给节奏预期：公开候选人面经样本里，OpenAI FDE 流程约 2-3 周（一篇 2026 年 3 月样本约 3 周、一篇 2026 年 5 月样本自述 2 周），比 Palantir 风格（公开样本 5 轮、约 3-4 周）更紧凑。常见骨架是 Recruiter Screen → HM/Intro → 技术轮 2-3 个（Coding、AI 系统/交付设计）→ take-home + 视频 walkthrough / 现场 defend → 交付场景轮 → BQ/HM 收尾，BQ 常被嵌入技术轮而不是单独成轮。注意：AI 实验室流程变化快，以下轮次与顺序是基于公开面经的归纳（见来源区的两个候选人样本），不是公司固定流程，不同团队会有差异，以实际邀请为准。

• Recruiter Screen（15-30 分钟）：背景、为什么 FDE（而不是 SWE / AI Engineer）、客户现场 + 最高 50% 差旅接受度（JD 明确写了 travel up to 50%）、时间线与期望薪资。差旅接受度是 FDE 的硬门槛，答得含糊会直接影响推进。
• HM / Intro（30-45 分钟）：聊你过往交付项目、对 OpenAI 模型能力的理解、为什么这个方向（Healthcare / Legal / 通用）。把项目讲成「模糊问题 → 快速原型 → 客户采用 → 可测量影响」的叙事，直接对齐 JD 的成功标准。
• 技术轮：Coding（45-60 分钟）：偏全栈 + 业务，常见是「给一个 API / 数据源写一个能跑的服务 + 前端」或「给一段 LLM 应用代码找 bug、加 guardrail」。考的是生产级代码 + 快速迭代，不是纯算法难度。
• 技术轮：AI 系统 / 交付设计（60 分钟）：给一个客户业务场景，设计端到端的 AI 交付方案：workflow 形态（agent vs 固定流程）、工具设计、eval 口径、数据接入与权限、成本与延迟、故障降级。这一轮和部署场景轮合并或分开，取决于团队。
• take-home + 视频 walkthrough / 现场 defend（公开面经强信号）：公开样本里的形态是限定时间（一篇样本约 5 小时、一篇约一周）的交付题，产出可跑原型 / 应用 + 简短文档，再录一段视频 walkthrough 或直接向团队 defend 你的取舍。AI 实验室的特色环节：考的是「一个人在限定时间内交付什么、怎么 defend 取舍」，这正是 FDE 的日常。
• 交付场景轮 + BQ/HM 收尾（30-60 分钟）：模糊客户问题现场拆解（公开样本里是 solution design 形态：给一个客户业务场景、设计端到端 AI 方案）+ 上线后的 adoption 与复盘问题；BQ 集中收口，重点是客户沟通、冲突处理、在高风险下保持冷静判断（JD 原话：model calm and judgment when the stakes are high）。

模糊需求拆解：从客户一句话到 hero workflow

OpenAI 官方 JD（Legal 方向）把拆解的第一步写得很具体：「identify the right first use case, rapidly prototype a solution, and prove measurable value」，早期聚焦打造「hero」workflow——一个能证明模型价值的高价值工作流。这是 OpenAI 和 Palantir 风格拆解的关键差异：Palantir 强调「砍到 P0 范围 + KPI 口径」，OpenAI 更强调「选对第一个用例 + 快速证明价值 + 让模型能力被看见」。

• 第一步：workflow mapping（5 分钟）：不要一上来就选模型。先问客户的完整工作流长什么样、每个环节的输入输出是什么、哪些环节数据密集、哪些环节人判断密集。OpenAI JD 里的「translating complex customer workflows, data, infrastructure, and regulatory constraints into production AI systems」考的就是这个翻译能力。
• 第二步：选 hero workflow（5-10 分钟）：从完整工作流里选出「数据可得、价值可测、模型能力匹配」的 1-2 个环节作为 hero。选法：优先选高频、重复、有明确对错口径的环节（如法律文档初筛、工单分诊），避开一次性、强关系、无口径的环节。说清「为什么先做这个而不是那个」是这一轮的核心评分点。
• 第三步：定义 measurable value（10 分钟）：给 hero workflow 定可测量的成功口径——处理时长下降多少、人工复核比例降到多少、错误率多少。OpenAI JD 强调「measurable workflow impact」，没有口径的交付在 OpenAI 语境里不算交付。
• 第四步：给 2 周交付计划 + 风险：数据接入（客户环境、权限）、模型选型与 prompt 设计、eval 口径、人工兜底路径、上线后的 adoption 计划。最后主动说出最大的两个风险和你的降级方案，体现「spot risks early and adjust without slowing down」（JD 原话）。

LLM workflow：agent vs workflow、工具与护栏

OpenAI FDE 的技术轮几乎一定会考「这个客户问题用 agent 还是固定 workflow」。官方 JD 要求你「理解模型行为如何影响产品体验」，所以这一轮不是考架构名词，而是考你能不能说出：为什么用这个形态、模型在哪个环节会不稳定、怎么护栏。更完整的 tool calling 与安全边界见 AI Agent 面试题，检索链路见 RAG System Design 面试指南。

• 默认从 workflow 开始：规则可覆盖的部分（格式转换、字段抽取、路由）用确定性 workflow，只有开放问题（归纳、起草、跨文档推理）才上 LLM / agent。面试里能说出「为什么不用最重的方案」比炫技 agent 更得分——FDE 要对交付成本和稳定性负责。
• 工具设计：LLM 调用的每个工具都要有：明确的输入输出契约、最小权限（工具能访问的数据范围）、失败返回结构（让模型能读懂失败并重试或降级）。客户场景里工具权限过大是安全事件的常见根因，面试里主动提会加分。
• 护栏与人工兜底：高风险动作（对外发送、写入生产系统、删除）必须 human-in-the-loop approval；低置信度输出走人工复核队列而不是直接给用户。说清「哪些动作自动、哪些人工」是这一轮的硬考点。
• prompt 注入与越权：客户数据会进入上下文，外部内容（邮件、文档、网页）可能被注入。防御要点：外部内容标记为不可信数据而不是指令、工具调用做权限二次校验、敏感操作不依赖模型判断单独放行。医疗 / 法律方向尤其会追问这一点。

Eval：OpenAI FDE 面试的分水岭

Eval 是 OpenAI FDE 和其他 FDE 岗位最大的差异点。官方 JD 把「eval-driven feedback that changes product and model roadmaps」写进成功标准——FDE 不只是用模型交付，还要把客户的评估反馈变成模型和产品改进的信号。医疗方向 JD 更具体：「evaluation loops that establish customer-specific benchmarks, acceptance criteria, and launch readiness」。面试里 eval 答不到这一层，基本拿不到高分。更完整的评估体系（golden set 构建、pointwise / pairwise、human rubric、A/B）见 LLM Eval 面试指南。

• 客户特定 benchmark（官方 JD 原话）：每个客户、每个 workflow 都要有自己的评估集和基准线。面试里要能说出构建路径：从客户的真实样本抽 100-300 条 golden set、按正常 / 边界 / 拒答分层、人工标注口径、版本化管理。
• acceptance criteria 与 launch readiness：上线前定义明确的通过门槛（如：关键场景准确率 ≥ X%、人工纠正率 ≤ Y%、P95 延迟 ≤ Z），达不到不上线。这是「launch readiness」的具体含义，也是 FDE 对交付结果负责的体现。
• eval 怎么反馈到模型：客户的 bad case 库、人工纠正记录、线上指标变化，要能沉淀成可回传给 Research / Product 的结构化信号。JD 里「share field feedback that helps Research and Product understand where the models succeed and where they can improve」考的就是这条闭环。
• 防退步（regression）：每次 prompt 修改、模型升级、数据源变化，都在 golden set 上跑回归，关键指标低于门槛就阻断。LLM 应用和传统软件最大的差异：传统软件有 unit test，LLM 交付有 eval regression——这条说出来直接拉开和「只会跑 demo」的候选人的差距。

数据与权限：客户 VPC、PII 与合规边界

企业 AI 交付的架构大部分被数据约束决定：数据在哪、谁能看、能不能出网、行业合规要求什么。OpenAI FDE 的方向（医疗、法律、政府）全是 regulated 领域，数据与权限是技术轮和交付场景轮的高频追问点，也是区分「做过 demo」和「做过生产交付」的关键。

• 数据在哪、怎么接：客户数据通常在自己的 VPC / 私有云里，不能出网。接入路径：API 拉取、数据库复制或文件投递；讲清增量 vs 全量、去重键、顺序保证，以及「模型推理发生在哪一侧」（客户环境内 vs 调用 OpenAI API 的数据出境问题）。数据出境合规是医疗 / 政府方向的硬考点。
• 权限过滤发生在哪一层：不同角色能看到的数据不同，权限过滤必须发生在检索 / 调用层（metadata filter），不能只靠 prompt 说「只用你有权限的内容」。单靠 prompt 不可靠：模型可能忽略指令、无权内容已进入上下文、无法审计。这是企业场景的标准答案。
• PII 脱敏与审计：医疗（HIPAA）、法律（attorney-client privilege）方向对 PII 要求极高。说清：哪些字段是 PII、脱敏发生在接入前还是展示层（答案是接入前）、脱敏规则怎么版本化、审计日志记什么。
• 数据不可信时的降级：数据质量差、schema 漂移、上游中断时怎么办——校验失败告警 + 止损（暂停自动处理转人工）、旧数据继续可用但标注时效、模型不可用时 fallback 到人工路径。FDE 对交付可用性负责，降级路径必须主动说。

快速原型：全栈 v0 与 take-home

OpenAI JD 明确 FDE 要「build full-stack systems that deliver customer value」并「contribute directly in the code when progress or clarity depends on it」——FDE 不是只写方案，是亲自写能跑的全栈代码。公开面经信号里，AI 实验室的 take-home + 视频 defend 是强信号环节：限定时间产出可跑原型 + 文档，然后 defend 取舍。这一节讲怎么准备。

• 45 分钟 v0 的节奏：面试里的现场原型题，按「数据源 → 最小 pipeline → 一个能跑的接口 → 失败模式」推进，第一版不求完整，求「能跑 + 能演示 + 能说清哪里会坏」。45 分钟讲不出能跑的 v0，是 FDE 现场轮最常见的挂法之一。
• 全栈范围要心里有数：JD 要求 Python/JavaScript 全栈生产级代码。准备时确保你能写出：一个 FastAPI / Express 服务 + 简单的状态管理 + 前端调用，并讲清部署（容器化、健康检查、日志）和测试（至少关键路径的集成测试）。「只熟后端」在 OpenAI FDE 轮里是短板，要补。
• take-home 的打法：① 先花 30 分钟读题并写下你的理解（scope、假设、不做清单），防止做偏；② 先做最小可演示版本，再迭代；③ 文档写三件事：你做了什么、为什么这样取舍、哪里会坏 + 下一步计划；④ 预留时间录 defend 提纲。take-home 考的不是代码量，是「一个人在约束下的交付判断」。
• 视频 defend 的准备：defend 时按「假设 → 取舍 → 失败模式 → 下一步」讲，主动说出你砍掉了什么、为什么。能主动说「这里如果时间再多我会 X」的候选人，比假装做完了的候选人得分更高。

客户沟通、上线与复盘

OpenAI FDE 的交付闭环不止于上线：JD 要求「embed closely with customer teams, understand their needs, and guide adoption of what you build」，并用「production adoption」衡量成功——客户没用起来，交付就不算完成。BQ 和交付场景轮都会考「上线之后」的部分，这部分被大多数候选人忽略。

• adoption 是交付的一部分：上线后要做的事：选 seed users（最痛、最有影响力的 3-5 个人）、做 onboarding、收集 bad case、快速迭代。面试里能说出「我怎么让客户的团队真的用起来」，直接对齐 JD 的 success 定义。
• 客户沟通的语言：JD 要求「communicate clearly with engineers, product teams, and customer stakeholders」——同一件事要对工程师讲实现、对产品讲 trade-off、对客户高管讲业务影响和风险。准备 2-3 个「同一技术决策，三种听众三种表达」的例子。
• 冲突处理：客户要求跳过 eval 直接上线、坚持用错误指标、数据不给权限——用量化证据（错误率、成本、延迟数据）换共识，给可接受的折中（分阶段上线、灰度 + 回滚、先上 guardrail 版本），把决策和风险写进文档。一味迎合或硬顶到底都会挂。
• 复盘与反馈闭环：每个项目结束要能说出：哪些指标达到了 / 没达到、bad case 怎么沉淀、什么经验回传给了产品 / 模型团队、下一个客户能复用什么（playbook、工具、building blocks——JD 原话：codify working patterns into tools, playbooks, or building blocks）。这条是 FDE 从「做项目」到「建能力」的分界。

7 / 14 / 30 天准备路线

按你距第一轮技术面的天数选路线。三个版本的共同原则：交付场景 + eval 表达永远优先，LLM workflow 与数据权限次之，最后两天只留 mock 和状态调整，不学新东西。和 Palantir 路线（decomposition / learning 优先）的差异在于：OpenAI 要额外投入 take-home 视频脚本的准备。

• 7 天（保下限）：Day 1 用「workflow mapping → hero workflow → measurable value → 2 周交付计划」做 2 个场景（医疗文档、客服工单）；Day 2 做 1 个 eval 表达练习：给客户场景定 benchmark + acceptance criteria + launch readiness，讲 3 分钟；Day 3-4 练 2 道全栈 coding（API 服务 + 前端调用），写可跑代码 + 关键路径测试；Day 5 打磨 2 个「模糊问题 → 原型 → 客户采用」项目案例 + 准备「为什么 FDE」动机；Day 6 完整 mock 一场交付场景 + 10 分钟 BQ；Day 7 状态调整，过 eval 四步和挂点清单。
• 14 天（补 LLM workflow 与数据权限）：在 7 天基础上，Day 8-9 做 2 个 LLM workflow 设计（agent vs workflow 取舍 + 工具 + 护栏 + prompt 注入防御）；Day 10-11 做 2 个数据接入方案（客户 VPC + PII 脱敏 + 权限过滤 + 降级路径），覆盖医疗 / 法律方向；Day 12 第一次 take-home 模拟（限时 48 小时，产出原型 + 文档 + defend 提纲）；Day 13-14 完整 mock 2 场（交付场景 + take-home defend 各一），录音回听。
• 30 天（加专项追问与完整 mock）：前 14 天按上面走，Day 15-21 针对 OpenAI 高频追问做专项：模型行为影响产品体验（幻觉、延迟抖动、成本）、eval 反馈到模型路线图、客户数据出境合规、adoption 失败案例，每个准备 3 分钟表达；Day 22-27 做 4 场完整 mock（覆盖全部环节，含 1 次 take-home + defend），每次复盘追问链；Day 28-30 状态调整、过挂点清单、准备 HM 轮的「为什么 OpenAI、为什么这个方向」深度表达。

和 Palantir FDE、SWE、AI Engineer 的差异

准备 OpenAI FDE 之前，先搞清楚它和 Palantir FDE、标准 SWE、AI Engineer 的差异，避免用错误的框架准备。完整对比见 FDE 角色页，Palantir 的流程信号与 Decomposition / Learning 见 Palantir FDE 面试。

• 和 Palantir FDE：Palantir 强调 decomposition（模糊目标拆到 P0 + KPI + 高管摘要）、learning round（陌生领域快速上手）和平台能力组合（Foundry / Gotham），公开样本流程更长（约 5 轮、3-4 周）；OpenAI 强调 AI 交付闭环（discovery → rollout）、eval 方法学（customer-specific benchmarks + launch readiness）和 take-home + 视频 walkthrough / 现场 defend，公开样本更紧凑（约 2-3 周）。两者的部署 / 场景轮考的是同一类能力（模糊问题 → 可交付），但 OpenAI 的题更偏 LLM 应用，Palantir 的题更偏数据平台与业务流程。
• 和 SWE：SWE 在内部平台做深度工程，面试以 OA、Coding、System Design 和独立 BQ 轮为主；OpenAI FDE 嵌入客户现场做 AI 交付，eval 和 adoption 是独立考点，BQ 嵌入每个技术轮。用纯刷题 + 系统设计思路准备 FDE，会在交付场景轮和 take-home 掉队。
• 和 AI Engineer：AI Engineer 聚焦 RAG、Agent、LLM serving 和 eval 的工程化，技术深度是主考核；OpenAI FDE 的 AI 能力是手段，重心在客户问题拆解、原型速度、数据权限合规和跨干系人沟通，AI 交付必须落到 production adoption。技术很强但没有客户交付叙事的人，在 OpenAI FDE 轮里要补「对业务结果负责」的证据。

FAQ：OpenAI FDE 面试高频问题

以下 5 个高频问题覆盖 OpenAI FDE 面试中最容易失分的点。答案给出的是面试中可复用的评分框架，不是 OpenAI 官方标准答案；每个问题都可以继续展开成 3-5 分钟的追问。