FDE 能力模型：工程、AI 应用、业务沟通、现场应变四层拆解

一份可以直接拿来给自己打分的能力清单。

四层拆解里最有工程含量的是第二层：多数团队把 AI 应用能力等同于「会用提示词」，真正拉开差距的是评测——能不能为业务场景定义量化指标、建立回归用例，决定了功能能不能从 Demo 走到生产。第三层的「双向翻译」同样被低估：FDE 的方案要同时向客户和自己的工程团队成立，缺一侧都会返工。

国内招聘口径常把 FDE 理解成「全栈加会沟通」，四层里最容易缺的是现场应变——它没法靠刷题补，只能在真实项目里积累。转岗前建议确认目标岗位是否提供有后援的现场环境，单兵作战式驻场对新手并不友好。

用文末雷达表给自己打一次分，先补最低的一层，三个月后复测；转岗准备期建议按「工程—评测—沟通」的顺序投入。

—— FDEChina编辑部 · 架构师视角

导语

公开可见的招聘信息与一线实践显示，FDE 的能力要求很少是单点的：既要能独立写生产代码，又要能听懂业务、在信息不完备的现场自主推进。新手指南第七节把 FDE 能力概括为四层，本篇逐层拆开——每层讲构成、自测问题与提升路径，文末给一张可以打分的雷达自检表。

四层的整体关系

四层不是并列的四个标签，而是有依存关系的结构：工程基本功是地基，AI 应用能力建立在工程能力之上，业务沟通决定方案是否成立，现场应变决定上述三层在混乱环境中能否正常发挥。单层突出、其他层塌陷的组合，在现场都比四层均衡但不出挑的组合更容易出问题。

第一层：工程基本功

构成：扎实的编程与调试能力、基本的系统设计能力、版本管理与测试习惯，能独立交付生产级代码。这一层决定交付下限——现场没有后援，代码质量会直接变成客户信任。

自测问题：脱离现成框架与同事支援，你能否独立完成一个带数据库与接口的小系统并部署上线？线上出问题时，你的第一反应是看日志定位，还是等别人来处理？

提升路径：以交付为导向补短板。完整做一个端到端小项目（含部署与监控），比刷题更接近现场要求；坚持给代码写最基础的测试，习惯会在大项目里还回来。

第二层：AI 应用能力

构成：理解大模型的能力边界与失效方式，熟悉提示工程、RAG、Agent 等常见范式的适用场景，以及把「效果好不好」变成可度量指标的评测方法。

自测问题：拿到一个新需求，你能否判断它该用提示词、RAG 还是微调来解决？你负责的 AI 功能上线前，有没有一套固定的评测用例可以回归？

提升路径：评测是普遍被低估的一环——先学会为业务场景定义 3 个量化指标并建立回归用例，再谈模型选型。阅读材料优先选模型厂商文档与工程博客里的一手复盘，尤其是写失败案例的那种。

第三层：业务沟通

构成：双向翻译能力——把模糊的业务诉求转成技术方案，把技术约束翻译回业务影响；还包括会前准备、纪要、预期管理这些朴素动作。

自测问题：业务方说「我们想要智能化」，你能否用三个追问把这句话变成可界定的需求？你能否不用术语，向客户解释清楚为什么某个方案做不了、代价是什么？

提升路径：每次客户沟通前写下「本次要澄清的三个问题」，会后 24 小时内发纪要；练习用客户的业务指标（成本、时长、差错率）描述技术方案的价值。

第四层：现场应变

构成：信息不完备时自主推进的判断力、预期与风险管理，以及计划被客户现场突发状况打乱后的重排能力。

自测问题：客户接口人突然换人、关键数据拿不到、演示前夜系统出问题——你能否在不升级求助的情况下给出应对方案，并让项目继续推进？

提升路径：事前为关键节点准备备选方案（数据拿不到怎么办、接口人不配合怎么办）；每次意外处理完写两行复盘，慢慢积累自己的应急预案库。

四层雷达自检表

按 1-5 分给自己打分（1=基本缺失，5=可独立带队），总分看均衡，最低分看优先级：

最低的一层就是下一步的投入方向：先补短板，再谈均衡。

小结与下一步

四层能力的稀缺性在叠加而非单项：工程与沟通两侧同时可用的人，在任何团队都是少数。看完自检表，建议接着读《FDE 项目生命周期：从需求发现到交付复盘的六个阶段》，看能力如何落到项目各阶段；正在权衡岗位方向的，可对照《FDE vs AI Engineer：客户现场与产品团队的两条路》；更多转型与面试材料见职业发展频道。

参考来源

• OpenAI、Anthropic、Palantir 招聘页面对 FDE 及相近岗位的公开职责描述：openai.com、anthropic.com、palantir.com；
• 四层划分、自测问题与提升路径为 FDEChina 根据公开资料与一线实践整理，供自检参考，不构成任何公司的岗位标准。