用声音在一起，听荔枝 CTO 丁宁聊 UGC 声音互动平台的技术世界

[ONES]

· 本文内容为图文形式

· 栏目：对话 CTO

· 阅读时间：15 分钟

· 阅读建议：深度长文，请配合文末福利慢慢食用

· 掌握难度：★★★☆☆

专栏介绍

「对话 CTO 」是极客公园的一档最新专栏，以技术人的视角聊聊研发管理者的发展和成长。

本专栏由 ONES 的创始人&CEO 王颖奇作为特邀访谈者。王颖奇曾参与金山软件 WPS、金山毒霸等大型软件的核心开发工作； 2011 年创立了正点科技，旗下产品正点闹钟、正点日历在全球用户过亿； 2014 年，王颖奇在知名美元基金晨兴资本任 EIR，并以个人身份参与十余家公司的管理咨询工作； 2015 年，王颖奇创立 ONES，致力于提供企业级研发管理解决方案。

摘要

美女主播、短视频、游戏直播，这些纷繁的视觉信息似乎已经将我们的日常填满。然而，在视觉的另一端，荔枝正在挖掘声音的一万种可能。荔枝是国内最大的 UGC 声音互动平台，在荔枝你可以感受到或独特、或美好的声音带来的故事，通过声音的互动来认识一个主播或体验一种生活。在这个用声音打造的世界里，荔枝已经孕育了超过 500 万的优质声音主播和 2 亿多注册用户。

2013 年，荔枝还是一个普通的播客创业团队。当时中国的移动互联网方兴未艾，但流量价格还远未及现在的体贴亲民。作为声音互动平台的技术负责人，荔枝联合创始人兼 CTO 丁宁当时最棘手的问题是如何让用户以最少的流量听到最高品质的声音。2013 年荔枝上线了 iOS 和 Android 两个移动 App 版本，音频编码用 mp3 还是 AAC，长链接的研发投入是否有必要，是当时的丁宁每天都在思考的问题。

2014 年，荔枝便获得了 5 万个电台的开通，超过 Podcast 时代中文播客的总量。从零到一的过程中，能够实现业务如此快速发展，不仅是创始团队对于播客市场趋势的准确判断，也是以用户体验为准则的技术团队夜以继日对技术架构的优化、尝试和探索。在业务发展的关键阶段，用户体验和研发运营成本的平衡又该如何解决？

2015 年的播客平台爆发之后，移动音频出现了巨大的竞争和分化。经过阵痛和思考，荔枝仍然留在了 UGC 的战场，坚持最初的理想——给年轻人一个用“声音陪伴的世界”。激烈的市场环境下，丁宁也在经受着磨练和自我升级，完成了从技术项目的管理者到成熟 CTO 的管理转型，带领大家突出重围，构建荔枝的技术壁垒。

今天，颖奇拜访了荔枝 CTO 丁宁，一起来聊聊这个国内最大的 UGC 声音互动平台，是怎样从创业团队发展成为拥有 200 名研发人员的高效率平台。在这个过程中，荔枝又经历了什么样的技术调整、组织结构演化和人员管理的蜕变，是如何在大浪淘沙的竞争中，坚持了最初的产品理想。

1、移动互联网早期的技术“拓荒者”，一切从用户出发的技术探索和优化

颖奇：今天很高兴能够跟荔枝 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 上去。

颖奇：所以本质上来说，始终还是用户体验为第一优先级，而不是运营成本。

丁宁：是的，我们从始至终没有过多考虑过运营成本，必须是考虑用户体验优先。我宁愿效果好，贵一点没问题。因为我们相信用户体验永远是第一，没有用户再便宜也没有用。

颖奇：这是一个非常棒的价值观。

丁宁：也是我们一直的坚持，能够保证体验的基础上，再去节省成本，做一些自动化的策略。

2、基础决定命运，专注擅长领域，掌握核心技术

颖奇：荔枝现在也面临着一定规模的增长。您觉得下一阶段，比如未来一两年内，最大的技术挑战可能会在哪些方面？

丁宁：最大的技术挑战一直是直播业务的并发。我们从 2016 年开始做直播后，明星直播的并发中出现的问题还是蛮多的，所以我们在明星直播上做了大量优化。因为我们做的整体策略是平的，没有做特殊处理，常规情况下平的策略不会有问题，因为不会有大的流量并发。但明星一来，可能带来的就是一两百万的用户，这需要做一些架构上的调整。我们也考虑过做两套系统，不过这样成本还是蛮大的，平常用不到另一套。所以解决直播业务并发上面，我们花了大量的精力。

