本帖最后由 透明的星尘 于 2025-6-27 15:51 编辑
寻花令：https://xiaoce.fun/xunhualing
无意间被朋友推荐了一个摸鱼神器，是一款模仿wordle做的猜诗句的游戏。大致玩法是每天更新一个目标诗句，玩家填入有效的诗句去猜，如果文字正确位置不正确会显示黄色，如果文字正确位置也正确会显示绿色。由于答案是每天0点刷新，所以猜到了就可以立刻停止摸鱼，自带防沉迷机制，属于轻度持续健康的摸鱼方案。（反例是组长买了chatgpt的会员，导致停不下来。）
在不断地感慨“越长大越文盲”的同时，作为程序员的我不禁在想，是不是可以做一个搜索引擎，根据已经猜到的字来搜索可能的诗句。说干就干，我从github上下了一个古诗词库，用python提取了里头的诗句，做成了json版的lib1.0。然后简单写了一个检索算法，套上一个UI，就做成了一个在线版的搜索工具（外挂）：http://spectrestar.top:9999/
看似很美好，用起来却很别扭。问题就出在有效诗句上，我找的这个库太巨大了，远超于寻花令自己的有效诗句库。这样就导致虽然有挂，却只能简单参考，如果能从一堆奇怪的诗句里看到一句自己认识的，那就基本是答案了。
就这样过了许久，有一天偶然发现在打开的http请求中，有一个checkvalid的请求，直接引起了我的警觉。我尝试了一下，把这一串请求“word=”后的内容改成我想验证是否有效的诗句，在返回的json中，就有一个“data”字段告诉我true or false。既然如此，是不是可以把数据库里的所有诗句验证一遍？这样就可以只保留有效诗句了。
说干就干，记得那天正好是一个周五，最简单的实现很容易，但这是我第一次真正面对算法效率的问题，毕竟有600多万句。最初使用grequest模块总是报错，最后问了ai，采用aiohttp写了一个代码，各种化整为零防止一次发送太多请求报错，看起来跑的还不错。临下班前我把程序挂在了我的树莓派上，心满意足地享受周末去了。
不出意外还是出意外了，回来之后一查看日志，全是403（拒绝访问）。打开寻花令网站，发现也全是403。突然意识到玩脱了，这是寻花令的服务器把我的ip封了。虽然转换ip的方法有很多，但终究是不能用这个方法去撞数据库了。
虽然失落，我还是对这个问题进行了一些尝试，我发现0.1s以内连续发送2个请求，第二个请求会返回“不要连续发送请求”，所以就算不封号，真正有效的验证也只能0.1s进行一次，算了一下全过一遍也要接近一个月。当然，暂时没考虑多台设备每台负责一部分，或者伪装ip去干这个事，过于丧心病狂了。最终形成了一个妥协方案，从每次搜索到的结果中取前100个进行有效验证，只显示有效的结果，然后记录下判断结果，下一次搜索会检索更多没有判断的内容。虽然退而求其次，但也舒服多了，只要猜到一个字，就可以从有效结果中选取这个字在不同位置的诗句，去定位这个字的位置，总之只要猜到一个字，基本就能猜出来了。
后来又搜到一个诗词库，决定试一试sqlite3对数据进行储存和检索，称为lib2.0，似乎比lib1.0小一点，但是不是子集。使用sql也引来了不少麻烦，明明电脑上一瞬间的事，放服务器上需要检索3min，后来对数据添加了索引进行搜索，然后用事务功能去修改，大大减少了这两步的时间。
本来以为这事就这么完了，一次偶然的机会，我点开了控制台，发现里头有一个“getTemp？”的请求，我看了一眼响应，竟然是今天的答案！原来兜兜转转了这么半天，谜底就在谜面上，答案就在试卷里？问题是这变量名也太草率了吧，咋就Temp了？也难怪我一直没找到判断诗句对错的请求，以及判断文字对错和位置对错的返回结果，原来是打开网页的时候就把答案发过来了，剩下的内容全交给前端去渲染了。我后来还发现，修改“date=”后边的日期，还可以查看昨天和明天的答案，试了试发现服务器里大概预存了3个月的题。至此，这个问题彻底解决。
可是，谁还记得，最初只是为了摸个鱼呢？
| 
发新帖
