上周在《写了个刷论文的辅助网站：Cool Papers》中，笔者分享了一个自己开发的刷论文网站Cool Papers，并得到了一些用户的认可。然而，“使用的人越多，暴露的问题就越多”，当用户量上来后，才感觉到之前写的代码是多么不严谨，于是过去一整周都在不停地修Bug之中，直到今天下午还发现了一个Bug在修。这篇文章简单总结一下笔者在开发和修Bug过程中的感想。

Cool Papers：https://papers.cool

技术 #

事实上，“papers.cool”这个域名已经注册了四年多，从这可以看出笔者其实很早以前就计划着做类似Cool Papers的网站，也做过一些雏形，但之所以这个网站在四年后才正式诞生，根本原因就只有一个：技术不行。

一方面，是建站的技术不行，因为笔者并不会写网站，充其量也只能对个别地方简单修修补补。虽然“科学空间”这个博客已经运行了十年多，但那是基于现有的博客系统，像安装软件那样安装的，并且网站模板也是基于别人的开源主题来瞎改的。而一个完整网站的开发涉及到方方面面的技术，笔者作为外行人实在搞不过来。另一方面，是模型的技术还不行，没有足够智能的模型辅助刷Paper，就算东拼西凑把网站搭起来了，那么网站的亮点在哪？如何才能让刷Paper真的Cool起来？

幸运的是，大模型的出现，一定程度上让这两个问题迎刃而解。建站方面，有啥不会可以直接问GPT4、Kimi，只要有耐心、有想法，并且有一定的编程/网页基础，都可以把网站开发出来，不得不说大模型对于编程方面真的是非常强大的生产力，Cool Papers几乎所有的源码，都是在GPT4和Kimi的帮助下写出的；模型方面，Kimi最大支持128k长度，足够直接塞一篇论文进去做准确的FAQ，无疑这是快速了解一篇论文的极Cool的方法，因此亮点也有了。所以，在大模型的背景下，Cool Papers看起来是“呼之欲出”了。

艺术 #

然而，事情还没有那么简单。大模型解决了“技术”问题，但还没能解决“艺术”问题。举例来说，在大模型的辅助下，对着一个现成的网站，笔者或许能将其抄个七七八八，但要自己从零写一个的话，那就完全崩溃了，这是个“艺术”或者说“美术”的问题，建站中称之为“前端”。不少读者可能都觉得Cool Papers有点丑，但是很抱歉真的尽力了哈，就目前这效果，已经是在GPT4写好的模版之下反复调优的了。大模型能拯救笔者的技术不足，但拯救不了笔者那一片空白的艺术细胞。

更要命的是，笔者经常会陷入细节方面的强迫症中，比如有时候半天都写不出一句代码，只因为没想好一个变量应该怎么命名，又比如因为一个半个像素的Margin和Padding调整了老半天，等等。对于非常看重工作量的网站开发来说，这种强迫症显然是非常不利的，对于更加关注整体审美而不是局部细节的前端开发来说，更加是雪上加霜。所以说，笔者天生就没法吃这碗饭。在整个开发过程中，只能不断跟自己强调“将就将就”，也只能委屈用户跟着笔者一起“将就将就”了。如果有前端大佬愿意帮忙美化，笔者将不胜感激。

后端 #

唠嗑完前端，再来说说后端。简单来说，“网站=前端+后端”，“前端=HTML+CSS+JS”，这些可以说是通用的网页编程，而后端则比较广泛，比如本博客后端用的是曾经被誉为“最好的语言”的PHP，而对于笔者来说，唯一熟悉的编程语言只有Python，所以自然选择Python开发。而Python开发网站又有很多框架，比如Django、Flask、Tornado等，而笔者用的是一个非常小众的选择——Bottle。

用Bottle的原因其实很简单，它是笔者早年接触的第一个Python网站开发框架，于是也就用下来了。其实用哪个都差不多，对于Cool Papers来说轻量级一些就好了，更重要的是整个网站背后的工作逻辑。

