三条判据，比任何岗位名称都可靠

先说质疑里对的部分

2026 年下半年，关于 FDE 的质疑集中出现。有几篇的论点，我读下来是站得住的。

雷峰网 9 月 22 日那篇《在中国，别指望FDE能搞定AI落地》，写的是从业者视角：FDE 被当"赠品"用、没去过客户现场、沦为围着需求文档转的操作员、公司拿得出手的"产品"只有一套方法论。这篇的结论是 FDE 不过是"新瓶装旧酒"，以前叫交付顾问，本质是懂技术的销售专家。

澎湃新闻·湃客 10 月 13 日那篇《FDE，突然成了一个"不想谈"的话题》，记录了一位云厂商副总裁的说法：FDE 在中国很容易"变味"，会被说成新瓶装旧酒、挂羊头卖狗肉。文章里还有一句流传很广的调侃——“FDE 在中国，就是驻场牛马的新名词”，说实施工程师换个头衔，人天单价就想从 1500 涨到 15000。

这些话说得难听，但描述的现象是真的。这个行业里确实有一批人，把一个存在了十几年的岗位名称贴到了原来的售前和实施团队身上，然后涨价。

所以我不打算辩护"FDE 是个好东西"。 我想说的是另一件事：正因为标签不可信，才需要判据。

三条判据

这三条写在官网 FDE 是什么 那一页，也写在 常见问题 里。这里展开讲怎么验证。

第一条：工程师是否写生产代码。

验证方法很简单——问一句"项目结束后，交付物里有没有你们提交的代码"。不是演示脚本，不是原型，是进了生产环境、现在还在跑的代码。

这条能筛掉很多人。因为做访谈、写方案、做汇报，不需要写代码；而写进生产环境，意味着要对稳定性负责，这是另一回事。

第二条：是否对实际采用率负责。

这条更硬。多数交付的终点是"上线"，验收单签了、系统跑了，任务完成。但上线不等于用起来——很多项目验收完，业务人员还在用微信和 Excel。

验证方法：看验收标准里有没有"采用率"这一项。如果没有，无论对方怎么说，他都不对"有没有人用"负责。

第三条：单客户经验是否进入标准产品。

这是最容易糊弄、也最能区分的一条。

一个项目做完，经验留在哪里？如果留在某个人的脑子里、留在项目文档里，那下一个项目就要从头再来一遍。如果进入了可复用的标准能力，那第二个客户会更便宜、更快、更可靠。

缺这一条，再豪华的岗位名称也改变不了项目制生意的本质——每个客户都是重新开始，成本降不下来，价格也就降不下来。

四条反证据

判据是"怎么判断"，反证据是"怎么验证"。这四条都是能写进合同的东西，比口头承诺硬。

一、验收含采用率。 我们的 P2 验收三条缺一不可：功能层（约定清单全部跑通）、采用层（业务人员真的在用）、交接层（客户能独立接手）。只有功能验收不算通过。

二、能力转移独立计价。 P4 能力转移是单独一档服务，2-4 周，一次性计价。它不是赠品，也不是捆绑销售——客户可以选择不做，也可以选择做。独立计价的意义在于：它是一件被认真对待的交付物，而不是"顺便教一下"。

三、代码与交付物归客户。 交付即归属客户，我们不保留客户代码用于其他项目。使用开源组件的会列明许可证。

四、离场清单。 项目结束按清单执行：账号注销、权限关闭、数据销毁并出具书面确认、代码与文档全部移交。保密条款在合同终止后至少 2 年。

这四条合起来，回答的是同一个问题：这家公司希望我继续依赖他，还是希望我以后不需要他？

哪些情况下确实不该找 FDE

这一节可能是最实用的。下面这些情况，我们会在诊断阶段直接说不做：

规则能解决的问题。 用规则更便宜、更稳定、可追溯。用 AI 去做本该用规则解决的事，是这两年最常见的浪费。

数据基础不具备。 没有可用数据源，模型无从判断。这种情况下先做数据治理，别做 AI。

需求还在变、决策人不在场。 这两件事同时出现，项目大概率会拖成无底洞。

只想做演示。 给客户看、给银行看、给投资人看。这类项目我们不做，因为它没有"采用"这个环节，三条判据里的第二条直接失效。

另外还有一条边界值得单独说：不按人天报价。 按人天报价会把注意力引向"用了多少天"，而不是"解决了什么问题"。我们的 P2 是 30/50/20 分三期付款，每个阶段不通过验收不进入下一阶段。

结论

FDE 不是万能。它有明确的适用边界，也有大量冒名顶替者。

但"这个词被滥用了"和"这件事没价值"是两个判断。前者是真的，后者不成立。

对客户来说，能做的其实只有一件事：不看标签，看判据。 三条判据加四条反证据，问完这七个问题，对方是真做交付还是换个名字卖人天，基本就清楚了。

对我们自己来说，这篇文章也算一次公开承诺。上面写的四条反证据，都可以拿来对照我们自己的合同。如果哪一条对不上，说明我们也在变成自己批评的那种公司。