确立了要做的产品、使用的架构后，我和Alex草草敲定了产品的功能和UI（用户界面）。我们缺乏互联网产品经验的问题在这一刻开始显现，从此我们做了很多不那么正确的决策，走了不少弯路。我们之前的行业追求的是性能、可扩展性和高可用性，UI很次要[\[12\]](#anchor212)。所以我们几乎都没有美感，也不知道怎样更能打动消费者这个群体。有一次我在国家图书馆结识了新浪的Liujia，她对途我睿很感兴趣，在产品上提出了不少自己的见解，可惜那时我对产品设计师这样一个职位没太多认同，觉得自己兼任足矣，于是错过了产品上的一次提升。 要构建旅行计划，首要的是构建结构化的景点数据库。景点库可以用用户产生内容（User Generated Content，UGC）的方式生成，但是你需要有基线数据让你的用户用得起来这个服务。所以途我睿一开始就面临两重冷启动的问题：数据的冷启动和用户的冷启动。用户冷启动可以先放在一边不管，可数据冷启动迫在眉睫——它是一切的基石。 我想到的方式就是爬数据。当时国内旅游类产品没有太好的提供结构化信息的网站，尤其没有介绍国外景点的。因此我把目光转向了TripAdvisor（猫途鹰）。我们当时盘算“爬”下TripAdvisor的景点的数据，然后将名称和描述翻译过来，就变成我们的数据。这么做有些游走于灰色地带，但我们对数据做了深度二次加工，几乎没有原始的痕迹。所以虽然这不太光彩，我们当时别无选择。 TripAdvisor的页面DOM结构不是特别好，用Scrapy爬有点儿费劲[\[13\]](#anchor213)，正当我研究怎样更有效率时，Alex发现了Gogobot，它的结构很漂亮，数据基本来自TripAdvisor[\[14\]](#anchor214)，所以我就开始抓Gogobot欧洲的数据。 一个晚上就有几万条景点被“爬”下来。我又做了一个内部系统toureet.me用于在线翻译。Alex在网上找翻译人员，约定每个景点的翻译价格，然后可以用这个系统给第三者开账户，供他们翻译及结算。就这样，他负责景点信息的整理，而我则负责产品的开发。我在AWS注册了3个账号，用3台免费的最小计算单元（tiny instance）来运行还在襁褓中的途我睿。每天我都会把最新的版本上线。 回过头来看，双重冷启动对像我们这样一个创业公司来说是很要命的，我们提供了一个工具来创建旅行计划，但这个工具需要有大量的POI才能让用户无障碍使用；然而大量的POI完全靠我们本身产生并不现实，所以我们期望以后有海量用户的时候，用户能自然帮我们完成这件事。其他依赖用户产生内容的网站，如论坛、帖子（主帖和回帖）就是用户唯一要创建的内容，内容和内容间没有依赖性。但在途我睿，用户要创建的旅行计划，严重依赖POI，如果没有用户要使用的POI，它需要自己创建。两种有依赖性的内容大大增加了用户创建的成本，为了降低这种成本，我们被迫维持一个“庞大”的编辑团队来为用户创建POI。这让我们的人员结构从一开始就往臃肿的方向发展。当然，如果说我们能跨过这个坎，让用户增长的红利启动网络效应，那我们的城堡外将建起一道宽阔的护城河。 我们后来得出的教训是：小团队一开始要避免做太复杂的、用户使用成本高的产品——尤其是要避免在数据和内容方面双重冷启动。 * * * * * [\[12\] ](#ac212)当你花钱去雇个工程师专门来配置某个设备的时候，UI的一致性比它的美感要重要得多。 [\[13\] ](#ac213)DOM是文档对象模型，是网页在浏览器的内部结构。爬取一个网页意味着将关键信息抓取下来结构化，使用的方法是正则表达式匹配或者XPath。Scrapy是Python的一个异步抓取框架，可以使用XPath匹配DOM中的元素并放在对应的数据结构中。 [\[14\]](#ac214) gogobot.com是一家比我们早一些的创业公司，Google的Eric Schmidt也对其投资过。几度改版，现在似乎发展得很一般。不知道是否与TripAdvisor有协议，它获取了几乎所有TripAdvisor的景点数据。