读不完的电子书，堆不下的实体书

打开各种读书APP，看着长长的书单，又添加了几本，“好像还挺有意思”；逛逛书店，又买下几本，“装帧很对味”；还有几个线上课程的更新提醒，“这几个老师讲得不错”。

对知识的渴望越来越强烈，对自己也越来越有信心，读书似乎是一剂藿香正气水，疏解2020这个神奇年份带来的焦虑。

标记一本又一本“已读完”，带来了巨大的愉悦，仿佛可以掩盖背后隐隐约约的匆忙和慌乱，就像是大口大口的吞咽，吃饱就不怕了。即是读不完，也要不停浏览、发现、收藏、转发到笔记，“稍后阅读”就意味着“我已拥有”。

对自恋的投喂

“自恋”是一种很底层的动力，失意的现实冲击着“自恋”，所以需要读书，需要代入小人物逆袭的故事，需要职场秘籍，需要心灵鸡汤，需要技能工具。就像增肥能让人看起来“有力量”一样，吞咽知识获得的理性力量感，也是一种对抗，根植于对“虚弱”的恐惧，是在证明“我还不错，只是这世界没有看到”。

可是，是在向谁证明呢？

追求卓越和自卑感是硬币的两面，即使看穿那一层自恋，也会带来内心的撕裂和冲突。能力和见识的提升，同时告诉我们天空和深渊的极限一样，在想象之外。

虚胖与肌肉

虚胖并不能带来多少力量，肌肉才可以。用读书投喂自恋，也需要经过长时间锻炼，才能喂养出健康充沛的自恋动力。考试和写作，都是对内在的塑形，一寸一寸的进，可以增加知识的味道，让投喂的过程多一点乐趣。

拿过最近在看的一本书，挑出来最打动人的一章，用自己的话重复几遍，变成能在朋友圈发出来的片段，甚至做成一张漂亮的图片，用这种仪式感让周围能看见一丝丝火光，如果远处传来一声回应，那就是滋养自恋的最好养分。

所以，去读书，去投喂，去锻炼，去自恋。

前言

汽车领域的区块链应用应被归于垂直的产业区块链应用，市场上常见的，是利用OBD盒子的数据类项目，通过智能合约，让用户在数据所有权上有更多话语权，实现利益分配，处于早期探索阶段。

本文探索的是从汽车设计生产到报废拆除整个生命周期中的区块链应用可能性。

技术适用条件

瑞新资本孟岩对于比较适合使用区块链技术的产业领域，有这样的描述：

• 多个相互没有隶属或指令关系的实体之间相互协作
• 各方均不愿让渡数据主权或数据治权，也不愿意无条件共享数据
• 由信息不透明导致的过度博弈，严重降低协作效率

汽车行业上下游链条非常长，产业利益关系复杂。主导制造的主机厂、渠道销售能力较强的经销商集团、数量庞大又分散的保养维修企业、甚至是二手车车商，各有一席之地，非常符合上面提到的三个条件。

汽车数据玩家都是谁

在汽车从生产到报废的时间轴上，以可能产生和收集数据的位置为节点，参考各节点的数据玩家，形成区块链应用内的基本框架。罗列一下除用户自身之外的潜在玩家：

• 产生环节

  • 主机厂（前装优势明显）

• 使用环节

  • 导航APP / 后装智能设备
  • 维修保养企业
  • 停车场
  • 加油站 / 充电站
  • 保险

• 报废环节

  • 汽车报废企业

• 交易环节

  • 经销商
  • 二手车商

以上的玩家可以收集到各项数据，包括驾驶习惯、车体磨损、轮胎磨损、能耗、路径风险、零配件情况、交易价格等，可以完整描述汽车状态，用于评估汽车价值及使用风险。

区块链的应用

区块链技术应用目标是让上下游强话语权玩家形成数据信任，促成合作。各玩家掌握的数据存在差异化，有交易的价值。实际上，少数大玩家能形成协议信任，不需要区块链技术也可以协作，甚至在面向用户宣传时，中心化背书的初始信任成本更低。只是从长期看，过渡到去中心化是更好选择，因为在接入整个信任网络时，新玩家成本更低，有利于网络效应的形成。

