夜雨聆风上个月在一个项目启动会上，产品总监用大模型现场跑了一段 Demo。自动分析用户反馈、提取情感倾向、生成回复建议，甚至画了个简单的趋势图。效果很惊艳。
总监放下电脑，说："这个功能，两周能上线吧？"
技术负责人沉默了三秒。"我先评估一下。"
这个场景，如果你参与过任何一个 AI 相关的软件项目，大概率经历过。会议室里那几秒钟的沉默起于一个简单的事实：技术负责人知道，Demo 里那个准确率 95% 的 AI，到了真实生产环境里，可能连 60% 都保不住。
而这，还只是开始。
每个 AI 项目的早期都有一个共同点：Demo 太好看了。好看得让人忘了问一个问题。这段演示到底是在什么条件下跑出来的？
答案几乎是固定的。精选的数据，封闭的场景，有限的边界条件，零干扰的运行环境。开发者在准备 Demo 时做的第一件事不是写代码，是选数据。把边缘 case 剔掉，把脏数据洗掉，把 happy path 留下来。不是作弊，是 Demo 这种形式本身决定的。演示就是要好看。
但问题也出在这里。Demo 越好看，它越像魔术。魔术师不会告诉你道具是怎么准备的，观众也不想琢磨——观众只想被震到。
工程落地的逻辑完全反过来。生产环境从来不关心你的模型在干净数据上表现多好。它关心的是：当用户输入一段含 3 个错别字、夹杂方言、语义模糊甚至自相矛盾的文本时，你的系统会不会炸。当数据量从 Demo 阶段的 500 条飙到每天 50 万条，响应时间还能扛住几个 QPS。当一个边缘 case 触发了另一个边缘 case，形成连锁反应，你的监控能不能在用户发现之前拦住它。
这件事，Demo 一个字都不会告诉你。
我管这里面的差距叫"能力上限"和"能力下限"的落差。能力上限，是 AI 在最优条件下能做到什么。能力下限，是 AI 在最差条件下不会跌破什么。
Demo 展示的是百米冲刺的成绩。工程要的是马拉松配速。你可以用冲刺的速度跑第一个 100 米。但没有人能用冲刺的速度跑完 42 公里。
产品人员和业务领导看到的是上限。工程团队要兜住的是下限。两者之间隔着 3 到 12 个月的工程化工作。而这段距离，刚好被一台效果惊艳的 Demo 遮住了。
当决策者看完 Demo 之后，事情就开始变味。
第一个变化砸在需求上。立项时的需求文档有 12 个功能点。做完 Demo 后产品总监觉得 AI 能做的远不止这些。加上智能推荐行不行？加上自动报表行不行？加上多语言行不行？一周后需求文档变成了 28 个功能点。一个没删，加了 16 个。
产品经理的想法我能理解。既然 AI 在 Demo 里几秒钟就分析完了一组数据，那把分析范围扩大 3 倍，应该也不在话下。这个逻辑直觉上成立，技术上不成立。AI 的能力不是线性的。覆盖场景每扩大 1 倍，边界条件的复杂度可能扩大 10 倍。但这件事，Demo 不会帮你算。
第二个变化落在工期上。技术团队估了 3 个月，领导看完 Demo 后直接砍到 1 个月。"AI 不都帮你写代码了吗？怎么还要那么久？"
这句话我听过太多次了。它的杀伤力在于，它背后有一个半真半假的逻辑。AI 确实能加速某些环节：原型搭建、简单模块的代码生成。但它不能加速需求澄清、系统设计、边界条件排查、异常流校验、联调测试。而这些，恰恰是占工时最大的部分。你代码写得再快，不知道要写什么的时候，AI 帮不了你。
第三刀砍在预期上。Demo 阶段 95% 的准确率，变成了领导心里的及格线。低于这个数就是"你们没做好"。
但那个 95% 是在一个精心挑选的 500 条测试集上的表现。换一批数据，结果可能是 72%。换到真实用户场景，可能是 61%。数据已经进到决策者的认知里了，改不掉。
你看，传导链条就这么完成了：Demo 震撼拉高了预期，预期膨胀了需求，需求压缩了工期，工期逼低了质量。这就是 AI 项目里的"不可能三角"——在一个已经被挤压的周期内，用超出承载范围的功能清单，交付一个够得上 Demo 水平的产品。三角里只能保住两个。但领导要三个都保住。
产品经理卡在中间，两头受气。上面说"人家 Demo 都做出来了你怎么不行"。下面说"这个真不行，至少再加一个月"。技术负责人更惨。他说的每句话听起来都像借口。因为 Demo 确实跑出来了，视频确实录了，PPT 确实写了。你说有技术瓶颈？放 Demo 里跑一下不就行了？
这时候就会出现 AI 项目里最危险的一句话："先做着吧，有问题上线再说。"
上线之后的问题比想象中多，但没人意外。网上那些翻车的 AI 客服截图、社交平台上疯传的生成灾难，本质上都是同一个剧本：Demo 阶段被小心翼翼绕开的所有坑，上线后被真实用户用脚踩了个遍。
真正有意思的地方是，幻觉产生了这件事本身不可怕。可怕的是为什么每次都会产生。明明上一次就栽了，下一次 Demo 一来，又陷进去了。
这个循环之所以这么顽固，背后藏着三重认知陷阱。
第一重，幸存者偏差。你能看到的 AI 项目，都是拉到台前被展示的。失败的不会被打包成案例分享在朋友圈里。你看到的成功 Demo 越多，就越觉得 AI 什么都能做。但你没看到的，可能比看到的多一个数量级。那些需求膨胀到一半发现根本做不了然后砍掉的项目，没人写复盘。
第二重，能力外推。大模型在对话任务上表现越好，人们就越容易把它"会聊天"这件事外推到"什么都会做"。这是一种很本能的思维惯性。一个东西足够聪明，它就应该能胜任你交给它的任何事。但大模型的能力分布是极其不均匀的。常识问答接近专家水平，数学推理像初中生，因果推断像三岁小孩。不亲自踩一遍，你永远不知道边界在哪。
第三重，沉没成本。一旦 Demo 过了、立项了、预算批了、领导点头了，推翻重来的代价就不再只是技术层面的。承认 AI 能力有差距，等于承认前期判断错了。没有几个人想在会议室里做这个承认。而且越往后拖，纠正的代价越大，承认的意愿越低。于是一整个团队骑着老虎下山，一路祈祷老虎别回头。
三重陷阱叠在一起，这个幻觉循环就很难靠自己停下来了。Demo 震撼了所有人，没人问边界条件。上线时间逼得太紧，没人有时间做压力测试。出问题了也不敢大幅调整，因为沉没成本已经太高了。下个项目来了，再循环一遍。
那怎么破？
不是靠"少信 AI""理性评估"这种虚话。你需要的是几件具体的事。
第一件，Demo 之后立刻跑一轮压力测试。在干净数据上拿了 95% 之后，换一组脏数据进去：错误输入、超长文本、多语言混合、恶意攻击性输入。让决策者坐在屏幕前，看着 AI 在这些极端条件下怎么翻车。一次翻车演示，比 10 页技术评估报告有用。
第二件，把"Demo 指标"和"工程指标"分开汇报。Demo 只报最好的，工程只报最差的底线。两个数字的差距，就是工程化的真实工作量。决策者看不懂技术细节，但看得懂数字差距。
第三件，Demo 通过后别急着立项。先留两周，在最小可用范围内接真实数据跑起来。看看那些 Demo 阶段刻意绕开的边界条件，在真实场景中出现的频率有多高。你会发现有些你以为只会出现 1% 的情况，实际上频率是 15%。
第四件，从一开始就把"衰减预期"写进排期表。别等到上线后再说"这里有个 gap"。立项会上直接摊开说：Demo 准确率 95%，第一个版本上线目标定 65%，第二个迭代 75%，第三个迭代接近 85%。让衰减成为计划的一部分，而不是事后才发现的事故。
AI 最大的风险，从来不是它不够强。是它看起来太强。
当产品经理、业务领导甚至工程师自己，都被 Demo 的效果说服，觉得 AI 什么都能做了、落地就是时间问题了——真正的工程折磨才刚刚开始。
所以下次看完一个惊艳的 AI Demo，别急着排期。先问三个问题。
它在脏数据、异常输入、边界条件下，表现如何？
Demo 的能力上限和工程的能力下限之间，衰减算过吗？
如果上线后准确率从 95% 跌到 60%，你的用户体验预案是什么？
幻觉不怕被识破。怕的是从来没人去问。