现阶段AI是否会替代人类

近期在读一个LangChain的系列文章,文章的最后,作者提出了一个问题:“AIGC来了,人类画师还有价值吗?”

这是一个好问题,在现阶段,我的理解是这样的:

AI绘画提供了一种通用能力,而且很多时候效果很不错,有商用价值,但并非无所不能。说白了就是一种新工具而已,我们该用积极心态看待问题。

就像本文指出的,对人来说效果并非一切。人是有情感的,不仅现在的AI生成物无法替代,很多客观指标更好的物品都无法替代。自己钓的鱼和市场买的是不一样的,自己阳台种的菜和农场种的是不一样的,父母做的菜和餐厅里的是不一样的,儿女给我们画的画和别人的画是不一样的,哪怕替代品指标更好,也无法完成情感需求的替代。

但更进一步,人从一开始不应该和AI比。人很早就学会了不要和机器去比,机器比人力气大,比人跑的快,比人跳得高,但人类为何还要不断挑战自我呢?一旦我们把人工智能,随便换个名字,类人脑型计算阵列设施,问题就简化了。影像医生为何要和AI去比谁能先找到微小肺结节?画师为何要和AI比谁画图更快?网球裁判为何要和AI比谁能更准确的判断球是否出界?用好这些工具就好了啊。

从人类历史的经验看,机器替代人工的过程,在近现代史上出现了太多次,但实质上都是,熟练用工具的人大幅提升效率,最终替代了无法熟练使用工具的非顶尖人才。互联网时代也是一样的,互联网媒体兴起时,对传统媒体产生了巨大压力,但现在自媒体市场兴起,又给多少非科班同学创造了机会。AI短期内一定会抢占一些人类的工作岗位,熟练使用AI辅助编程的人,会挤压掉很多重复编码的工作机会。

但同样的,非科班同学将会拥有编程能力,未来一定会创造更大的市场。未来我们每个人都能有足够好的编程,绘画,作曲,剪辑,写作能力,都有便捷高效的获取并使用近乎无限知识的能力。专业知识普及化,会缓解人类教育周期过长的问题,会带来生产力质的变化。希望这种生产力的飞跃,能带领我们进入一个新的时代。

碳基生物和硅基生物

在ChatGPT大力出奇迹之后,大模型已经从“萌宠时代”,正式迈入了蹒跚学步的“婴儿时代”。
这个婴儿虽然短期记性不算好,但学习能力和长期记忆能力却无与伦比,潜力无限。

现在大家又通过langchain、plugin等方式,帮助这个婴儿学习使用工具。
当大模型可以理解工具,使用工具,甚至制造工具、创造工具时,硅基生物时代也就开始降临了。

在这个过程中,可能会有以下几个阶段:
1、硅基生物智力和能力有限的阶段
碳基生物需要学会如何运用硅基生物,提升自己的生活水平

2、两种可能
2.1、硅基生物智力无限和能力有限的阶段
碳基生物变成了硅基生物的执行者,相互依赖,容易形成共同体,更容易走向共存的结局

2.2、硅基生物智力有限和能力无限的阶段
碳基生物需要学会如何控制硅基生物的能力,熊孩子教育不好,容易走向一起灭亡的结局

3、硅基生物智力和能力无限的阶段
硅基生物最好能学会如何和碳基生物共存,希望碳基生物不要仅仅是一段引导代码,善待引导代码

导致惨重代价的运维事故

导致惨重代价的运维事故

光大证券事件
2013年8月,光大证券在向客户演示时连接了正式数据库,导致股市震荡,被罚款5.2亿。

宁夏银行删库事件
2014年7月,宁夏银行在季末结算业务量较大的情况下,因备份系统异常导致备份存储磁盘读写处理严重延时,备份与主存储数据不一致。工程师在采取中断数据备份录像操作后,造成生产数据库损坏并宕机。造成38小时,700多定点医疗机构和定点零售药无法使用医保支付。

小插曲,2014年5月宁夏银行使用CDP软件进行了一场容灾演练,曾完成800公里的容灾切换。

