——这是我做过最烂的一个AI项目。我决定把它全部写出来。

作者按 这篇讲失败。真实的失败，不是那种"遇到困难但最终克服了"的励志故事。是那种让我在凌晨两点盯着天花板、反复想"我到底哪里做错了"的失败。我之所以决定写出来，是因为我发现，比"学习别人的成功"更有价值的，是"理解别人是怎么失败的"。

Karpathy说他"从未感到如此落后"。我想说，我也做过让自己感到羞耻的项目。但那次失败，是我付出最贵、也学到最多的一次学费。

一、项目启动：一切看起来都很完美

客户背景

2024年初，我通过一个行业群认识了李总。

李总在广东做连锁餐饮，旗下品牌有32家直营门店，主打中高端粤菜。

他是个很有远见的人，在同行还在讨论"要不要数字化"的时候，他已经把门店的收银系统、会员系统、供应链系统全部打通了。

他来找我，是因为看了我的一篇关于"AI供应链优化"的文章。

第一次见面，他直接说：

"我知道你的文章，讲得很实在，不是那种只会吹概念的人。我有个具体的需求——我们每年在食材浪费和采购超支上损失大概400-500万，你能不能帮我用AI解决这个问题？"

我当时心里咯噔了一下——400-500万的损失，这是一个巨大的数字。

但同时，我也感到兴奋：这是一个可量化的痛点，数据可能有，场景清晰，如果做成了，ROI非常漂亮。

我们聊了三个小时。李总给我展示了他们的数据体系：

• 三年的食材采购记录（按门店、按品类）
• 两年的菜品销售记录
• 供应商的历史价格数据

我看完之后，当时判断：这个项目可以做。

方案设计

基于李总的需求，我设计了一个三模块的AI系统：

模块一：需求预测系统 根据历史销售数据、季节规律、节假日等因素，预测未来7天每家门店的食材需求量。

模块二：智能采购建议系统 结合需求预测和供应商价格历史，自动生成最优采购建议（买什么、买多少、从哪个供应商买）。

模块三：浪费监控系统 每天记录各门店的食材领用和废弃数据，实时监控浪费率，异常时自动预警。

方案说明会上，我给李总展示了一张ROI测算表：

李总看完这张表，沉默了大约30秒，然后说：

"好，我们签。"

合同签了。首款60万，到账了。

我开始做项目。

二、项目推进：第一道裂缝

数据地狱（第1-4周）

拿到数据访问权限的那天，我打开数据库，第一眼就感觉不对。

李总说的"三年采购记录"，是真的有三年的数据。

但当我开始做数据探查的时候，发现了一个让我头皮发麻的问题：

这三年的数据，是三套完全不同的格式。

2021年的数据在一个老ERP系统里，字段名是中文的，食材的计量单位混乱（有些用"克"，有些用"斤"，有些用"箱"，没有统一标准）。

2022年，他们换了一套新的供应链系统，数据结构完全重新设计了，和2021年的字段名字没有任何对应关系。

2023年，因为疫情后业务调整，他们手工在Excel里补录了大量数据，格式又是另一套。

更严重的是：三套数据里，食材的命名也不统一。

同样是"鸡翅"，2021年的数据里叫"鸡翅膀"，2022年叫"翅中"，2023年叫"鸡翅（中）"。

这不是一个小问题。这是一个需要几个月才能解决的数据工程问题。

我意识到，我在签合同之前，犯了一个严重的错误：

我没有做"数据质量评估"。

我在合同启动前，应该用1-2周时间做一份数据质量报告，然后基于数据质量重新评估方案的可行性。

但我没有。我基于"数据看起来挺完整"的印象，就拍板签了合同。

我的第一个错误决定

面对这个问题，我做了一个在当时看起来很合理、但事后证明是灾难性的决定：

我决定硬撑，自己解决数据问题，不告诉客户。

理由是：如果我告诉李总"你的数据有问题"，他可能会觉得这是我在推脱责任，或者会认为我在找借口延期。

我不想在项目刚开始的时候就给客户留下"事情比预期复杂"的印象。

于是我花了4周时间，试图通过Python脚本把三套格式的数据手工清洗统一。

4周后，我清洗完成了大约60%的数据。剩下40%，要么逻辑不通，要么缺少关键字段，无法通过自动化处理，必须人工核对。

但我一个人处理不了这40%。

而且，我4周没有给客户任何进展报告。

李总开始发消息问：项目进展怎么样了？

我说：正在做数据对接，进展顺利。

这是我说的第一句谎话。

三、中期加速：危机爆发

技术方案的根本缺陷（第5-8周）

数据问题还没解决，另一个问题出现了。

我开始搭建需求预测模型的时候，发现餐饮食材的需求预测，比我预想的复杂10倍。

原因在于：餐饮的需求受到的影响变量太多，而且很多变量的数据根本不存在于李总的系统里。

以鸡翅的销量预测为例：

影响鸡翅销量的变量包括：

