反模式清单：26 种失败模式

给正在现场、想知道自己是不是已经踩进去的人。每一条给五样东西：现象、根因、早期信号、解法、出处。早期信号那一栏是这一页真正的价值——大部分失败在发生前两到六周就有征兆，只是没人认得出来。

怎么用这一页

进场前：通读一遍 A、B 两组，它们决定这一仗值不值得打。
每周五：拿早期信号那一栏对照本周，勾出命中的。命中两条以上就该停下来查。
结项后：用它做复盘检查表，把踩到的写进交付病历的「并发症」栏。

关于证据强度：出处一栏里，标【一手】的是官方发布、原作者文章或平台可查数据；标【转述】的是中文行业公众号或社区流传的叙述，未经独立核实，其中的具体数字不能当作事实引用，但结构本身有教学价值；标【复合案例】的是多个公开报道中反复出现的模式的合成叙述，公司与人物非实指。

和 07 案例库 A/B/C 等级的对应关系：【一手】≈ A（一手且可独立核对），【转述】≈ C（二手转述、行业流传，不可作统计引用），一方自述但来源可点开的材料在案例库标 B；【复合案例】没有对应等级——这一档不进 07 案例库索引，只作教学素材。等级定义见 07-cases/README.md 的证据等级一节。

本页目录

组	条目
A 进场与选题	1 用样例数据做 POC｜2「数据没问题，你先开始」｜3 一期铺八个场景｜4 三个 D 互相等｜5 把老板的焦虑当需求做
B 需求与 Context	6 会议室里的 5 Whys｜7 把「更好的报表」直接当需求做｜8 只访谈最配合的人｜9 越界替业务做专业判断｜10 用发生频率排列排查顺序｜11 把免责声明当安全设计
C 数据	12 不做数据剖面就开始建模｜13 脱敏之后问题已经不能解了｜14 两个数打架时选一个信
D 构建	15 追测试集分数｜16 先做平台后做场景｜17 agent 自作主张｜18 技术债静默累积
E 上线与采纳	19 逼一线学一个新门户｜20 用考核逼使用｜21 没有埋点的上线｜22 把「上线」当成「做完」｜23 把有价值的人际接触也自动化掉
F 组织与商业	24 冠军离职｜25 最重的那段活在合同里值零｜26 内部 FDE 退化成内部 Professional Services
附：属于这一行的三条	27 把 FDE 当速成头衔｜28 更多责任更少权力｜29「AI 赋能」买成六轮喂 JD

A 组：进场与选题

1. 用样例数据做 POC

现象：两周做出惊艳演示，签约后真实数据一接进来，模型要么报错要么给出一本正经的错误结论，8 周计划做到第 20 周。
根因：POC 被当成销售表演而不是风险探测。样例数据跑通只证明「模型会做这道题」，对「客户的数据能不能出这道题」零证明力。
早期信号：演示用的数据是你方准备的；评审会上有人说「技术可行性已验证」而没人追问验证用的是谁的数据；客户的数据审批流程还没启动。
解法：缩小范围换真实性——只取一个分厂 / 一个品类 / 一个月，但必须是真的。把「真实数据切片」写进 POC 合同。参见从 demo 到生产。
出处：【复合案例】《中国 FDE 手册》04-案例库《败 · POC 陷阱》；对照【一手】Palantir AIP Bootcamp 的真实数据切片要求。

2. 「数据没问题，你先开始」

现象：对方口头保证数据没问题，你开始搭链路；六天后拿到真实切片，发现编码在某年改过、两张表用两套主键，前六天的工作作废一半。
根因：口头承诺在企业内部成本为零。这句话的实际含义是把风险从他那边挪到了你这边。
早期信号：这句话本身就是信号，没有比它更早的了。
解法：数据切片没实际躺在你硬盘上之前，一行代码都不要写。 把「第一批切片到手日期」当成里程碑写下来。
出处：【转述】《中国 FDE 手册》03-模板库《客户准备协议》样例，当事人自述「这六天是我自己的学费」。

3. 一期铺八个场景

