对话 Eolink 创始人刘昊臻：超越 API

小红花技术领袖俱乐部对话 Eolink CEO 刘昊臻：

▲ 揭秘：从 Eolinker 到 Eolink 的原因！

▲ 突围：如何在国外、国内竞争对手的重围之下稳固自己的阵地，并保持竞争优势？

▲ 产品：为什么 Eolink 独有产品矩阵？技术人做产品的独特视角是动力还是阻力？

▲ 思考：技术、产品带领一家企业，其中有什么独特的人生经验值得大家品味？

🌸 小红花：作为一位连续创业者，其中软件开发经历甚至可以追溯到初中时代，可以给我们讲一讲在 Eolink 以前的学习、工作和创业历程吗？

其实初中接触编程并不是什么很新鲜的事情，很多小学生其实都已经在做程序了，我身边认识的很多创业者或者是技术大牛，基本上也是从初中甚至更早就已经在做网站或者是软件的开发。

我最开始的时候其实是对平面设计感兴趣，当时觉得编程全是英语，而我自己的英语水平比较烂，所以就一直没有下决心去学。

后来我拥有了第一台手机，也是第一台 Android 机,， HTC dream one（ g1 ） 。当时觉得智能手机真的很有意思，只不过界面比较丑，所以就加入了线上的一些开发小组，一起去做国内最早一批的优化系统。

一开始我负责的是界面的重新设计，但后面发现有很多的效果，光是设计出来还不够过瘾，还是需要去学习编程，自己动手做起来会更加有成就感，因此才逐渐的转向开发，并且发现里面的英语其实挺简单的哈哈。

当时我们做的优化系统下载量有近百万次，在当时国内是非常大的下载量了，也是因为这段经历，让我觉得和一群有趣的人去做一件有意义的事情，是非常有成就感的，所以就下定决心以后一定要创业。

高中期间也是一边上学一边兼职工作，不断的锻炼自己各方面的能力，也认识到了自己真正想要的是一个什么样的氛围，想做什么样的事情。

高考完之后，我去毕业旅行的路上便开始着手准备组建自己的团队，大学开学之后就正式做各种项目以及创业的尝试。

在创办 Eolink 之前，我自己参与了几个创业项目，有技术外包、在线医疗、 o2o 电商，但是觉得不太符合自己的期望。

刚好15年底觉得自己团队内部的 API 管理是个麻烦事，而市面上的产品做得不太满足需求，所以才决定做个产品来解决 API 协作问题。后面逐步开源出来，得到许多用户的认可，再逐步成立公司做 saas 产品。

直到现在，我们应该算是国内做 API 研发管理领域坚持得最久的团队了。

🌸 小红花： Eolinker 是以前的品牌名，后来为什么改成了短名 Eolink 呢？

Eolinker 是个缩写，全称是 easy & open linker ，一个简单、开放的连接器，其实就是代指的 API 。

我一直觉得这个名字很有意思，它并没有直接说我们做的是某某 API 产品，但是又解释了 API 到底是做什么的，其实就是做一个连接器。

我们希望把全世界的企业数据和服务都能通过更加简单和开放的方式连接起来，这是我们公司的使命，从创立到现在一直没变过。

因此我们也没有限制一定要做跟 API 相关的事情，API 只是实现互联目标的多种手段之一，如果有其他的方式能够实现这个使命，那我们也会去尝试。

去年我们把品牌名称做了个简化，因为我们发现大部分的人在读或者是搜索的时候，往往会把 er 给去掉，而且 link 相比于 linker 而言，代指的范围更广了，我们是在做连接的事情，而不是做连接器这个产品。

想到这点就会让我觉得很兴奋，因为我们在做的是更大的事情、面向更大的市场、服务更多的人群，因此才下定决心要把 er 去掉。

既然要做，就做一件能让自己难忘且兴奋的事情，我觉得新的品牌名称 Eolink 能够赋予团队这样的使命感。

🌸 小红花： API 网关、文档、测试软件都不是很“新”的产品领域，而且国外也有 PostMan 等产品，甚至有一些开源项目提供大差不差的功能，你为什么会选择这样一个产品方向呢？

的确如你所说， API 并不是一个新问题， API 这个概念存在的时间比我的年龄都大。

市面上也有许多做得不错的产品，比如说在 API 文档管理领域有 swagger ，在基础测试领域有 postman ，在自动化测试、性能测试，安全测试等领域也有 jmeter、soapui、loadrunner 等。

但我们也发现，API 领域其实是高度分散的，像我刚列举的一些产品，其实就是为了解决不同的 API 问题。

但如果我们希望把 API 的整个流程都给管理起来，从研发、测试、运维、安全，甚至到交易都给串联起来，会发现市面上极少有产品能够满足这个需求，这也是我们在 2015 年遇到的问题。

随着项目规模的不断扩大，微服架构越拆越细以及团队规模的增长，整个 IT 团队围绕着 API 的协作会越来越强，这时候我们发现很难通过现有的单点产品去解决一个系统性问题。

