FDE到底要练什么：业务问题、工程边界，还是交付责任？

文章主旨：FDE的训练应围绕“交付证据”展开，把模糊需求收敛为有人使用、有人验收、有人接手的可运行系统，而不是只学习框架、工具或做演示。

关键要点：

1. FDE岗位职责覆盖从客户首次沟通到生产交付的全过程，业务理解与动手实现需在同一段工作中连接起来；公开岗位说明可作为参考，但不能当作所有企业统一的资格标准。
2. 理解需求要形成可执行约定，明确输入输出、业务动作、数据字段来源与含义、验收口径、责任人和人工处理边界，不能停留在“提升效率”“智能决策”等表述。
3. 文章以“关键零部件按时交付”岗位问题为例，将其缩成“找出需要跟进的订单”训练：先核准可确定字段和规则，用确定性逻辑做基线，再检验模型在文本理解等环节是否有帮助，并区分读权限与执行权限。
4. 演示之外要主动设计失败样本和评估集，如缺字段、编码不一致、权限受限、接口超时、重复请求；权限检查应放在数据获取和动作执行环节，评估结果应分项记录并保留独立验收集，离线通过不等于业务收益成立。
5. 成本要算到复核与维护，责任要按动作分清，企业需提供数据、业务负责人和接手条件；训练收尾应让另一位工程师独立跑通，形成问题约定与流程图、字段映射与最小实现、正反样本与验收记录、运行手册与复用说明等交接产物。

内容结构：

• 引言：以Palantir对Brian的早期访谈引出FDE的具体工作内容，提出关键问题：客户把说不清的问题交给你，能否变成有人使用、有人验收、有人接手的系统；由此提出FDE训练应围绕交付证据展开。
• 岗位说明里的责任，比工具清单更有用：介绍FDE含义及Palantir、Anthropic公开岗位说明中的职责与能力要求，强调业务理解与动手实现需在同一工作中衔接；需求要形成可执行约定；数据、AI、IT从业者转型应先判断自己在哪个环节缺证据。
• 拿“关键零部件按时交付”练一次：将Palantir岗位说明中的供应链问题缩成订单跟进训练，限定“帮助交付负责人找出需要跟进的订单”；建议建立订单号、订单行号、物料编码、承诺交付日期、实际到货日期和状态等字段并明确来源与含义；交付对照表说明原流程、系统替代步骤、确认人和人工处理情形；先核准字段规则，以确定性逻辑做基线，再检验模型；读权限与执行权限对应不同风险。
• 把演示里看不到的失败做出来：结合岗位说明和Brian访谈中的安全开发、访问控制、权限隐私、故障定位与稳定性监控要求，设计缺字段、编码不一致、部分数据权限、接口超时、重复请求等反例；权限检查不能只靠提示词；评估集要包含失败样本，分项记录对象字段、解释依据、权限遵守和人工接管情况，保留独立验收集，并检查错误说明是否可操作；离线检查通过后，还需回到同一任务比较查询、确认、复核和重复查证等流程成本。
• 账要算到复核与维护，企业也要给出条件：引用Databricks官方FDE介绍中客户业务结果、共同OKR和与研发共同扩展产品的描述，说明现场交付需要组织支撑；用同一口径比较原流程与新流程的数据接入、运行调用、人工复核、异常处置和维护成本；责任按业务、数据、系统、交付等动作分清；定制越深，越要提前谈规则归属、代码复用、需求范围和版本升级。
• 练习结束时，让别人接过来跑：引用Anthropic关于可重复部署模式和反馈产品工程团队的要求，以及Databricks对现场与研发反馈的强调；交接验收应让另一位工程师独立启动环境、检查样本、定位失败并尝试恢复，临时询问原作者之处即为交付包缺失信息；可按问题约定与流程图、字段映射与最小可运行实现、正反样本与验收记录、运行手册与复用说明逐轮推进；该训练顺序是方法建议，并非某家公司考试大纲。
• 结论：判断一个人是否接近FDE交付要求，可看他能否把开放问题收敛为可验收工作，并说明实现、例外和交接；企业是否采用该角色，应看是否愿意提供数据、业务负责人和接手条件，条件缺失时更换岗位名称不会让项目自动落地。

文章总结：FDE应以可交付、可验收、可接手的工程证据接受检验，个人需补齐交付链条中的缺环，企业也需提供相应组织条件，而不能依赖工具更新或岗位名称。