2026-07-19

FDE不是先写代码：为什么AI落地的第一步，应该是手动

87%的企业启动了AI项目，但真正落地的不到12%。差距不在模型能力，在推进顺序——大多数团队一上来就建自动化系统，跳过了最关键的半人工验证阶段。FDE（Forward Deployed Engineer）三步法的核心洞察：先手动跑通流程，用3个独立信号确认方向，最后再建工具。做反了，大概率失败。

全球87%的企业已经启动了AI工作流项目，但真正实现规模化落地的，不到12%。

这两个数字摆在一起，中间差了75个百分点。不是缺模型，不是缺工具，2026年的AI基础设施比两年前强了不止一个量级。那问题出在哪？

一种被反复验证的解释是：顺序做反了。


绝大多数团队做AI落地的路径是：识别一个业务场景 → 选模型/搭工作流 → 建SaaS或CLI工具 → 推给一线用。看起来合理，但这一步跳到"建工具"的动作，恰恰是失败率最高的那个节点。

FDE（Forward Deployed Engineer）这个概念在2025-2026年快速扩散，OpenAI成立了FDE公司Tomoro，Anthropic与高盛、黑石联手成立AI服务公司，上海甚至启动了全国首个FDE专项培训班。但概念热归热，真正把FDE做对的人，遵循的是一套反直觉的顺序。

自动化先行的幻觉

工业界有两个经典翻车案例。

一个团队做了N个版本的AI视觉检测系统：支持切换型号、云端训练、人工调参，功能列表拉得很长。交付给客户后，客户说了一句话："我们只要准确率100%。"之前所有高大上的功能，在这个要求面前全部失效。

另一个团队把样机做得灯光闪烁、运动机构眼花缭乱，拿到产线上根本跑不动——不是性能不够，是产线的真实环境里有太多边界条件，实验室里根本模拟不出来。

这两个案例指向同一个问题：在没搞清楚业务究竟需要什么之前，写的每一行代码都可能是错的。

WPS社区论坛上有个更具体的版本：用户建了一个自动化流程，前几天运行正常，之后持续失败，但手动执行每次都成功。这说明自动化缺的不是功能，是对边界条件和环境变化的鲁棒性——而这些边界条件，恰恰只有在手动跑通流程的过程中才会暴露出来。

"不了解业务流程就贸然自动化，反而是幻觉。"这句话不是哲学感慨，而是工程事实。业务流程里的细节——异常分支、人工判断节点、上下游系统的隐性依赖——不亲手走一遍，靠PRD和需求文档是覆盖不到的。

三步法：不是慢就是快，是顺序错了力气就白费

FDE实践者总结了一套三步节奏，每一步对应一个月的周期，但时间的绝对值不重要，重要的是次序不能乱。

**第一步：半人工跑通流程。**

不写代码，不搭系统。人模拟Agent的行为，把整个业务流程从头到尾走一遍。遇到判断点就自己做判断，遇到数据缺口就手动补数据，遇到异常就记录异常。这一步的目标是搞清楚"这件事到底是怎么做的"，而不是"我能不能自动化它"。

**第二步：用三个独立信号确认方向。**

这是最容易踩坑的一步。很多人以为"信号"就是同一个指标看三次，或者让三个Agent跑同一段数据得出相似结论。这不是验证，这是自我欺骗。

多份答案一致不等于多份独立证据一致。三个Agent读的是同一段日志、同一段代码、同一份业务描述，它们得出相似结论不奇怪——它们只是在同一条信息缺失上给了三种表述略有不同的猜测。

真正的交叉验证是：让不同证据类型互相印证。代码路径是否支持假设的流程？运行日志里有没有对应的执行记录？配置和部署版本是否匹配？最近一次变更是否引入了新的变量？只有当代码显示有异步刷新路径、日志显示刷新事件没有消费、配置显示消费者实例仍用旧版本——这三条不同维度的证据同时指向同一个结论，才算"三个同方向信号"。

**第三步：建SaaS/CLI自动化。**

只有在前两步都验证通过后，才进入自动化。这时候编写的每一行代码，背后都有真实的业务流程做支撑，清楚哪些异常需要兜底、哪些边界需要处理、哪些判断不适合交给模型。

三步法的核心逻辑不是"慢工出细活"，而是一个更简单的工程原则：不可能自动化一个自身都未跑通过的东西。


这个原则不只属于FDE

这个"先手动验证，再自动化"的逻辑，在不同领域反复出现。

Zappos创始人Nick Swinmurn在1999年验证"人愿不愿意在网上买鞋"这个假设时，没有建电商网站，没有库存系统。他直接去本地鞋店拍鞋的照片，放到网上。有人下单，就去店里买来寄出去。跑通了——然后才有了后来被亚马逊12亿美元收购的Zappos。在AI产品开发中，这个方法有一个专有名字叫Wizard of Oz测试法——用人在后台模拟AI行为，验证用户需求和交互模式后，再用模型替代。本质就是FDE三步法的第一阶段。

量化交易圈有一句行话："手动交易和量化交易完全是两套逻辑。"实操者的经验是：策略构想（手动验证）→ Python脚本半自动辅助分析（人工确认下单）→ 全自动执行。直接跳到全自动的，往往踩了一堆本可避免的坑。

上海识渊科技的FDE团队提供了一个工业场景版本：消费电子产线换线调机，型号一换工程师要折腾两三个小时。FDE团队白天在产线旁采集异常样本，晚上回实验室迭代模型——半人工循环了几个月，最终把时间压缩到55秒，换产型号从单日5款扩展到近300款。

摩根士丹利引入AI辅助资产顾问时，技术上不过是一套RAG（检索增强生成）方案。但真正的难点不是技术——是顾问们不信任这个"黑盒子"。FDE团队蹲在业务一线反复沟通、演示、调整，用连续100天每日站会的耐心建立信任。信任建立之后，AI建议才被真正执行。

这两个案例说明同一件事：FDE的核心能力不是工程，是在真实业务环境里反复摩擦出正确的方向。自动化只是最后一步的输出格式。

不要用"三个Agent都说对"骗自己

回到那个最容易自欺的环节：信号验证。

掘金上有一篇写得很直白的文章，标题叫《AI同时跑3个任务时，新人最容易误判》。核心观点一句话：让不同Agent验证不同类型的证据，而不是让多个Agent对同一段信息发表意见。

证据矩阵的威力在于异质性。代码表明路径存在，日志显示路径没被触发，配置显示版本不匹配——这三条信息来自三个完全不同的信源，但它们交汇在同一点上时，形成的判断置信度远高于"三个Agent都认为有问题"。

这才是FDE方法论里"三个同方向信号"的真正含义：不是同一种信号看三次，是三种不同类型的证据都指向同一个方向。


不是"别自动化"，是"别第一个动作就自动化"

这篇文章不是在反对自动化。FDE三步法的终点恰恰是SaaS和CLI——只是它把自动化放在了第三步，而不是第一步。

全球95%的企业AI导入以失败告终。95%不是一个小数字，它说明这件事的主流做法大概率有问题。如果把失败归因于"模型不够好""数据不够多""预算不够大"，那永远找不到真正的原因。但若愿意审视自己的推进顺序——是不是跳过了手动验证直接奔向了系统搭建——答案可能就在那里。

半人工跑通，不是效率低，是在为后面的自动化买保险。