现象：同时启动多个 AI 方向，要求各业务单元各自探索。半年后技术栈变了，一部分被砍，剩下的因彼此依赖无法独立交付，全部烂尾。
根因：把「覆盖面」当成了「进展」。多线并行时每条线都得不到足够的现场时间，而现场时间是这件事唯一的稀缺资源。
早期信号：立项文件里出现「全面赋能」；场景清单超过 3 个；没有一个场景能说出具体是谁在痛、他叫什么名字。
解法：一期只做一个点做穿。选择标准：业务痛感最强 × 可行性最高 × 交付周期最短。不允许「看到功能就搭智能体」——先有场景，再有智能体。
出处：【转述】中文行业公众号整理的 FDE 能力清单中的反面案例。

4. 三个 D 互相等

现象：所有人都同意，没有人拍板。技术方案等业务确认，业务等 IT 确认可行性，IT 等老板批授权。
根因：决策权没有唯一化。Bain 的 RAPID 模型里 D（Decide）必须唯一，而中国企业的典型形态是三类决策各有一个 D，且互相观望。
早期信号：会议纪要里反复出现「会后同步」「待进一步对齐」；同一个议题开了三次会结论都是「原则同意」。
解法：干系人地图上按决策类型写三个 D——技术方案谁定、流程变更谁定、上线授权谁定。三个格子填不满，别往下走。
出处：【一手】Paul Rogers & Marcia Blenko，《Who Has the D?》，HBR，2006。

5. 把老板的焦虑当需求做

现象：花大钱建了一个漂亮的「AI 智慧大屏」，数据在跳、图表很酷、领导来参观都夸。问一句「这屏的数据是车间的人每天在更新吗」，IT 总监答「这个⋯⋯主要是展示用的」。
根因：需求源头是「要有 AI」，不是「有个问题要解」。这类项目从第一天起就没有用户。
早期信号：项目目标里没有一个具体的人名；验收物是一次汇报或一场演示；没有人能说出「这个项目的经营结果是什么、用哪个数字验收」。
解法：把公司手头所有 AI 项目列出来，逐个问「这个项目的经营结果是什么？用哪个数字验收？」答不上来的，先暂停。
出处：【转述】王一荔，《你招的不是 FDE，是月薪十万的外包》，微信公众号「一荔说OPC」，2026-08-25，开篇案例。

B 组：需求与 Context

6. 会议室里的 5 Whys

现象：五个 why 一口气推完，推出一个听起来很深刻的结论，方案照着做完之后没有任何指标变化。
根因：5 Whys 是现场方法，不是推理方法。在会议室里，每一层的答案都是猜的。
早期信号：问题分析里没有一个带人名或时间的事实；「因为员工意识不足」「因为流程不规范」这类答案出现。
解法：加一条硬约束——每一层的答案后面必须附一个你在现场看到或听到的事实（带人名或时间），附不上的那一层，停下来，回现场。
出处：【一手】大野耐一，《丰田生产方式》（现地现物与 5 Whys）。

7. 把「更好的报表」直接当需求做

现象：业务方说「我需要更好的报表」，你就去改报表格式，做完他还是不满意。
根因：没做翻译。一线说出口的是解决方案的形状，不是问题本身。
早期信号：需求文档里全是名词（做一个 XX 系统），没有动词和场景；你说不出「他现在这一步花几分钟」。
解法：追问到具体动作。一个被反复引用的例子是：情报分析员说「我需要更好的报表」，追问后发现真正的痛点是跨三个数据源的关联查询需要手动切换四次界面，需求于是变成「跨源关联查询的一键切换」。要求所有需求按固定结构输出：业务背景 → 目标 → 现状流程 → 差距与问题 → 具体需求 → 技术方案。
出处：【转述】中文行业公众号整理的 Palantir 早期做法叙述。方法本体见 ../04-methodology/discovery-and-scoping.md。

8. 只访谈最配合的人

现象：访谈很顺利，所有人都很客气，收集到一堆「挺好的」「有价值」，然后做出来没人用。
根因：最配合的人和别人服的人经常是两个人，而新人天然会选前者——好约、态度好、不让人难堪。
早期信号：访谈记录里没有一句反对意见；没有人对你说过「上次那个也是这么说的」；你没有见过任何一个怀疑者。
解法：灰度名单必须包含一个意见领袖、一个已知的怀疑者、一个新人。找意见领袖的方法：跟班时看别人遇到问题时去问谁。
出处：【一手】Everett Rogers，《创新的扩散》，意见领袖与同侪影响。