颖奇：应该有第三方公司能够提供这样的解决方案。

丁宁：嗯，的确有一些。但我们有一个技术理念就是最核心的技术或能力一定要自己可控。不论是在发展中，还是现在。

颖奇：这可能跟荔枝的发展过程有关系，以前早期创业公司没有那么好的开发者服务工具，所以只能自己做。而现在的创业公司一开始就有很多的选择，所以他们不愿意自己做，发展到中后期的话可能还要补课。

丁宁：是的，自己控制核心的能力和技术，本身的好处很容易理解。例如，出现问题能快速解决，所有需求能够快速响应，不依赖于外部。更重要的是，可以“锻炼程序员的灵魂”。当我们面临非常底层的技术时候，都需要去面对和克服挑战的对吧？这是一种技术价值观，如果没有坚持这种技术价值观，这样的技术文化传承不下去的话，等到我们需要去挑战一些更大型项目的时候，技术人员的水平就很堪忧了。

颖奇：说到这里，想聊聊荔枝的研发团队管理。荔枝现在的研发团队是什么样的规模？

丁宁：200 多人吧。

颖奇：管理这么大规模的团队，有没有您已经坚持了很多年的管理方法或理念，包括一些策略？

丁宁：对于整个技术团队，我有一个最基本的要求，就是刚刚所说的核心的东西要掌握自己手里。你会发现，当团队有这么一个信念之后，技术团队聚拢的就是这批人，这就是我在技术层面的价值观。我认为这个价值观可以锻炼人。

我们潜心从底层一点点去敲代码、分析，去思考可能出现的各种问题过程中，可以锻炼技术团队的思维能力，让大家更缜密的去考虑技术问题，所以当时我们招聘技术人员的时候一直都是秉承这个理念，而我们的招聘也是非常严格的。无论是正式员工还是实习生，我们的面试要求都一视同仁，在技术水平上我们的要求一直很高。

随着时间推移，我的招聘思维也会有一些变化。最早我的要求是技术能力第一、理念第二、人品可能是第三。后来慢慢我调整了，我开始认同技术理念第一、人品第二、技术能力第三的顺序，这也是一个认识上的变化。

颖奇：200 多个程序员，他们会有很多想法，怎么去理性地管理这些人？

丁宁：这也是有一个发展过程的。在 100 个研发人员的时候，我们没有特别地去做管理。大家按照组织架构去分工，产品线、研发线、运营线。我就管研发这条线，例如客户端、服务端、数据等等，是很典型的组织架构。需求来了就一层层分下去，然后所有迭代我那时候都管。

随着公司发展，业务线更多的时候，我们就开始了结构调整。首先，是调整一些工程师去到业务线上，分业务研发和基础研发。基础研发还是分客户端、服务器以及数据分析，慢慢开始做基础的核心业务。这种组织结构会有一个问题，就是他们去做很多东西的时候会和业务的系统有一些重复工作，在中后期时不时会发生重复的情况。

当业务线变得庞大，企业相对稳定了的时候又要进行调整。业务线发展速度非常快，基础研发提供一些东西不满足他们的需求，认为这个东西做的还没我们做得好，于是业务线自己就做了相同的东西。基础研发就很头疼，觉得既然不认同我们做的东西，那我们存在的价值是什么？所以我们回过头来就要去调整整个基础研发，重新定位基础研发和业务研发，大家的目标是什么？然后我们就逐渐地拆分和确认目标，比如分成增长技术化的，就是以数据来驱动整条业务线的前进，然后还有一些技术留在那个研发体系里，目标是去做更好地底层支持，进行产品化。

颖奇：基础研发的产品化，是说他必须得被业务部门认可。

丁宁：对。未来大方向就是可以产品化。我的小目标是基础研发可以支持业务发展，大目标是以后把做的这些东西全部串联起来，技术方面全部进行项目制的变革。把所有事情全部包装并且项目化，项目化之后确定责任人。

颖奇：那是否会面临一个问题，可能外面有很多方案做得更好，所以业务部门选择方案时，并不用选公司内部的，这样在荔枝内部可以吗？

