先给答案：多数 AI 项目卡住，不是模型不行，也不是缺工程师，是中间断了一环——没人同时看得懂业务、又能把判断落成可实施的方案。这类角色现在有了名字，叫 FDE（Forward Deployed Engineer，前沿部署工程师）。这篇讲清楚它是干什么的、为什么缺，以及多数企业其实不需要全职招一个。
为什么 AI 项目总卡在业务，而不是技术？
一个典型路径：企业买了工具或找了开发，Demo 做得出来，领导也认可，然后停在半路——接不进真实的数据和流程，业务部门不认，最后不了了之。
回头看，卡住的每一处都不是「代码写不出来」：是没人说得清这段流程的判断标准是什么，没人定得了 AI 的输出谁来验收、错了算谁的。技术团队问业务要需求，业务说不清；业务提想法，技术说做不了。项目死在两边之间，不死在任何一边。
这不是哪一方的错，是缺了一个把两边接起来的角色。
FDE 到底是干什么的？
FDE 是国外公司（Palantir 最早，现在主流 AI 公司都在设）养的一类人：不坐在自己公司写通用产品，而是进到客户的具体业务里——把流程拆开、把判断标准定下来、把方案立起来，再让工程跟上。名字里带「工程师」，但真正值钱的部分不是代码，是把一个模糊的业务问题翻译成可实施方案的那一步。
它和两个常见角色都不同：不像纯算法工程师只对模型负责，也不像传统咨询顾问交完 PPT 就走——FDE 要对「方案真的跑起来」负责到上线。
AI 项目的断层不在模型和代码之间，在业务判断和工程实施之间。FDE 补的就是这段断层。
把这件事拆开看：判断与实施，是两段活
我们自己的交付方式就按这个拆法写在了官网上：识度承担环节识别、方案设计、结果判断——AI 该进哪个环节、这段业务的输入和判断标准是什么、结果由谁验收；工程实施按项目组建或对接专业团队。为什么敢这么拆？因为前半段依赖的是对业务的理解，不是人头数；后半段是成熟的工程活，按项目组队比养一支固定团队更轻、也更诚实。
这条边界同时是个筛选器：如果一家服务商什么都接、承诺自己包圆从判断到开发的一切，你反而要小心——判断和实施混在一起卖，多半是按人天卖人力，而不是按结果卖方案。
多数企业不需要全职 FDE，先过三问
FDE 现在是稀缺岗位，薪酬被市场抬得很高。但稀缺不等于你该去抢一个。先自问三个问题：
- 这段流程说得清吗？说不清先别上 AI——先花小成本把流程和判断标准写下来，这件事不需要 FDE 级的人，需要的是业务负责人自己下场。
- 错了的代价有多大？代价低的环节，内部小步试就行；错了影响客户和钱的环节，才值得请专业判断介入。
- 结果谁验收？定不出验收人，说明这段业务的权责还没理顺，谁来实施都会烂尾。
三问过完，多数中小企业会发现：自己缺的不是那个天价的稀缺人，是先把业务判断写下来的那段工作——这段可以找外部判断介入，工程再单独组。
FDE 和传统实施顾问有什么区别？
传统顾问交方案就撤，FDE 对上线结果负责。企业采购时可以不管对方头衔叫什么，只盯一条：他管不管「真的跑起来」。
内部培养 FDE 靠谱吗？
方向对，但周期长，而且最好的培养材料是你自己的业务——让懂业务的人带着真实流程去学工具，比送人上速成课实在。急着推进的项目，判断段先借外力，培养并行。
怎么判断服务商有没有这个能力？
听他怎么谈你的业务：能先问清你的流程、判断标准和验收口径的，是干判断段的；上来就报价开发人天的，是卖人力的。我们写过一篇自己做还是找外部做，可以配着看。
如果手上有个停在半路的 AI 项目，或者正准备立项，预约一次适配沟通。我们拿你的业务过一遍「判断与实施」的分工：哪些环节你自己就能定，哪些值得专业判断先介入——先把断层补上，再谈动工。
← 返回识度洞察