9. 越界替业务做专业判断

现象：IT 出身的工程师把厂里几年的报警工单当金矿，挖出统计规律喂给 AI，系统在报警时提示「过去 30 天，某比例的同类报警最终定位为通讯故障，建议优先检查通讯链路」。数据是真的，统计是对的，设备专业工程师看到的反应是警觉。
根因：把相关性当成了机理。同一类报警可能有多类成因（采集链路问题、工况问题、机械磨损早期征兆），指向完全不同的部件和风险等级。
早期信号：你写得出这个领域的相关性，写不出失效机理；专业工程师在评审会上皱眉但说不出具体反对理由。
解法：写不出机理，就把建模主导权交出去，自己退到工具和工程实现的位置。成因树、每个分支的风险等级、哪些情况必须立即停机——这些知识的所有权在专业人员手里，FDE 的工作是把它结构化地请出来，不是绕过它自己从工单里挖一套。
出处：【转述】源自中文行业公众号「智盛汇」《六刀剑指「主流」FDE 定义》一文引发的公开辩论；批评者给这套做法起的名字是「用错误喂养错误」。案例细节与具体百分比未经独立核实，勿作事实引用；但「温度异常有多类成因、统计频率与风险等级错位」符合设备工程通识，可由任何设备专业人员独立验证。完整案例卡见 07-cases/china-cases.md#C14（同一出处，标 C 级）。

10. 用发生频率排列排查顺序

现象：系统按「最常见原因」给出排查建议，一线照做。
根因：统计上最常见的原因，往往恰好是后果最轻的那个。 通讯故障频率高但不烧设备；轴承劣化占比小，可一旦被「先查通讯」耽误，等到的可能是抱轴、停产甚至安全事故。
早期信号：排序依据是频次；方案里没有风险等级这一列。
解法：停下来找专业工程师问一遍成因分类。排序依据要改成风险加权，而不是频率。 高风险分支必须永远显式呈现。
出处：同上第 9 条。

11. 把免责声明当安全设计

现象：界面上加一行「本建议仅供参考」，然后继续把统计结论当结论用。
根因：混淆了法律免责和工程安全。那行小字挡不住一线对系统建议的默认信任。
早期信号：风险评审的结论是「加个免责说明即可」；没有任何一条建议触发强制人工复核。
解法：真正的安全设计是让高风险分支永远显式呈现、永远提示专业复核，而不是把它藏在概率后面。高风险场景用白名单模式，见从 demo 到生产的风险分级表。
出处：同上第 9 条。

C 组：数据

12. 不做数据剖面就开始建模

现象：跑了两周才发现某关键字段在某年之前全是空的，或者某个字段被一线挪用成了备注栏。
根因：把「拿到数据」当成了「数据可用」。
早期信号：你说不出任何一个字段的空值率；你没有按月统计过行数。
解法：拿到切片后 48 小时内跑完数据体检 12 项（空值率、分布、时间断层、编码变更史、主键关联、重复、时区单位、量级代表性、自由文本真实用途、历史判定质量、脱敏后回测、互相打架的数）。清单见干系人与数据获取。
出处：【一手】Neil Lawrence，《Data Readiness Levels》，arXiv:1705.02245；【转述】多份中文交付复盘。

13. 脱敏之后问题已经不能解了

现象：合规通过了，数据到手了，但关键特征被脱掉，模型再也复现不出人工判断的逻辑。
根因：脱敏方案由合规单方面决定，没有做过效果回测。
早期信号：脱敏规则是「把所有可能敏感的字段都去掉」；没有人用脱敏后的数据跑过一次手动验证。
解法：脱敏后用脱敏数据把之前那 10 到 30 条手动验证再跑一遍。结论变了就回去重谈脱敏规则，而不是硬着头皮往下做。假名化（保留可关联性）通常比删除更适合分析场景。
出处：本库归纳，方法见干系人与数据获取。

14. 两个数打架时选一个信

现象：同一个指标在两份材料里是两个数，你挑了看起来更合理的那个当基线。
根因：口径没对齐。「自动回复率」的分母可能是全部工单，「成功率」的分母可能只是系统尝试处理的那部分。
早期信号：两个部门在用同一个词说不同的事；没有人能说清这个数是谁算的、多久算一次。
解法：不要选一个信，去把它们的分母问出来。 问出来通常是三种情况之一：口径冲突（你找到了）、一个是给上面看的另一个是内部真用的（记下来）、两个都没人负责（这个指标不能当基线，换一个）。
出处：本库归纳；方法见干系人与数据获取第五节。

