FDE 的核心能力：工程师、产品经理、交付负责人三合一

FDE 难招，是因为它不是单一能力岗位。它要求一个人同时跨过工程、产品、交付和商业判断几个边界。任何一项能力缺失，都会让这个角色变形。

第一层是工程能力。FDE 里的 E 不是摆设。真正的 FDE 至少要理解系统怎么搭、数据怎么流、接口怎么接、权限怎么管、日志怎么看、模型输出怎么评估。不是每个 FDE 都必须是算法专家，但不能只会讲方案。如果完全不懂系统，就无法判断一个方案为什么卡在数据、权限、部署或稳定性上。

第二层是产品能力。FDE 要把客户的模糊表达拆成具体问题。客户说“提升效率”，他要追问哪个角色、哪个流程、哪个动作、当前耗时多少、错误代价是什么、系统输出给谁用。客户说“做一个 Agent”，他要判断这个 Agent 是问答型、流程型、审批型、分析型，还是根本不该做成 Agent。

第三层是交付能力。企业现场不是实验室。项目会遇到老系统、合规、安全、采购、部门协作、用户抗拒和临时变更。FDE 不能只在理想环境里做 Demo，它要能在约束里推进项目。它要知道什么时候坚持技术原则，什么时候顺应客户习惯，什么时候先做一个能跑的小闭环。

第四层是商业判断。不是所有问题都值得做。有些痛点是真的，但价值太小；有些价值很大，但数据和组织条件不成熟；有些客户预算充足，但没有真实业务负责人。FDE 要能判断项目是否值得投入，而不是把所有机会都接下来。

第五层是复用意识。FDE 不能只服务眼前客户。一个客户现场反复出现的集成问题，可能是产品连接器机会；多个客户都需要的评估方式，可能应该做成框架；某个行业反复出现的流程，可能应该沉淀成模板。没有复用意识，FDE 很快会变成人力交付。

很多产品经理懂业务，但不懂系统。很多工程师懂系统，但不懂客户。很多顾问懂表达，但不负责运行。很多交付人员懂项目，但没有产品化意识。FDE 的价值，就是把这些能力放到一个闭环里。

它不是要求每个人都成为全能选手，而是提醒团队：AI 落地需要复合型能力。真正能把项目做成的人，必须同时看见业务目标、技术路径、交付阻力和长期复用。

如果把 FDE 能力拆成训练路径，可以分三步。第一步，能看懂系统。知道前端、后端、数据库、API、权限、日志、部署、评估这些基本概念，能和工程师对话。第二步，能做小闭环。用低代码、自动化工具或 AI 编程工具做出一个能跑的小业务系统，而不是只写需求文档。第三步，能做复盘沉淀。每做完一个项目，都能写清楚问题定义、技术路径、指标变化、失败点和可复用资产。

这条路径对非技术人尤其重要。非技术人不一定一开始就成为生产级工程师，但可以先成为“懂系统的业务人”。他能比传统产品经理更靠近交付，也能比传统顾问更靠近系统。这类人未来会很吃香，因为他们能帮组织把 AI 从概念推进到真实流程。

对技术人来说，训练方向正好相反。不要只展示技术复杂度，要学会把技术结果翻译成业务结果。不是“我做了一个 RAG 系统”，而是“这个系统让客服查找答案的时间从 5 分钟降到 30 秒，并把高频问题沉淀成知识库更新流程”。

如果写成职业成长文章，这一篇可以直接变成“FDE 型人才能力模型”。每一层能力都配一个自测问题：工程能力，看你能不能把一个 API 调通并处理报错；产品能力，看你能不能把一句模糊需求拆成流程图；交付能力，看你能不能在客户约束下跑出最小版本；商业判断，看你敢不敢拒绝低价值项目；复用意识，看你项目结束后有没有沉淀模板。

FDE 型人才不是靠头衔证明的，而是靠闭环证明的。你能不能把一个问题从发现、定义、构建、上线、验证、复盘走完一遍，才是关键。