丁宁：没错，这可以。业务线具有最大决策权。因为 Team Leader 是要考虑到非常多事情包括成本，而且身上承担最终业绩的。如果他觉得用外部的方案更好，那你可以去用。而内部的这些技术研发肯定也有一些优势。比如说内部的成本核算，灵活的需求定制等等。

基础研发的第一目标是业务支持，第二是把自己做成成熟的项目。项目最大的目标就是能做成通用的，能够具备完整的对外标准化服务的能力，所以现在全部都往这种平台化系统化去引进。以前都是不成体系的。

3、“责任权利”一致的管理方法，真正激活研发团队潜力

颖奇: 现在的组织结构下，如何确保大家目标一致，完成业绩呢？

丁宁：技术在每年年初的时候会进行讨论。这一年我们要去做什么，每半年调整一次目标。我们先定几个大的方向，然后从这里面摘出来一些重点项目。其实每一个团队要跟的项目不止一个。但重要的核心考核往往是核心的负责人身兼 1-2 个项目。所以我们把这些一年的项目，根据职能摘出来。比如说是客户端做主导的，那就是放到客户端的这个 Team Leader 里，跟服务端相关的，就放在服务端的 Team Leader 里。所以最后你会发现每个人身上都跟了大量项目。

颖奇: 这是 OKR 的拆分方法了。

丁宁：技术团队根据 KPI 来拆分 OKR。比如有两个重要的项目和两个内部项目的情况下，判断哪些是重要的、哪些是在这个季度我们一定要做完的，哪些是在要在下个季度要去完成的，哪些是这个季度要做一些预研的，全部拆出来，是一种 OKR 和 KPI 结合的管理方法。KPI 只是数字，那怎么实现这个数字，这就要把路径写出来。技术同学在讨论 KPI 的时候会有些偏离业务，所以我们会开会多次讨论 KPI，会明确下来这个 KPI 最终是为什么东西来服务的。

颖奇：所以制定 KPI 的人，就是整个研发中心的班委。类似阿里体系的班委。

丁宁：是的。一个研发中心会有一个班委，这个班委就决策哪些项目是需要被列入 KPI 的，需要去跟进的，以及考察它的指标是什么、它到底产生什么效果、它的结果会对什么东西产生作用？从这个角度去设计 KPI 就避免了 KPI 都是一些技术指标这种情况。因为数字本身没有意义。做的再好看、响应再快，没人用就没有意义。

这个过程需要大量的沟通，班委内部要达成一致。开始的时候大家都是不一致的，比如说客户端的要做一个项目，需要服务端的支持，那是不是把部分 KPI 让服务端去扛，客户端扛一部分。后来考虑觉得不行。我要求“责任”、“权利”必须要一致，不能两个团队都去扛。如果项目最后做失败了，到底是服务端的责任还是客户端的责任。

颖奇：其实我们在做 ONES 的时候也有这样一个理念，就是任何事情有且只有一个人负责，每个任务包括每个版本每个迭代都是这样。

丁宁：是的，但也有一个问题就是技术同学比较单纯。我们强调的企业文化是目标一致嘛，大家就想，那个目标一致不就是让我配合其他团队么。而其实目标一致的前提是要“责任、权利”清晰，再去做到目标一致。如果不清晰，又要求大家一致，就会出现扯皮的现象。所以这个要先思想进行转变，思想要想转变，首先要清晰责任人是谁。

颖奇：所以这是说，我们建立企业文化的同时，也需要给研发同学进行企业文化的翻译，激发团队的战斗力。

4、CTO 的四年之痒，以产品思维和更高的视角做研发管理

颖奇：我刚才听您讲的是技术上的一些理念和技术团队的发展过程，那您个人是怎样的职业经历呢？才能使得技术团队形成了现在的规模和战斗力。

丁宁：我早期是做项目管理的，我是从 2007 年开始做项目管理，一直做到 2016 年。当时的项目管理牵扯不到这么多像 OKR、KPI 这样的管理目标等上层管理方法。

颖奇：当时的项目管理更多可能是瀑布流的或 PMP。

丁宁：对，我那时候用 Scrum，到今天还是。但是项目管理本身管的是时间、风险、项目人员的安排，做完以后出不出业绩是完全不确定的。当我从项目管理这个圈子里面跳出来的时候，站在更高的层面从公司业绩实现这个角度去看时，看到的就不仅仅是项目管理这么一个点了。我们不能是原来那种只是盯着这个项目“做完就好”这样简单的逻辑，业务思维要更好，更多考虑到整体业绩。