D 组：构建

15. 追测试集分数，不追「老师傅会不会这么说」

现象：测试集准确率过得去，一线用两次就不再用了。
根因：评估标准是工程团队自己定的，不是业务方定的。系统的回答「不像老师傅说话」——老师傅被问「温度报警怎么办」，第一句是「八成是探头脏了，先擦探头」，先给经验判断再给排查步骤；系统的第一句是「请按照以下规程逐项检查」。
早期信号：评估集里没有一条是业务方写的；你和业务方就「什么算对」这件事从没吵过架。
解法：把系统的 10 条真实回答打印出来念给老师傅听。他皱眉说「谁这么修啊」，这条语料就该重写。知识库的单位是「老师傅会怎么说」，测试集分数排在它后面。
出处：【转述】《中国 FDE 手册》04-案例库《胜 · 恒岳重工》（脱敏虚构案例，数字为示例，因此不进 07 案例库索引）；同一故事在中文社区流传的非虚构形态，本库按 C 级收录为 07-cases/china-cases.md#C13，引用请用后者。方法本体见 ../04-methodology/evaluation.md。

16. 先做平台，后做场景

现象：半年时间建了一个「AI 中台」，接口齐全、文档完整，没有一个业务在用。
根因：平台的价值来自第二个、第三个场景的复用，而在没有第一个跑通的场景时，「复用什么」是猜的。
早期信号：项目里程碑全是技术组件；第一个真实用户的名字还没出现在任何文档里。
解法：严格执行顺序——能力验证（手动跑通）→ 工程化（稳定部署）→ 产品化（权限 / 计费）→ 运营优化，不允许跳步。第一阶段允许手动复制粘贴、允许没有 UI，样本量 10 到 30 条足够。
出处：【转述】中文行业公众号整理的 AWS FDE 做法叙述（45 天驻场周期、前 10 天最小验证），未见 AWS 官方页逐字确认。

17. agent 自作主张，而没人看它的指令输出

现象：代码 agent 主动加了一个「推荐判定」按钮，上线给业务主管看的时候她第一句是「这个谁负责」，当场关掉。
根因：硬约束只写在人的脑子里，没有写进给 agent 的指令，也没有人逐条审阅 agent 的产出。
早期信号：你已经连续几天没有读过 agent 的完整输出；提示词里没有一条「不得做什么」。
解法：把不可越界的业务约束写死在指令里（例如「不得给出自动判定结论，只给依据」），并且每天至少完整读一遍 agent 的关键产出。人的判断点不能外包给 agent。
出处：【转述】《中国 FDE 手册》03-模板库《交付病历》样例第 2 条并发症。

18. 技术债静默累积

现象：内部 FDE 一个人身兼 PM、开发、QA，用 AI 编码以极高速度推进，部署的代码开始碰到研发团队正在改的同一段代码；他解决问题比研发还快，甚至帮研发把活干完。
根因：速度是真的，但没有任何机制在记账。一位社区评论把它总结为：「FDE 会爽上一年，直到技术债到期那天。」（该帖 299 赞）另一位补充：「他不会 burnout，但他的方案会变成一坨无法维护的烂摊子，而且大概率正好在他跳槽的时候。」
早期信号：FDE 的提交和研发团队的提交开始冲突；没有人做 code review；文档滞后超过两周；接手人还没有出现。
解法：从第一天设技术债台账并公开；产品化关卡强制执行（每个项目至少 1 项能力回流到平台）；交接包在上线时就开始写，而不是离场前一周。
出处：【一手】Reddit r/ProductManagement 帖《My PM role seems to be quite... threatened》，2026-08-08，139 赞 / 100 评论（票数为 2026-08-30 读数）。https://www.reddit.com/r/ProductManagement/comments/1vj6yeu/

E 组：上线与采纳

19. 逼一线学一个新门户