• 当天的菜单（有没有推荐鸡翅菜品）
• 当天的天气（下雨天很多人点外卖，上门的少）
• 当天是否有团体预订
• 是否有附近竞争对手搞活动
• 社交媒体上最近有没有和鸡翅相关的热点
• 当天的促销活动（半价鸡翅活动当然销量更大）

这里面，只有"菜单"和"团体预订"的数据在李总的系统里。其他变量，不存在。

没有这些变量，模型预测出来的结果，准确率大概在60-70%之间。

什么意思？就是10次预测里，有3-4次是偏差超过20%的。

对于普通的库存预测，70%准确率还勉强可以接受。

但对于餐饮食材来说，这个准确率是灾难性的：

• 如果预测偏高，买了太多，食材过期浪费，成本上升。
• 如果预测偏低，买了太少，某道菜做不出来，客户投诉。

这不是AI帮了李总，这是AI给李总制造了新的麻烦。

演示会议：信任崩塌的那一刻（第9周）

第九周，李总催着要看阶段性成果。

我做了一个演示系统，展示了三个门店的食材需求预测结果。

为了让演示效果好看，我特意选了预测准确率最高的几个品类展示。

演示开始，我展示了鸡肉类食材的预测：准确率83%，比较不错。

李总在看，没说话。

然后他问了一个问题：

"你演示的是鸡肉类。我们的食材里，牛肉的浪费最严重，能不能看一下牛肉的预测？"

我切换到牛肉的预测界面。

沉默了3秒。

系统显示：明天2号门店的牛肉需求量是8.2公斤。

李总说："明天2号门店有一个40人的企业团建，提前一周预订的，在系统里都有记录。他们点的是牛肉主题套餐。实际需要的牛肉，应该是35-40公斤，不是8公斤。"

我没有说话。

我知道原因：AI的预测模型没有把"预订信息"纳入输入变量。因为当时数据清洗还没完成，预订数据的接口还没对接进来。

但在那一刻，我没法解释这些。

因为如果我解释，就意味着我要承认：项目已经进行了9周，但系统连最基础的预订信息都没有接入。

李总看着我，说了一句话：

"你当初跟我说，上线后可以做到误差控制在15%以内。"

这句话，像一根针扎进我的心里。

因为我确实说过这句话。但我说这句话的时候，是基于理想数据条件下的假设，而不是基于他实际的数据质量。

四、项目死亡复盘

第二个错误

那天演示会之后，李总给我发了一条消息：

"我需要你下周一给我一份详细的项目进度报告，包括：现在做到了哪里、离当初承诺的目标还差多远、以及你的解决方案。"

我花了整个周末写那份报告。

写报告的过程，是一次非常痛苦的自我审视。

我把项目开始至今的每一个决策、每一个假设，重新梳理了一遍。

我发现，这个项目从立项的那一刻开始，就有一个根本性的错误：

我在签合同之前，做出了超出数据支撑的承诺。

我承诺"准确率控制在15%以内"，但我没有评估过他的数据质量是否支撑这个准确率。

我承诺"项目6个月上线"，但我没有考虑过数据清洗需要多长时间。

我承诺"年化ROI 3-5倍"，但这个数字是基于我的理想假设，不是基于他的真实业务约束。

我卖给了李总一个我自己都不确定能不能实现的承诺。

这是这个项目最根本的错误，不是技术问题，不是数据问题，是诚信问题。

周一的会议

周一上午，我带着那份报告，去见了李总。

我没有用PPT。我直接跟他说：

"李总，我需要先跟你道歉。"

他抬起头，看着我。

"在项目启动之前，我没有认真评估你们的数据质量，就给出了准确率承诺。这个承诺是我在不充分了解实际情况的前提下做出的，是错误的。"

"现在项目进行了9周，系统还有很多问题没有解决。我有责任把真实情况告诉你。"

然后我把报告给他看：

李总看完这份报告，沉默了很长时间。

然后他说了一句话：

"我现在最难受的，不是进度慢，不是准确率达不到。是你9周没有告诉我实情。"

这句话，比任何指责都更让我难受。

五、终止与反思

合同终止

最终，我和李总协商终止了合同。

退款方案：退还剩余款项中的50%，即30万。

我实际拿到的：60万（首款）- 30万（退款）= 30万。

我实际付出的：9周全职时间 + 外包数据工程师费用12万 + 情感成本无法计量。

这30万，是我当时最亏的一个项目。

但如果我继续硬撑下去，结局会更惨：系统无法达到承诺标准，李总口碑受损，我也会承担更大的法律风险。

及时止损，是这件事里我做的唯一一个正确决定。

六、死亡后的重生：我从这个项目学到了什么

教训一：数据资产评估必须在签合同之前完成

这是这个项目给我最刻骨铭心的教训。

在AI落地项目里，数据质量决定系统上限。

在签合同之前，我现在会做一份标准的"数据资产评估报告"：

这份评估，需要在签合同之前完成，需要2-4周时间，需要收费。

是的，评估阶段就要收费。

为什么？因为这个评估本身就是有价值的工作，而且它保护了双方：

• 保护你不会因为错误的假设做出无法兑现的承诺
• 保护客户不会因为错误的项目立项浪费钱

