易栈网-膘叔

 之前写过一篇Mac蓝牙鼠标卡顿、飘的临时解决方案，但当时这种方法其实现在感觉一般其实还有一个简单粗暴的办法，打开活动监视器，搜索bluetoothd（其实只要搜索blu三个字母就出来了）。然后直接杀掉这个进程。

因为这个是系统服务，你杀完后他会自动重启，这时候晃晃鼠标什么的，就又会自动连上了。

卡顿的问题基本上确实就是：2.4G的wifi冲突，当然还有可能是某些中断导致。但一般重启一下bluetoothd服务就能解决90%以上的问题。

再不济，重启吧

mac突然间就没有声音了。。。按照以往的办法，拿出耳机，插拔一下。。。结果 还是没有

不知道从什么时候开始，「阅读」之类的小说工具能找到的更新越来越难了。

尤其是一些不那么热门的小说，基本上过了公众版之后，后面的章节就很难再找到。

后来才知道，现在不少小说的更新已经转移到了 Telegram 上的一些频道里。

看来「阅读」这类工具这些年对小说网站的吸血，多少也让一些站点开始受不了了。

不过这又带来了另外一个问题。

Telegram 上分享的小说很多都是纯 TXT 文件。

TXT 本身倒没什么问题，是个阅读软件都能打开。但它有一个不算大问题的问题：内容跟章节名称是混在一起的，而不同的阅读软件处理的方式都有一些差异，尽管有些允许你自定义一些识别规则，但是依然很麻烦，对于非技术人员来说更是天书。

就算你解决了识别问题，很多小说本身的目录就不规范。

有些小说是：

第1章
第2章
第3章

这种算好的了。

更多的时候它可能是：

第一章

第001章

第1章 我回来了

第1卷 第一章

正文 第一章

Chapter 1

甚至还有些文件前面几十章一种格式，写到中间作者或者整理者突然又换了一种格式。

再加上网上流传的 TXT 文件经常经历过很多次转载、合并和重新整理，里面还可能夹杂：

广告网址、下载站水印、重复章节、缺失章节、章节倒序、乱码，以及莫名其妙插进去的说明文字。

这种文件直接丢进阅读软件以后，经常会出现一个很尴尬的情况：

正文能看，但目录不能用。

几百上千章的小说如果没有一个正常目录，体验还是挺糟糕的。

手工整理当然可以，但太累了

最简单的方法当然是打开 VS Code、Notepad++ 之类的编辑器，自己用正则表达式处理一下。

如果只是几十章倒还好。

但一部长篇网络小说动不动就是几百上千张。

更麻烦的是，很多 TXT 并不是简单地把：

第一章

替换成：

第1章

这么简单。

真正需要解决的是：

哪些行是章节标题？

哪些只是正文里碰巧出现了类似的文字？

章节编号是不是连续的？

有没有漏掉一章？

有没有重复？

有没有本来是第 135 章，结果文件里写成了第 153 章？

如果碰到卷、章混排这种更是头大，只能将就着看。

正则能解决一部分，但用起来还是比较折腾。

于是群里的资深书友巨大出手了！

作为之前大站站长兼程序猿，巨大受够了这些问题，他做了个叫 NovelLint 的在线工具。

NovelLint 可以直接导入 TXT 或 EPUB，然后扫描整本小说，自动识别里面可能的章节标题。

地址：https://novellint.com

和普通的“搜索一下 第.*章”不太一样，它会把识别出来的章节单独列出来，然后分析章节编号。

例如一本小说应该是：

第128章
第129章
第130章
第131章

结果文件里面变成：

第128章
第129章
第131章

它会提示你：

第130章可能缺失了。

并且提供一些修复手段，比如附近潜在的章节名称，或者没找到潜在章节时允许你通过配置的AI帮你在附近的内容中找一下。

重复章节、编号倒序之类的问题也比较容易找出来。

对于网上弄到的 TXT 小说，这个功能还是挺实用的。

还有一个很有意思的小功能，它允许你一键将章节命名方式对齐，什么意思呢？

比如小说的章节列表是：

（01）xx

（02）yy

或者：

第一章：xxx

第2章：yyy

这样的格式，但你更喜欢 「第01章：xx」 这样格式，工具可以一键将它们转换成：

第01章：xxx

第02章：yyy