现象：系统很先进，一线要多打开一个网页、多登录一次、多导出导入一遍，然后就没有然后了。
根因：为了显得先进而重建入口。一个每天要开六个系统的人，不会为了你再开第七个。
早期信号：用户为了用你的东西需要新增 2 个以上动作。
解法：系统可以新，入口必须旧。 用户在哪干活，结果就送回哪里——Excel 就写回他那张表，企业微信 / 钉钉就机器人推消息，ERP 就写回单据字段，现场作业就语音输入大字单手操作，纸就在那张纸上多一行。自查只有一个问题：用户为了用你的东西需要新增几个动作？0 最好，1 可以接受，2 以上这个系统会死。
出处：【转述】《中国 FDE 手册》03-模板库《采纳设计检查表》；理论底见 Google PAIR《People + AI Guidebook》。

20. 用考核逼使用

现象：发现没人用，于是发文把使用率写进考核。使用率数字上去了，价值没有。
根因：诊断错了。不用的原因有三种——产品烂（能力问题）、不会用（知识问题）、动了谁的奶酪（意愿问题），三种解法完全不同。ADKAR 模型的核心不是五个字母，是「障碍点」：进度被第一个不足的环节卡死，缺的如果是意愿，再多培训也没用。
早期信号：极度配合，零抱怨，零使用。 真正嫌产品烂的人会骂你；真正不会用的人会问你；只有第三类会对你笑。
解法：三选一诊断——抱怨具体（太慢、找不到、字太小）→ 当天改，别开培训会，培训解决不了慢；打开过一次就没再打开 → 陪他做一次完整的、真实的活，别发操作手册；表面配合就是不用 → 别加考核，改用署名（让他成为规则的定义者）、减负（先做一件让他轻松的事）、退路（受损者的出路必须被显式设计）。
出处：【一手】Prosci ADKAR（Jeff Hiatt，2006）；第三类原因与解法为中文现场的补充，见【转述】《中国 FDE 手册》。

21. 没有埋点的上线

现象：上线两周，问「用得怎么样」，答「反馈还不错」。
根因：没有事实，只有印象。而印象在组织里会被自动美化。
早期信号：你说不出昨天有几个人用了，也说不出他们叫什么。
解法：埋点必须在上线第一天就有，至少三样：谁打开了、谁用了、谁用到一半退出了。日报四行且能点到人名，其中「谁一次都没登录」那一行就是今天的工作清单。
出处：【一手】Google HEART 框架与 GSM 流程（Rodden、Hutchinson、Fu，CHI 2010）。https://kerryrodden.com/heart/

22. 把「上线」当成「做完」

现象：系统上线，账号开了两千多个，周活个位数到几十。技术侧说该换更大的模型，业务侧说该发文写进考核，两边都拿不出证据。
根因：把努力分配倒过来了。BCG 的 10-20-70 原则说，AI 成功的努力分配应该是 10% 算法 / 20% 技术与数据 / 70% 人与流程；把比例倒过来的组织持续拿不到可测的回报。
早期信号：项目计划里「上线」是最后一个里程碑；上线之后没有安排任何每日动作。
解法：把「周活 37 的系统不是技术失败，是采纳设计失败」这句话立在会上，然后做每天三个动作：早上看能点到人名的埋点日报、白天去找那个没登录的人看两分钟、晚上在群里发一句「今天根据 X 的反馈改了 Y」。连发十天，群里会开始有人主动提意见。
出处：【一手】BCG《The Leader's Guide to Transforming with AI》（10-20-70）；【转述】恒岳重工脱敏虚构案例（同第 15 条，不进案例索引；可查证的对应案例是 C13）。

23. 把有价值的人际接触也自动化掉

现象：某在线教育公司用 AI 全面接管学员课后答疑，效率提升了，三个月后续费率下降。复盘发现：学员发消息给班主任本身是班主任了解学员状态、建立信任的核心触点，全面自动化后班主任不知道学员在学什么、卡在哪里，续费沟通完全失去针对性。
根因：把「搬运」和「接触」混为一谈。
早期信号：自动化清单里出现了带有关系属性的环节；效率指标在涨而留存 / 复购 / 满意度在跌。
解法：对每个拟自动化的节点追问三句——这个环节是否承载业务人员与用户的关系建立？自动化后业务人员是否还能了解用户状态？这一步是「无价值搬运」还是「有价值接触」？原则：自动化消除无价值搬运，不消除有价值的人际接触。
出处：【转述】中文行业公众号整理的 FDE 能力清单案例，公司未具名。