携程删库事件
2015年5月,携程无法访问。官方反馈是由于运维工程师误操作,误删生产环境,而且重新部署后还是会被删除。经过十几小时努力,最终恢复成功。

小插曲,携程挂掉后,导流给了艺龙,结果艺龙也挂了。

Gitlab删库事件
2017年2月,Gitlab运维人员,在应对前一晚的DDOS攻击后,发现备库复制数据缓慢,并无法解决。最终决定删除备库,重新开始复制。但在十分疲倦的情况下,工程师误删了300G的生产数据,由于备份机制设置不合理,最终导致20多小时系统宕机,707位用户丢失数据,5,037项目丢失,受事故影响的用户基数不到1%。
我们可以看到的问题有:
1、审核和监控全部备份策略:虽然Gitlab号称有五重备份机制:常规备份24小时做一次、自动同步、LVM快照24小时做一次、Azure备份对数据库无效、S3备份。但没有一个可靠地运行或设置,而且备份失败也没有良好的预警机制。最终只能基于LVM的备份(最近6小时以前),还原了6 小时前的备份。
2、积极演练应对重大问题,保证备库是随时可用的,应急时也应该有序进行
3、数据中心之间数据传输要考虑好,本次数据传输也花费了较长时间
4、防止人肉运维,谨防开夜车,脚本工具化自动化。人总归会出错,而且总是在最不该发生的时候出错。
5、Gitlab本次事故发生后,公开透明的处理方式,值得大家借鉴和尊重。

AWS删服务器事件
2017年3月,一名S3工程师根据预先编写的playbook执行一条命令时,输入命令时输错了一个字母,结果删除了一大批本不该删除的服务器。经过4个多小时后恢复正常。

verelox.com删库事件
2017年6月,荷兰云主机厂商verelox.com,一前任管理员,恶意报复公司,删除全部用户数据,并擦出了多数服务器上面的内容。

广西移动扩容事件
2017年9月,华为工程师在进行广西移动扩容时,误将HSS设备的用户数据格式化,导致广西移动损失80万用户数据。

顺丰删库事件
2018年9月,顺丰一个高级工程误删线上库,然后跑路。导致部分服务无法使用并持续 590 分钟。

微盟删库事件
2020年2月,,导致系统6六天无法访问,市值蒸发28亿,预计赔偿金1.5亿,官方反馈是内部员工恶意行为导致,没有加到列表中。数据最后在腾讯云的帮助下得以恢复。

============================================================
注:本文主要是整理了系统Bug导致的惨痛代价,没有记录下面几种情况(设计失败,黑客攻击,病毒爆发)
*从计算机诞生以来,众多失败的软件项目,没有加到列表中

导致惨重代价的Bug

导致惨重代价的Bug

纪念“瞳”解体事件

千年虫事件
在上个世纪,软件行业初期,计算机硬件资源十分昂贵,很多软件为了节省内存会省略掉代表年份的前两位数字”19”,或默认前两位为”19”。按这个规则,1999年12月31日过后,系统日期会更新为1900年1月1日而不是2000年1月1日,这样可能意味着无数的灾难事件,导致数据丢失,系统异常或更加严重的灾难。

幸好大家发现的早,最终全球花了上亿的美元用来升级系统,没有引起毁灭性后果。

水手1号探测器
1962年7月28日,水手1号空间探测器发射升空,但由于程序编码中的轨道计算公式是错误的,导致火箭轨道偏离预定路线。最终在大西洋上空自爆。

南极臭氧层测绘事件
1978年,NASA启动臭氧层测绘的计划。但在设计时,用于该计划的数据分析软件忽略了和预测值有很大差距的数据。直到1985年,才发现南极洲上方的臭氧层空洞,但是英国科学家先发现的。直到NASA重新检测它们的数据,才发现这一错误。在修正错误后,NASA证实南极臭氧层的确有个很大的空洞。

反导系统误报事件
1980年,北美防空联合司令部曾报告称美国遭受导弹袭击。后来证实,这是反馈系统的电路故障问题,但反馈系统软件没有考虑故障问题引发的误报。