有几个应用的关键点：

• 数据加密存储，保护隐私
• 数据确权与定价，用户最好能获得分润
• 数据授权及延伸应用

可以上链的数据：

• 车况数据
• 零配件溯源，是否使用原厂配件
• 车辆票证
• 物流仓储数据

潜在的数据应用领域：

• 车险定价
• 社群互助，可以看
• 汽车供应链金融
• 汽车消费金融
• 共享出行
• 跨省跨国二手车或二手配件交易

总结

区块链在汽车领域的应用，可能有以下一些特性：

• 以联盟链为主，主机厂话语权重
• 金融领域需求更强，有机会向上游推动应用
• 小玩家参与是长期的事情，短期诉求不明显

“生产-交付”模型如下图，整个过程中会产生各类数据，业务类型不同，每个节点产生的数据类型也不同。通过这个细化这个模型，可以从更小的颗粒度上，发现和定义基础数据，为理解和处理业务流做准备。

需要强调的是：先有模型，后有数据

通过某个模型来抽象业务，做出假设，才可能通过收集数据来描述和改进业务。“生产-交付”模型是抽象业务的一种方式，串联和并联节点，形成可能接近真实业务的架构。

简言之，数据完整性是相对模型来说的，数据来源于模型。

将视线关注到一个小的节点，可以看到下面的结构：

外部数据

即是原料，输入生产过程

生产过程包括：

• 人工处理，过程数据如操作时长，经常用于人效管理
• 规则自动化处理，这里的规则是泛指既定的处理流程
• 模型处理，主要指较难解释的机器学习结果及近似黑盒的外部服务，通常与计费有关

这三种处理模块并不一定全部需要，根据实际需要删减

交付结果

主要是综合结果，可能包含一些容易被非财务角色忽视的财务相关数据，比较合适的方式是形成快照存储，方便回溯。

每个节点都可以预置一组校验规则，相当于生成环节的质检，保证输入和交付都是合法的。

尽量避免使用“中台”这个概念，而是倾向于“能力复用”这个概念。

前言：

在开车使用导航途中想到的一个方法，可能并不新鲜。利用导航 APP 的大量数据，基于统计计算出城市各种路口红绿灯的间隔时间，修正到达目的地的预估时长，帮助规划更合理的导航路线，降低用户在路口等待时的焦虑。

更好的方案：红绿灯接入智慧城市相关系统，开放实时数据给导航 APP，这应该是大趋势，北京部分红绿灯是可以在导航 APP 看到红灯剩余时长的。

基于统计的思路：

地图数据已经包含红绿灯的位置信息，假设大量使用导航的车辆经过红绿灯，遇到红灯的车辆直行方向会停止，绿灯亮起时会启动。因为车辆数量足够大，可以获得全天不同时段的数据，帮助识别是否存在根据路口繁忙程度规则调整时长的红绿灯。

考虑到交通高峰期，收集到的数据将极大偏离真实时长，可以将拥堵时段和非拥堵时段的数据分别处理。

采集到车辆的停止时间和启动时间，计算时长，记为 T1。此时获得多个 T1，如果将这些 T1 的值标注在一个时间轴上，会呈现出相对均匀的分布，然后在大于某个时长值的时候，标注点突然急剧减少（这些是过红绿灯时走神，启动慢的车辆），排除这些干扰时长值后，收集到的 T1 时长里的最大值，就接近真实的红灯时长，按照人们的设定习惯，时长应该是 5 的倍数，做出修正，大于计算所得的 T1 的最近的，5 的倍数的那个时长，就是真实的红灯时长。比如计算得到的 T1 是 43 秒，那么真实的红灯时长应该是 45 秒。

同理可以处理得到绿灯时长。

这样，我们就通过统计得到近似真实的红灯亮起时间，红灯时长，绿灯亮起时间，绿灯时长。

使用场景：

• 在车辆行驶到红绿灯时，展示给驾驶人，形成等待预期，增强驾驶人的掌控感
• 帮助自动驾驶系统，调整车速和转速
• 提高行驶预估时间的准确率