F 组：组织与商业

24. 冠军离职，项目无人认领

现象：推动这件事的业务负责人调岗。接任者不反对这个项目，他只是不认识它。例会降频、需求排不上日程、预算被挂起，系统在惯性里运行半年后使用率阴跌。
根因：项目的组织生命完全悬在一个人身上。使用是他推的，价值是他向上讲的，阻力是他压的。
早期信号：推广靠他打电话、价值靠他汇报、阻力靠他去压，三条占了两条，你的项目就是单点故障架构；新负责人问的第一个问题从「这周省了多少小时」变成「这个一年花多少钱」。
解法：立项那天就画巴士图（逐个问「这个人明天调走，项目靠什么活」）；从上线第一天做四件事——业务侧值班对接人（公开宣布）、价值口径文档（业务方是作者之一）、系统指标进某个人的考核表、每月自动发出的使用情况表。听到调岗消息，正确动作是立刻把交付节奏让位给制度化，趁他还有权力把这三件事钉死。
出处：【复合案例】《中国 FDE 手册》04-案例库《败 · 冠军离职》；【一手】RAND，《The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed》，2024，把发起人流失列为反复出现的失败根因。https://www.rand.org/pubs/research_reports/RRA2680-1.html

25. 最重的那段活在合同里值零

现象：为客户做深度的专家知识沉淀，做得越深，交付越重，人越多，毛利越薄，越像项目制，越难规模化。
根因：成本结构与定价结构错位。挖专家知识的成本几乎全部落在乙方，挖出来的资产高度绑定单一客户，而客户是按项目付费的——合同上没有一条写「我们一起养一个知识库，它以后越用越值钱，收益分你一部分」。于是乙方投入最重、最不可替代的那段工作，在定价上接近于免费赠送。
早期信号：你的案例里最亮眼的那个数字（例如「沉淀了 10 万余条专家知识」）在合同里找不到对应的收费项；第二个客户的交付成本没有明显低于第一个。
解法：做深度知识沉淀之前先把三个问题写在纸上——挖这些知识的成本谁承担？挖出来的资产归谁？第二个客户能复用多少？ 三个答案如果分别是乙方、甲方、很少，那么这单做得越好，现金流越紧。这是结构问题，加班和降价都解决不了。
出处：【一手 + 分析】澜码科技公开报道与创始人公开表述；欠薪与裁员事实见界面新闻《因融资不顺，大模型创业公司澜码科技成立 2 年陷欠薪风波》（2025-02-24，https://www.jiemian.com/article/12388136.html）：46 人协商解除合同、留守约 20 人、2024 年 9 月起延迟发薪；流传的「800 万 / 66%」不在原文中，本库不采用，见 ../07-cases/china-cases.md C2。结构性分析属本库判断，不代表当事公司看法；公开材料无法拆分「交付结构」与「融资环境」各自的权重。 完整案例卡见 07-cases/china-cases.md#C2；现场形态见中国现场特有的约束。

26. 内部 FDE 退化成内部 Professional Services

现象：CTO 以「试验」名义引入 FDE。头三四个月没什么动静，之后 FDE 开始独立造东西、部署东西，不咨询研发团队也不咨询 PM。业务部门开始「什么事都找他」，PM 和研发被架空。
根因：把一个高速的定制交付职能放在了产品团队的平行位置上，却没有产品化关卡把它拉回来。一条高赞评论把这件事说得最清楚：90 年代买企业平台时随软件一起买的就是「某个倒霉蛋被派驻到你现场」，他会学你的业务、参加你的会、集成定制产品、让那个鬼东西在你的环境里跑起来——「这个实验我们做过了。技术变了。组织物理学没变。」
早期信号：每个部门都开始想要「自己的那个 FDE」；产品路线图和 FDE 的交付清单开始互相看不见；没有任何一项能力回流到平台。
解法：设产品化关卡并当成领先指标考核（每个项目在 90 天内至少有一个能力回流到核心产品）；FDE 汇报给产品或工程，而不是销售；FDE 与 PM、平台工程的职责边界写成一页纸，其中「谁定专业判断、谁定技术选型、谁提供知识库内容」三条要写死。
出处：【一手】Reddit r/ProductManagement，2026-08-08，帖 139 赞 / 100 评论，最高赞回复 299 与 98（票数为 2026-08-30 读数）https://www.reddit.com/r/ProductManagement/comments/1vj6yeu/；【一手】Perspective AI 的五阶段关卡表与产品化率指标。

