原型要保留被讨厌的权利

第一周原型不是产品的小号版本。它是一件仪器，用来在「猜错」还只值一周的时候，搞清楚问题是不是大家以为的那个问题。这个用途对形态的约束，比任何功能清单都强。

五项最低合格条件

1. 跑在客户的真实数据上。 端到端闭环成立即可，可以很窄。合成样本和脱敏样本不计入合格判定，因为生产里坏掉的几乎总是数据。
2. 至少一个失败模式有可观测的出口。 日志、链路追踪、用户看得见的错误提示，三件齐备。看不见失败的原型，只能被评价为「像不像做完了」。
3. 覆盖口径表里锁定的那一个最高优先级指标。 一个，不是一屏看似合理的指标。
4. 标注已知未知。 一页 README 或风险清单：什么没做、对数据做了什么假设、先坏会坏在哪。
5. 留下不喜欢的权利。 客户可以拒绝它，不需要付出代价，也不需要解释。

第五项才是承重的

多数团队把第五项当礼貌，工期一紧就先砍。它恰恰是让另外四项成立的那一条。一个原型，如果肯当着客户的面、写在同一份标注未知的文件里，承认自己丑、不完整、很可能会失败，评审的性质就变了：问题从「这个好不好」变成「这是不是那个问题」。而第一周里，「这个好不好」只有一个诚实的答案：不是。

这项权利还有个商业形态。如果讨厌这个原型要让客户付出点什么——一笔钱、一个公开表态、欠介绍人一个人情——他就不会讨厌它。他会沉默，团队则把沉默读成认可。一个本该让项目转向的原型，就这样变成了整个构建的地基。

Demo 驱动的原型要付什么账

Demo 是为了被喜欢而造的。它为那间会议室优化，于是恰好藏起原型要暴露的两件事：数据在哪里断，以及人悄悄跳过了哪一步。换来的是一致，不是信息。

这种失败有两个记录在案的变体，长得不一样。第一种是做得完整但没有界定范围的 mock：效果好，话题直接跳到合同，Demo 后来原样进了附件成为验收基准。它之所以没出事，是因为附件在同一步里写完了；一个没有附件的完整 Demo，是一项标价为零的隐含承诺。第二种是换了形态的同一个错：平台方案在开工前被一次业务访谈推翻——那份方案回答的是一个没人问过的问题。

同样的错误还有工程版本：把本地跑通当成可以上线。有一份最终验收共五十七项：三十六项通过、十八项失败、三项跳过，失败项里包含只在真实鉴权下才出现的来源校验拒绝。教训不是「做得差」，而是判决被切成两半：Demo 这一片可以上线，完整版不可以。返回 200 只证明系统接受了请求，既不证明动作完成，更不证明业务端点收到了结果。

真实数据、更窄范围、定死截止

三条规则承担了范围界定的活。真实数据，没有例外。砍覆盖面，不砍深度——把一个门店做透，比浅浅铺开一片门店更有价值。定死截止时间，因为截止时间才是逼出取舍的东西，开放式原型会把同一个取舍无限往后推。

记录在案的周期都以周计，不以季度计：训练营五天封顶，一家厂商最快四周，另一家四到八周。五天格式是同一套逻辑的极端版本：第零天只选一个极窄的战场；第一天打通系统、抽出数据；第二到第三天和客户的技术人员背靠背写代码；第四到第五天把结果放到高管面前，让他们自己点，当场决定要不要进商务。原型和购买决定发生在同一间屋子里，中间那道「用演示替代证据」的缝就被省掉了。

第二周之前的一道检查

在原型变成计划之前，把五项条件逐条确认，然后只问一句：客户能不能在不损失任何东西的情况下说不。不能，它就是 Demo，这一周买到的是一种情绪，不是信息。接下来要量的是什么东西活下来了，那是四周法则的活；量什么由口径表决定；而这一整套条件的位置，在五阶段方法的交付段。