1983年,苏联卫星报告有美国导弹入侵,但主管官员的直觉告诉他这是误报。后来事实证明的确是误报。

幸亏这些误报没有激活“核按钮”。在上述两个案例中,如果对方真的发起反击,核战争将全面爆发,后果不堪设想。

辐射治疗超标事件
1985到1987年,Therac-25辐射治疗设备卷入多宗因辐射剂量严重超标引发的医疗事故,其罪魁祸首是医疗设备软件的Bug。据统计,大量患者接受高达100倍的预定剂量的放射治疗,其中至少5人直接死于辐射剂量超标。

AT&T网络终端事件
1990年1月15日,纽约60万用户9个小时无法使用电话服务。原因是,AT&T交换机从故障中恢复后,就会发送一条特殊的小时给临近的设备,但在新版本软件中,这条消息会导致电话交换机重启。于是,每6秒,所有交换机都会重启一次。最后,将程序换回了上一个版本,解决了问题。

宰赫兰导弹事件
在1991年2月的第一次海湾战争中,一枚伊拉克发射的飞毛腿导弹准确击中美国在沙地阿拉伯的宰赫兰基地,当场炸死28个美国士兵,炸伤100多人,造成美军海湾战争中唯一一次伤亡超过百人的损失。

在后来的调查中发现,由于一个简单的计算机bug,使基地的爱国者反导弹系统失效,未能在空中拦截飞毛腿导弹。当时,负责防卫该基地的爱国者反导弹系统已经连续工作了100个小时,每工作一个小时,系统内的时钟会有一个微小的毫秒级延迟,这就是这个失效悲剧的根源。爱国者反导弹系统的时钟寄存器设计为24位,因而时间的精度也只限于24位的精度。在长时间的工作后,这个微小的精度误差被渐渐放大。在工作了100小时后,系统时间的延迟是三分之一秒。

对一般人人来说,0.33秒是微不足道的。但是对一个需要跟踪并摧毁一枚空中飞弹的雷达系统来说,这是灾难性的——侯赛因飞毛腿导弹空速达4.2马赫(每秒1.5公里),这个“微不足道的”0.33秒相当于大约600米的误差。在宰赫兰导弹事件中,雷达在空中发现了导弹,但是由于时钟误差没有能够准确地跟踪它,因此基地的反导弹并没有发射。

Intel奔腾处理器浮点错误
1993年。Intel奔腾处理器在计算特定范围的浮点数除法时,会发生技术错误。Intel最终花费了4.75亿美元来为用户置换处理器。

飞行事故
1993年,瑞典的一架JAS 39鹰狮战斗机因飞行控制软件的Bug而坠毁。

1994年,苏格兰一架吉努克型直升飞机坠毁,29名乘客全部罹难。然而最初指责声都指向飞行员,但后来有证据表明,直升飞机的系统错误才是罪魁祸首。

死Ping
1995-1996年,由于没有进行足够的校验,在收到特殊构造的Ping包时,会导致Windows设备蓝屏并重启。

阿丽亚娜5型运载火箭事件
1996年6月4日,阿丽亚娜5型运载火箭的首次发射点火后,火箭开始偏离路线,最终被逼引爆自毁,整个过程只有短短30秒。(原计划将运送4颗太阳风观察卫星到预定轨道)

阿丽亚娜5型运载火箭基于前一代4型火箭开发。在4型火箭系统中,对一个水平速率的测量值使用了16位的变量及内存,因为在4型火箭系统中反复验证过,这一值不会超过16位的变量,而5型火箭的开发人员简单复制了这部分程序,而没有对新火箭进行数值的验证,结果发生了致命的数值溢出。发射后这个64位带小数点的变量被转换成16位不带小数点的变量,引发了一系列的错误,从而影响了火箭上所有的计算机和硬件,瘫痪了整个系统,因而不得不选择自毁,4亿美元变成一个巨大的烟花。

