如题。怀念一下。
新版本完全采用了vibe coding...
Misc
小说导入阅读工具后，章节目录识别不对怎么办？
不知道从什么时候开始，「阅读」之类的小说工具能找到的更新越来越难了。
尤其是一些不那么热门的小说，基本上过了公众版之后，后面的章节就很难再找到。
后来才知道，现在不少小说的更新已经转移到了 Telegram 上的一些频道里。
看来「阅读」这类工具这些年对小说网站的吸血，多少也让一些站点开始受不了了。
不过这又带来了另外一个问题。
Telegram 上分享的小说很多都是纯 TXT 文件。
TXT 本身倒没什么问题，是个阅读软件都能打开。但它有一个不算大问题的问题：内容跟章节名称是混在一起的，而不同的阅读软件处理的方式都有一些差异，尽管有些允许你自定义一些识别规则，但是依然很麻烦，对于非技术人员来说更是天书。
就算你解决了识别问题，很多小说本身的目录就不规范。
有些小说是：
第1章
第2章
第3章
这种算好的了。
更多的时候它可能是：
第一章
第001章
第1章 我回来了
第1卷 第一章
正文 第一章
Chapter 1
甚至还有些文件前面几十章一种格式，写到中间作者或者整理者突然又换了一种格式。
再加上网上流传的 TXT 文件经常经历过很多次转载、合并和重新整理，里面还可能夹杂：
广告网址、下载站水印、重复章节、缺失章节、章节倒序、乱码，以及莫名其妙插进去的说明文字。
这种文件直接丢进阅读软件以后，经常会出现一个很尴尬的情况：
正文能看，但目录不能用。
几百上千章的小说如果没有一个正常目录，体验还是挺糟糕的。
手工整理当然可以，但太累了
最简单的方法当然是打开 VS Code、Notepad++ 之类的编辑器，自己用正则表达式处理一下。
如果只是几十章倒还好。
但一部长篇网络小说动不动就是几百上千张。
更麻烦的是，很多 TXT 并不是简单地把：
第一章
替换成：
第1章
这么简单。
真正需要解决的是：
哪些行是章节标题？
哪些只是正文里碰巧出现了类似的文字？
章节编号是不是连续的？
有没有漏掉一章？
有没有重复？
有没有本来是第 135 章，结果文件里写成了第 153 章？
如果碰到卷、章混排这种更是头大，只能将就着看。
正则能解决一部分，但用起来还是比较折腾。
于是群里的资深书友巨大出手了！
作为之前大站站长兼程序猿，巨大受够了这些问题，他做了个叫 NovelLint 的在线工具。
NovelLint 可以直接导入 TXT 或 EPUB，然后扫描整本小说，自动识别里面可能的章节标题。
和普通的“搜索一下 第.*章”不太一样，它会把识别出来的章节单独列出来，然后分析章节编号。
例如一本小说应该是：
第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越用越卡怎么办？？
有没发现，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速度还行，得益于我机器内存大。。。但，这个方案是没错的，你们可以自己试试，立刻就会感觉象飞起来了
用Agent管理服务器
这里不就说具体品牌的Agent了，但也别乱猜。我用的国产的
其实这应该不是什么新鲜事了吧，我现在就经常在服务器上用cli，先分析服务器环境和安全，主要是可以让他写成安全脚本，这样以后任何一台机器都可以复用，也避免在每台机器上都安装 Agent 之类的
然后让他配置防火墙之类的，改改什么ssh账号和限制 密码登录等，也确实方便。
自从有了AI，外包业务也越来越少了，最近网上有个段子，我特别感到好笑，以下是大意内容：有公司接项目，报价了10万，但甲方说现在都有vibe coding了，他们花了半个月用vibe coding写了整个项目，现在有点BUG，问甲方是否同意5000 改一改BUG。 甲方感慨的发了这个贴，我看有评论说，本来是10万，现在要改这个项目，那就得50万了。
agent越来越多，但不要让自己变成agent的奴隶 就行了。。
虽然大家都说ClawCloud是aliyun青春版，但我总感觉他已经死了
如题。
为什么这么判定？是因为之前在 run.claw.cloud上提问没人回，开始我以为我不是会员，后面升了会员，提问也没有人回。创建个容器还3天2头崩。虽然我只是个尊贵的5刀会员，但也毕竟每个月都有5刀出去啊，结果 今年就突然说停止服务了。嗯，我也没收到邮件，不知道其他人是怎么收到消息的
为什么我现在又判断说他快死了呢？是我前几天发的工单，一周了，也没有任何人回复。去年活跃的时候，凌晨1点的工单，5点就有人回复了。要知道我们和新加坡是没有时差的。
见微知著吧。坐等他随时关闭，已经不敢随便续费了
简单的运维大概是真要失业了吧
如果一个运维，只是到服务器上配置配置工具，装装防火墙，优化一下系统之类的。估计比程序员还要先失业了。毕竟现在服务器装个codex或者kimi-cli等工具，妥妥的帮你配置好各种。为了安全你可以先不让他执行，或者你在另外的机器上问问题，只是在将服务器上的结果 反馈给Agent。
这种都不要太多量，kimi最便宜的/Qwen lite应该都可以。minimax大活做不了，这种小活还是问题不大的，毕竟大多数中小白，也都实时现 查的，那minimax可做的 就很多了。难道不是是吗？
自从各种agent/各种虾越来越多，天天都在叫，这个行业要消失了，那个行业要灭亡了，有没有灭亡不清楚，但每个月消耗的token倒是变多了，而且消耗的token变多了，原来的各种群，技术探讨群倒是越来越冷清了。怕是行业没消失，技术论坛、技术BBS以及 QQ聊天群之类，倒真是要消失了。。
试用了tabbit浏览器后有话说
看到mactalk推荐的tabbit浏览器（https://mp.weixin.qq.com/s/rYF_bx3FGCmHWs_V61NmxA），试用了一下，没有想像中的那么好
抛开下面codex的结论，我还是觉得arc目前更适合我。比如那12个pin的网页，那是真叫一个方便。所以在ARC目前功能不再更新的情况下，我arc和zen混用了。
（主要是dia不支持切换profile保留在同一窗口。。。。）
相比这个tabbit，不能使用自定义模型，也没有pin网页以及多profile（多profile其实很重要，因为他其实是session隔离，你可以开上多个 gmail，而且不会互相影响，一个针对国内，一个处理国外，还不用打开额外的窗口）。
不能自定义模型，其实就是我们所提的隐私了，在国内，宁可将隐私扔给阿里和腾讯，也不太愿意交给一些创业公司吧！
推荐结论
### ? 综合最佳：夸克（61/80）
- ✅ 适合：大众用户、阿里生态用户、移动端需求
- ⚠️ 注意：隐私问题、AI 能力相对较弱
### ? AI 能力最佳：Dia（60/80）
- ✅ 适合：学生、研究者、办公人员、隐私敏感用户
- ⚠️ 注意：平台有限、价格未知
### ? 模型最多：Tabbit（59/80）
- ✅ 适合：开发者、多模型对比需求、免费体验顶级模型
- ⚠️ 注意：代码争议、公测稳定性、隐私待明确
### ? 体验最佳：Arc（60/80
- ✅ 适合：重度自定义用户、Mac/iOS 生态、设计爱好者
- ⚠️ 注意：学习曲线、部分功能付费
最终建议
┌───────────────┬────────┬──────────────────────┐
│ 需求 │ 推荐 │ 理由 │
├───────────────┼────────┼──────────────────────┤
│ 免费体验 AI │ Tabbit │ 公测免费 + 多模型 │
├───────────────┼────────┼──────────────────────┤
│ 深度学习/研究 │ Dia │ 学习辅助功能最强 │
├───────────────┼────────┼──────────────────────┤
│ 日常使用 │ 夸克 │ 稳定 + 移动端 + 生态 │
├───────────────┼────────┼──────────────────────┤
│ 设计/自定义 │ Arc │ UI 最佳 + 扩展丰富 │
├───────────────┼────────┼──────────────────────┤
│ 隐私优先 │ Dia │ 数据控制最严格 │
├───────────────┼────────┼──────────────────────┤
│ 阿里生态 │ 夸克 │ 无缝整合 │
└───────────────┴────────┴──────────────────────┘
没想到绕了一圈，又用回百度五笔了
有时候真的感觉像是一个轮回。
用了mac后，各种五笔都用过，后面选择了百度五笔，中间确实切换过为微信输入法，但他突然间就输入不了中文。。。
虽然有不少五笔可用，什么鼠须管之类的。N年前都用过，不过还是选择了百度。
opencode 使用 antigravity 时报错的处理
opencode 在使用 antigravity 的时候突然报错：This version of Antigravity is no longer supported. Please update to receive the latest features!，翻了一圈，发现是昨天的更新导致的 reddit 上已经有解决方法了，意思是，这个 antigravity-accounts 的 JSON 需要更新一下，将其中两个地方更新：1、antigravity 的版本和 SDK 的版本
编辑：~/.config/opencode/antigravity-accounts.json
找到 fingerprint，修改：
"userAgent": "antigravity/1.15.8 linux/arm64",
"apiClient": "google-cloud-sdk vscode/1.104.0",
目前 antigravity 版本最新是 1.15.8，所以改成这个就行了。下面 apiClient 我原来是 python 的，目前我也改成这样。改完重启 opencode，否则可能会被覆盖。
目前 antigravity 版本最新是 1.15.8，所以改成这个就行了。下面 apiClient 我原来是 python 的，目前我也改成这样。改完重启 opencode，否则可能会被覆盖。
然后我就恢复正常了：reddit 的原贴在此 :https://www.reddit.com/r/opencodeCLI/comments/1qqhywb/opencode_this_version_of_antigravity_is_no_longer/
或者看这里：https://github.com/NoeFabris/opencode-antigravity-auth/issues/324 ，有现成的一键解决方案
clawdbot 和 slack 之间踩的坑
昨了试了一下，发现在频道里发消息要一直@，有点麻烦 ，就想着用私信解决。结果发现不能和应用发私信，搜索了一下之后发现有个配置，大致如下：
1. 如果你是该应用的开发者
你需要进入 Slack API 管理后台 进行以下配置：
- 在左侧菜单中选择 App Home。
- 向下滚动到 Show Tabs 部分。
- 确保 Messages Tab 已开启。
- 关键步骤：勾选其下方的 "Allow users to send Slash commands and messages from the messages tab"（允许用户从消息标签页发送指令和消息）。
- 修改后，回到你的 Slack 客户端，按
Ctrl + R(Windows) 或Cmd + R(Mac) 刷新界面，输入框才会出现。
---
我原来改好后没刷新页面，就一直不能发送，现在就 OK 啦。把 cron 的事件通过私信发送（主要是 slack 真的不用翻梯子，方便）
