《FDE案例100》方法论特辑 · No.18｜反面教训：比成功更值钱的失败模式

失败模式一：为了 AI 而 AI#

这是最隐蔽的一种，因为它看起来特别”正确”。

NO.20 里有个例子我印象极深。一家金融机构的业务部门抱怨找设计师做营销图片太慢，想用 AI 提效。需求合理吧？可金融机构有数据合规要求，不能直接用外部模型，最后只能本地部署。结果呢——花了不少钱搭了一套 AI 图片生成系统，生成出来的图片实际不能用。最后 IT 部门完成了”AI 转型”，合规部门完成了数据安全要求，领导也可以说企业完成了 AI 转型。业务部门呢？还是回去找设计师做图。

从企业经营的角度看，什么都没有改变。

当 AI 变成一项”要完成的指标”，它就会离业务越来越远。

失败模式二：高估 AI、低估行业难度#

NO.10 的作者讲过一个国内电商横向价格对比的项目。他当时知道这事不容易，因为市场上已经有专门做电商比价的公司，人家背后有数据、有接口、有各种门道。但他还是判断：AI 应该能解决其中百分之七八十的问题。

真做起来才发现，现实复杂得多。国内电商平台的风控和反风控一直在博弈，平台对快速价格查询、模拟人为操作有很强的限制。即使找到一个方案，也可能很快被平台策略堵掉。最后交付周期拉长，能覆盖的场景不断缩小。

他复盘时说的话特别实在：如果一个行业里已经有公司专门靠某个问题生存，你就该先认真研究——它到底解决了什么难点，掌握了什么信息差，为什么值得一家公司长期投入。 本质上是行业认知不够。

失败模式三：需求调研不深，一路返工#

还是 NO.10，另一个例子是学校批改作业和智能推题。需求听起来特别顺：先批改，再给分，再分析，然后按学生情况推题，题目还来自学校自己的题库。

可真正拆开，问题一大堆：准确率到底要多少？批改时效要求是什么？哪些科目？批改频率多高？题库要结构化到什么程度？推题有什么规则？学生一道难题做错后，是降低难度，还是围绕同一知识点给更难的题？人工在哪个环节介入？

这些问题前期没问清楚，后面就会不断出现需求变化。过去这叫”产品经理需求没定义清楚，研发不断返工”；到了 AI 时代本质没变，只不过返工成本还可能直接表现成大量 Token 消耗和交付成本。

失败模式四：有系统 ≠ 有 AI 准备#

这个坑特别容易骗人，因为从纸面上看，你会以为客户早就”准备好了”。

NO.14 的客户是一家省属国企的一级子公司，有 OA、有 ERP、有数据中台，还有自己的信息化部门，在国企里数字化建设已经算领先。但真进去才发现，很多企业知识根本没被沉淀。法务审核过很多合同，最后只留下一份改完的合同，中间为什么改、哪些条款关键，都在法务脑子里。

NO.18 更典型。一家生物科技上市公司，听起来数字化程度应该很高。可销售数据散落在不同系统和个人手里，客户关系在销售个人手上，提成靠 Excel 人工统计，数据延迟一个月以上。作者说得直白：业务领先和数字化领先，完全是两回事。 企业有 ERP 有 OA，但系统老旧、数据不通，大量关键数据不在系统里。这种情况下直接上大模型，很容易变成一次性的演示项目。

失败模式五：过早追求标准化产品#

做项目的人都有个本能：做完一单，就想把它包装成标准产品卖给下一批客户。案例里反复提醒的恰恰是——别急。

NO.08 的作者说得很清楚：先标准化的应该是方法，产品可以先放一放。 因为 AI 技术变化太快，一开始就想把某个功能沉淀成标准产品，很容易又回到”拿着锤子找钉子”的老路。

NO.20 的作者补了一刀：同一行业、规模差不多的企业，底层的数据基础、口径、业务流程都可能差很多。所以他没有急着把方案做成标准产品，而是说了一句很关键的话——方法论可以复用，但底层的数据和业务逻辑，未必能直接复制。

NO.23 从另一个角度讲：绝对标准化的产品，竞争烈度极高，而且对真正想做 AI 转型的企业来说不够深。所以 FDE 更适合做的是：底层能力标准化，业务解决方案保持一定程度的定制化。说白了，能被反复搬走的，一直是方法论，不是一张现成的图纸。

失败模式六：忽视效果归因#

这一条最容易被忽略，因为它发生在”项目成功交付之后”。

NO.22 的作者讲了一个很坦率的故事。那个跨境电商项目交付结束后，客户把团队权限移除了，后续的营收、广告成本、利润数据，他们没拿到完整的。更麻烦的是，他们当初没有设计”效果基线”，没法系统记录到底省了多少时间、减少了多少成本、对营收和利润产生了多少影响。

所以他说：如果再重做一遍，会在一开始就设计好一套效果基线——上线前记录人工处理需要多少时间，上线后持续记录，关键环节尽量找到可量化的指标。否则你交付的只是一个”能跑的 AI”，而不是一套能证明自己创造了多少价值的方案。

失败模式七：只顾节点 ROI，忽视组织级 ROI#

最后这一条，我觉得是七种里最”高级”、也最难自查的坑。

我们前面提到的节点效率，往往都很好看：审核从 15 分钟压到 3-5 分钟，跨部门报告从 3-5 天变成 10-20 分钟。但请停一下，追问一句：这些节点的提效，真的传导到业务和组织的整体收益了吗？

典型陷阱是这样的：产品、产研团队先用上 AI，效率大幅提升，但前端业务没跟上——上游产出变快，下游消化不变，组织整体并没有提效；同时产研在持续消耗 Token，成本实打实地增加。最后的结果是”产品提效了，公司没有”。

NO.16 里那句”漏油的车不用谈省油”，说的就是这件事：如果架构设计得不好，Token 一直在往下掉，你根本不用谈节省成本。 调试成本、长期运行成本，都要在一开始就设计进 ROI。这个话题我们在 No.05 里专门拆过，这里不再展开。

那到底该怎么办？#

七种失败模式写下来，你会发现它们指向同一件事：AI 的风险，几乎都不在模型本身，而在模型之外的业务、数据和组织。

所以几个可以带走的动作：

• 立项前先问”这件事不做 AI 行不行”，逼自己排除”为了 AI 而 AI”；
• 进一个行业，先搞清它为什么难，别默认模型能碾过去；
• 需求别停在会议室，追到能验收、能连到钱的口径；
• 有系统不等于有数据，先做数据审计再谈 Agent；
• 方法标准化，产品慢一点；
• 上线前就设计好效果基线，别等交付后才想起来要证明价值；
• 算 ROI 时，把节点 ROI 和组织级 ROI 一起算。

成功经验告诉你”怎么赢”，失败模式才告诉你”别怎么输”。 而后者，往往是团队能活着走到下一个项目的关键。

这个系列也快到尾声了——下一篇是收官篇，我们把 24 个案例归成六类场景，讲清那句贯穿全季的话：方法可复用，场景无边界。