我现在的所有项目，都从"数据评估阶段"开始，价格是3-5万，交付一份数据质量报告和项目可行性评估。

签了这个阶段的，才进入正式开发。

教训二：承诺结果，不要承诺指标

在李总的项目里，我犯了一个典型的技术人员错误：

我承诺了一个技术指标（"准确率控制在15%以内"），而不是一个业务结果（"帮你把食材浪费降低X%"）。

这两个承诺，表面上相似，本质上完全不同。

承诺技术指标的问题：

• 客户不理解指标的真实含义
• 指标的计算方法可以被操纵（选有利的品类计算）
• 指标好但业务没改善，客户仍然不满意

承诺业务结果的优势：

• 客户能直接感受到价值
• 计算方式透明，无法作弊
• 结果好，客户自然续约

我现在的承诺方式：

❌ 旧方式："系统预测准确率达到85%以上"

✅ 新方式："系统上线3个月后，与对比基线相比，食材浪费率降低20%以上。如果未达到，退还当月服务费。"

教训三：分阶段交付，每阶段设置Go/No-Go节点

李总项目死在哪里？

死在"一次性承诺6个月交付全部功能"这个决策上。

如果我当时把项目分成三个阶段：

这个分阶段方案，有三个好处：

第一，风险可控：任何一个阶段出了问题，损失都是有限的。

第二，信任递进：每个阶段交付一个可验证的成果，客户的信任是一点一点建立的。

第三，学习迭代：Phase 2的原型阶段，就是用来发现"我不知道我不知道的事情"的。

我在原型阶段发现"预订信息没有接入"，后果是重新设计Phase 2的技术方案。

但如果这发生在Phase 3，后果就是整个项目的交付危机。

教训四：透明，永远比面子重要

这是最后，也是最重要的教训。

在整个项目里，我最大的错误不是技术判断失误，而是：

在知道问题的时候，选择了隐瞒，而不是透明。

第一周发现数据问题的时候，如果我立刻告诉李总：

"李总，我在做数据分析，发现你们的历史数据有三套不同的格式，清洗统一这些数据需要额外4-6周的时间。这个情况会影响我们的原定计划。我建议我们重新梳理一下项目节奏。"

结果会是什么？

李总可能会不高兴。但他不会在9周之后才发现这件事。

他不会在演示会上被那8公斤牛肉的预测结果打脸。

他不会感到被欺骗。

客户能接受项目出问题，但接受不了被蒙在鼓里。

问题出现的时候，第一时间告诉客户，是FDE这个职业最基本的职业道德。

也是最有效的客户关系维护方式。

七、重生：用正确的方式，重做一个类似的项目

这个故事还没结束。

合同终止6个月后，我重新做了一个餐饮食材优化的项目。

但这次，我用了完全不同的方式。

客户：广东另一家连锁餐饮，8家门店。

切口（用场景手术法重新定位）：

不做"全面的需求预测系统"——那需要太多变量，数据要求太高。

只做一件事：牛肉、海鲜等高价值食材的当日实际使用量监控。

核心逻辑：不预测未来，而是追踪今天用了多少，和采购了多少对比，找出哪里在浪费，以及为什么浪费。

方案：

技术实现：简单得多。不需要复杂的预测模型，只需要一个数据采集Agent + 对比计算 + 企业微信推送。

数据要求：只需要菜品销售记录（已有）和食材用量记录（需要新增扫码环节）。

预期效果：不承诺"节省多少钱"，只承诺"让主管能在24小时内发现哪里浪费"。

结果：

项目4周上线，运行3个月后：

• 发现了两个门店的厨师长在用高价食材"以次充好"（用便宜的食材顶替菜单标注的高价食材）
• 发现了一个门店的供应商少量多送的问题（收货登记的重量和实际重量有偏差）

这两个发现，帮客户每月减少损失约3.5万元。

系统成本：API费用约600元/月。

ROI：约58倍。

客户在项目上线第二个月，主动追加了另外5家门店的改造。

尾声：失败是最诚实的老师

Karpathy做了MenuGen，被Gemini一个提示词取代，他说"那个App不该存在"。

他没有假装MenuGen从未存在过，他没有删掉那段历史。

他把它写进了Software 3.0的叙事里，变成了一个更深刻的理解的起点。

我的李总项目，也是这样。

它不是我履历上的污点，它是让我彻底理解"为什么场景手术法如此重要"的那次手术。

切口找错了，技术再好也没用。

数据不支撑，承诺就是谎言。

透明，永远比面子值钱。

这三句话，我现在写在工作台旁边的便利贴上。

每次接新项目之前，我都会看一眼。

最后，我想对所有正在做AI落地项目的人说：

你们一定会遇到项目出问题的时候。

那个时候，你们会面临一个选择：是告诉客户实情，还是先撑着，希望自己能在被发现之前把问题解决掉。

我的建议是：告诉客户实情。

不是因为这样做的后果更好（有时候后果一样惨）。

而是因为：你做这行的根基，是信任。

一次失败的项目毁不了你，但一次失去信任的项目会。