【黄啊码】几万块的单子烂尾后，我发现工程师做 FDE 根本是条死路

起初是一家头部快消品牌的电商运营团队主动找上门，痛点提得直截了当：大促期间每天要处理上千组投放素材和评论区反馈，希望用 AI 自动提炼不同渠道的用户痛点，一键生成千人千面的投放文案和话术策略。

我团队的人大都在做交付中，所以没时间，刚好手头有位认识的大厂出来的工程师，背书非常好，想着把单派给他，让他去试试水。

在盘完模型调用和工程成本后，发现方案总共也就几万块钱，可顺着投放组、内容组、渠道运营一级级对接下去，项目却彻底没了下文，方案交上去石沉大海，最后怎么推进都得不到任何回应，还被客户说得专业度不够。

在经过他深度复盘后，他感慨说：这本质上是来自业务基层的隐性防御，组织越复杂，阻力越深不见底。

确实，我和团队长期在一线做 AI 落地与交付，此前我们深度访谈了不少一线同行，在经历沉淀过专项行业洞察后，但最终让我们彻底看清现实的，恰恰是这类真刀真枪踩出来的教训：

大家以为 FDE是工程师驻场帮业务做落地，其实这是条死胡同；AI 时代真正的 FDE，从来都不是工程师转出来的，而是业务专家自己练出来的。

工程师驻场，为什么大概率失败？

硅谷带火 FDE 这个词时，描绘得非常高级：过去软件开发是横切的，产品、研发、测试各管一段；现在一个人就能纵切打通从需求到交付的全流程。

听起来像超级个体，但只要把工程师派进传统企业驻场，然后你就疯狂撞南墙，南向撞完跑北墙撞，因为这本身不是你技术的问题：

第一道是组织权限的防御

AI 项目几乎必须是一把手工程，老总不拍板，底层推不动；可哪怕老总签了字，员工也绝不会老老实实配合。原因：很多业务场景做智能化，终点就是裁员或削减预算，你让一个可能被替代的运营人员，把吃饭的投放 SOP 和独家经验全盘交出来，换谁都会藏着掖着，那个电商项目的烂尾，无非就是基层在用沉默筑起高墙。

第二道是行业壁垒

很多人以为技术懂业务只是时间问题，其实根本是降维打击，以临床试验数据处理为例：有位业务老手自己用早期工具搭了个贯穿临床药理流程的自动化系统，中间涉及两百多个合规校验节点。后来找技术团队做架构优化，结果一开会就傻眼了，前半小时还能聊接口，后半小时全是不良事件归因、双盲解密规范、稽查轨迹等行业术语，技术人员完全听不懂。

效率对比更扎心：技术团队一天吭哧吭哧最多调通 2 个逻辑节点，业务专家自己半天就能配置 5 个，还嫌工程师拖后腿。

AI 犯错，行业专家一眼能看出来并纠正；你作为技术二道贩子犯了错，不可能每一趟都去问他，他只会嫌你烦，中间隔了一层，你就永远比业务本身慢。

第三道是数据安全

医疗、审计这类行业，底层数据出不了私有网络，合规卡得死死的，外来驻场团队连测试数据都摸不透，谈什么深度建模？

学习成本倒挂：业务补工程，远比技术补业务划算

既然角色没问题，那就是人选错了。

核心判断非常干脆：不要妄想把程序员改造成懂行业的人，应该给行业老手递上工程工具。

这两者的学习成本完全不对等：

• 业务专家补工程：生产环境部署、工作流编排，现在有成熟的工具链、Agent 和现成 SOP，几天高强度培训就能上手；
• 技术人员补行业：行业直觉、合规红线、深层潜规则，没有在这个行当浸泡三五年，靠几场需求会根本补不回来。

事实也在印证这一点。

就像前段时间有位位资深税务师曾试图用 AI 攒一个处理跨国企业转让定价的分析系统，前三天勉强搭出框架，后面几天越做越臃肿，AI 动不动卡死。后来他直接套用封装好工程逻辑的工具链，三天就把整套系统重构跑通。他自己动手的原因很简单：找外面的程序员太慢，沟通三次有两次在说这税则逻辑冲突不能做。

还有家几百人规模的连锁文旅集团，过去要 8 个人专职处理各景区的客诉判定与退费审批，团队帮他们搭建好工作流工具后，直接把原本冗长的工单系统压缩成 1 个人日常维护的智能流转后台，这条链路，在我们看来，执行压缩执行得太慢了，早日弄，整条链路大家都能松口气。

两件事底层逻辑一样：构建业务能用的系统，根本不需要堆砌最前沿的技术；但要做出真正好用的系统，必须用透最前沿的行业经验。

FDE 里的这个「F（Forward，前瞻）」，核心是站在行业认知的前列，绝对不是代码层面的前列。

信息时代是马，AI 时代是火车。很多技术驻场不过是用旧时代的工单模式在轨道上生拉硬拽，当技术逐渐退化为水和电，真正不可替代的壁垒，永远只属于那些懂得用新工具重构自己业务的老法师。