养虾记:与人乐乐 -- OpenClaw 资讯日报搬家记

“独乐乐，与人乐乐，孰乐？不若与人”

新手任务

读过第一篇养虾记的你兴许还记得，Mini 懵懂上线之后的第一个新手任务，就是每天早上收集科技资讯，挑热门消息发到我的 Telegram。后来为了省事，又让它做成语音，这样我可以吃饭或坐车的时候听一耳朵。

这贴心的每日资讯，像小情人一样陪了我几个月。

老情人不香了

可是，日复一日，小情人变成了老情人。

Telegram 版面有限，文字日报的内容十分精简，且缺少格式排版，看着费劲。 想看下以前的资讯，得费劲翻着找。或者搜索历史。不爽。

曾经温柔可人的 Telegram 日报，现在看着越来越不顺眼了。

金屋藏娇

我琢磨着：资讯这东西不应该总埋在聊天记录里呀。

得整个专门的地方，金屋藏娇。

何不弄个网站，让每日资讯住进去。这样既可以尽情妆扮，又能随叫随应。

但是一座大宅子，只住一位日报小米（Mini），似乎未能物尽其用。

AI模型的三千佳丽，各有各的风韵，有时想要比较一番，却乱花渐欲迷人眼。

我需要一位博闻强记，心思细密的资料秘书，负责整理编纂所有 A模信息： 身材/三围，学识，能力，记忆，反应 等等，皆登记在册。 于是钦点“文书小丽”（List）全权管理A模一览表，以便我随时问询。

自己心心念念的AI新模选秀，时不时会来几位眉清目秀的妹子。 每有风吹草动，我都要心急火燎地溜过去饱餐秀色，生怕错过一位新人。 但自己又不能天天盯着。

因此，要安排一名跑腿小厮，每日前往打探。一旦发现新人，马上回来禀报。 不仅仅是A模新人，还有坊间传闻，A模人气，各种选秀榜，也一并打探来。 这便是消息灵通的“探报小阮”（Ranking）。

不过这么一来，我本打算“金屋藏娇”的宅子，就成了报馆。

小米做起报馆里的主笔兼播音；小丽掌资料；小阮跑外勤。

整理的日报和佳丽信息，都贴到外面公告栏里。独乐也可成为众乐。

安排馆舍

先得有报馆。

我琢磨着，要是买地盖房，光租主机配环境就得折腾个半死，还是租现成的省事。

没想到，天下居然还有免费的宅子。

比如：Cloudflare。馆舍现成的，地主家自个有人看家护院，打扫修缮。只要不住深宅大院，消耗无度，连租都不收…… 这么良心的地主，必须赞一下。

拎包，入住。

文书和规矩

每日收集来的资料，不能随用随丢，得登记入册，形成文书，以便随时查阅。

而馆里几个伙计，得让他们按规矩办事，每天的行事章程（代码/工作流）得安排妥当。

这些章程和文书统统放在书柜（GitHub）里。

当然两者得分开记。

网站构建用的代码/工作流得逐步制定和完善，可一旦稳定了，就不怎么用改了。 但是网站内容这类文书，特别是四处搜集来的A模小档案，可要认真记录。好好保存。

日报小米

日报小米可是咱的老情人了。

不仅日报理得好，还有一副好嗓子。每天的日报以评话（MP3）道来，娓娓动听。 且是本土官话和异域方言皆精。 从 Telegram 转到这报馆里，老手艺用起来依旧是熟门熟路。

就有一样事儿需得特别操办，就是这评话比较占地儿。不能像普通文书那样搁书柜里，得专门搭台唱戏。 好在 Cloudflare 有 R2，10G 以内免费。于是就在 R2 给小米搭了戏台。

文书小丽

要管三千佳丽的花名册，还真不是件容易事。

这些信息来自各处：有的在模型市集上，有的在评测榜上，有的在选秀榜上。虽然小丽不用负责收集，但要把它们整理好，登记成册，也是一件颇让人挠头的事情。

光是A模的花名，就够让人迷糊一阵的。 因为各家对同一个A模的叫法，可能不完全一样。 市集上叫这个，评测榜上叫那个，开源社区又换个叫法。

小丽头一天上手就懵了：这到底是三位佳丽，还是一位佳丽的三个马甲？ 忙活到次日，小丽顶着黑眼圈来汇报了——“艾玛，总算理完了……要不是我定下规矩，刚上岗就得变成烈士：每个模型定一个正名，至于花名、旧名、版本别名统统挂在正名下。”

探报小阮

小阮是跑外的。 他不写稿、不评论，只管打听坊间的A模消息，每日天不亮就出门。他都打听啥呢？

每天回来，他能揣回几百条消息。然后去找趴在文书堆里的小丽。

“小丽姐，新消息都搁这儿了。你慢慢看哈……”

“小丽姐，还在忙啊，要不要我帮你冲杯提神茶呀？”

“小丽姐，歇会儿吧，看你忙的，皱纹都快累出来了……哎哟，疼……疼……救命呀……”

内外有别

报馆，人员，都到位了，但真要运转起来，还有不少头绪要理。

现在，章程和文书已经分开记，不会相互影响。

