1、
经常有人问我，蝉游记跟同类型的XX，XX有什么区别吗？
最早的时候我回答说，我们是横着看，他们是竖着看。
后来，我们的App也竖着看了……这时就很难用一句话去回答。
从数据层面上来讲，同类产品的数据结构是日期>相片，地点作为相片的注释。蝉游记的数据结构是日期>地点>相片，相片作为地点的注释。这涉及到一些底层的设计理念，具体解释起来太复杂了。换个面向用户的角度，蝉游记是旅行的“创作工具”，同类产品则是旅行的“记录工具”。
因为核心的数据粒度是地点而非相片，在蝉游记中，内容并不按时间轴来排序。你可以随意移动相片，移动文本，移动地点，随意将相片和文本归入不同的地点，随意创造个性化的地点作为“特别章节”——比如“以弗所古城的萌物们”。这像是将传统的游记打成碎片，再随心所欲地归纳章节，重组顺序，按照自己的创作意图来写一篇游记。
这样搞，上手难度略高，操作略复杂，灵活度更大，展现效果略好。而同类产品更像是将一系列关于旅行的微博按时间轴串起来。很难说谁好谁坏，只是两种设计思路而已。一方面，蝉游记的创立初衷是收集结构化数据，以地点为核心粒度，收集数据的效果更好得多。另一方面，强调“创作意图”来自于我写游记的习惯——有可能创始人自己写游记的习惯，影响了不同产品的设计方向。
2、
说说我自己写游记的方式。
我通常在旅行中建立游记框架，旅行结束后，抽一两个周末来填充文字。
在旅行中，我只为游记做一件事情，就是“打点”。添加相片，关联地点，把旅行的脉络记录下来。如果数据库里找不到地点，或者想添加个性化的章节，就自建一个地点，再调取相片经纬度来给地点定位。稍微空闲一点的时候筛筛图，给图片和地点排序，每天只花十几分钟，游记的框架就搭好了。
我旅行时光顾着玩，常常早上八九点出门，晚上十点回旅店，压根没时间在路上写字。回家以后，把游记同步成云端的草稿游记，然后像做填空题一样，给地点和图片挨个配好字，游记就写完了。
无论蝉游记还是同类产品，都大大减轻了“写游记”的压力，把开放式的创作场景改造为流程化的“+图+地点+字”。写游记最难的就是思路与节奏，流程化之后，思路由交互流程来引导，节奏由图片多少来控制，最难的部分就解决了。
即便如此，制作稍微像样的游记，还是一件相当吃力的事情，“写很多字”是免不了的成本。如果说以前的难度指数是100，现在只不过降低到了70而已，一点也不大众化。驱动你写游记的，是特别强烈的记录旅行的冲动，也只有在这样的冲动下，才能写出一篇有可读性的游记来。
老友曾经劝我说，你们这些游记产品还是太复杂了，为什么不继续降低写游记的门槛呢？答：那样就变成相册了呀。做一个旅行专用的相册，我觉得是没有生存空间的。传统游记的价值在于它的可读性、帮助性，而我更看重从中获取的结构化数据。
3、
创业伊始，我有一个观点，“游记”只是一个功能组件，并不能支撑一款产品独立生存。如果只做游记，又没有免费优质的流量导入，产品必挂。
两年半以后，我仍然这么看。
和传统游记相比，我们这些基于移动端制作的游记，重图片，轻文字，重感受，轻攻略。通过蝉游记能很轻松地了解一个目的地，但谈到获取实用信息，还是网页端富文本编辑的传统游记远远胜出。这使得单独的游记产品存在两个致命伤：首先推广成本高，写游记是小众化概念，看游记又敌不过传统品牌。其次缺乏稳定的唤醒场景——新用户的新鲜感过去以后，在什么场景下想到再次打开应用？留存率逐月递减是不可避免的，只能靠新增用户来止血。
所以独立的游记应用，如果不烧钱推广，别说做大，生存都成问题。就算撇开推广主题窄成本高的硬伤，数据做上去之后，如何获取与烧钱对等的商业回报？
游记作为过渡性的入口，藉此开局之后，必须过渡到下一个更大的市场，更稳定的用户场景，才能存活下来。
