小朋友拥有比大人更清晰的世界：
2024年春节期间，在重庆鸿恩寺游玩，登顶鸿恩阁下来的路上，偶闻一小女孩对妈妈说：回家给你捶背，收费0元。妈妈问：0元是多少钱啊，小女孩说0元就是不要钱。（u1s1，鸿恩阁在那会儿阴雨重庆的夜里，是真美，宛若天宫）
你看，其实小朋友对世界的理解，还是很清晰的，他们不收钱，就明确的给出了标价是0元，而不是不告诉你（也就是给你“空”），虽然在语言世界里面还可以说“不收钱”，但是他们理解的世界就是一个明确的0元。
挠头的成年人，可怕的自以为是：
紧接着春节返工后，团队一个在进行项目继续和三方对接拉锯，中间遇到一个特别傻缺的问题。API对接里面，我方需要指定一些属性的属性值入参，对三方系统进行调用创建订单，如果涉及到一些属性值没有或不满足的时候（比如：某个sku的code、商品规格值等），对方系统不会认为自己没有，而是直接阻断报错。但前提是，对方允许指定属性/属性值、且允许缺货下单，那我们现实世界的理解就是你既然允许我要、也允许自己没有，那你没有时候你还报错阻断个锤子啊！
你至少允许我订单提交过去，但是你没有的商品就下单不包含在里面，并返回给缺货的商品list就OK了。但是，对方对缺货下单的理解是必须是商品档案库有的商品才能允许缺货下单。如果包含没有的商品，直接整个订单就会错误。你看这些理解，就很奇葩。（话说如何识别到这个问题呢？面临对方文档信息的不完善，且对接沟通时候也未识别这种情况，团队成员在几次失败之后，我自己拿着开发捞出来的错误报文才识别到了该问题，对方拿到这个信息也是恍然大悟。）
这里其实已经产生了严重的定义偏歧：
对方定义的允许缺货下单，其实并不是“无”，也就是说不允许不存在这个商品。他们所说的允许接缺货下单，前提必须是存在这个商品档案，其实对应的是“有➕非空”的要求，然后与他们的现有商品可用库存值做对比。
而我们理解缺货下单应该可以是无的情况，也就是说，我报订了一个你经营范围之外的商品，但是不能因为这个商品你没有经营，从而影响我其他商品的正常下单和业务数据的流转。对方处理是偏程序思维的 但却脱离了业务的实际。但是你说，产品不得服务于业务吗？
千里之行，始于足下：
反观我们的产品实操，对于团队连锁门店店员操作来说，很多时候我们为了让店员清晰自己的系统输入动作，而不允许空数据提交，如果你不能执行，请输入0表示你“关注到了且不能执行”。0表示你的明确表达，但“空”则是未知。
0 和空白是不是有区分？
当然，空代表的是不确定，是不是出现了故障，所以没有响应？
从用户情绪出发，这个时候是恐慌、不确定。
0，是确定性的结果输出，我做出了动作，你给我了反应，这是一种闭环的信息流。
往生活里面想一想，也是一样，我们问别人个东西，他不能因为不知道，所以不吱声吧，那到底是知道还是不知道呢？
靠猜啊！别，太累。
