📦 3 Parts + Conclusion
👉 滑动
PART 01
第一本账
AI的考场成绩
PART 02
第二本账
真人的工地日记
PART 03
对账
同一笔欠款
PART ///
写在最后
一个问题
AI当FDE,真实项目成功率只有6%;人当FDE,最大的坑不是技术,是政治、回款和撤不出来
FDE(前沿部署工程师)今年有多热,不用我多说:岗位在涨,大厂在抢,Anthropic 10月宣布拿出1亿美元、计划到2027年底培养1万名 Frontier Deployed Engineers。先把口径放这儿:这是它一家的人才计划目标,不是市场统计。
热归热。我把最近收进资料库的几份材料放在一起看,发现一件有意思的事:让AI去当FDE,有一本难看的账;让真人去当FDE,还有一本。这篇就对一对这两本账。
材料一边是三篇刚出的基准论文,百度、FDE-Gym、Oracle团队各一份;另一边是国内从业者 zlbigger 滚动更新到 V2.4 的《FDE白皮书:前沿部署工程师行动指南》。前者是考场成绩,后者是工地日记。
01
PART
第一本账:AI上场,49个真实项目只交出6%
THE AI LEDGER · 考场成绩
百度这篇最狠,因为它用的不是玩具任务:49个真实客户项目,需求都是没说全的。18个智能体配置轮番上场,最好的平均交付分 0.5510(满分1.0,是客户验收的参考分),成功率最高的一家也只有6.12%。49个项目里只有8个出现过参考级交付,机器学习类项目一个都没有。
6.12%
百度FDE-Bench最高成功率 · 49个真实项目
14 / 95
FDE-Gym端到端任务,最强配置解决数
8次过2次
Oracle团队实测的交付验收通过数
FDE-Gym 换了个考法:95个端到端交付任务,最强配置解决了14个,约15%。里面有个细节值得记:任务规则给全时,领先模型能拿到 0.73–0.82;只给问题、不给规则,直接跌到 0.39–0.62。掉分最狠的一刀,是发现客户没说出口的约束,不是听不懂话。
Oracle 团队的实测是同一个结论的另一面:让模型做需求发现,能找回80% 以上的关键需求;真到交付验收,8次只过了2次。
三篇论文口径不同,指向同一个卡点:AI不缺写代码的能力,缺的是在规则没说全的世界里,自己把“什么算完成”问清楚、定下来。这一关过不去,代码写得再快也是白干。(三篇均为预印本,未经同行评审,数字按论文原文引用。)
02
PART
第二本账:真人下场,最大的坑是政治,不是技术
THE HUMAN LEDGER · 工地日记
换真人来。zlbigger 这份指南不是论文,是一位从业者从今年8月一路滚动修订到 V2.4 的实战手册,9章加5个附录。它最特别的地方是克制:作者明确说,“9个月暴涨800%”“年薪百万美元”这类传播数字没有可核验口径,不写;旧版本里出现过的国内报价区间,V2.3 被他自己删掉了,因为找不到统一公开样本。这种删法,比任何数字都更能说明这个行业现在有多早期。
他给真假 FDE 定了三问:生产代码谁写?上线坏了谁扛?客户不用,算不算失败?答不上来,大概率是换了名字的外包、咨询或销售。
然后是国内7大坑。排第一的叫政治阻力,他引了一位同行的话:
“员工对你的敌视会比做咨询顾问的时候要强很多。因为你帮老板部署Agent,结果是‘过两个月他就要失业了’”
表现很具体:员工阳奉阴违、不给真实数据,最后 FDE 被当炮灰。后面六个依次是:需求无限蔓延、被当高级外包、回款难、价值难量化、一人干五家公司的活(咨询+培训+软件+销售+心理咨询)、退出难。每个坑都配了对策,比如需求蔓延的对策是 SOW 写死、提前明确“什么算完成”。
钱的账更直白。他在指南里写:签约金额不是已收款,已收款也不是利润。报价三原则是:报价不在调研前出现、先收诊断费、分阶段里程碑回款。回款难那个坑的对策,翻来覆去也是这件事。
最后一本是撤场的账。他把“交付完成”的标准收紧成一句话:下一位责任人可以继续工作。撤场前要过一遍“可继续工作”检查:客户管理员能自己发布、停用、回滚;运行手册写明版本和失效条件;故障演练做过;复验责任和报价写清。过不了这一关,人走了,项目还挂在你名下。
03
PART
两本账对完,欠的是同一样东西
SAME DEBT · 对账
把两本账并排看,欠的都是同一样东西:没说清的规则。
AI那边,规则没说全,分数从0.8掉到0.5以下;人这边,规则没写进合同,表现就是需求蔓延、验收扯皮、回款拖延。指南里有个工具叫“范围账户”:新增需求必须确认成本、延期影响和被替换的原需求。说白了,是把客户没说出口的约束,提前变成白纸黑字。这恰好是论文里 AI 最弱的那一环。
不要问谁对谁错,先问哪一个机制没有被设计
指南第9章是吐槽专区,四方互相吐槽:FDE吐槽甲方,甲方吐槽FDE,一线员工吐槽双方,经营者吐槽这门生意。作者给的使用方法只有一条:不要问谁对谁错,先问哪一个机制没有被设计。每条吐槽都能改写成一条合同或验收清单——“需求永远加,预算一分不加”,对应范围账户;“上线后所有问题都算我们的”,对应责任矩阵和保修期后的运维报价。
所以我的判断是:FDE 这活儿,技术只占一半,另一半是把规则、责任和钱在开工之前谈清楚。AI 暂时做不了后一半,真人经常懒得做后一半,结果两边栽在同一处。
04
PART
能直接拿走的五条
TAKEAWAYS · 可复制
开工前先收诊断费,报价不要在调研前出现。
改造前先记基线数据。没基线就证明不了价值,验收必扯皮。
SOW 里写死“什么算完成”;新增需求走范围账户,确认成本、延期和被替换项。
回款按里程碑分段结,别等项目结束一次性结。
撤场标准只有一个:下一位责任人不用翻聊天记录,就能继续工作。
还有一条是给从业者自己的。指南的结论是:FDE 是阶段性职业,岗位名可能消亡,能力会留下;能沉淀下来的资产是脱敏后的流程模板、可复用连接器、评估集、部署清单和故障手册;终点是 2–3 人加 AI 的小团队。用他引的一句话说:“OPC 本身不成立,但团队规模小是成立的。”
///
LAST
写在最后
ONE QUESTION · 一个问题
最后留个问题给正在做 AI 交付的朋友:你手上项目的验收标准,是写在合同里,还是写在客户的脑子里?如果是后者,换 AI 还是换人下场,结局不会差太多。
说明:文中论文数字来自三篇 arXiv 预印本(百度 FDE-Bench,arXiv:2610.14539;FDE-Gym,arXiv:2610.22350;Oracle 团队实测,arXiv:2611.03551);指南为个人实战总结与中文区定性观察,不是行业统计,文中不采用任何未核验的薪资与客单价数字。指南原文见 zlbigger.com/fde。
我是雷神,在「雷哥AI探究」写 AI 落地与 FDE 观察。
既然看到这里了,如果觉得有用,随手点个赞、在看、转发三连吧。
THANKS FOR READING