火星气候探测者号事件
1999年9月,火星气候探测者号在火星坠毁。火星气候探测者号的目的为研究火星气候,花费3亿多美元。探测者号在太空中飞行几个月时间,接近火星时,探测器的控制团队使用英制单位来发送导航指令,而探测器的软件系统使用公制来读取指令。这一错误导致探测器进入过低的火星轨道(大约100公里误差),在火星大气压力和摩擦下解体。

火火星极地登陆者号件
1999年12月,火星极地登录者号在火星坠毁,原因是设计缺陷导致其在达到行星地表之间就关闭了主引擎,最终撞毁。

辐射治疗超标事件
2000年11月,巴拿马美国国家癌症研究所,从美国Multidata公司引入了放射治疗设备及软件,但其辐射剂量计算值有误(软件本身运行医生画四个方块来保护患者健康组织,但医生需要五块,于是医生自己想办法欺骗了软件,殊不知该操作方式将放射剂量进行了加倍处理)。部分患者接受了超标剂量的治疗,至少有5人死亡。后续几年中,又有21人死亡,但很难确定这21人中到底有多少人是死于本身的癌症,还是辐射治疗剂量超标引发的不良后果。

北美大停电事件
2003年8月,由于GE的一个监控软件,没有有效的通知操作人员有一个地方电站断掉了,电力缺口导致了多米诺骨牌效应,最终导致了加拿大安大略州和美国八个州断电,影响到了5千万人,总损失达60亿美元。

丰田普锐斯混合动力汽车召回事件
2005年10月,丰田宣布召回16000辆锐斯混合动力汽车。这次召回的原因是“发动机熄火意外”及“警示灯无故开启”。本次召回的根本原因不是硬件问题,而是汽车嵌入式编程代码的问题。

东京证券交易所事件
2005年12月,J-COM公司上市,开盘价格61.2万日元一股,日本瑞穗证券的一个交易员接到了客户委托“请以61万日元的价格,卖出1股J-Com的股票”。但交易员输入成了“以每股1日元的价格,卖出61万股”。由于交易系统限制,交易系统自动调整为“以57万日元,出售61万股”。

2分钟后,操作员发现操作失误,执行了3次撤单操作全部失败。J-COM股票一路狂跌,瑞穗证券拼命拉高到77.2万日元,仅此一项,瑞穗证券一共损失了约270亿日。但仍引起了很大的连锁效应。

更大的问题是,J-COM的股票一共只发行了14000多股,但卖出去的可远不止这么多。最后经过协商,瑞穗证券用每股91万日元的价格,现金清算了股民手上的9万多股,全部损失,扩大到400多亿日元。

然后瑞穗证券状告东京证券和富士通,官司打了十年。最后判定,以当日瑞穗证券电话联络东京证券的时间点为分界线,之前全部由瑞穗证券承担,之后产生的损失由东京证券承担70%瑞穗证券承担30%。富士通及程序员没有收到罚款。

恩,痛定思痛,决定开始开发了新的交易系统,开发商仍然是富士通。

Gmail故障
2009年2月份Google的Gmail故障,导致用户几个小时内无法访问邮箱。据Google反馈,故障是因数据中心之间的负载均衡软件的Bug引发的。

温州7.23动车事故
2011年7月23日,甬温线浙江省温州市境内,由北京南站开往福州站的D301次列车与杭州站开往福州南站的D3115次列车发生动车组列车追尾事故,造成40人死亡、172人受伤,中断行车32小时35分,直接经济损失近2亿元。

上海铁路局事后反馈,“7·23”动车事故是由于温州南站信号设备在设计上存在严重缺陷,遭雷击发生故障后,导致本应显示为红灯的区间信号机错误显示为绿灯。

骑士资本事件
2012年8月1日,骑士资本的技术人员,在1台设备中部署了错误版本的应用(一共8台,7台正常),该设备触发了n年前的代码,在一个小时内就执行完了原本应该在几天内完成的交易,导致错误的买入卖出,直接将公司推向了破产的边缘,投资人紧急注资4亿美元才得以幸免,最终损失高达5亿美元。

12306订票助手拖垮GitHub
2013年1月15日,GitHub受到中国大陆的DDOS攻击,网站几乎被拖垮。

