AI 让 Demo 变简单，但产品没有变简单

最近我发现一个现象：公司里几乎所有人都在做 demo。

每个人都能用 AI agent 做出非常漂亮的 demo，可能就是一个页面，底层的数据也是 agent 生成的。大部分只是静态页面，少部分带点简单逻辑。

AI 让 demo 的成本接近于零，但它也制造了一个新问题：大家越来越容易把「能演示」误认为「快上线」。

当每个人都能轻松做出 demo，一个问题就来了：AI 让大家觉得做什么都变得又便宜又快，但 demo 并不等于产品。一个真正可用、稳定、支持多人长期使用的产品，和 demo 之间差距很大。demo 的视觉欺骗性太强了。

以前，产品要做 demo，需要产品经理画原型、设计师出图、研发做前端后端，周期很长，老板自然知道这只是个方向，离开发完成还远。但现在变了。产品、算法、运营、PD，甚至实习生，给 AI 一堆提示词就能做出一个能点、能跑、能演示的东西。老板一看：这不是已经做出来了吗？工程团队实现一下不就完了？

这句话其实非常要命。

演示链路跑通，和真实业务系统的落地，差距很大。很多 demo 可能只完成了 10% 的工作。

demo 只意味着完成了 10%，而大家的预期是已经完成了 80%。

Demo 和工程系统之间到底差什么？

demo 是给一个人用的，追求自己用着爽，想怎么改就怎么改。它只能证明这个想法好像还行，可以跑通。

但一个真正的工程系统要解决的问题就多了：

多人怎么用？
出现异常怎么办？
权限怎么控制？
数据怎么存储？
日志怎么查询？
如何处理失败？
性能和安全性如何保障？
上线后如何维护？
业务变化时如何迭代？

你的 demo 可能只是自己点一下跑通了，甚至用的是伪造的假数据。

但生产系统面临的是：一百个人同时点，网络抖动、接口超时、权限异常、脏数据、性能瓶颈。这些才是工程真正要解决的问题。

Demo 幻觉

我觉得现在最大的问题，是产生了一种「demo 幻觉」。

这种幻觉不是 demo 本身单独造成的，而是 demo、AI coding 宣传、组织压力和团队汇报共同叠加出来的。

1. Demo 让进度看起来被大幅压缩

过去做完 PRD，所有人都清楚后面的开发时间还很长。

但现在 demo 一出来，大家就觉得离实现已经很近了。

实际情况是，一分钟就能做出 demo，但要花一个月去优化。

尤其是现在大量工作围绕 agent skill 展开，优化成本更高。skill 本身没有固定标准，好不好用必须运行起来才知道，需要边上线边调整。demo 跑通了，离真正可用、对业务产生价值，还远得很。

很多 AI 项目都是这样：演示时看起来很令人印象深刻，然后就停滞了。演示和生产之间的差距，往往就是大多数 AI 项目失败的地方。

大多数 agent 框架也有类似问题：它们更容易针对演示进行优化。酷炫演示和生产级 agent 经济之间的差距，可能还有 90% 尚未解决。

2. 老板容易把演示链路误判成上线进度

这里老板的认知非常关键。

如果他看到一个 demo 已经完整实现了流程，就会觉得系统很快能上线，忽略中间繁重的工程化工作。对工程不熟悉的老板，这种误判更常见。

3. AI coding 的宣传进一步放大预期

更麻烦的是，现在外部媒体和社交平台对 AI coding 的宣传太密集了。很多叙事都在强调：以前需要工程团队做很久的事情，现在 AI coding 很快就能完成。

这会进一步放大老板的预期。他会认为 demo 和上线之间差的只是「把代码补完整」，而 AI coding 似乎已经解决了这个问题。于是 demo 看起来离产品更近了，工程化工作也更容易被低估。

但真实情况是，AI coding 解决的是一部分代码生成效率问题，不等于解决了系统落地问题。上线不是把页面写出来，也不是把一个流程跑通，而是要把权限、数据、异常、日志、性能、安全、稳定性、运维和业务迭代全部纳入系统。

AI Coding 擅长平地起高楼，而不擅长持续迭代精装修。