工具本身提供了一个可以转换的列表，基本涵盖了大部分章节命名习惯，算是强迫症的一点小福利。

工具很易用，基本传一本书跑一次就明白了，另外巨大也提供了详细的图文帮助文档。

我比较喜欢的一点：文件不用上传服务器

这类工具我比较在意一个问题：

小说文件会不会被上传到别人服务器？

NovelLint 目前的处理方式是直接在浏览器本地完成。

也就是说把 TXT 拖进去之后，分析和处理主要在当前浏览器里进行，不需要先把整本小说上传到服务器再处理。

这样至少在处理私人整理的文本时比较省心。

而且打开网页就能用，也不用为了偶尔整理一两本小说专门安装一个软件。

还能顺手生成 EPUB

TXT 整理完以后，还有一个挺实际的需求：转成 EPUB。

现在很多阅读软件虽然支持 TXT，但 EPUB 在目录、章节跳转这些方面还是舒服很多。

如果原始 TXT 本身没有标准目录，就算直接找个 TXT 转 EPUB 工具转换，最后生成出来的 EPUB 目录通常也不会特别理想。

NovelLint 的思路是先：

识别章节
→ 检查章节结构
→ 清理标题
→ 再输出

这样最后得到的 EPUB 目录会规整很多。

对喜欢把小说丢进 Apple Books、Kindle 或其他本地阅读器的人来说，这一步还挺方便。

它比较适合什么情况？

如果只是一本格式特别标准的 TXT：

第一章
第二章
第三章

其实完全没必要用什么特殊工具，阅读软件自己一般就能正确识别。

NovelLint 更适合的是那些已经被“折腾过很多遍”的小说文件。

比如：

网上下载的 TXT；

Telegram 频道里拿到的小说合集；

多个 TXT 手工合并出来的长篇小说；

章节标题格式不统一的文件；

怀疑存在缺章、重复章的小说；

想整理完以后再转换成 EPUB 的文件。

这种情况下，先扫一遍目录还是挺有用的。

最后

网络小说发展这么多年以后，一个挺有意思的现象就是：

小说本身越来越容易保存，但整理小说反而成了一件麻烦事。

以前可能是在网站上直接一章一章看。

后来是阅读工具自动抓。

再后来又变成 TXT、EPUB、网盘、Telegram 到处流转。

文件倒是拿到了，但各种转载、合并和格式转换之后，章节目录往往已经惨不忍睹。

如果只是偶尔遇到一本，手动改改也无所谓。

但如果经常下载 TXT 小说，可以试一下 NovelLint：https://novellint.com

至少比拿着几百章的 TXT 自己一行一行找章节轻松得多。

有没发现，Cursor在使用超过1个月后，会开始逐渐变得卡一点，用2个月会更卡。如果你频繁使用，那么你就会发现，你的输入框打一字，就要卡住半天，而且CPU占用也非常高，经常2~300%

这是为什么呢？其实除了网络等原因外，还有一个巨大的原因，就是cursor的聊天数据库太大了，我看了一下，我本地有4G，ls -lah ~/Library/Application\ Support/Cursor/User/globalStorage，看看这个：-rw-r--r--  1 admin staff 4.0G Aug 11 22:46 state.vscdb，
想想看，你每次切一下session，他就要从这4g的sqlite里查找一波对话。如果你还要往上翻页看历史对话，你自己想想，性能能高到哪里去？？

所幸，官方本身就有解决方案，在agent界面，你cmd(ctrl)+shift+p，输入developer，会出来一个delete old chats。然后你自己选择删除几天前的对话。我删除了10天前的，我觉得10天前的对话，应该意义不大了（但其实不能完全这么想，比如有些项目，你暂时没动它，但他可能是一个月前的，你要删除了，那所有的历史对话就全没了），删除前，你可以自己做一个导出，要么让cursor整理成文档，要么你copy一下数据库做备份。

我4G速度还行，得益于我机器内存大。。。但，这个方案是没错的，你们可以自己试试，立刻就会感觉象飞起来了

有一说一，真的已经好久没有古法编程了，倒不是不会写，而是普通用户使用古法编程中最常遇到的，或者说80%以上的工作，都是在重复的，比如做后台的时候，大量的列表、筛选、关联，再接下来就是UI的交互、细节。写着写着，人心就疲了