最后发现,是由于春运期间,各大浏览器厂商集成了一位网友iFish(木鱼)的“订票助手”插件,帮助春运大军抢票回家。但该软件的早期版本,直接引用了GitHub的Raw File而不是静态文件,并且在访问文件失败时,每5S会重试一次。这样,抢票大军的每一个人,没5S都会向GitHub发送一次请求,造成对GitHub的DDOS攻击。

OpenSSL Bleeding Heart漏洞
2014年4月,谷歌和芬兰安全公司Codenomicon分别报告了OpenSSL存在重大缓冲区溢出漏洞。在OpenSSL心跳扩展的源码中,没有去校验缓冲区的长度,导致攻击者可以直接获取网站的私钥信息。这次漏洞的影响面很广,几乎所有厂商都在打补丁和更新私钥及证书。

Twitter丢失400万活跃用户
2015年2月,Twitter在在季度财报中指出,苹果iOS8升级后出现的漏洞让Twitter至少损失了400万用户。首先是iOS8和 Twitter的兼容性问题流失了100万用户,Safari流览器升级后的共用链接功能无法自动升级,这一问题流失了300万用户,另外还有100万iPhone使用者在升级系统后忘记了Twitter密码,导致无法使用而离开了Twitter。

日本天文卫星“瞳”解体事件
2016年03月,日本天文卫星升空不到一个月(仅正常工作3天),就解体了,该卫星造价约19亿人民币,并搭载了多国的观测设备。
首先,由于干扰,追星仪发生了故障,启用了备用的陀螺仪。
但是,陀螺仪也有故障,导致没有旋转的卫星开始加速旋转,并达到阀值。
然后,为了阻止卫星旋转,卫星开始反向喷气,但程序员把喷气的方向搞反了,卫星越转越快,最终解体。

============================================================
注:本文主要是整理了系统Bug导致的惨痛代价,没有记录下面几种情况(设计失败,黑客攻击,病毒爆发)
*从计算机诞生以来,众多失败的软件项目,没有加到列表中
*1982年,苏联天然气管道爆炸事件,涉及植入恶意代码,没有加到列表中

浅析SOA框架演化

说到SOA的兴起,已经是几年前的事情咯。

按我的理解,SOA框架的演化,主要按四条路来进行的:

第一条路,就是从CORBA衍生,可以作为CORBA的替代品。
这一条路上,典型代表为ICE、Thrift,Avro,ProtocolBuffer+GRPC
其典型行为是,定义idl,对每种语言提供编译器及运行库,然后提供RPC调用功能

第二条路,就是语言框架需要
这一条路上,主要代表为DCOM,EJB,DUBBO,最初目的都是为了给语言框架提供更好的分布式功能。
其典型行为是,语言或框架本身不具备改功能,对其进行了扩展。自身对原语言框架依赖比较严重。

第三条路,就是HTTP中新规范的出现
这一条路上,主要代表为SOAP,REST。
其典型行为是,每种语言都有多种实现,定义schema,每种语言会有多种库支持,最后通过HTTP通讯进行调用

第四条路,就是功能整合
这一条路上,主要代表为WCF,各类ESB产品
其典型特征为:提供多种SOA解决方案

具体使用的时候,其实大家可以看到,这些框架都是万变不离其宗。
那就是,都需要接口描述语言(无论是IDL、WSDL还是什么),都提供良好的支持功能开发较为简单,都是SOA框架解决通讯问题,对于开发人员透明。
大家具体使用是,根据实际情况选取即可。

浅析海量小文件的存储

海量小文件(LOSF,lots of small files)的存储是很多公司都遇到的难题,不管是互联网公司(如社交网站)还是传统的IT企业(如医疗IT的PACS厂商),都会遇到这个难题。

