FDE · 职业能力 · 企业AI落地
FDE到底要会什么？会写代码，只够你走到客户门口
一名FDE的工作，从识别值得解决的问题开始，到客户能够独立运行、判断和恢复系统才结束。
最近很多人问：想转FDE，到底该补哪些技能？
有人列模型、RAG、Agent、MCP和私有化部署；有人补产品、售前、咨询和项目管理。清单越写越长，最后像在招聘一个会写代码的CEO。
先给一个可能不太讨喜的答案。
会写代码，只够你走到客户门口。
客户愿意让系统进入生产，还要经过问题判断、业务翻译、范围控制、权限设计、效果评测、上线运维、员工采用和项目交接。
FDE不必成为每个领域最强的专家，但必须看得见整条链路，也能在断点出现时把合适的人拉进来。
所以，FDE的能力地图可以压成三层：方向判断、工程交付、组织采用。
第一层：先判断这件活值不值得做
FDE最容易被忽视的一项技能，是筛选问题。
客户说"想做全公司AI改造"，听起来预算很大。继续问几句，第一批用户是谁、数据在哪里、哪个部门愿意配合、做完怎么验收，可能没人能确认。
另一个团队只想把每天两小时的订单整理缩短到半小时，负责人愿意拿真实样本，也愿意每周参加测试。目标没有那么宏大，项目反而容易跑起来。
判断一个机会，可以先看四件事。
问题有没有持续产生代价
有人反复做、经常出错、响应太慢或已经影响收入，才值得投入。只在演示会上显得酷，通常撑不过第二个月。
内部有没有人对结果负责
FDE可以推动项目，无法长期代替业务负责人。没人维护资料、确认规则和处理异常，系统迟早会停。
能不能接触真实流程和数据
只看方案文档，得到的是标准流程。真实工作可能发生在群聊、个人表格和审批前的一通电话里。看不到这些绕路，设计出的系统会在现场撞墙。
第一阶段能不能在几周内验证
范围越大，责任越模糊。把目标收窄到一个岗位、一个环节和一个指标，团队才知道做到哪里算赢。
预算表达愿望，日常工作暴露准备度。选错客户或选错问题，后面的技术越强，损失越大。
沟通要变成工程输入
客户很容易说出想买什么，却很难一次讲清问题怎样发生。
"做一个AI客服"，可能对应三种完全不同的情况：重复问题太多、知识更新太慢，或者用户找不到正确入口。
三个项目都能做成聊天框，数据、风险、权限和验收方式却不一样。
FDE要把不同角色的话翻译到同一张工作图里：谁在什么时刻收到什么输入，打开哪个系统，根据哪些规则判断，遇到例外找谁，结果写到哪里。
AI可以整理访谈、比较不同角色的说法、拆出事实和待确认项。最终确认仍要回到有权负责的人。
项目记忆也要正式保存。原始材料、已确认事实、决策、风险、负责人和变更记录分开管理。信息只留在聊天群里，项目争议发生时，所有人都会拥有一个不同版本的"我记得"。
第二层：技术能力必须走到生产
算法、模型和代码是FDE的底座。生产环境还要求他同时关注知识、工具、权限、评测、发布和运维。
一名FDE未必亲自包办所有模块，至少要能做出端到端版本，也能判断故障落在哪一层。
做知识库，先处理错误的知识
同一份制度有多个版本、文档没有负责人、特殊客户价格混在公共资料里、扫描件解析后表头丢失。把这些内容直接放进知识库，模型回答得越流畅，风险越难被发现。
文档需要补齐版本、生效时间、负责人、访问权限和原文位置。查询精确编号时用结构化或关键词检索，寻找语义相近内容时再用向量检索。
回答必须带证据。资料不足、版本冲突或用户无权查看时，系统要敢于停下来。
做Agent，工具接通以后风险才浮出来
让模型查询客户、生成总结、调用写入接口，做个Demo并不难。
生产环境会继续追问：这次调用代表谁，能访问哪个租户，写入前是否审批，重复执行会不会写两次，出错能否追踪和撤销。
模型负责理解、提议和规划；确定性程序检查权限、参数和状态；高风险动作交给人确认。这套分工比"Agent能调多少工具"更值得关注。
选API还是本地部署，要看真实负载
"数据不出域"不能直接推出采购机器，"调用最强模型"也不能直接推出成本更低。
要拆开看数据敏感度、峰值并发、输入长度、延迟要求、容灾时间和运维能力。成本也要算完整：调用次数、长上下文、缓存、闲置容量、电力、升级、安全和人力。
最后比较的是每个合格任务花多少钱，而非一张显卡报价或一百万Token的单价。
上线门禁必须允许系统说"不行"
生产发布要锁定应用、模型、提示词、知识索引、工具和权限策略的版本，重新跑核心测试，并提前写好回滚目标。
"我刚才本地跑过"不能成为发布证据。
上线后还要看到质量、延迟、费用、工具调用和人工接管。用户报告错误时，团队能追到当时的模型、知识版本、引用证据和批准记录，才有机会快速修复。
第三层：上线之后，还要让组织接得住
系统部署完成，只代表技术工作到了一个节点。
员工不用新工具，原因可能很朴素：入口离原来的工作太远，多了一次复制粘贴；系统错过两次，信任没了；它给一线省了时间，却给主管增加了审核任务；也有人担心自己的经验进入系统后，岗位价值会变化。
培训因此不能只讲按钮和模型能力。不同角色要拿自己的真实任务练一遍，知道什么情况下可以采用建议，什么情况下要停下来，反馈交给谁处理。
业务专家还要参与评测。因为"什么叫答对"，往往掌握在一线人员手里。
客户接不住，交付就没有结束
项目验收后，客户遇到故障仍要在群里呼叫原工程师，这个项目只完成了安装。
交接至少要覆盖架构与数据流、部署与回滚、评测证据、权限边界、资料负责人、已知限制、事故手册和支持范围。
更可靠的办法，是让客户团队独立走一遍：发布一次，更新一次知识，处理一次模拟故障，再完成一次回滚。
FDE站在旁边观察，不抢键盘。
只有这样，藏在交接文档里的空白才会暴露出来：某条命令依赖个人电脑，某个账号还握在供应商手里，某项评测只有原工程师知道怎么解释。
客户能独立运行、判断和恢复系统，FDE才有资格离场。
做完一单，下一单应该轻一点
每个客户都从空白代码和空白文档开始，FDE很快会变成昂贵的驻场外包。
项目结束后，可沉淀的不只有客户代码。问题诊断方法、行业对象模型、连接器、评测结构、权限策略、发布检查和交接模板，都能成为下一次工作的底座。
这也是判断一名FDE是否成熟的一个办法。
他完成的项目越多，下一个相似项目应该越容易启动、越容易验收，也越少依赖他本人救火。
一张更实用的FDE自测表
如果准备转型，可以用下面七个问题检查自己。
1. 能否把模糊愿望写成一句可验收任务
写清岗位、业务环节、输入、判断、动作、指标和责任人。
2. 能否发现客户没有说出口的流程
走到现场，看群聊、表格、口头确认和例外处理怎样发生。
3. 能否独立做出端到端版本
从数据进入，到模型处理、工具调用、权限检查、结果展示，至少亲手跑通一遍。
4. 能否建立一套真实评测
测试正确答案、无答案、过期资料、权限越界和异常输入，而非只挑几个漂亮问题演示。
5. 能否设计发布、监控和回滚
系统要能上线，也要能发现错误、停下来并恢复。
6. 能否推动真实用户持续使用
把工具放进原有工作入口，让反馈进入下一版。
7. 能否把客户经验变成可复用资产
同一个坑不踩第二遍，同类客户不从零开始。
最后
FDE并不等于"什么都会的工程师"。
这份工作的难度，来自持续守住问题到结果之间的缝：商业目标有没有说清，业务流程有没有看全，系统能不能安全运行，员工愿不愿意使用，客户最终能不能独立接手。
AI让一个人可以覆盖更长的工作链。判断、责任和现场推进仍然落在人身上。
所以，FDE最稀缺的能力很难写成某个工具名称。
他得把一句模糊的"我们也想上AI"，一路做成一个有人使用、有人负责、可以验收、能够交接的生产系统。
做到这里，才算把活干完。
参考资料
你认为FDE最难补的是技术、业务判断，还是推动组织采用？欢迎在评论区聊聊。
— 完 —