FDE 面试不是懂模型就行：客户现场、系统判断和交付怎么讲

面试官给你一句模糊需求：“客户想把 AI 接进客服流程，六周内看到价值。”如果你马上开始讲模型、RAG 和 Agent，下一问往往就会把答案打穿：数据能不能出域？谁对错误建议负责？现有工单系统怎么接？客服根本不用怎么办？

FDE 的难点不只是把系统做出来，而是把客户现场的模糊问题变成能上线、能被采用、能维护的交付。本文以 OpenAI 在 2025-08-06、2026-02-13 和 2026-07-10 发布的三个相关职位作为单一雇主样本，不代表行业通用定义、级别或统一面试流程。

客户说“做个 AI 功能”时，你先问什么

第一步不是选模型，而是把需求从口号压到工作流。谁在什么时点完成什么任务；现在最慢或最贵的一步是什么；错误会造成什么后果；客户如何判断六周后值得继续。

可以按四层追问。业务层确认目标与负责人；用户层确认真实操作者和当前替代方案；系统层确认数据、接口、权限和延迟；交付层确认上线窗口、验收指标和退出条件。

例如“做客服 Agent”至少要问：是给坐席建议还是自动回复；哪些客户数据可以进入模型；高风险投诉是否必须人工确认；成功看平均处理时长、一次解决率，还是纠正负担。模型名称在这些边界之后才有意义。

从现场约束到可交付系统，要有完整证据链

强项目故事不是“我和客户沟通后上线了模型”，而是能还原一条决策链：怎样发现问题；比较过哪些方案；哪些约束改变了设计；你亲自负责什么；如何灰度、监控和回滚；用户是否持续采用；反馈怎样进入下一版。

OpenAI 的三个职位样本分别覆盖 FDE、FDE 组织内的平台工程与技术部署负责人，支持候选人围绕客户上下文、平台集成、生产交付、部署 ownership 和反馈闭环准备证据。它们不能证明其他公司也有相同职责组合。

准备时为每个项目写七个节点：目标、用户、约束、选择、交付、采用、复盘。任何数字都要能说明口径；任何“我们”都要能拆出你的决定与产物。Enterprise AI Rollout 面试指南可以帮助你补齐采用和变更管理，但不要照搬其中的假设到目标岗位。

集成、安全和运维决定方案能不能落地

客户现场通常已有身份、权限、数据仓库、工单、CRM、日志和审批系统。FDE 不能把这些当作“平台团队之后会处理”的背景噪声。

系统题里应主动说明数据从哪里来、以什么权限访问、写回哪些系统、失败时怎样降级、谁可以查看日志、敏感字段怎样处理。对于 Agent，还要说明工具权限、不可逆动作、人工确认与审计记录。

面试官可能追问：“如果客户不允许数据离开区域怎么办？”“第三方 API 每分钟限流怎么办？”“模型输出错误但接口已经写入怎么办？”强回答不会承诺零风险，而会给出边界、监控、停止条件和恢复路径。

需求变、数据脏、用户不用时，怎样继续推进

真实交付很少按最初方案前进。客户可能在第二周改变成功标准，历史数据缺字段，安全评审延后，试点用户继续使用旧流程。只讲理想架构，会让项目像实验室作业。

面对需求变化，先区分目标是否变了，还是实现偏好变了。目标没变，就保留验收指标，重新比较范围；目标变了，则重新确认 owner、时间和不做什么。面对脏数据，不要先承诺“清洗一下”，而要量化缺失、定义可用下限、建立人工兜底并暴露不确定性。

面对低采用，先检查工作流是否真的减少负担，再看 onboarding、权限、延迟和信任。不能把用户不用简单归因于“抗拒变化”。客户交付的核心是找到可验证阻力并调整，而不是守住最初 Demo。

只讲模型指标，为什么很容易被追问打穿

离线准确率、召回率或评测得分可以证明一部分系统能力，却不能证明生产价值。客户可能更关心端到端完成率、人工纠正负担、响应时间、升级率、故障恢复和重复使用。

一个强回答会把指标分三层：模型质量说明输出是否达到基本门槛；工作流指标说明任务是否更快或更稳；业务与采用指标说明用户是否持续使用并产生预期结果。三层之间要有因果假设，而不是把好看的数字并排念完。

如果客户信任下降，也不能只说“再提升模型”。AI 招聘信任差距候选人指南展示了不同角色如何用不同证据评价 AI；FDE 同样需要把内部效率和最终用户风险放在一张决策图里。

现场案例题先定 owner，再给两阶段方案

遇到模糊案例，不要直接给大架构。先复述目标与未知项，明确谁对业务结果、技术上线、安全审批和用户采用负责。随后提出一个受限试点与一个扩展条件。

第一阶段只覆盖价值清楚、错误可恢复的窄工作流，保留人工确认，接入必要日志，并定义停止条件。第二阶段必须由证据触发：达到质量门槛、纠正负担可接受、关键用户持续使用、安全评审通过，才扩大数据、用户或自动化权限。

面试官继续追问时，用约束驱动调整。例如时间减半，就缩小范围而不是删除验证；数据不能出域，就改变部署或处理边界；客户要求全自动，就说明不可逆风险、审批责任与渐进授权。这样的答案体现判断，而不是背架构图。

把项目整理成面试官能核验的交付包

准备三类材料。第一类是客户问题卡：原工作流、用户、成功标准、关键约束。第二类是系统决策卡：方案比较、集成边界、安全取舍、回滚。第三类是交付证据卡：上线范围、采用、故障、修正和客户反馈。

每个故事都练四个追问：“为什么先做这个？”“你个人决定了什么？”“最严重失败是什么？”“客户反馈怎样改变产品或平台？”不要编造客户名、合同金额或保密数据，必要时用范围和匿名描述保持真实性。

使用 Interview AiBox 做模拟时，可以在核心功能使用指南中建立项目事实与追问练习。它不能替你生成真实交付经历，也不能预测目标公司的面试轮次。职位说明、招聘联系人和你自己的项目证据才是准备边界。

一段可复述的 FDE 回答应该怎么收口

可以用五句话收住项目：客户要完成什么工作；最大约束是什么；你为何选择当前方案；怎样安全上线并验证采用；反馈怎样进入下一轮。

例如：“客户想让客服更快定位退款原因，但数据不能离开现有区域，且错误建议必须由坐席确认。我没有先做自动回复，而是把检索和建议接入现有工单侧栏，用权限隔离与引用证据降低误用。首批只覆盖两类高频问题，以纠正率和处理时长作为扩展门槛。试点发现术语映射比模型选择更影响采用，因此我把反馈回路改成每周审核错配词，再决定是否扩大自动化。”

这段话没有假装存在通用 FDE 模板，却同时给出客户、系统、风险、交付与反馈。面试官再追问哪一层，你都有真实证据继续展开。