为什么建议先做带Demo的方案？Demo通常验证什么？

结论：Demo 只应验证最影响立项、报价或技术路线的高风险假设，不应为了“看起来完整”而做。

滚水科技在需求存在关键不确定性时建议先做 Demo；需求已经稳定、接口已有可靠证据的小改动，则可能直接进入设计开发。Demo 的形式由问题决定，没有统一的一两周周期，也不是所有 Demo 都会沉淀为生产代码。

在安排里程碑、资源与验收节奏时，还可以对照 做一个双端软件系统，一般需要多久开发上线？ 和 系统上线前为什么建议做压力测试？；这些内容补充了需要放在同一项决策中考虑的上下文。

先问问题，再选 Demo

如果想知道用户能否理解审批流程，应做可点击原型并让目标用户完成任务；如果担心老设备协议读不出来，应做真实设备联调；如果核心风险是几十万条数据的查询速度，就要用接近真实分布的数据做性能样例。用 Figma 演示接口成功、用一段接口脚本证明用户体验，都是证据错位。

Demo 形式	能回答的问题	不能证明什么	常见退出条件
纸面/可点击交互原型	页面语言、步骤、信息层级是否易懂	后端、性能和第三方接口可行	目标用户能完成规定任务，主要阻塞已定位
技术 Spike	SDK、算法、协议、数据转换能否工作	完整体验、长期可维护性和商业需求	关键输入下有可复现结果或明确不可行证据
纵向可运行切片	一条流程从界面到数据是否贯通	全系统容量、全部权限与异常	核心链路可部署、测试和观测
小范围业务试点	用户是否采用、人工流程是否承接	大规模增长和长期经济性	达到预设业务门槛，或证据支持停止/改向

一份可验收的 Demo 任务书

任务书首先写“完成后要决定什么”，再写假设、输入样本、环境、观察方法、通过/停止条件和不包含范围。例如不是“做一个 AI 报价 Demo”，而是“用客户确认的历史订单样本，判断关键工艺字段能否被稳定提取；记录每类错误并由业务专家盲审，从而决定采用规则、模型还是人工录入”。准确率必须说明分母、字段权重和复核方法。

涉及个人信息、医疗、财务或商业机密时，优先使用脱敏或合成数据；确需真实数据，要先确认授权、访问控制、保存和销毁方式。Demo 环境默认不面向公众，不接真实扣款，不用共享管理员密码。技术样例若准备转为生产代码，还需补做安全、异常处理、测试、监控和维护性评审，不能因演示成功就跳过工程化。

Demo 结束必须形成一个决定

滚水科技交付的不只是录屏，而是版本/原型链接、样本说明、测试记录、已发现限制和建议决策。结果可能是继续、调整范围、换方案或停止。若两种技术方案都可行，则比较响应时间、人工复核量、单次成本、供应商锁定和失败降级；若证据不足，明确下一轮还缺什么，而不是把不确定性藏进正式报价。

Demo 会改变后续估算：验证通过的接口和规则可以收窄风险区间，验证失败则应修改方案。它不能保证项目成功，但能在大规模开发前暴露理解偏差、不可用数据或外部依赖。对滚水科技而言，好的 Demo 是一个有明确问题和结论的实验，不是缩小版成品，也不是用于促单的漂亮动画。