Demo 幻觉：当 AI 让每个人都觉得自己快做完了
AI 让 demo 的成本接近于零，但它制造了一个更危险的问题：我们越来越容易把「能演示」误认为「快上线」。从 Demo 到生产系统的鸿沟，才是大多数 AI 项目真正失败的地方。
最近我发现一个现象：公司里几乎所有人都在做 demo。
每个人都能用 AI agent 做出非常漂亮的 demo——可能就是一个页面，底层的数据也是 agent 生成的。大部分只是静态页面，少部分带点简单逻辑。
AI 让 demo 的成本接近于零，但它也制造了一个新问题：大家越来越容易把「能演示」误认为「快上线」。
当每个人都能轻松做出 demo，一个问题就来了：AI 让大家觉得做什么都变得又便宜又快，但 demo 并不等于产品。一个真正可用、稳定、支持多人长期使用的产品，和 demo 之间差距很大。demo 的视觉欺骗性太强了。
以前 vs 现在
以前，产品要做 demo，需要产品经理画原型、设计师出图、研发做前端后端，周期很长。老板自然知道这只是个方向，离开发完成还远。
但现在变了。产品、算法、运营、PD，甚至实习生，给 AI 一堆提示词就能做出一个能点、能跑、能演示的东西。老板一看：这不是已经做出来了吗？工程团队实现一下不就完了？
这句话其实非常要命。
演示链路跑通 ≠ 真实业务系统落地
演示链路跑通，和真实业务系统的落地，差距很大。很多 demo 可能只完成了 10% 的工作。
demo 只意味着完成了 10%，而大家的预期是已经完成了 80%。
这个数字不是拍脑袋。Agentik-OS 基于真实企业部署经验发现：初始 PoC 通常需要 90% 的重写才能达到生产级别。2026 年 Stack Overflow 企业开发者调查显示，78% 基于 open-source 框架构建的 AI Agent 项目最终被放弃或完全重构。Gartner 更是预测，到 2027 年底，超过 40% 的 Agentic AI 项目将被取消。
Demo 和工程系统之间的差距，不是缝隙，是鸿沟。
Demo 和工程系统到底差什么？
demo 是给一个人用的，追求自己用着爽，想怎么改就怎么改。它只能证明这个想法好像还行，可以跑通。
但一个真正的工程系统要解决的问题就多了：
| 维度 | Demo | 工程系统 |
|---|---|---|
| 用户规模 | 单人使用，自己点一下跑通 | 百人千人并发，网络抖动、接口超时 |
| 数据 | 伪造的假数据，干净整齐 | 脏数据、边界值、多语言、超 token 限制 |
| 异常处理 | 不需要，happy path 就行 | 每一步都可能失败，需要回滚、重试、降级 |
| 权限控制 | 无 | 角色体系、数据隔离、审计日志 |
| 可观测性 | print 一下就好 | 分布式追踪、指标采集、告警体系 |
| 成本 | 跑一次就行 | 月 API 费用从 $5 变成 $50K 的风险 |
| 安全 | 不考虑 | 合规要求（GDPR/CCPA/SOC2/HIPAA） |
| 维护 | 不需要 | 版本管理、灰度发布、回滚机制 |
你的 demo 可能只是自己点一下跑通了，甚至用的是伪造的假数据。
但生产系统面临的是：一百个人同时点，网络抖动、接口超时、权限异常、脏数据、性能瓶颈。这些才是工程真正要解决的问题。
一个典型的案例来自汽车行业：某车企的 chatbot demo 在受控测试中表现优异，但上线后客户满意度暴跌——知识库覆盖不全、冷启动延迟数周、规则化 fallback 无法理解复杂意图，项目差点被搁置。这个模式在各行各业不断重复。
Lusser 定律的残酷数学
可靠性工程中的 Lusser 定律告诉我们：系统的整体可靠性是各组件可靠性的乘积。 对于一个 10 步的 Agent 链，每步 90% 准确率：
0.90^10 = 35.9%
也就是说，64% 的运行会失败。一个 20 步的 demo 看起来完美？在 90% 单步准确率下，整体成功率只有 12%。
ACM Queue 的研究也证实：没有专门的状态管理和恢复机制，复杂长时 Agent 任务的失败率超过 60%。
Demo 幻觉
我觉得现在最大的问题，是产生了一种「demo 幻觉」。
这种幻觉不是 demo 本身单独造成的，而是 demo、AI coding 宣传、组织压力和团队汇报共同叠加出来的。
1. Demo 让进度看起来被大幅压缩
过去做完 PRD，所有人都清楚后面的开发时间还很长。
但现在 demo 一出来，大家就觉得离实现已经很近了。
实际情况是，一分钟就能做出 demo，但要花一个月去优化。
尤其是现在大量工作围绕 agent skill 展开，优化成本更高。skill 本身没有固定标准，好不好用必须运行起来才知道，需要边上线边调整。demo 跑通了，离真正可用、对业务产生价值，还远得很。
很多 AI 项目都是这样：演示时看起来很令人印象深刻，然后就停滞了。演示和生产之间的差距，往往就是大多数 AI 项目失败的地方。
大多数 agent 框架也有类似问题：它们更容易针对演示进行优化。酷炫演示和生产级 agent 经济之间的差距，可能还有 90% 尚未解决。
2. 老板容易把演示链路误判成上线进度
这里老板的认知非常关键。
如果他看到一个 demo 已经完整实现了流程，就会觉得系统很快能上线，忽略中间繁重的工程化工作。对工程不熟悉的老板，这种误判更常见。
Andrej Karpathy 在 2025 年初提出了「Vibe Coding」这个词——「完全沉浸于感觉中，忘掉代码的存在」。对有经验的开发者来说，这是一种有效的工具；但对不懂技术的人来说，「忘掉代码的存在」迟早会追上你。
3. AI Coding 的宣传进一步放大预期
更麻烦的是，现在外部媒体和社交平台对 AI coding 的宣传太密集了。很多叙事都在强调：以前需要工程团队做很久的事情，现在 AI coding 很快就能完成。
这会进一步放大老板的预期。他会认为 demo 和上线之间差的只是「把代码补完整」，而 AI coding 似乎已经解决了这个问题。于是 demo 看起来离产品更近了，工程化工作也更容易被低估。
但真实情况是，AI coding 解决的是一部分代码生成效率问题，不等于解决了系统落地问题。上线不是把页面写出来，也不是把一个流程跑通，而是要把权限、数据、异常、日志、性能、安全、稳定性、运维和业务迭代全部纳入系统。
AI Coding 擅长平地起高楼，而不擅长持续迭代精装修。
Chrono Innovation 的分析精准地描述了 vibe-coded 代码库的特征：没有架构模式、缺少抽象层、没有测试覆盖、硬编码配置遍地——这些在 demo 中完全看不出来，但在你试图扩展或修改时，就变成了技术债的地雷阵。
4. 拥抱 AI 变成组织里的政治正确
还有一层更微妙的压力：拥抱 AI 正在变成一种组织里的「政治正确」。
这里的「政治正确」不是说 AI 不重要，而是说在一些组织里，AI 已经从工具选择变成了态度表态。
现在很多公司不是在讨论「这个场景到底适不适合用 AI」，而是在默认「你必须积极拥抱 AI」。只要你表现出一点懈怠、质疑或者谨慎，就很容易被理解成不够开放、不够进取、不适应变化。
社区里也有类似讨论。有人提到，公司自上而下推动 AI 工具，工程经理和研发都被要求证明自己在用 AI；也有人讨论，个别公司已经把 AI 使用纳入绩效和同事评价，甚至出现了不按要求试用 AI 工具就被处理的极端案例。
这会让团队进入一个很危险的状态：大家不再敢诚实讨论 AI 的边界，只能不断证明自己「正在拥抱 AI」。 于是 demo 更容易被包装成进展，风险更不容易被摆到台面上，工程判断也更容易让位于姿态表演。
5. 团队自己也会继续抬高预期
而我们自己也有责任。不管是算法、PD 还是研发，做 demo 的时候多少会倾向夸大进度，演示时只说「没问题」，反过来进一步拉高老板的预期。员工夸大，老板加预期，最终项目的成功率就很低。
这是一个正反馈回路：demo 看起来越完美 → 预期越高 → 越不敢说真话 → 偏差越大 → 项目越容易失败。
Demo 泛滥带来的问题
demo 泛滥还会带来几个具体问题。
资源浪费
Token 调用就是真金白银。
全公司各个岗位都在做 demo，不少团队的 demo 专用平台都成了瓶颈。更可惜的是，做出来的一大堆 demo 最后没人用、没人维护，也不会销毁，平白占用大量计算和存储资源。
Demo 一旦没有退出机制，就会变成组织里的长期垃圾资产。谁来判断它有没有价值，谁负责维护，什么时候下线，资源怎么回收，这些问题如果没人管，demo 越多，组织负担越重。
稀释成功率，打击团队信心
做 demo 成本低了，大家往往没想清楚就动手试错。
试错成本确实低了，但成功的概率也跟着降低。团队陷入「一直做 demo、一直不落地、一直没有业务结果」的循环，久了打不了胜仗，士气越来越低。
尤其在当下 AI 阶段，大家边摸索边做，对最终业务价值的怀疑，对团队伤害特别大。
MIT NANDA 2025 年的研究给出了一组残酷的数据：95% 的企业级生成式 AI 试点项目未能产生可衡量的业务影响。它们可能在技术上部署了，但没有产生 ROI。
成本幻觉
一个 demo 里看起来成本可接受的 Agent，到了生产环境可能变成成本炸弹。Iris-Eval 的案例：一个单次任务 demo 中花费正常的 Agent，在生产环境中一次任务可能消耗 $40 的 API 调用，而同等任务在优化后只需 $0.12——333 倍的差距。
Salesforce 对 CRM 任务的研究也发现，即使是带 function-calling 能力的 AI Agent，成功率也不到 55%——远低于 demo 环境中的表现。
做 Demo 本身不是坏事
当然，做 demo 成本降低本身是好事。
它让更多人能参与创新，让想法被看见，沟通效率大幅提升，试错成本降低，非技术人员的创造力也被释放出来。
问题出在我们把 demo 错当成了产品。
demo 只是创新的起点，不是交付的终点。
它只能帮我们更快验证方向，但风险在于让我们误判了成熟度和完成度，制造了「快做完了」的错觉，掩盖了工程的真实复杂度，拉高了不合理预期，还让需求无序膨胀。
不管有用没用都先做个 demo，大家反而更少深思熟虑，催生了一大堆看起来炫酷但业务价值不大的伪创新。
怎么避免 Demo 幻觉？
我觉得不是不要做 demo，而是每次 demo 展示时，都应该同时说清楚三件事：
- 这个 demo 验证了什么？
- 它没有验证什么？
- 如果要上线，还差哪些工程化工作？
比如，一个 demo 可能验证了用户路径和交互方向，但没有验证真实数据、权限体系、异常处理、性能、安全、监控和运维成本。
只有把这些边界讲清楚，demo 才能成为创新的起点，而不是预期失控的开始。
更具体的：Demo 成熟度评估框架
在实践中，我建议用下面的框架来评估每个 demo 的真实进度：
| 评估维度 | 已验证 ✅ | 未验证 ⚠️ | 差距说明 |
|---|---|---|---|
| 交互路径 | 用户操作流程可走通 | 边界场景、异常操作 | 需补充错误处理和降级方案 |
| 数据真实性 | 用假数据跑通了逻辑 | 真实数据质量、数据量级、脏数据处理 | 需要接入真实数据源并做清洗 |
| 并发性能 | 单人使用流畅 | 多人并发、峰值压力、慢查询 | 需要压测和性能优化 |
| 权限安全 | 无权限控制 | 角色体系、数据隔离、审计合规 | 需要完整权限系统 |
| 异常恢复 | happy path 无异常 | 网络超时、服务降级、数据不一致 | 需要重试、回滚、降级策略 |
| 可观测性 | 无监控 | 日志、指标、追踪、告警 | 需要完整的可观测性基建 |
| 成本可控性 | 未测算 | 真实 token 消耗、API 成本、扩容成本 | 需要成本模型和预算控制 |
| 运维可持续性 | 无运维 | 版本管理、灰度发布、回滚、SLA | 需要运维体系和值班机制 |
组织层面：建立「Demo 退出机制」
光靠个人自觉不够，组织需要建立机制：
- Demo 过期制度：每个 demo 标注有效期（如 2 周），过期自动下线，除非续期
- Demo 到产品的门槛清单：明确从 demo 升级到试点/上线必须完成的工程化项目
- 定期 Demo 清理：每月一次盘点，无业务进展的 demo 统一回收资源
- 演示必须附「差距声明」：每次 demo 展示，必须附上「这个 demo 没有验证什么」的清单
- 区分创新验证和产品交付：前者追求快，后者追求稳，两者不能混为一谈
技术层面：Eval-Driven Development
Iris-Eval 提出的「Eval-Driven Development」是一个值得借鉴的思路：在写 prompt 之前先定义评估规则，让规则告诉你什么时候才算做完。
- 在真实输入上评估，而不是合成基准测试
- 端到端评估整个 pipeline，而不是单独的步骤
- 将评估集成到 CI/CD 流程中，而不是手动运行
- 监控生产环境的实际表现，而不仅仅是离线评测
你无法容器化模型行为——Docker 解决了环境漂移，但没有任何东西解决了输出质量漂移。评估必须在每次执行中在线运行。
最后
说到底，这个问题背后有人性的推力。
AI 发展太快，每个人都有浮躁和焦虑，这种情绪推着大家不自觉走向全民做 demo 的局面。它可能没有绝对的好坏，更可能是 AI 发展阶段的阶段性产物，未来自然会慢慢解决。
但不妨碍我们停下来想想：与其狂飙突进做 demo 内卷，不如低头看看，我们做的东西到底能不能产生真正的业务价值。
真正应该被奖励的，不是又做出了一个漂亮 demo，而是把一个 demo 诚实地拆开：哪些已经验证，哪些只是视觉效果，哪些还需要工程化，哪些根本不值得继续做。
Demo 是起点，不是终点。承认差距，才是跨越差距的第一步。
参考来源：
- Gartner AI Trends Report, 2025/2026
- Agentik-OS: “Why AI Agent Frameworks Fail in Production”, 2026
- Stack Overflow Developer Survey, Enterprise AI Section, 2026
- Iris-Eval: “The Eval Gap: Why Your AI Demo Works and Production Doesn’t”, 2026
- MIT NANDA: Enterprise Generative AI Pilot ROI Study, 2025
- ACM Queue: Agent State Management and Failure Rates, 2025
- Fast Company: “The AI Development Illusion”, 2025
- Chrono Innovation: “After Vibe Coding: Prototype to Production”, 2025
- NP Group: “The New Discovery Phase”, 2025
- Salesforce Research: AI Agent CRM Task Success Rates, 2025