附：三条不属于项目、但属于这一行的反模式

这三条不影响单个项目的成败，但影响一个人或一个团队能不能持续做下去。

27. 把「FDE」当成一个可以速成的头衔

一篇被广泛转发的批评文章记录了这样一个场景：一个工程师两个月里参加了三个 FDE 培训班、拿了两个证书，面试被问「你在客户现场遇到数据管道断连怎么处理」，愣住了——课上讲过 RAG、Agent、K8s 部署，唯独没讲过断连了怎么办。它的论点是培训教你的是「知道」，企业要的是「做到」，并给了三个鉴别问题：教不教离线私有化部署与模型量化优化？RAG 有没有工程化调优？有没有 K8s 集群内网部署与运维排障实战？

同一方向另有一位作者主张「与其重新招一批 FDE，不如先问我们的工程师能不能升级成 FDE」，并明确否定两周 AI 课程式的培训。

两位作者都在推广自己的产品，立场均不中立；前者文中的百分比数字全部没有出处，只能当市场情绪的证据。（《参加了几个 FDE 培训，啥也没学到》，公众号「数据驱动智能」，2026-08-17；Lydia，《别急着招 FDE》，公众号「IT斜杠女青年」，2026-08-24。）

28. 更多责任，更少权力

英文社区对这个岗位最集中的批评是一句话："...but with more accountability and less authority."（149 赞），紧随其后的回复是 "Just what I need: more accountability and less authority."（61 赞）。

同一社区给出的判真假标准可以直接用来读 JD：看有没有 quota、OTE、commission 结构（有就是销售岗）；看汇报给销售 / GTM 还是工程；如果职责重点是做 demo 和促成签单而不是生产环境部署，或者合同一签就交接走人，那不是真的 FDE 工作。

反方同样值得看：一位自称在做这行的人写道「我是销售 / 支持团队里最好的工程师，也是工程团队里最好的销售 / 支持⋯⋯干这类岗位，你拿到的薪酬会比你的技术水平高一个技术等级」（294 赞）。

（票数为 2026-08-30 读数，来自 r/cscareerquestions 与 r/salesengineers 的公开帖。社区自身有立场偏向，作为舆论证据使用，不作为事实结论。）

29. 「AI 赋能」买成了六轮把 JD 喂给模型

一个约 6000 人的组织雇顾问做「AI 赋能」，流程是：把团队的岗位说明书喂进模型，看吐出什么建议，拿给团队要反馈，反馈再喂回模型，再跑一轮。跑到第六轮，产出是给管理岗的流行词和给一线岗的空想；与此同时该团队手上明明有用 AI 能显著提效的任务，没人来问。

这一条界定了「AI 赋能」不能长成什么样：不下现场、不看真实任务、不接触真实数据的赋能，跑多少轮都不会产生结果。（r/ExperiencedDevs，《AI Consultant Frustrations》，2025-07-11，85 赞 / 44 评论。）

来源

