过去两年我见过不止一个这样的 AI 项目模型选型没有问题训练数据也做了清洗测试集上的准确率看起来相当不错可是一放进真实业务立刻变得不可用。业务方说“这不是我们想要的”技术方说“我们已经做完了是你们没说明白”。两边都觉得自己没有错但项目最终还是失败了。问题通常不是模型不够强也不是算法不够新而是整个工作流从一开始就离问题现场太远了。行业里已经出现一种专门针对这个问题的解法把最懂技术、最懂产品、甚至最有决策权的人直接派到客户现场、业务一线站在问题发生的地方去理解问题、定义问题、解决问题。这个模式叫做 Forward Deployed。过去它只是少数公司的特殊打法而现在一个更值得注意的变化正在发生——被派到前线的不再只是工程师还有高管。1. 为什么 AI 项目最大的卡点不是模型而是“问题现场”1.1 一个典型的失败路径POC 很漂亮生产很糟糕很多 AI 项目都会经历一个相似的轨迹业务方提出一个需求技术团队开始做概念验证。POC 在可控数据集上表现不错管理层看到演示觉得“AI 真的能解决问题”。进入生产环境数据变了、场景变了、权限变了、业务规则变了。效果急剧下降模型开始产出明显错误的结论。技术团队和业务团队互相推责项目进入漫长的“调优期”。最后项目被搁置或者被冷处理。表面上看问题出在数据和模型。但真正的问题在更早的地方在做 POC 之前需求本身就没有被定义清楚。业务方通常只会描述目标不太会描述边界。技术方通常只关注输入输出不太关注业务流程。两边之间缺少了一个能同时理解“业务语言”和“技术语言”的角色而 Forward Deployed 模式的本质就是把这个角色放到离问题最近的地方。1.2 从“技术迁移”到“组织迁移”传统软件项目的交付逻辑是“迁移”把一套系统从一个环境部署到另一个环境。技术风险主要集中在上线那一刻。但 AI 项目不一样AI 项目是持续运行的它的输入是动态业务数据它的输出会反作用于真实决策。一旦上线它就不是一个静态系统而是一个需要持续反馈、持续校正的“有机体”。这个时候真正决定项目成败的往往不是算法性能而是组织是否愿意把关键人员放到业务现场去。技术迁移只需要一次部署流程组织迁移却需要改变人的工作位置、汇报关系和决策路径。因此我才会反复强调一个判断AI 落地难难的不是技术而是组织的“部署密度”——你派了多少真正懂业务、懂技术、有决策权的人到问题现场。1.3 三个方法判断问题出在现场还是技术层如果项目进展不顺利不要急着调参数先判断问题出在哪一层。如果你能清楚描述“输入是什么、期望输出是什么”但结果不对那大概率是技术问题属于数据、模型、特征或参数层的故障。如果你连“什么是对的”都说不清楚不同业务方各执一词那问题出现在现场定义环节技术团队调多少轮参数都没有用。如果解决方案会影响部门利益、资源分配、责任归属那它已经不是技术问题而是组织决策问题。这类问题只有在现场由拥有决策权的人介入才能推动。三个判断可以合并成一个最简单的排查顺序先定义“正确的输出”再讨论“错误的输出”。如果前一步没有完成后面所有优化都是空转。2. Forward Deployed 到底在解决什么从 FDE 到 FDX2.1 FDE 的起源和核心逻辑“Forward Deployed Engineer”这个概念并不是一个新鲜词。最早被广泛关注是因为 Palantir 在服务大型机构时采用了这种模式工程师不坐在总部写代码而是直接驻扎在客户现场和客户的一线业务人员坐在一起每天看真实数据、真实操作、真实卡点。这种模式的核心逻辑很简单需求不是坐在办公室里想出来的是到现场看出来的。问题不是靠文档传真的是靠共同工作发现的。解决方案不是一次性交付的是和客户一起迭代出来的。用一句话概括先把人放到问题发生的地方再让解决方案自然生长出来。后来很多 AI 公司也引入这个打法并发扬光大为向客户派驻大模型应用工程师或者解决方案架构师帮助他们调整提示词、微调模型、改造工作流。类似的岗位名称有 Forward Deployed AI Engineer也有叫 Solution Architect 或 AI Implementation Engineer 的职责大同小异。但国内很多团队对 Forward Deployed 的理解仍然停留在“技术支持去现场解决部署问题”的层面。实际上这个模式的想象空间远不止部署。2.2 工程师到现场解决的是“能不能做”而不是“该不该做”工程师被派到现场确实能解决很多技术问题环境差异、数据质量、模型性能、系统对接。这些都属于“能不能做”的范畴。但 AI 项目会牵涉到更多“该不该做”的问题这个方案会影响某个部门的原有工作流程该不该改这个功能需要复用另一条业务线的数据该不该申请这个项目需要重新分配预算和人手该不该签字这些问题现场工程师没有权限回答。就算他发现了问题也只能把问题带回总部走立项、评审、批复流程。等流程走完现场情况早就变了。如果你经历过 AI 项目落地你一定会遇到这种情况方案在技术上完全可行但推进不下去。瓶颈不在技术而在决策链路太长。这时候就需要一个能现场拍板、现场协调资源、现场承担责任的人。2.3 FDX高管到现场解决的是权限、资源和组织流程“Forward Deployed Executives”——前哨部署高管——指的就是把决策链路上的关键人从总部办公室搬到项目现场。它不是让高管去现场视察不是去开会、剪彩、握手而是让高管真正在客户现场工作几个星期或几个月参与需求讨论、资源协调、流程重建。为什么这可能是“下一个十亿美元级的解锁点”原因很直接过去十年的 AI 技术突破解决的是“模型能做什么”的问题未来十年的 AI 商业化落地要解决的是“组织允许 AI 做什么”的问题。前者的主角是科学家和工程师后者的主角是能在现场拍板的经营者。一个项目如果既有技术可行性又有商业价值却因为组织流程而搁浅问题一定出在“没有合适的人在合适的层级把障碍搬开”。FDX 就是干这件事的。注意FDX 不等于“高管卖面子”。高管到现场不是刷脸而是把业务流程中的决策点前置让“发现问题”和“解决资源问题”发生在同一个时间窗口。3. Forward Deployed 真正改变的三层东西3.1 第一层从“用户提需求”变成“共同看见问题”传统项目最常见的问题是“需求传递失真”。业务方表达一个模糊的期望产品经理把它转述成需求文档技术负责人再转译成方案。每经过一次转译信息就会衰减一次。Forward Deployed 模式试图绕开这个链条。技术人员直接到业务现场观察真实操作高管直接参与核心用户访谈。大家看的不是同一个文档而是同一个实际场景。我在实践中经常发现只要让技术团队和业务团队在同一个屋里连续工作三天很多“需求分歧”会自动消失。不是因为他们学会了沟通而是因为他们看见了同一个问题有了共同的参照物。这就是 Forward Deployed 的第一层价值它不是提升沟通效率而是消除“翻译”这个中间环节。3.2 第二层从“项目制交付”变成“工作流重建”很多 AI 项目尤其是基于大模型的应用都会被当成“项目”来管理启动、开发、测试、上线、验收、结束。但这个思维本身就错了。大模型应用天然需要持续反馈。数据会变化用户会提出新问题业务规则会调整模型会失效。它更像一个持续运行的运营系统而不是一个有明确终点的工程项目。如果把大模型应用当成一次性项目去交付你会在上线后半年内发现准确率下滑、用户流失、业务方不再买单。原因是没有人持续在现场维护。Forward Deployed 模式把这个问题掰回来了技术人员不是交付完就撤而是持续驻扎持续观察模型在真实业务里的表现持续调整。它不是项目制而是“伙伴制”。这和现在大家讨论 AI Agent、AI 工作流重构是同一件事的两面。AI Agent 的能力上限不取决于模型多强而取决于你有没有把真实工作流拆到足够细让 Agent 能稳定执行。拆工作流这件事只有在现场才做得准。3.3 第三层从“工程师个人能力”变成“组织的决策密度”一个 AI 项目要走通通常需要三种决策技术决策模型选型、参数设置、系统架构。业务决策这个业务规则是否合理、流程是否调整。资源决策预算、人力、数据权限、跨部门协同。传统组织里这三种决策分散在不同层级、不同部门。技术决策在中后台业务决策在前台资源决策在高层。真正到项目落地时很难凑齐。Forward Deployed Executives 解决的就是这个错位。高管到现场不是替代技术人员也不是替代业务人员而是把原本需要十天才能完成的跨层级决策压缩到一天甚至几小时内。这种能力很难量化却直接决定了项目是推进还是停滞。从行业格局看谁先把这套打法固化下来谁就先拥有“快速把 AI 方案插进客户业务流”的组织能力。这种能力比模型参数更能形成壁垒。4. 如果你想尝试 Forward Deployed 模式该怎么落地4.1 五个判断标准什么项目真正需要 FDX不是所有项目都需要前哨部署高管。刚起步的探索型团队可以先从 FDE 开始。我认为可以在下面这几类项目里考虑 FDX场景技术型交付Forward Deployed需求明确度需求已经写清楚需求本身存在大量模糊地带数据环境数据已经整理好数据分散在多个系统、质量参差不齐决策周期客户方有统一接口人涉及多个部门、需要层层协调上线节奏上线即结束需要持续迭代、持续优化风险容忍度失败影响可控失败会影响核心业务必须现场实时纠偏简单说只要同时满足“需求模糊、数据分散、跨部门、上线只是开始”这四个特征就值得把关键决策人放到现场。4.2 五个执行步骤从试点到常态化第一步选对现场。不要贪多先挑一个业务复杂度高、反馈周期短、客户意愿强的场景试水。最好这个场景还带有“行业标杆”效应一旦做成能复制到其他客户。第二步明确现场的人。FDX 不是派一个人去而是组一个小型“前哨小组”成员至少包括一个懂业务的人、一个懂技术的人、一个能做资源决策的人。三个人可以不是全职驻场但在关键阶段必须能随时出现在现场。第三步设定现场目标。现场目标不要写“提升效率”“优化体验”要写得足够具体比如“在两周内完成现有数据流梳理识别最多三个高价值 AI 介入点”或者“用一条真实业务线跑通整套方案验证可行性”。第四步形成高频反馈闭环。现场团队至少每天同步一次今天看见了什么问题需要什么支持哪些决策被延迟了谁来推动。决策问题必须在当天上报给有权限的人不能拖。第五步沉淀可复用资产。每次现场任务结束后把问题和解决方案沉淀成模板、清单、代码库或提示词库。Forward Deployed 的价值在于它不只是解决当下客户的问题还把一个行业的共性问题抽象成可复用的资产。注意不要一上来就把 FDX 当成常态机制先做一次有边界的试点跑通后再扩大。否则很容易变成“高管出差”而不是“组织打法”。4.3 现场排查四个最容易卡住的地方即使人员到位项目还是可能卡住。这时按下面顺序排查先排查信息输入。现场团队是否真的拿到了完整数据流有没有信息在客户内部的不同部门之间被“选择性”传递再排查业务规则。你以为的“正常流程”和现场的实际操作是否一致很多系统逻辑是正确的但现场人员用“线下方式”绕过系统直接把规则搞变了。接着排查权限和资源。项目有没有被某个关键环节卡住比如数据权限没批、合规没有确认、跨部门接口人迟迟不回复。最后排查目标一致性。客户方的高层和技术团队是不是在“什么是成功”这件事上没有对齐如果目标是错位的现场再努力也会返工。四个排查点对应四个结论信息流、业务流、决策流、目标流。哪个环节断裂就补哪个环节。5. 边界与反思它不是万能药也不是下一个风口噱头5.1 这个模式适合谁不适合谁适合 Forward Deployed 模式的团队通常有以下特征产品需要深度嵌入客户业务流程而不是标准化即插即用。客户需求复杂AI 的价值只能靠现场发现。项目周期足够长支持“先派现场、再谈规模化”的打法。公司有足够的毛利或战略动机愿意为高成本人力买单。不适合的场景同样清晰如果你的产品是标准化工具用户打开就能用做 Forward Deployed 反而会拖慢增长。如果你还在探索 PMF业务模式本身还没定先不要去客户现场铺量。如果客户不愿为咨询式服务付费只想买一个“东西”那这个模式也很难落地除非你把它当作进入行业核心场景的战略投资。从成本角度看Forward Deployed 模式很贵。工程师本来就贵高管更贵。把人从总部挪到现场并不是一个省钱的方案。它真正的价值是省时间——省掉需求来回确认的时间、跨部门扯皮的时间、方案推倒重来的时间。一个判断做对了省下的钱远远超过人力成本。一个有经验的团队会这样用钱把最贵的人放在最容易放大判断价值的阶段。模型可以靠 GPU 加速业务理解不能靠算力加速。5.2 三个容易误判的地方第一个误判把 FDX 当作“大客户销售”觉得本质上是去搞关系。实际上FDX 的核心是重新设计工作流关系只是衍生品。第二个误判认为只要人到了现场项目就能成功。现场的失败概率同样很高。区别在于如果有人在现场失败会被更早发现复盘会更有依据。但“看见问题”和“解决问题”之间还隔着真正的方案能力。第三个误判把 FDE 和 FDX 当成完全不同的东西。我理解它们是渐进关系。FDE 解决技术层交付问题FDX 再往上一层解决组织层决策问题。真正成熟的现场团队往往是先有人能解决技术问题再逐渐具备组织协调和业务重构的能力。5.3 回到判断AI 项目的下一场竞赛是什么过去两年很多团队在追逐同一个目标把模型做得更大、更快、更强。这是模型能力的竞赛。但从落地角度看模型能力不再是唯一瓶颈。你会看到越来越多的 AI 公司开始重视工程化、Agent 工作流、私有化部署、一体机方案这些都是为了让 AI 能真正进入生产环境。而 Forward Deployed Executives 这个方向的出现意味着赛道可能正在切换。下一个竞争维度不再是谁的模型跑分高而是谁能更快、更准确地把 AI 塞进一个既有组织的真实运转过程中。这个能力依赖的不是单一技术突破而是组织设计、流程设计和人才配置。如果把 AI 落地看作一场持续战争那么前哨部署就是把侦察兵、作战参谋和前线指挥官同时放到战壕里。真正重要的是前线指挥官能当场决策而不是每隔几天发一封邮件回总部请示。这个模式不会适合所有人但我确信一点走在行业前面的人不是坐在办公室里画模型架构图的人而是愿意跑到一线和真实问题待在一起的人。如果你正在做 AI 项目而它恰恰卡在“业务说不清、技术推不动、资源批不下来”的泥潭里我的建议很简单停掉远程会议选一个现场派最合适的两个人过去住两周看看会发生什么。很多问题的答案不在文档里就在现场。