有烦恼的地方，就有需求，所以我之前写了一篇《我用Twitter的烦恼与解决方案》。但是，主要是烦恼的描述，对于解决方案，我并没有想得很清楚，之后就开始干起来了，经过这么几天的密集思考，我想清楚了一些部分，先记录下来。

1、当Twitter的follow低于50的时候，特别是follow的人属于普通发言频率的时候，还不是问题。但是，一旦人数上升，有follow到了一些话特别多的朋友时，信息过载的烦恼就凸显出来了。Google Reader，作为一个优秀的Blog Reader，很好的解决了Blog信息过载的问题。而TwitterFollowAgent，就是希望能够在Twitter领域，做到类似Google Reader的效果。

2、Tweet的内容虽然只有140字，但是，由于非常随意，因此垃圾信息和反复的RT，也是一种干扰，这方面的烦恼不是Google Reader需要面对的，因此，类似GMail的垃圾邮件自动化清扫工作，就会变得非常有价值。他的规则是隐藏在背后的，透露出来的操作界面，非常简单，对于某封邮件，点击一下“这是垃圾”即可。我想TwitterFollowAgent，也要做到这个效果。当然，背后的智能要求非常高，一开始肯定做不到满意的效果的，不过，这也是技术壁垒所在了！

3、在形成固定的朋友圈子之后，借助Twitter的零散讨论会不时出现，一种合适的规整机制，有助于将零散的讨论，集中显示。但是，这里存在一个问题：有些参与讨论的人，并非我follow的对象，作为BBS形式出现的讨论，自然不会遗漏，但是在Twitter中，却难免遗漏，这就可能存在一个“深度挖掘”的需求，但是这样的挖掘，计算量也是非常大的。

4、我找到了一个PHP的汉字分词类库，但是，他是将所有的词都切分出来了，其实在我的需求中，大多数词是不必保留了，因此我打算保留一个根据用户提交的词，组成的词库，并定期根据该词出现的频率，淘汰“冷门”词汇，以此减少计算量。

5、Tweet的归类，其实还是基于切分出来的词的，其中处于最高频率的N（N<5）个词，就是该Tweet的Tag。初步的判断垃圾规则，也是基于这个Tag的。

6、一个Tweet的特性，主要有以下方面：UserID、ReplyID、@UserID、#Tag以及普通Tag。归整、分类等等操作的算法，就是围绕这些属性展开的。具体的做法，还没想清楚。

7、接下来的开发工作，准备在服务器端装一个UserStory的管理系统，然后将各种特性，先通过UserStory的形式，明确下来，也方便开发的管理，和及时公开与大家交流。

8、基本的系统架构是Ext—PHP—Ruby，ExtJS做前端界面，PHP做后端服务，Ruby写Cron脚本来抓数据。

目前就是这些。