信创
今天，颖奇拜访了荔枝 CTO 丁宁，一起来聊聊这个国内最大的 UGC 声音互动平台，是怎样从创业团队发展成为拥有 200 名研发人员的高效率平台。在这个过程中，荔枝又经历了什么样的技术调整、组织结构演化和人员管理的蜕变，是如何在大浪淘沙的竞争中，坚持了最初的产品理想。
移动互联网早期的技术“拓荒者”，一切从用户出发的技术探索和优化
颖奇：今天很高兴能够跟荔枝 CTO 丁宁同学一起聊聊天，能否先介绍一下荔枝的在音频技术上的发展过程？
丁宁：好的，我先介绍一下整个过程。我们从 2013 年 7 月份开始做荔枝 App，首先考虑到当时的用户在移动环境下的流量消耗问题。探讨了几个方向，比如是用 AAC 还是 mp3？当时 mp3 还是很流行的。但是 mp3 本质的问题是在相同码率的情况下，效果没有 AAC好。
颖奇：当时如何判断音频效果好坏呢？
丁宁：第一种方法是通过听，第二种方法是通过 audition 去分析音频的频谱，能够看到整个能量点的分布情况。然后再通过一段标准的音乐，以及两个相同（音乐的）码率的解码输出，就会看到两者之间的差距。我们希望达到的效果就是要省流量，效果好，还要比较通用。当时在那个环境，用 mp3 在浏览器上可以直接播放；但 AAC 在个别浏览器上是无法播放的。我们想做出来的是全平台都支持的方案，不仅是 App，浏览器也要去支持。所以我们做了一个折中的方案，用户有 wifi 的情况下用 mp3 的 128kpbs。
颖奇：当时 128kbps 的在播客上属于什么水平的音质呢？
丁宁：听音乐的话，256kbps 才是最低的标准，128kpbs 的话被称为广播级别。 因为我们当时没有去考虑到音乐音质，更多的是考虑人声。在移动环境下是动态码率，动态码率差不多是在 16kbps 的AAC。这样的话，AAC 的输出效果就非常好。我们对比了一下，16kbps 的 AAC 其实比 32kbps 的 mp3 效果还好。
颖奇：还可以省一半流量。
丁宁：对，当时我们宣传的重点就是省流量。不过从省流量这方面来说，不仅仅是音频，还要从整个客户端的架构去思考，客户端也要省流量。站在现在来说流量已经不是那么重要了，但 2012、2013 年的时候，流量对人们来说还是蛮重要的。除了码率以外，要解决流量问题，我们就在想架构应该怎么做，我们同时也考察了很多架构。
我们做过几种模型，一种是完全的短链接。完全的短链接会有推送的问题，我可以推送给 iOS 端用户但无法推送到安卓端用户。其实，今天我们看到很多理论，比如增长模型等等，很重要的一点是你必须触达用户，那成本最低的方式就是推送，但当时国内的安卓系统已经去掉了谷歌底层框架，是无法触达用户的，也没有像今天的各类推送平台（例如小米推送、华为推送、极光、个推等等）。
颖奇：是的，推送是一个相对复杂的底层技术。
丁宁：是，所以那时候我们就思考怎么解决这个问题。最开始是完全的 http、轮询，我们做了一版，非常耗电，要想怎么去定轮询的周期。后来做了改进， 这种改进的形态有很多人也用过，叫法不一样但其实原理一样。就是 http 上去之后在服务端设置一个超时时间，把这个请求 hold 住，到了超时时间再把它放下去。受限于运营商、地域性等等，真实环境出了各种各样的问题。因为我们对自己技术的质量要求蛮高的，如果不考虑那么多，做 http 那就好，但我们还是希望高要求自己把东西做好，于是决定做长链接。但是一转长链接之后，对整体架构的调整会非常大。那要保持住这个长链接，底层就要去做 IM。
我们认为当时微信在 IM 上可以做出多种变化，那么长链接也可以在我们的 App 上实现各种能力，所以我们就照着 IM 的要求来做。而且还有一个好处，那就是如果后期去做变现业务，是要全链路加密的，如果跟一条 tcp 连接的话，整个全链路加密就可以快速的收到一起，不用去分开了。总之，这个过程有出现各种各样的问题，从 http 到长链接过渡中间还存在一个过渡，就是 http 和长链接并存的解决方案。但是真正做的时候也有各种问题，我们最后就选择做一条长链接。
颖奇：为了做好长链接，势必要做很多的技术架构调整。
丁宁：没错。那个时候开始建立整个长链接的架构，确定架构之后，就要去服务端和客户端进行调整，之后就是维护一个长链接的策略，对它做大量的优化。比如必须要省电省流量，保持链接的活跃。其中保活还包括进程保活和链接保活，这是两个问题。我相信你原来创业的时候都有遇到这些问题。
颖奇：对，都走过弯路，包括后来对齐策略唤醒等等。本质上来讲，在移动互联网早期发展的时候，作为工具环境、包括所谓的开发者环境，开发者工具没那么成熟的时候都要拓荒的。你们做了长链接架构对现在有什么样的影响呢？
丁宁：那个时候选择长链接作为最初的技术方案，的确对后面的发展产生很大影响。从今天来看，很少有 APP 是有一个长链接的。这种做法微信也有。我们当时对微信这类即时通讯也做了很多的调研。到今天来说，荔枝的主要业务仍然还是在长链接上，大的架构没有换，大部分业务还是在长链接上运行，这个在当时对技术实现的要求很高。
颖奇：是的，后来很多公司把推送做成了独立的业务来发展。
丁宁：对，再举个最简单的例子，一般所有 request response 在一个通道的时候，需要把它进行序号化。原来用 http 的时候，开一个就是一个通道，再开一个是另一个通道。然而现在全部压在一个通道里，要求快速的 response，这就需要进行编码了。早期的安卓机性能不太好，我们测试过当大量 tcp 并发的时候会在底层卡死。如果把这些东西挤在一个通道里，就要去管理这个通道调度。至于怎么样去把上传去做好，那就需要去切分。这个切分的策略，相当于最底层tcp的调度，我们在上层应用层做了一次调度。还有一套优化策略，response 的优先级一定要比上传的优先级要高，并且做好通道里面这些切分的调度，我们当时叫单通道多路复用。
上行就上传和和信令，如何让用户感知不是那么强，影响整个网络，这中间也有很多策略的调整。这事情前前后后折腾很久。我们对技术要求很高就体现在这一点上。
颖奇：但到了今天这个环境下，流量便宜，性能好了，手机电池容量也大了，那么与您当初做的这些努力，到今天来看还有什么变化，或者说有什么更深层次的影响?
丁宁：当初打下的基础，使得现在整体架构没有大调整。现在大家已经对流量不是很关心了，这时候我们推进的就是音频的质量问题。因为其实通道优化已经到一个点上了，那我们更多的是把音频质量往上提。用户上传的音频越来越大，我们就把码率逐渐放开。现在已经支持到 300 多的码率了，这时候上传下载的压力会变得更大，所以我们主要的调整都是在后端的编码与解码。
颖奇：所以是否可以理解为，早期可能更多重视用户体验，而今天其实更多考虑省流量，节省公司的运营成本？
丁宁：会有一些，但其实最大的成本还是音频里面的 CDN，这个流量成本其实没法省。你采用什么样的编码基本上就确定完了，所以我们其实更多考虑到用户层面，他们的流量怎么办。
颖奇：CDN 有多大的成本优化空间呢？是否会根据客户不同的位置和不同时间段去做一些 CDN 的负载，包括迁移、边缘的一些优化等等吗？
丁宁：这个其实有一个调度，最早的时候就有考虑到，但是一直没时间去做。在发展的过程中，我们始终没有特别重点的去考虑 CDN 的成本问题，考虑更多的是用户体验。假设从 1000 万费用中节省到 800 万，一定是省钱了。但如果效果不好，用户体验也会变糟糕。所以我们更多的技术考虑是从用户体验这个角度。怎么才能让用户体验变得更好呢。
我们做了 CDN 的调度体系，也就是融合 CDN，用户根据他的情况来选 CDN，用户的行为日志会不断上传，他请求这些节目的整体情况会不断上传到我们的后台。系统根据当时真实情况去调整 CDN 策略。客户端会收集用户收听情况，会把基本数据收集起来，传回服务器去计算所有收集到的用户信息，然后有算法、权重。 权重里面就包括刚才我说的各种各样的维度，例如地理信息、对接的 CDN、价格、断线率、响应时长等等。这些信息输进去，每天会计算一次并排出一张表，把这些信息全部下发到各类地区的用户，然后决定电信、联通、移动这些运营商的用户到底应该切到哪个 CDN 上去。
颖奇：所以本质上来说，始终还是用户体验为第一优先级，而不是运营成本。
丁宁：是的，我们从始至终没有过多考虑过运营成本，必须是考虑用户体验优先。我宁愿效果好，贵一点没问题。因为我们相信用户体验永远是第一，没有用户再便宜也没有用。
颖奇：这是一个非常棒的价值观。
丁宁：也是我们一直的坚持，能够保证体验的基础上，再去节省成本，做一些自动化的策略。
基础决定命运，专注擅长领域，掌握核心技术
颖奇：荔枝现在也面临着一定规模的增长。您觉得下一阶段，比如未来一两年内，最大的技术挑战可能会在哪些方面？
丁宁：最大的技术挑战一直是直播业务的并发。我们从 2016 年开始做直播后，明星直播的并发中出现的问题还是蛮多的，所以我们在明星直播上做了大量优化。因为我们做的整体策略是平的，没有做特殊处理，常规情况下平的策略不会有问题，因为不会有大的流量并发。但明星一来，可能带来的就是一两百万的用户，这需要做一些架构上的调整。我们也考虑过做两套系统，不过这样成本还是蛮大的，平常用不到另一套。所以解决直播业务并发上面，我们花了大量的精力。
颖奇：应该有第三方公司能够提供这样的解决方案。
丁宁：嗯，的确有一些。但我们有一个技术理念就是最核心的技术或能力一定要自己可控。不论是在发展中，还是现在。
颖奇：这可能跟荔枝的发展过程有关系，以前早期创业公司没有那么好的开发者服务工具，所以只能自己做。而现在的创业公司一开始就有很多的选择，所以他们不愿意自己做，发展到中后期的话可能还要补课。
丁宁：是的，自己控制核心的能力和技术，本身的好处很容易理解。例如，出现问题能快速解决，所有需求能够快速响应，不依赖于外部。更重要的是，可以“锻炼程序员的灵魂”。当我们面临非常底层的技术时候，都需要去面对和克服挑战的对吧？这是一种技术价值观，如果没有坚持这种技术价值观，这样的技术文化传承不下去的话，等到我们需要去挑战一些更大型项目的时候，技术人员的水平就很堪忧了。
颖奇：说到这里，想聊聊荔枝的研发团队管理。荔枝现在的研发团队是什么样的规模？
丁宁：200 多人吧。
颖奇：管理这么大规模的团队，有没有您已经坚持了很多年的管理方法或理念，包括一些策略？
丁宁：对于整个技术团队，我有一个最基本的要求，就是刚刚所说的核心的东西要掌握自己手里。你会发现，当团队有这么一个信念之后，技术团队聚拢的就是这批人，这就是我在技术层面的价值观。我认为这个价值观可以锻炼人。
我们潜心从底层一点点去敲代码、分析，去思考可能出现的各种问题过程中，可以锻炼技术团队的思维能力，让大家更缜密的去考虑技术问题，所以当时我们招聘技术人员的时候一直都是秉承这个理念，而我们的招聘也是非常严格的。无论是正式员工还是实习生，我们的面试要求都一视同仁，在技术水平上我们的要求一直很高。
随着时间推移，我的招聘思维也会有一些变化。最早我的要求是技术能力第一、理念第二、人品可能是第三。后来慢慢我调整了，我开始认同技术理念第一、人品第二、技术能力第三的顺序，这也是一个认识上的变化。
颖奇：200 多个程序员，他们会有很多想法，怎么去理性地管理这些人？
丁宁：这也是有一个发展过程的。在 100 个研发人员的时候，我们没有特别地去做管理。大家按照组织架构去分工，产品线、研发线、运营线。我就管研发这条线，例如客户端、服务端、数据等等，是很典型的组织架构。需求来了就一层层分下去，然后所有迭代我那时候都管。
随着公司发展，业务线更多的时候，我们就开始了结构调整。首先，是调整一些工程师去到业务线上，分业务研发和基础研发。基础研发还是分客户端、服务器以及数据分析，慢慢开始做基础的核心业务。这种组织结构会有一个问题，就是他们去做很多东西的时候会和业务的系统有一些重复工作，在中后期时不时会发生重复的情况。
当业务线变得庞大，企业相对稳定了的时候又要进行调整。业务线发展速度非常快，基础研发提供一些东西不满足他们的需求，认为这个东西做的还没我们做得好，于是业务线自己就做了相同的东西。基础研发就很头疼，觉得既然不认同我们做的东西，那我们存在的价值是什么？所以我们回过头来就要去调整整个基础研发，重新定位基础研发和业务研发，大家的目标是什么？然后我们就逐渐地拆分和确认目标，比如分成增长技术化的，就是以数据来驱动整条业务线的前进，然后还有一些技术留在那个研发体系里，目标是去做更好地底层支持，进行产品化。
颖奇：基础研发的产品化，是说他必须得被业务部门认可。
丁宁：对。未来大方向就是可以产品化。我的小目标是基础研发可以支持业务发展，大目标是以后把做的这些东西全部串联起来，技术方面全部进行项目制的变革。把所有事情全部包装并且项目化，项目化之后确定责任人。
颖奇：那是否会面临一个问题，可能外面有很多方案做得更好，所以业务部门选择方案时，并不用选公司内部的，这样在荔枝内部可以吗？
丁宁：没错，这可以。业务线具有最大决策权。因为 Team Leader 是要考虑到非常多事情包括成本，而且身上承担最终业绩的。如果他觉得用外部的方案更好，那你可以去用。而内部的这些技术研发肯定也有一些优势。比如说内部的成本核算，灵活的需求定制等等。
基础研发的第一目标是业务支持，第二是把自己做成成熟的项目。项目最大的目标就是能做成通用的，能够具备完整的对外标准化服务的能力，所以现在全部都往这种平台化系统化去引进。以前都是不成体系的。
“责任权利”一致的管理方法，真正激活研发团队潜力
颖奇: 现在的组织结构下，如何确保大家目标一致，完成业绩呢？
丁宁：技术在每年年初的时候会进行讨论。这一年我们要去做什么，每半年调整一次目标。我们先定几个大的方向，然后从这里面摘出来一些重点项目。其实每一个团队要跟的项目不止一个。但重要的核心考核往往是核心的负责人身兼 1-2 个项目。所以我们把这些一年的项目，根据职能摘出来。比如说是客户端做主导的，那就是放到客户端的这个 Team Leader 里，跟服务端相关的，就放在服务端的 Team Leader 里。所以最后你会发现每个人身上都跟了大量项目。
颖奇: 这是 OKR 的拆分方法了。
丁宁：技术团队根据 KPI 来拆分 OKR。比如有两个重要的项目和两个内部项目的情况下，判断哪些是重要的、哪些是在这个季度我们一定要做完的，哪些是在要在下个季度要去完成的，哪些是这个季度要做一些预研的，全部拆出来，是一种 OKR 和KPI 结合的管理方法。KPI 只是数字，那怎么实现这个数字，这就要把路径写出来。技术同学在讨论 KPI 的时候会有些偏离业务，所以我们会开会多次讨论 KPI，会明确下来这个 KPI 最终是为什么东西来服务的。
颖奇：所以制定 KPI 的人，就是整个研发中心的班委。类似阿里体系的班委。
丁宁：是的。一个研发中心会有一个班委，这个班委就决策哪些项目是需要被列入 KPI 的，需要去跟进的，以及考察它的指标是什么、它到底产生什么效果、它的结果会对什么东西产生作用？从这个角度去设计KPI就避免了 KPI 都是一些技术指标这种情况。因为数字本身没有意义。做的再好看、响应再快，没人用就没有意义。
这个过程需要大量的沟通，班委内部要达成一致。开始的时候大家都是不一致的，比如说客户端的要做一个项目，需要服务端的支持，那是不是把部分 KPI 让服务端去扛，客户端扛一部分。后来考虑觉得不行。我要求“责任”、“权利”必须要一致，不能两个团队都去扛。如果项目最后做失败了，到底是服务端的责任还是客户端的责任。
颖奇：其实我们在做 ONES 的时候也有这样一个理念，就是任何事情有且只有一个人负责，每个任务包括每个版本每个迭代都是这样。
丁宁：是的，但也有一个问题就是技术同学比较单纯。我们强调的企业文化是目标一致嘛，大家就想，那个目标一致不就是让我配合其他团队么。而其实目标一致的前提是要“责任、权利”清晰，再去做到目标一致。如果不清晰，又要求大家一致，就会出现扯皮的现象。所以这个要先思想进行转变，思想要想转变，首先要清晰责任人是谁。
颖奇：所以这是说，我们建立企业文化的同时，也需要给研发同学进行企业文化的翻译，激发团队的战斗力。
CTO 的四年之痒，以产品思维和更高的视角做研发管理
颖奇：我刚才听您讲的是技术上的一些理念和技术团队的发展过程，那您个人是怎样的职业经历呢？才能使得技术团队形成了现在的规模和战斗力。
丁宁：我早期是做项目管理的，我是从 2007 年开始做项目管理，一直做到 2016 年。当时的项目管理牵扯不到这么多像 OKR、KPI 这样的管理目标等上层管理方法。
颖奇：当时的项目管理更多可能是瀑布流的或 PMP。
丁宁：对，我那时候用 Scrum，到今天还是。但是项目管理本身管的是时间、风险、项目人员的安排，做完以后出不出业绩是完全不确定的。当我从项目管理这个圈子里面跳出来的时候，站在更高的层面从公司业绩实现这个角度去看时，看到的就不仅仅是项目管理这么一个点了。我们不能是原来那种只是盯着这个项目“做完就好”这样简单的逻辑，业务思维要更好，更多考虑到整体业绩。
当思考业绩本身的时候，就会不断的去转变。从原来盯的效率，讨论能不能我做出来，能不能按要求按时间做好，到现在要考虑的是业绩本身，不仅要做完项目，更要看这个东西上线了以后有没有很好的效果。让它能够更好的发展和迭代，这个思维一定要先转变。
颖奇：是怎样的契机，使您从项目管理的程序员转换成一个对业绩或者对业务有理解的 CTO？
丁宁：应该说是 2016 年吧。2016 年的时候，公司在做调整。从原来录播的大业务线调整出一个直播的新业务线。当时直播的时候业务线发展速度非常快，让我们看到，第一，有一个业务要快速去调整的时候，需要去做很多的适配。我们之前做了很多的东西都不一定合适。在这个新的业务线上去实施的时候是没有办法快速去适应的。那时候，我需要想办法去面对快速的变化，这个其实是作为创始人应该去关注的。那我发现不仅是 Marco（荔枝 CEO 赖奕龙）需要关注的，我觉得我也需要跳出来，面对变化和发展，来适应支撑新的业务，需要有更多思考。
当时我想，如果我仅仅是技术员去做技术管理、项目管理，能支撑起这样的业务吗？从现在来看，这些快速的发展、这种演变，以当时的我根本就支撑不起。所以我要求自己往高了拔，刚好那时候也参加了很多外部的管理培训，把目标管理、项目管理、业绩管理慢慢全部融合在一起。让我真正意识到要去站得更高，最终要考虑的是业绩。
颖奇：这是一种管理意识，我们不是仅仅把东西做出来，我们做的也不是产品本身。
丁宁：是的，跳出来后发现其实项目管理只是要做事情中间的一小部分。当时我做了很多的思考，怎么样让技术团队、让中层管理也要有这种转变。大家一起来关注的是最终的那个结果，而不是做完这件事情就结束了。
颖奇：其实这个转变挺难的。可能需要一个契机，例如公司转型或发展速度非常快。要有这样的一个空缺和要求去压着大家去成长，包括压着 CTO 去成长。
丁宁：没错。其实很多人不是说有一个叫 CTO 的四年之痒。如果公司业绩一直往上走，那其实 CTO 做到第四年的时候会发现基本上各种框架、服务都已经做的很完善了。如果没有很大的挑战，之前的坑都踩完了，过不去的坎其实也肯定早就不做了。CTO做到第四年、第五年到底应该做些什么？
颖奇：CTO 需要被业务推着再次成长。
丁宁：对，所以说有四年之痒的这么一个说法。其实我也深刻地感受到，到了那个时间点，需要去关注更大的东西了，能力应该要有更大地发挥，而不是仅仅在技术本身了。刚跳出来时候其实蛮难受的。管业务线的时候觉得抓不住。以前面对技术同学都好管，大家一起做完一个东西就好。现在要去看业务，让数据更好的增长，也要去分析业务和用户需求。
颖奇：所以一个什么样的技术人员才可能在未来变成 CTO 呢？
丁宁：我认为是有产品思维的，既做技术又需要有产品思维。CTO 需要有对业务发展的趋势判断，也需要有自己的看法和理解。在带业务的过程中，肯定有很多挑战，因为毕竟管理产品和运营肯定不是管理技术那种手段。运营和产品又是直接跟用户打交道的人。那怎么样用产品运营的话术去沟通？然后怎么样去理解他们的需求？现在要去挖掘用户深层次的需求点，要和产品和运营一起去观察用户核心的需求在哪里，而不仅仅是站在技术角度去思考。
深耕音频 UGC，用声音和用户在一起
颖奇：您怎么看待现在的直播行业，包括直播视频，或者有哪些商业领域是您现在比较关注的？
丁宁：我们现在做的主要是直播和录播两个业务。直播其实现在大家可以看到是从 2015 年左右开始到 2016 年一步步发展起来的。我个人判断，直播仍然是个流量型业务。从整个直播生态来说，它的留存一直都在很难持续的往上做，需要不断的去拿流量来支撑起来商业变现。所以我们要做的工作就是精细化的深度运营来提高转化率。
颖奇：基本上不同产品的单个用户的获取成本基本差不多？
丁宁：对。所以需要精细化的深度运营提高竞争力。精细化运营的话，品类要足够丰富，要建立一些制度、规则，以及和别人不一样的特点。当然，别人去抄你这是很难避免的。但是要保持有一些跟别人不一样的东西。
颖奇：就好像我们现在创业一样，行业本身没有什么秘密。我们能做的事情大家都能做，但是大家在同样的情况下，选择打牌的方法跟出牌的顺序是不一样的。这个明牌是说所有人都可以看得到我的出牌，这样的话这个公司在市场上取得成就才不是靠运气，而是真正实打实的定位和战略。通过组织和精细化运营，切实的把战略真正执行出来。不知道荔枝是否也是这样，有你们独特的定位，而且明确告诉大家的。
丁宁：荔枝从一开始到现在一直定位的都是 UGC，纯 UGC。我们的理念就是把草根培养出来。有些人对自己的声音比较自信或者有异于常人的能力，我们就要把他们挖掘出来，推向更多的用户。偶尔明星过来代言，也是为了能够去提升整个品牌的知名度。而荔枝产品本身不管是录播还是在直播，是完全纯 UGC 的。
为了培养起 UGC 的模式，我们不仅有录播的播客学院，也有直播的播客学院。面向小主播会去教这种播客怎么样去做，直播怎么样去开，要怎么样去发声、说话，怎样去跟用户互动。到了中间段的这些主播，我们会去教大家怎么样去找流量实现自我增长、拉新以及保证留存和促活，怎么样去做变现，促进用户帮你做分享。而面向大主播，则更多的是变现和名气。要去思考商业模式是什么。直播其实非常简单。大主播有固定的金主，他要做的是怎么样去获得更多流量，找到更多的金主，所以可能会有不同的业务形态和变现方式。
颖奇：所以这特别像淘宝的发展状态，像淘宝大学。中小主播自己学会运营、找流量、自己去做广告。成长到一定规模后，像淘宝大学来教这些卖家们去来运营。
丁宁：对，教给大家基础技能，怎么包装自己宣传自己。完成了整个的包装链学习链，到大主播后就是有整个主播运营团队去跟进了。我们会义不容辞去帮助主播，也会去投一些工作室。我们并不是狭隘的只在做荔枝本身，我们其实是做整个中国的播客市场，这个市场我们觉得现在还很早期。
颖奇：除了声音领域的录播、直播，您还关注哪些好玩的商业？
丁宁：我现在特别看好的是新能源汽车。因为我觉得新能源智能汽车会是一个超级终端。它不仅是像手机载体，它是比手机还大的一个超级终端。当然可能使用频度没有手机这么高。汽车具有承载作用，还有移动和汇聚的作用，各种信息都汇聚在一起，像车联网、物联网、互联网等等。而新能源的发展将会对这个行业产生很大的激发。我们现在也在和一些新能源汽车进行合作。
颖奇：这会回到一个非常经典的场景上去，就是开车听电台。新能源汽车取代旧能源车，然后荔枝来取代掉老的电台。
丁宁：是的。语音一说，需要什么电台节目，还能有些互动。现在大屏又是趋势，不久的将来，整个前挡风玻璃是有可能是完全的AR显示。AI在音频领域可以审核内容也可以做千人千面的智能推荐。每天输入一些性格、音色、知识面等等这些参数数据，那它可能就会去学习相关的这个领域，同时去做相关领域的节目。然后我们输进去的一个基础音色，可能就是你的音色，再有一些微调的变化，这样一个很有特色的主播就出来了。 这完全是有可能的。
颖奇：是否可以推荐些您最近在看的觉得不错的书给大家？
丁宁：How Google Works（《重新定义公司》）挺好的，这是一本管理书籍。除此以外最近德鲁克的书我也看的特别多。从技术视角跳出来之后，我发现纯管理重塑了我。它一直在向我提问，我到底在做的是什么？我的客户到底是谁？他们的需求到底是什么？就这三个问题一直在问自己，让我对我们现在做这个事情有更深刻的了解。