Cool Papers与一般网站最大的区别是，它本身没有内容（论文），它的内容都是来源于别的网站（目前是Arxiv），所以后端部分涉及到从其他网站下载内容的操作。一开始在内部使用的时候，由于使用人数比较少，所以这部分代码直接写在页面的路由上，即用户访问页面的时候实时下载。尽管Arxiv允许通过接口来获取论文数据，但是有频率限制的，而当用户量大了之后，访问间隔就可能非常短，所以极有可能出现非常高的下载频率，从而导致所有下载行为被Arxiv封禁。

所以，从稳定性出发，所有涉及网络通信的操作都应该要通过有稳定访问间隔的队列来完成。具体来说，需要队列的操作有三部分：1、从Arxiv获取当天的论文列表；2、从Arxiv下载论文PDF（给Kimi用）；3、与Kimi进行对话实现FAQ。这三部分队列如何设计才能稳定地运行、交互，且不会相互“拖后腿”，花费了笔者不少时间。特别地，很多错误只有访问量大了之后才能体现出来，所以这段时间修Bug可谓是“马不停蹄”。最后，就算考虑了很多，但任何网络操作都有失败的风险，所以队列中的进程还必须加入值守功能，中断后自动重建。

更新 #

上周发布后，Cool Papers很幸运得到了不少读者的认可，也提出了不少改进意见，其中部分也已经升级到最新版中：

1、开放所有类别：上周发布时只支持Arxiv上几个类别，然后陆续不少读者申请增加自己想看的类别，于是尝试开放了所有类别，并允许在首页选择显示自己需要的类别；

2、Feed订阅支持：不少读者有RSS订阅习惯，所以建议增加RSS链接，目前已经补充上去，但用的不是RSS格式而是更标准的Atom格式（几乎所有订阅器都同时支持两种格式）；

3、Markdown解析：Kimi生成的FAQ一定程度上是Markdown格式的，对它进行解析可以有更好阅读体验；

4、点击次数显示：[PDF]和[Kimi]后面多了一个数字，分别代表着两个按钮的点击次数，一定程度上代表了这篇论文的受欢迎程度

5、其他细节优化：如移动端效果优化，[Kimi]稳定性优化等。

此外，新建了一个Github项目，用来记录以后的更新日志，以及收集用户的意见：

还有一些有价值的意见还未在Cool Papers上实现，其中有一部分还在开发或者设计中，另一部分则可能不大符合Cool Papers定位。到目前为止，Cool Papers的定位是“刷（筛）”论文，不是“读”论文，它尽量考虑一些其他读论文网站没有的特性来快速“刷”论文。例如，“刷”的重点是“及时”、“全面”，一些可能会带来滞后、漏召可能性的改动可能不会被采纳。

最后，有读者希望能够访问历史论文，事实上，对于已经在数据库中的历史论文，可以通过https://papers.cool/arxiv/<paper_id>访问，对于不在数据库中的论文，其访问压力还在评估中（主要担心[Kimi]被爬虫滥用），后面可能会试探性地开放测试。

小结 #

总结就到这里了。说是总结，其实也就是一个网站开发新手的流水账罢了，难登大雅之堂，请高手们一笑了之。最后，祝大家元旦快乐，在新的一年里万事顺利，技术突飞猛涨，错漏销声匿迹！

转载到请包括本文地址：https://spaces.ac.cn/archives/9920

更详细的转载事宜请参考：《科学空间FAQ》

如果您还有什么疑惑或建议，欢迎在下方评论区继续讨论。

如果您觉得本文还不错，欢迎分享/打赏本文。打赏并非要从中获得收益，而是希望知道科学空间获得了多少读者的真心关注。当然，如果你无视它，也不会影响你的阅读。再次表示欢迎和感谢！

如果您需要引用本文，请参考：

苏剑林. (Jan. 01, 2024). 《新年快乐！记录一下 Cool Papers 的开发体验 》[Blog post]. Retrieved from https://spaces.ac.cn/archives/9920

@online{kexuefm-9920,
        title={新年快乐！记录一下 Cool Papers 的开发体验},
        author={苏剑林},
        year={2024},
        month={Jan},
        url={\url{https://spaces.ac.cn/archives/9920}},
}