当思考业绩本身的时候，就会不断的去转变。从原来盯的效率，讨论能不能我做出来，能不能按要求按时间做好，到现在要考虑的是业绩本身，不仅要做完项目，更要看这个东西上线了以后有没有很好的效果。让它能够更好的发展和迭代，这个思维一定要先转变。

颖奇：是怎样的契机，使您从项目管理的程序员转换成一个对业绩或者对业务有理解的 CTO ？

丁宁：应该说是 2016 年吧。2016 年的时候，公司在做调整。从原来录播的大业务线调整出一个直播的新业务线。当时直播的时候业务线发展速度非常快，让我们看到，第一，有一个业务要快速去调整的时候，需要去做很多的适配。我们之前做了很多的东西都不一定合适。在这个新的业务线上去实施的时候是没有办法快速去适应的。那时候，我需要想办法去面对快速的变化，这个其实是作为创始人应该去关注的。那我发现不仅是 Marco （荔枝 CEO 赖奕龙）需要关注的，我觉得我也需要跳出来，面对变化和发展，来适应支撑新的业务，需要有更多思考。

当时我想，如果我仅仅是技术员去做技术管理、项目管理，能支撑起这样的业务吗？从现在来看，这些快速的发展、这种演变，以当时的我根本就支撑不起。所以我要求自己往高了拔，刚好那时候也参加了很多外部的管理培训，把目标管理、项目管理、业绩管理慢慢全部融合在一起。让我真正意识到要去站得更高，最终要考虑的是业绩。

颖奇：这是一种管理意识，我们不是仅仅把东西做出来，我们做的也不是产品本身。

丁宁：是的，跳出来后发现其实项目管理只是要做事情中间的一小部分。当时我做了很多的思考，怎么样让技术团队、让中层管理也要有这种转变。大家一起来关注的是最终的那个结果，而不是做完这件事情就结束了。

颖奇：其实这个转变挺难的。可能需要一个契机，例如公司转型或发展速度非常快。要有这样的一个空缺和要求去压着大家去成长，包括压着 CTO 去成长。

丁宁：没错。其实很多人不是说有一个叫 CTO 的四年之痒。如果公司业绩一直往上走，那其实 CTO 做到第四年的时候会发现基本上各种框架、服务都已经做的很完善了。如果没有很大的挑战，之前的坑都踩完了，过不去的坎其实也肯定早就不做了。CTO 做到第四年、第五年到底应该做些什么？

颖奇：CTO 需要被业务推着再次成长。

丁宁：对，所以说有四年之痒的这么一个说法。其实我也深刻地感受到，到了那个时间点，需要去关注更大的东西了，能力应该要有更大地发挥，而不是仅仅在技术本身了。刚跳出来时候其实蛮难受的。管业务线的时候觉得抓不住。以前面对技术同学都好管，大家一起做完一个东西就好。现在要去看业务，让数据更好的增长，也要去分析业务和用户需求。

颖奇：所以一个什么样的技术人员才可能在未来变成 CTO 呢？

丁宁：我认为是有产品思维的，既做技术又需要有产品思维。CTO 需要有对业务发展的趋势判断，也需要有自己的看法和理解。在带业务的过程中，肯定有很多挑战，因为毕竟管理产品和运营肯定不是管理技术那种手段。运营和产品又是直接跟用户打交道的人。那怎么样用产品运营的话术去沟通？然后怎么样去理解他们的需求？现在要去挖掘用户深层次的需求点，要和产品和运营一起去观察用户核心的需求在哪里，而不仅仅是站在技术角度去思考。

5、深耕音频 UGC，用声音和用户在一起

颖奇：您怎么看待现在的直播行业，包括直播视频，或者有哪些商业领域是您现在比较关注的？

丁宁：我们现在做的主要是直播和录播两个业务。直播其实现在大家可以看到是从 2015 年左右开始到 2016 年一步步发展起来的。我个人判断，直播仍然是个流量型业务。从整个直播生态来说，它的留存一直都在很难持续的往上做，需要不断的去拿流量来支撑起来商业变现。所以我们要做的工作就是精细化的深度运营来提高转化率。