问题的根源在与,无论是文件系统还是网络传输,小文件都需要很多额外操作,如
1、数据布局没有优化,寻址次数大大增加,寻道时间及旋转延迟大大增加,从而每秒的输入输出量 (IOPS,Input/Output Per Second) 、数据吞吐量(Throughput)都明显下降
其实很简单,大家考虑下,拷贝一个1G的文件,和拷贝一个都是零散文件的1G文件夹,其速度差距如何,就清楚了
2、网络通信开销增加,网络延迟变大
其实很简单,大家考虑下,网络传一个1G的文件,和传一个都是零散文件的1G文件夹,其速度差距如何,就清楚了
3、分布式存储,网络交互次数增加,数据存储位置频繁变化,网络通信增加,速度变慢
其实也不难,比如,从一个服务器上拉取10000个文件,与从10个服务器上拉取10000个文件(每次都要问下,下一个文件存储在那个服务器上),谁快谁慢,就清楚了

大家应对这个问题时,采用的方法无非是4种:
1、砸硬件,用硬件性能提升,让传输效率提供
2、用缓存,通过缓存,减少磁盘访问次数,减少交互环节,提高传输效率
3、改变存储策略
4、减少询问次数,比如一次通信,找到1000个文件的地址,400个在服务器A,600个在服务器B,不按文件顺序,而是先从A取400个,再从B取600个,通信就会减少很多,速度就会有所提升(但业务场景要合适才行)

这里主要说一下第3点。
传输一个都是零散文件的1G文件夹时,我们可以这样做,先压缩一下,然后再传递,再解压,发现很多时候居然会节约时间。
也就是说:
压缩+传输压缩文件+解压用的时间 < 直接读取并传送零散文件的时间

但如果直接存储压缩文件,那压缩我们只需要上传时做一次,平时读取时,其实为:
传输+解压用的时间 < 压缩+传输传输压缩文件+解压用的时间 < 直接传送零散文件的时间

那如果压缩和解压的时候,我们只做归档,不做压缩岂不是更节约时间?
传输+归档读取用的时间 < 传输+解压用的时间 < 直接传送零散文件的时间

恩,对了,其实大家的解决方案就是,将大量小文件,写到一个大文件里,这样读取效率就飞一样上来了。
无论是Facebook的Haystack还是淘宝的TFS,用的都是类似的方案。(实际上要复杂的多,请参考论文”Finding a needle in Haystack:Facebook’s photo storage”)

那HDFS呢?当然也支持咯,但要写代码处理一下,大家可以自行找一下Hadoop Archive, Sequence file, CombineFileInputFormat等。

互联网后面10年的重点

当今互联网,已经基本解决了吃、穿、用、住、行、娱乐的问题。

下馆子吃,已经被大众点评、美团、饿了么等刮分完毕。
不下馆子吃、穿、用,各大商城都在做,被淘宝、京东、亚马逊、一号店等刮分完毕。
住、行被携程、艺龙、滴滴快的、神州等刮分完毕。

旅游类的娱乐项目,很大一部分开支为吃、住、行。除去这一部分,组团、自由行等也已经慢慢向成熟市场变化,包括马蜂窝等很多都在做。
非旅游类的娱乐项目,在大众点评、同城等也有了立足之地,更何况这铺天盖地的购票软件咯。

上述市场,一些已经局势明朗很难有大的变化,一些仍是杀得难解难开,一些还待开发。

依据互联网的长尾效应,后面大家要做的是差异化竞争,现在国内互联网巨头中,还没有特别好的、在红海中的差异化竞争案例。大家刚刚从实体店的红海杀到了互联网的蓝海,并正在把互联网蓝海杀红。我相信这方面还是有很多可以做的事情的。

另外,当一个人吃、穿、用、住、行、娱乐的问题解决了,就会有更高的追求。按以往的历史规律,医疗、健康、教育、艺术、科技、政治的需求会逐渐增强。而且,当下各大公司正在努力向医疗领域进军,互联网这10年,应该是医疗健康的十年。

远程预诊存在的问题

现在不少公司在推远程预诊,或者视频问诊,但没有一家真正解决了下面的问题:
1、没有足够的专业医疗队伍资源,在我的另一篇博文中已经说明原因,并指出医学院学生及退休医生是可以考虑的资源
2、没有专业设备,可以获取患者的第一手资料。必须有设备的技术变革,例如大白去掉AI功能。(高清视频音频、心率、血压、脉搏、血糖、呼吸等等等等)
3、没有好的盈利模式,单纯靠吸引患者就诊不太可取,单纯靠卖保健品。。。
4、没有解决患者实际问题,预诊后要做什么呢(请到XX医院做进一步治疗?),患者仅仅多排了一次队浪费时间而已
5、患者不信任,不愿意承担风险,需要一个漫长的过程

