2019年，一个创业团队接了个智慧工厂的单子。先用AI工具3天搭了一套Demo，给甲方演示的时候，大屏上园区模型转起来、数据在跳、灯光在闪——甲方负责人当场拍板：签了。

签完之后噩梦才开始。AI生成的场景是"一块死皮"——想拆出一栋楼来做设备绑定？做不到。Demo里那些漂亮的仪表盘数据是写死的假数据，要接真实PLC——接口重写。甲方每周催进度、每个月要看到一个"完整版"——他们以为就是在Demo基础上"改一改"，不接受"要推倒重来"的解释。

那个Demo用3天拿了项目，用了3个月差点把项目搞黄。

"先用AI快速Demo、后期精细化交付"这个策略本身没毛病。但如果你在执行上犯几个常见错误，它就会从"加速器"变成"拖后腿的"。

先说说这个策略为什么吸引人

没什么不好意思承认的：拿项目需要Demo。PPT的杀伤力远不如一个能转能点的3D场景。

AI工具把Demo的搭建成本打到了一个前所未有的低位。以前一个园区Demo，外包建模师两周、引擎开发一周。现在很多环节AI辅助，几天甚至几小时就能出一个看着挺像那么回事的场景。

对小型团队和创业公司来说，这是现实选择。没有足够的人力和时间去做精模，但又需要给甲方一个"你在说什么"的可视化锚点。AI快速Demo解决了这个"从0到1"的卡点。

更重要的是风险控制。需求还没完全定的时候，先出一个"差不多的场景"跟甲方一起看——"是不是长这样？""数据展示在这边行不行？"——比纯文字需求文档沟通效率高太多了。甲方看到东西能给你反馈，看不到东西只能说"你看着办"。

翻车是怎么发生的

同一件事，有人用得好有人用得砸。关键区别在下面几个坑，踩中任何一个都够你喝一壶。

坑一：甲方把Demo当半成品，不接受推倒重来。

这是最常见也最要命的。Demo演示的时候甲方感觉"已经做得差不多了"，签合同后你的开发计划是"从零重新搭建架构"，甲方直接懵了："那你之前给我看的是什么？"

这个认知错位的根源在于：你在做Demo的时候，为了让效果好看，做了太多"看起来已经完成"的效果。灯光氛围调得很好、数据面板做得很详细、天气效果切得很流畅——甲方不是技术出身，他判断进度的唯一标准就是"看起来像不像成品"。你说这是概念验证，他看的是"这不已经做好了吗"。

坑二：Demo的展示效果超出了真实开发能力。

为了拿项目，Demo阶段把效果做到120分——航拍数据用最高精度、场景里加了大量预渲染动画、甚至借用了第三方商业引擎的高级特效。甲方一看：就这个标准。

正式开发的时候，真实团队的产出是85分水平。甲方不接受："之前的那个版本不是很好吗？"

你没办法跟他解释"那是Demo，是用各种临时手段拼出来的"。你说得越多，他越觉得你在找借口。

坑三：Demo资产和工作流与正式开发不兼容。

AI工具生成的模型格式、材质系统、交互逻辑，和正式开发用的引擎之间没有"升级路径"。你以为Demo是"地基"，可以直接往上盖楼。实际情况是：Demo里的东西放到正式引擎里——材质没了、贴图乱了、脚本报错了。

这意味着什么？意味着从Demo到正式版，不是"升级改造"，是"全部推倒"。Demo阶段投入的所有技术工作，零复用。

坑四：Demo的架构根本扛不住正式需求。

Demo里为了追求快速出效果，很多底层设计是将就的——数据是写死的、性能优化没做、接口没考虑扩展。到正式开发的时候发现：Demo的这个架构如果要接上百个实时数据点，直接崩溃；如果要支持多用户并发，完全不行。

如果在Demo到正式开发之间，没有做一个技术验证环节来测试这些关键链路——等正式开发跑起来才发现架构不行，那时已经晚了。

靠谱执行的四条法则

法则一：在Demo阶段就划好"临时"和"永久"的边界。

Demo演示的时候，大大方方告诉甲方：这是概念验证，用AI工具快速搭建的，目的是对齐需求和风格。正式交付会重新搭建。

怎么判断哪些可以复用、哪些必须重做？

数据和接口层要尽量复用——你定义的API格式、数据模型、设备编号体系，在Demo阶段就应该按正式标准来。因为"数据怎么组织"这件事，Demo和正式是可以一致的。

表现层可以大方地承认是临时的——模型精度、材质效果、光影氛围、这些在AI生成的Demo里不可能达到交付标准。别在演示时回避这个问题，提前说清楚就好。

法则二：控制Demo的视觉预期。

Demo的视觉效果做到"合格但不出格"。让甲方清晰感知到场景的风格和交互逻辑，但不要做到让甲方"哇塞这个太好了"的程度。

具体操作：模型用低精度、材质用基础贴图、场景不加复杂特效。把精力和预算放在交互逻辑和数据展示的清晰度上——让甲方觉得"功能设计得对"，而不是"画面做得漂亮"。

这不是降低标准，这是诚实。

法则三：合同阶段就把Demo和正式交付"拆开"。

在合同里明确写的交付物不包括Demo，Demo只是"前期沟通工具"。

报价的时候，正式开发独立计价。不要在报价里暗示"Demo已经做了一半了所以正式开发可以打折"——这是在给自己挖坑。

如果甲方希望在Demo基础上继续开发——可以，但要明确告诉他：Demo的底层架构需要重构，相当于从头开发。接受与否让甲方自己判断，但你必须说清楚。

法则四：Demo之后插入一个技术验证阶段。

从Demo到正式开发之间，留出一到两周的POC时间。专门用来验证几个"如果这个链路断了，后面全完"的问题：

• 实时数据接入能不能跑通？拿一台真实设备的数据接进去试试。

• 大场景性能能不能扛住？导入一个接近真实数据量的场景，跑一下帧率。

• AI模型/精模的导入流程通不通？从建模软件到引擎到Web发布，完整走一遍。

这个短期POC的成本极低（可能就一周时间），但价值巨大——它能帮你提前发现"Demo架构到正式架构之间的断层"，而不是开发过半了才撞墙。

说到底

"AI快速Demo + 后期精细交付"是一把好刀，但刀有两面。

用得好：用AI的速度优势降低项目前期的不确定性和沉没成本，帮你更快锁定方向。

用得差：Demo成了甲方心里的"交付标准"，后期每一步都在填前期挖的坑。

关键不在于"做不做Demo"，在于"怎么做、怎么说、怎么衔接"。管好甲方预期、管好团队节奏、管好技术边界——这三条做到了，这条路就走得通。

关于作者：14年数字孪生项目经验，既要帮团队拿项目，也要帮团队守住交付底线。最怕的不是甲方提要求，是甲方因为我们的表达产生了错误预期。