以前做 Demo，我也会比较自然地追求“看起来完整”。
页面做得顺一点、状态多补一点、视觉像成品一点、切换更流畅一点。因为大家潜意识里都希望 Demo 能打动人，最好一演示就让人觉得这个方向没问题。
但我后来越来越觉得，Demo 最重要的价值其实不是“像”，而是“准”。
它不一定要像最终产品，但它必须足够准确地验证关键问题。更理想一点，它应该尽早把问题暴露出来，而不是把问题藏起来。
Demo 的真正价值，是帮助判断而不是帮助想象
如果一个 Demo 只是让人觉得“以后做出来可能不错”，那它的价值其实有限。因为它更多是在刺激想象，而不是提供判断依据。
我现在更看重的是：这个 Demo 验证了什么？否定了什么？让哪些判断更清楚了？
比如做实时答题页时，我最关心的不是页面是不是已经很像最终上线版本，而是：
- 用户能不能清楚感知录制状态
- 语音输入入口是否会干扰主流程
- 哪些状态必须显式提示
- 结果反馈应该是即时打断还是流程后展示
- 页面信息层级会不会让人紧张或者困惑
这些问题如果不通过 Demo 提前验证，后面越往正式开发走，改动成本就会越高。
好的 Demo 应该围绕关键不确定性来做
我现在做 Demo，通常不会先从“功能尽量全”开始，而是先找最不确定的点。
因为一个项目真正危险的地方，不是你已经知道怎么做的部分，而是那些你以为问题不大、结果后面会持续反噬你的点。
比如一个页面 Demo，如果只是验证排版，那它提供的信息其实很少；但如果它明确验证了某个状态流、某个关键操作、某种信息层级的可理解性，那它就很有价值。
说白了，Demo 不该是“缩小版成品”，而更像“放大版问题验证器”。
为什么我不太喜欢过度包装的 Demo
过度包装的 Demo 有一个问题：它很容易让人误判进度和风险。
看起来很顺滑，很完整，很像上线版本，大家就会自然以为后面的事情也差不多稳了。但实际上，很多关键约束可能根本没处理，很多复杂状态只是被临时绕过去了。
这种 Demo 在汇报时也许很讨喜，但对项目判断未必有帮助。
我更喜欢那种哪怕还不够好看，但已经把关键问题摆到台面上的 Demo。因为那才是真正对项目负责的方式。
Demo 的完成标准，应该是“问题更清楚了”
现在如果让我判断一个 Demo 做得好不好，我通常不会先看它是不是精致，而会先看一件事：它有没有让问题变得更清楚。
比如做完之后，团队能不能更明确地回答：
- 这个方案是不是继续往下做
- 哪个环节风险最大
- 哪些状态必须重新定义
- 哪些交互需要收敛
- 哪些功能其实不该第一阶段做
如果这些问题还都说不清，那这个 Demo 做得再完整，价值也有限。
结语
我现在越来越把 Demo 当成一种前置验证工具，而不是展示道具。
它最好的状态，不是“像一个已经完成的产品”，而是“把后面可能出的问题提前带到今天”。只有这样，Demo 才真正参与了项目决策，而不是只参与了项目表达。