FDE · 企业AI落地 · 人才配置
最强AI工程师，不一定是最好的FDE
把顶尖技术人才直接派到客户现场，看起来是对项目最大的重视。可如果企业没有为现场工作重新设计角色，这个人很可能既解决不了组织问题，也没有机会发挥技术价值。
很多AI公司遇到重点客户时，会做一个看起来很稳妥的决定：把最强的工程师派过去。
理由也很充分。模型要调，数据要接，系统要上线，现场还会不断冒出意外。项目这么重要，当然应该让技术最好的人顶上。
问题是，客户现场最先考验的往往不是技术。
业务负责人说“先做个知识库”，可能只是想缓解老板的催促；部门说“数据没有问题”，也许只是没人愿意承认口径冲突；一线员工嘴上配合，心里却担心系统上线后自己的岗位被削弱。
代码不会故意隐瞒前提，组织会。
于是，最擅长把明确问题做对的人，被放进了一个连问题都不能直接说清楚的环境。很多FDE项目的麻烦，就从这里开始。
工程师处理“对错”，现场更多时候处理“利害”
优秀AI工程师的训练方式，是尽量消除模糊。
输入是什么，约束是什么，结果怎样验证，异常如何复现。接口有契约，模型有评测，代码能测试。就算暂时没有答案，问题本身也应该被描述清楚。
客户现场却经常反着来。
同一句“这个功能很重要”，销售可能指成交，运营可能指少返工，IT关心权限和稳定性，管理层只想在下次汇报前看到进展。每个人说的都没错，但他们并不在回答同一个问题。
FDE必须识别这些差异。他要知道谁掌握真实数据，谁能决定流程，谁承担系统出错后的责任，谁表面支持却没有动力配合。
这类工作很少有标准答案。你得到的通常是一组彼此冲突、还会随项目进展变化的条件。
技术能力当然重要，但它不能自动长成组织判断力。会写最稳定的Agent，不等于会让五个利益不同的部门同意一套验收标准。
一个很贵的误会：把FDE写成“全能工程师”
不少公司的FDE岗位，像是把半张组织架构压缩进一个人。
他要懂模型和数据，能写生产代码；也要做需求访谈、项目管理、方案汇报、跨部门协调，最好还懂采购、安全和行业规则。客户不配合时，他要推进；系统出问题时，他要兜底；结果不明显时，他还要解释ROI。
这样的招聘要求看起来是在提高门槛，实际是在掩盖角色设计的缺失。
公司没有明确谁负责问题定义，便让工程师自己去问；没有客户侧负责人，便让工程师自己协调；没有验收口径，便让工程师一边开发一边猜。
最后暴露出来的，往往是一条很消耗人的链路：
需求没有问透，技术团队只能用代码填空。做得越多，客户越容易觉得“这不是我要的”。工程师继续加功能、补兜底，现场关系却越来越僵。项目挫败感不断积累，顶尖人才开始怀疑自己为什么每天都在开会、催资料、解释边界。
等到人离开、项目停摆，双方往往各有一套结论：客户觉得AI公司不懂业务，AI公司觉得客户需求总在变。
两边都说到了现象，没有碰到角色错配这个源头。
更稳的配置，是让两种能力共同到场
FDE并不适合被设计成一个孤胆英雄。更实用的做法，是把现场交付拆成两个清楚的责任中心。
第一位是现场负责人。他不一定写最多的代码，但要对问题定义负责。
他需要跟着真实任务走一遍，找出决策者、使用者、数据负责人和风险承担者；把“想做一个Agent”拆成具体工作；确认哪些冲突需要管理层拍板；把验收从一句“效果要好”变成双方能复核的标准。
第二位是技术骨干。他对系统可行性和生产质量负责。
他判断数据是否够用，模型能力是否匹配，接口能不能接，错误能否被发现，人工接管和回滚怎样设计。面对不合理的准确率、周期或自动化要求，他必须有权说“不”，并给出验证办法。
两个人不是前台与后台的简单分工。他们要共同参加问题定义、方案取舍和最终验收。现场负责人不能替技术承诺，技术骨干也不能绕过现场关系直接猜需求。
如果项目规模较小，这两个角色可以由同一个人承担。但公司仍然要把两类责任写清楚，并提供客户侧业务负责人的授权。否则，“一人兼任”很容易滑回“一人背锅”。
选FDE，不要只看他会多少技术名词
判断一个人是否适合现场交付，可以分别看两组证据。
技术侧要看：他能否把模糊目标变成可测试的系统，能否区分模型错误、数据问题和流程问题，能否设计权限、审计、人工接管与回滚。
现场侧则要看：他能否在别人只讲方案时追问最近一次真实任务，能否从客气的表达里识别尚未解决的分歧，能否把让步变成有条件的交换，能否在没有证据时拒绝随口承诺。
还有一个经常被忽略的指标：他能否把现场经验带回产品。
如果每次驻场都从头救火，再优秀的FDE也只是昂贵的人肉补丁。项目结束后，错误类型有没有进入评测，通用流程有没有变成组件，下一位客户的交付成本有没有下降，这些才决定公司有没有留下能力。
老板要设计的，是一套交付关系
把最强工程师派去现场，并不能替代管理层应该做的决定。
项目为什么做，谁对业务结果负责，哪些部门必须配合，哪些流程允许改变，系统错了由谁接管，这些问题需要客户和AI公司共同确认。
工程师可以把系统做对，却不能靠个人情商修复一套没有授权、没有边界、也没有共同目标的合作关系。
所以，企业AI项目很难只靠“技术、产品或人”中的某一个因素。更准确的说法是：让合适的人承担合适的责任，再用技术把这套责任关系落实进系统。
最强AI工程师当然应该接近客户，但不该被独自扔进现场的迷宫。
否则，公司以为自己派出了王牌，最后消耗掉的恰恰是王牌。
你见过的AI项目里，最难处理的是技术问题，还是那些没人愿意说透的关系问题？
完