因此我们才决定要把这些单点的场景串联起来，不再从一个一个小点去思考，而是站在一个更加宏观的角度去思考“一个围绕着 API 的团队或者公司会是怎么样的工作方式？”，并且基于这个出发点去设计 Eolink 的产品体系。

所以从我的角度来看，Eolink 的定位并不是另一个 Swagger 或 Postman 之类的产品，而是一个围绕 API 的团队协作平台，解决的是系统性的 API 治理问题，而不是单纯解决如何管理 API 文档以及做测试的问题。

因此也可以看到，我们的付费客户往往是一些成熟企业，偏向科技、金融、汽车等领域，体量也会比较大。

我们把产品在这些深度客户中充分打磨之后，再提供给更多更小一些的企业或团队，把行业的最佳实践给做出来。

🌸 小红花：在 Eolink 产品的开发、迭代过程中，你们做了哪些让 Eolink 与“众多竞争对手”不同的功能？这些功能的开发过程又是怎么样的？

因为 Eolink 不只一个产品，所以我比较难通过具体功能来做对比，不过从目前国内友商的功能来看，基本上是我们在 17 年的功能强度。

API 行业是一个“门槛在门里面”的行业，不进去之前是不知道的。外人看 API 的东西都很简单，但实际进去之后会发现可以做得非常的深。

我们算是在业内做了非常多有益的尝试，有许多第一，比如：

第一个，把 API 全流程串联起来的产品矩阵;

第一个，通过图形化界面来做 API 自动化测试的产品，让新手也能够快速做自动化测试;

第一个，把 API 文档和测试用例关联起来，让测试用例可以自动更新，减少大量的维护成本;

第一个，做 API 的版本管理与变更通知，让你可以很清晰的知道 API 在什么时候改变了什么内容;

第一个，在自动化测试中结合了 AI 能力的产品;

等等等等。

总的来说，我们会更喜欢做有创新的事情，喜欢做出差异化。

目前，一些国内的友商把精力都花在了打广告或者是中伤对手上，我觉得这对整个行业是不利的。应该花更多的时间去提供独特产品价值，服务好国内甚至全球客户。

🌸 小红花： Eolink 有 API 生成、研发管理、自动化测试、监控，甚至还有开放平台，是众多 API 工具同行中唯一做了“产品矩阵”的厂商，为什么要这样做？这个打法是否为 Eolink 带来了竞争优势？

我的思路不太一样，这并不是打法决定的，并非是同行没有做，我们就要做一大堆产品。

而是我们发现用户问题必须要通过一个产品矩阵去来解决。在这个矩阵中，用户的研发，测试，运维和业务团队都能有自己对应的产品，并且能够串联起来，这是我们对未来趋势的判断决定的。

目前各家产品服务的客户群体不太一样，因此不太好去做对比、讲优势。但如果用户在现有的 swagger、postman、jmeter 等成熟产品中找不到解决办法，那往往会找到我们。我觉得这是独特产品定位的好处。

🌸 小红花： Eolink 的 API 平台思想，可以说是“超越 API ”，这个产品战略是谁提出来的，是灵光一闪还是深思熟虑？

在创业之前，我们是做过一段时间的市场调研和用户分析，API 全生命周期或者说 API 平台这想法也是在我们经过一段时间的调研和思考之后得出的结论。

我认为它会代表着 API 行业在未来十年内的一个大致发展方向：企业对于 API 的需求会越来越深，并且 API 所关联的团队规模和影响的业务范围也会越来越广。

我在 16 年做这个判断的时候，还只是一个推测。但经过 5 年，从我们接触到的客户以及看到的行业变化情况，我目前是越来越有信心的。

🌸 小红花：Eolink 多次赢得顶级风投青睐，你认为那些资本大佬最为欣赏的特性是什么？

我觉得首先是选择一个在高速发展的市场，其次是团队的韧性，然后是产品再变得越来越好，在不断地解决用户的问题。

🌸 小红花：在过往的工作、创业中，你也做过技术合伙人等技术管理岗，在不同岗位上的心态和感受是否不同？你觉得技术人做产品的独特视角是动力还是阻力？请分享一下几次创业过程的心路历程。

因为我们做的是技术行业，面对的是开发者群体，所以技术背景是很必要的。

不过技术背景往往只是一个门槛，我觉得更重要的是产品视角和商业化思维，毕竟用户想要解决的问题和好的交付产品之间可能差了十万八千里。

而好的产品和能够带来持续收益的商业产品又差了十万八千里，所以说创业是一个高风险的事情。就算是在硅谷能够验证有商业潜力的初创公司也不超过 10% 而已。

创业往往要求早期团队里的每个人都是十项全能，同时每个人还必须有自己能提供的独特价值，而我们常说的勤奋往往只是独特价值里的标配。

经历了几次创业，我现在会把它当做是一个高度复杂的游戏，我们操作发挥得最好的时候，往往不是你拼了命想赢的时候，而是团队协作去打怪升级，并且收获快乐的时候，这时你的节奏、操作都会更好、更长久。