任鑫（Mars），《中国 FDE 手册》（fde-arsenal），04-案例库《败 · POC 成功，项目死亡》《败 · 冠军离职，项目无人认领》《败 · 专业边界事故》《败 · 澜码科技》《胜 · 恒岳重工》，03-模板库《客户准备协议》《采纳设计检查表》《交付病历》，02-方法论「培养旅程」04 / 07 站。第一人称手册，主张企业内部培养；其中案例多为脱敏虚构或复合案例，公司与数字为示例。公开发布地址【待核实】。
Gartner 新闻稿，2024-07-29。https://www.gartner.com/en/newsroom/press-releases/2024-07-29-gartner-predicts-30-percent-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025
MIT NANDA，《The GenAI Divide: State of AI in Business 2025》。https://mlq.ai/media/quarterly_decks/v0.1_State_of_AI_in_Business_2025_Report.pdf
RAND Corporation，《The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed》，2024。https://www.rand.org/pubs/research_reports/RRA2680-1.html
Paul Rogers & Marcia Blenko，《Who Has the D?》，Harvard Business Review，2006-01。https://hbr.org/2006/01/who-has-the-d-how-clear-decision-roles-enhance-organizational-performance
Jeff Hiatt，《ADKAR》，Prosci，2006。https://www.prosci.com/methodology/adkar
Everett M. Rogers，《Diffusion of Innovations》，Free Press，1962 / 第 5 版 2003。
Google PAIR，《People + AI Guidebook》。https://pair.withgoogle.com/guidebook/
Kerry Rodden、Hilary Hutchinson、Xin Fu，CHI 2010（HEART / GSM）。https://kerryrodden.com/heart/
BCG，《The Leader's Guide to Transforming with AI》（10-20-70）。https://www.bcg.com/featured-insights/the-leaders-guide-to-transforming-with-ai
Neil D. Lawrence，《Data Readiness Levels》，arXiv:1705.02245，2017。https://arxiv.org/abs/1705.02245
Perspective AI，《The Forward Deployed Engineer Playbook》，2026-06-12。https://getperspective.ai/blog/the-forward-deployed-engineer-playbook-how-to-structure-run-and-scale-an-fde-function-in-2026
Palantir，《Deploying Full Spectrum AI in Days: How AIP Bootcamps Work》。https://blog.palantir.com/deploying-full-spectrum-ai-in-days-how-aip-bootcamps-work-21829ec8d560
Reddit r/ProductManagement，《My PM role seems to be quite... threatened...》，2026-08-08。https://www.reddit.com/r/ProductManagement/comments/1vj6yeu/
Reddit r/ExperiencedDevs，《AI Consultant Frustrations》，2025-07-11；r/cscareerquestions 关于 FDE 岗位的多个公开帖。票数均为 2026-08-30 读数。
王一荔，《你招的不是 FDE，是月薪十万的外包》，微信公众号「一荔说OPC」，2026-08-25。
Lydia，《别急着招 FDE：真正需要升级的，是你现在的工程师》，微信公众号「IT斜杠女青年」，2026-08-24。
《参加了几个 FDE 培训，啥也没学到》，微信公众号「数据驱动智能」，2026-08-17。立场文，数字无出处。
智盛汇，《六刀剑指「主流」FDE 定义》及其引发的行业讨论，微信公众号。案例细节未经独立核实。
界面新闻，《澜码科技因融资不顺陷欠薪风波》。https://www.jiemian.com/article/12388136.html
大野耐一，《丰田生产方式》，1978（英文版 1988）。

反模式清单：26 种失败模式 ​

怎么用这一页 ​

本页目录 ​

A 组：进场与选题 ​

1. 用样例数据做 POC ​

2. 「数据没问题，你先开始」 ​

3. 一期铺八个场景 ​

4. 三个 D 互相等 ​

5. 把老板的焦虑当需求做 ​

B 组：需求与 Context ​

6. 会议室里的 5 Whys ​

7. 把「更好的报表」直接当需求做 ​

8. 只访谈最配合的人 ​

9. 越界替业务做专业判断 ​

10. 用发生频率排列排查顺序 ​

11. 把免责声明当安全设计 ​

C 组：数据 ​

12. 不做数据剖面就开始建模 ​

13. 脱敏之后问题已经不能解了 ​

14. 两个数打架时选一个信 ​

D 组：构建 ​

15. 追测试集分数，不追「老师傅会不会这么说」 ​

16. 先做平台，后做场景 ​

17. agent 自作主张，而没人看它的指令输出 ​

18. 技术债静默累积 ​

E 组：上线与采纳 ​

19. 逼一线学一个新门户 ​

20. 用考核逼使用 ​

21. 没有埋点的上线 ​

22. 把「上线」当成「做完」 ​

23. 把有价值的人际接触也自动化掉 ​

F 组：组织与商业 ​

24. 冠军离职，项目无人认领 ​

25. 最重的那段活在合同里值零 ​

26. 内部 FDE 退化成内部 Professional Services ​

附：三条不属于项目、但属于这一行的反模式 ​

27. 把「FDE」当成一个可以速成的头衔 ​

28. 更多责任，更少权力 ​

29. 「AI 赋能」买成了六轮把 JD 喂给模型 ​

延伸阅读 ​

来源 ​