这张卡讲 FDE 存在的根本理由：为什么好技术总是差最后一公里。
核心拆解：最后一公里的三类阻力——数据（客户数据脏、散、权限碎）、流程（系统要嵌进的真实工作流远比演示复杂）、组织（人的习惯、考核与利益）。关键认知：这一段没有通用解，只能现场逐个解决，这正是 Forward Deployed Engineer（FDE）被发明出来的原因。大模型让能力通用了，但让能力落地的最后一公里依旧一步没少，甚至因预期升高而更难，演示与生产之间的落差只会更刺眼。
增量判断：国内语境再叠一层：私有化部署、内网限制与行业合规，让最后一公里更长。解法是双管齐下——工程侧用评测与工具复用降低单点成本，组织侧用拥护者与发起人推动系统采纳，让系统活到产生数据飞轮的那天。
行动建议：把你项目里卡得最久的一个问题归类到三种阻力之一，再决定该补数据、改流程还是做组织工作，归类对了，解法通常就近在眼前。
—— FDEChina编辑部 · 实战派
定义
最后一公里问题（Last-Mile Problem）指技术在实验室或演示环境已经成熟，进入真实客户场景时却遭遇数据、流程与组织阻力、难以完成落地交付的现象，是 Forward Deployed Engineer（FDE）这一角色存在的根本理由。
展开
最后一公里的阻力可归为三类：数据——客户的数据脏、散、权限碎，与公开数据的分布差距大；流程——系统必须嵌入的真实工作流远比演示复杂，异常与例外层出不穷；组织——人的使用习惯、绩效考核与部门利益都会抵消技术收益。关键认知是：这一段没有通用解，只能现场逐个解决，无法靠更好的模型或更全的产品文档自动消失——这正是 FDE 被创造出来的原因。大模型时代这个问题加剧而非缓解：能力通用了，落地的最后一公里一步没少，客户预期反而更高，对落地质量的容忍度更低。
解法要工程与组织双管齐下：工程侧用评测基线、工具与模板复用降低每个场景的边际成本；组织侧用高管发起人与拥护者用户推动采纳，让系统能活到产生数据飞轮的那天。国内语境还要叠加私有化部署、内网与合规约束，最后一公里更长，也因此更需要前置部署的工程力量。