確立了要做的產品、使用的架構后，我和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的景點數據。