4. 拥抱 AI 变成组织里的政治正确

还有一层更微妙的压力：拥抱 AI 正在变成一种组织里的「政治正确」。

这里的「政治正确」不是说 AI 不重要，而是说在一些组织里，AI 已经从工具选择变成了态度表态。

现在很多公司不是在讨论「这个场景到底适不适合用 AI」，而是在默认「你必须积极拥抱 AI」。只要你表现出一点懈怠、质疑或者谨慎，就很容易被理解成不够开放、不够进取、不适应变化。

社区里也有类似讨论。有人提到，公司自上而下推动 AI 工具，工程经理和研发都被要求证明自己在用 AI；也有人讨论，个别公司已经把 AI 使用纳入绩效和同事评价，甚至出现了不按要求试用 AI 工具就被处理的极端案例。

这会让团队进入一个很危险的状态：大家不再敢诚实讨论 AI 的边界，只能不断证明自己「正在拥抱 AI」。于是 demo 更容易被包装成进展，风险更不容易被摆到台面上，工程判断也更容易让位于姿态表演。

5. 团队自己也会继续抬高预期

而我们自己也有责任。不管是算法、PD 还是研发，做 demo 的时候多少会倾向夸大进度，演示时只说「没问题」，反过来进一步拉高老板的预期。员工夸大，老板加预期，最终项目的成功率就很低。

Demo 泛滥带来的问题

demo 泛滥还会带来几个具体问题。

资源浪费

token 调用就是真金白银。

全公司各个岗位都在做 demo，不少团队的 demo 专用平台都成了瓶颈。更可惜的是，做出来的一大堆 demo 最后没人用、没人维护，也不会销毁，平白占用大量计算和存储资源。

demo 一旦没有退出机制，就会变成组织里的长期垃圾资产。谁来判断它有没有价值，谁负责维护，什么时候下线，资源怎么回收，这些问题如果没人管，demo 越多，组织负担越重。

稀释成功率，打击团队信心

做 demo 成本低了，大家往往没想清楚就动手试错。

试错成本确实低了，但成功的概率也跟着降低。团队陷入「一直做 demo、一直不落地、一直没有业务结果」的循环，久了打不了胜仗，士气越来越低。

尤其在当下 AI 阶段，大家边摸索边做，对最终业务价值的怀疑，对团队伤害特别大。

做 Demo 本身不是坏事

当然，做 demo 成本降低本身是好事。

它让更多人能参与创新，让想法被看见，沟通效率大幅提升，试错成本降低，非技术人员的创造力也被释放出来。

问题出在我们把 demo 错当成了产品。

demo 只是创新的起点，不是交付的终点。

它只能帮我们更快验证方向，但风险在于让我们误判了成熟度和完成度，制造了「快做完了」的错觉，掩盖了工程的真实复杂度，拉高了不合理预期，还让需求无序膨胀。

不管有用没用都先做个 demo，大家反而更少深思熟虑，催生了一大堆看起来炫酷但业务价值不大的伪创新。

怎么避免 Demo 幻觉？

我觉得不是不要做 demo，而是每次 demo 展示时，都应该同时说清楚三件事：

这个 demo 验证了什么？
它没有验证什么？
如果要上线，还差哪些工程化工作？

比如，一个 demo 可能验证了用户路径和交互方向，但没有验证真实数据、权限体系、异常处理、性能、安全、监控和运维成本。

只有把这些边界讲清楚，demo 才能成为创新的起点，而不是预期失控的开始。

最后

说到底，这个问题背后有人性的推力。

AI 发展太快，每个人都有浮躁和焦虑，这种情绪推着大家不自觉走向全民做 demo 的局面。它可能没有绝对的好坏，更可能是 AI 发展阶段的阶段性产物，未来自然会慢慢解决。

但不妨碍我们停下来想想：与其狂飙突进做 demo 内卷，不如低头看看，我们做的东西到底能不能产生真正的业务价值。

真正应该被奖励的，不是又做出了一个漂亮 demo，而是把一个 demo 诚实地拆开：哪些已经验证，哪些只是视觉效果，哪些还需要工程化，哪些根本不值得继续做。