颖奇：基本上不同产品的单个用户的获取成本基本差不多？

丁宁：对。所以需要精细化的深度运营提高竞争力。精细化运营的话，品类要足够丰富，要建立一些制度、规则，以及和别人不一样的特点。当然，别人去抄你这是很难避免的。但是要保持有一些跟别人不一样的东西。

颖奇：就好像我们现在创业一样，行业本身没有什么秘密。我们能做的事情大家都能做，但是大家在同样的情况下，选择打牌的方法跟出牌的顺序是不一样的。这个明牌是说所有人都可以看得到我的出牌，这样的话这个公司在市场上取得成就才不是靠运气，而是真正实打实的定位和战略。通过组织和精细化运营，切实的把战略真正执行出来。不知道荔枝是否也是这样，有你们独特的定位，而且明确告诉大家的。

丁宁：荔枝从一开始到现在一直定位的都是 UGC，纯 UGC。我们的理念就是把草根培养出来。有些人对自己的声音比较自信或者有异于常人的能力，我们就要把他们挖掘出来，推向更多的用户。偶尔明星过来代言，也是为了能够去提升整个品牌的知名度。而荔枝产品本身不管是录播还是在直播，是完全纯 UGC 的。

为了培养起 UGC 的模式，我们不仅有录播的播客学院，也有直播的播客学院。面向小主播会去教这种播客怎么样去做，直播怎么样去开，要怎么样去发声、说话，怎样去跟用户互动。到了中间段的这些主播，我们会去教大家怎么样去找流量实现自我增长、拉新以及保证留存和促活，怎么样去做变现，促进用户帮你做分享。而面向大主播，则更多的是变现和名气。要去思考商业模式是什么。直播其实非常简单。大主播有固定的金主，他要做的是怎么样去获得更多流量，找到更多的金主，所以可能会有不同的业务形态和变现方式。

颖奇：所以这特别像淘宝的发展状态，像淘宝大学。中小主播自己学会运营、找流量、自己去做广告。成长到一定规模后，像淘宝大学来教这些卖家们去来运营。

丁宁：对，教给大家基础技能，怎么包装自己宣传自己。完成了整个的包装链学习链，到大主播后就是有整个主播运营团队去跟进了。我们会义不容辞去帮助主播，也会去投一些工作室。我们并不是狭隘的只在做荔枝本身，我们其实是做整个中国的播客市场，这个市场我们觉得现在还很早期。

颖奇：除了声音领域的录播、直播，您还关注哪些好玩的商业？

丁宁：我现在特别看好的是新能源汽车。因为我觉得新能源智能汽车会是一个超级终端。它不仅是像手机载体，它是比手机还大的一个超级终端。当然可能使用频度没有手机这么高。汽车具有承载作用，还有移动和汇聚的作用，各种信息都汇聚在一起，像车联网、物联网、互联网等等。而新能源的发展将会对这个行业产生很大的激发。我们现在也在和一些新能源汽车进行合作。

颖奇：这会回到一个非常经典的场景上去，就是开车听电台。新能源汽车取代旧能源车，然后荔枝来取代掉老的电台。

丁宁：是的。语音一说，需要什么电台节目，还能有些互动。现在大屏又是趋势，不久的将来，整个前挡风玻璃是有可能是完全的 AR 显示。AI 在音频领域可以审核内容也可以做千人千面的智能推荐。每天输入一些性格、音色、知识面等等这些参数数据，那它可能就会去学习相关的这个领域，同时去做相关领域的节目。然后我们输进去的一个基础音色，可能就是你的音色，再有一些微调的变化，这样一个很有特色的主播就出来了。 这完全是有可能的。

颖奇：是否可以推荐些您最近在看的觉得不错的书给大家？

丁宁：《 How Google Works 》（《重新定义公司》）挺好的，这是一本管理书籍。除此以外最近德鲁克的书我也看的特别多。从技术视角跳出来之后，我发现纯管理重塑了我。它一直在向我提问，我到底在做的是什么？我的客户到底是谁？他们的需求到底是什么？就这三个问题一直在问自己，让我对我们现在做这个事情有更深刻的了解。

颖奇：最后三个问题特别值得我学习和思考，我也再复述一遍。1.我在做的是什么？ 2.我的客户是谁？ 3.客户的需求是什么？非常感谢您的分享。

本文作者：王颖奇 联系方式： [email protected]