但是章程本身刚起头，要不断修改，小米、小丽、小阮每天为这个吵得鸡飞狗跳。

所以，已经定稿的部分（main branch）和讨论稿（dev branch）是分开的。 讨论稿里，大家吵清楚达成一致的部分才会写进正式稿的章程里去。

而且公告发布也分开了。 正式发布从 main 出；讨论稿的预览发布从 dev 出，只在内部用。

我以为这样就万事大吉，结果还是出岔子……

正式发布公告里，居然出现了内部讨论的内容。 甚至还有这个：

“小阮！！！是不是你顺走了我桌上的丝巾！一个时辰内要是不还回来，你就死定了！”

好家伙，正式公告里，随处可见小米的吐槽，小丽的涂鸦，甚至还有小阮给小丽的私密小纸条。

真头大呀……赶快查一下咋回事？ 原来内外发布的文书都放在书柜同一个格子里（site/content/）。 它是入册的，放和取跟着分支走——切换分支会带走没提交的改动，合并分支会带走已提交的改动。一马虎，涂鸦啦、便条啦，就跟着进了正式公告。

于是把文书分成内外两份，放不同的格子。可是，还是有问题——格子分了，柜子还是一个（同一个 git worktree）。

柜子里，正本是按分支拿的：git checkout 一执行，就取到正本。 可一些内部讨论是不入册的，换分支时它还在那儿。有时拿正本时一不留神，就拿混了。

只要还在一个柜子里，手一伸就能拿到隔壁格的东西——靠人记着“别拿错”，是靠不住的。

索性连书柜都拆成两个（两个 worktree）。一个柜只放正本，另一个只放讨论稿。每日例行发布时只从正式柜取。这下才算彻底不会混了。

被收租金

报馆开工没几日，大伙正干得热火朝天的，忽然收到一份讨租信。

我愣了一下：不应该呀，Cloudflare 这馆舍是免费的，GitHub 那个书柜也是免费的，哪里来的租金？

仔细一看，原来是我用书柜的附加功能超额了，GitHub Actions 有每月 2000 分钟的免费额度，其实还算慷慨的啦……

只不过我这刚开工，章程在不断地修改，反复起草公告，光一份日报加上评话 TTS，就要二三十分钟。2000 分钟的额度，没几天就用完了。

叫来小米聊了一下，像写日报、生成语音这些工作，没必要非在书柜这儿做嘛，回自己屋搞去，写好了再拿到书柜这儿来。这样的话，只在发布公告（网站部署）的时候才会用到 GitHub Actions，一次就一两分钟。免费额度完全够用。

完美。

伙计撂挑子

既然有日报，当然是每天一大早都会发公告啦。

我早上都会溜达过来看一眼。

结果，隔三差五地被我发现公告栏不更新，或者是公告里缺这少那……

每次看得我气不打一处来，冲进去找仨人算账……

结果他们还一肚子委屈：

“大模型调用不稳定呀…… 大伙干活不都得靠大模型嘛……大模型一抽风，咱活就没法干了…… 比如前些天 OpenCode 套餐接口升级不兼容，咱们只好全体躺平啦呀”；

“还有那个微软 TTS 服务升级，搞得小米的评话出不来，公告没语音，也不是我们的错啊……”

bala bala……

虽说有推诿嫌疑，但是大模型调用和输出有时不稳定，确实是个事。

好吧，章程里增加失败重试和备用模型切换逻辑，配上三套模型，以后再失败可别想拿这个搪塞。

救火队长

但是，很多问题，不是切换模型或简单重试就能解决的。 构建或发布失败，也许是网络抽风，也许是哪家的接口改了规矩，但更多时候就是那仨伙计上班摸鱼整出了岔子。

出了岔子得能及时发现。

要有个盯梢的。到了发公告的点儿，就跑去瞧一眼，公告出来没有？内容对不对？ 如果发现问题，赶紧摇人来修。

至于摇谁，肯定不是我啦……我可懒得管。

这事交给 Nano（对，就是那只 Hermes 虾），让它定时巡查，并且负责收拾烂摊子。

公告发布是有章程的，每一步都有记录。Nano 会查记录，已完成的部分不用重做，只把失败的部分修好补上，再把公告发出去就成了。 Nano 够机灵，遇到问题修修补补的不在话下。就算真碰到大问题解决不了，也会通知我。

公告栏

这座报馆，自 8 月初开始每日出炉双语带评话公告，到现在已经有几个月了。

从开始时，报馆里问题连连，鸡飞狗跳；外加 Nano 三天两头救火搞得怨声载道，到如今风平浪静。期间称得上一波三折。

小米，小丽，小阮，Nano，还有时不时溜达到报馆瞅一眼的我，都已混得倍儿熟。

馆里依然时不时响起小米珠圆玉润的播音腔，偶尔还有小丽的娇叱，小阮的得意坏笑亦或惨叫哀号……

馆墙外，公告栏静静伫立，日复一日展示着 AI 资讯和模型排行。心止如水，宠辱不惊。

或许有一天，会有路人驻足一瞥，会心一笑。 亦或始终无人过问，倒也清静自得。

都无妨。独乐、众乐，皆乐矣。

附： 公告栏：https://techub.minixspace.com

往期文章