那现在能做的是什么呢?
1、慢性病的跟踪治疗,比如高血压、糖尿病等
2、私人诊所的个人咨询
3、私人护理的定期巡诊

与上面最大的区别是什么呢?
1、医患之间有过接触,有了信任
2、医生了解患者的病情
3、患者病情不是很紧急
4、医院可以持续盈利

要预防什么呢?
1、高大上的产品变成了产品推销平台
2、打擦边球,因此医疗事故,触犯法律
3、乱烧钱,最后不了了之

下一次技术进步是什么呢

恩,我说的是技术进步,不是技术革命哦。

个人认为,比较近的一次技术进步有可能为能源的进步,或者说是电池的进步。
电池现在其实是遇到了很大的瓶颈。
随便打开一个智能手机后盖,至少三分之一是电池,而且瞬间会耗光。

另一个进步,就是屏幕的进步,
或者说,可能不再需要特定的屏幕了,
桌面,皮肤,衣服,都可以作为屏幕,甚至这些都不需要。

然后,就是可穿戴设备的进步,
前两个进步完成后,可穿戴设备才会真的牛起来。
现在的可穿戴设备,还没有真正能超越智能手机的。

另外,AI还没有跟上来哦,需要真正天才的指引,这个需要的是技术革命哦。

其他的吗,就要看物理的发展啦。

移动医疗不应该按打车模式推进

现在一些移动医疗的厂商,在做产品的时候,完全采用了打车模式进行推进。

甚至开始照抄出租、专车模式,出来了现有医院、新建医院模式。

但他们忽略了一个问题。

那就是医疗,并不像打车,有如此多的线下资源可以调用。

有几个明显的现象要注意:
1、中国的医疗资源十分匮乏
2、中国的医疗资源过于集中
3、越好的医生越忙,越难以到线上
4、好的医院,不缺患者;
5、看病和打车不一样,不是是个医院你就敢去,是个人你就让他给你治疗
不信?那我问下,如果是你关心的人生病了,你会随便找家医院看看,还是各种打听哪里靠谱?

那问题就来了,即使能有医生到线上,人数有限不说,水平也不会很高。
新建医院,需要有医院的实体,这样成本就高了,而且医生整体数量,不会呈爆炸性增加。
所以,不会像打车软件这样,一呼百应,这个并非不能为的事情,而是一个要持之以恒的工作。

那有哪些是讨巧,现在又能推进的呢:
1、把学医的学生拉到线上,他们不一定有行医资格,但有医疗知识,可以做咨询、网上导诊,这是个不错的开始,比如丁香园就在做
2、用好退休医生队伍,他们经验丰富,有一定闲散时间,但对互联网及移动设备使用不熟练,需要更易用的软件及设备
3、推动国内的社区医院,我们现在的社区医院形同虚设,社区医院的价值根本没有体现出来,其实小问题就应该在社区医院搞定。这个出现的原因,上面已经说到了。解决的方式应该是与政府合作,才会长久。
4、私人诊所,比如牙医、私人医生,这样的服务,这个有美国模式可以借鉴。但要等待政策。
5、远程预诊,缺少专业易用廉价的设备
6、大集团化医院,这个建议几个巨头联合起来,在一二线城市,进行推动。打响品牌战。
7、快速做好远程会诊、诊断、手术等

其实,大家烧钱的地方太集中,另外有几个市场被低估了:
1、运动健身。没有特别专业厂商在做,其实已经可以开展起来了。
2、健康咨询。营养咨询、健身指导、心理咨询、幼儿护理、产前培训。
3、幼老年护理。你懂的。
4、真正的可穿戴设备,现在都是Baby Product,呵呵。
5、需要一个很强势的协会,制定标准,造福人类。