邸报 v0.2.1 发布，这次是 v0.2 发布之后拖延了很久的一次性能优化和 bug 修复，没有太多显式升级，但建议更新。
后续邸报采用 tick-tock 更新策略，奇数大版本升级优化算法和体验，偶数大版本升级更新功能。
下一个版本是 v0.3，会着重进一步优化推荐算法。

早～

如果不是刷到这条新闻，我大概永远不会知道我买的国债，有可能被用来补助别人家小区修电梯。
我对这个行为没什么意见，只是第一次知道中国的基建投资已经下沉到了如此程度。
这回总不能说中国的基建支出和民生没关系了吧？

OPPO ColorOS 现在是可以统一管理国内 App 的个性化广告的。
我对个性化广告没什么意见，所以就没关个性化广告。因为关了也有广告，而且可能是更烂的广告。
Find n6 用了半年左右，发现广告给我的个性化标签是这样的。
怎么说呢，感觉并不是很准。

研发人员真的应该给自己用很烂的设备。
我之前不是说我的群晖硬盘坏了一只吗？这个是 Codex 发现的。
Codex 怎么发现的呢？是我一直觉得邸报测试实例很卡。
从未发布版本到 0.2，我大概让 Codex 进行了 3 轮性能优化，但是依然很卡。
直到有一次 Codex 感觉 I/O 一直不对劲的高，自作主张去查了群晖日志，发现是 RAID 1 虽然显示正常，但其中一块硬盘总是有写错误拖慢了整个群晖和邸报的速度。
最近换了新硬盘之后，群晖恢复了正常 I/O，我本来说接着把邸报的性能优化收个尾。
结果发现，哪里需要优化，根本是丝滑流畅。
之前的 3 轮性能优化相当于在远低于预期的性能环境里做了极限测试了。
如果不是我硬盘坏了，邸报可能永远不会做这么多性能优化。🤣

公布我的方式：针对有限主题订阅的个性化日报，最节省 Token，同时也是在最简性能下的技术栈是，仅在用户首次订阅主题时使用 LLM 生成 n 个主题范文。之后所有的文章过一遍 0.6B Embedding 来和主题范文进行匹配。在当日日报生成时按主题进行 rerank 取上层结果，全程无需 LLM 介入。这个方案的日常运行边际成本为 0，效果好的惊人。

LLM Wiki WebUI v0.2.0 发布：github.com

适配 LLM Wiki 昨天发布的 v0.6.0 版本暴露的新 API，现在可以在 WebUI 上直接对 LLM Wiki 进行提问了。

这意味着你可以在局域网内任何设备上近乎完整的使用 LLM Wiki 的功能了。

对 Embedding 的理解，是一个人 AI Harness 水平的试金石。
问一个人要做一个个性化日报系统，每天从 500 篇文章里抓出指定主题文章，回答全过一遍 LLM 的人。
大概率是从小红书和 X 上学的 Harness。
Harness 出来的东西大概和清朝马拉火车差不多。
就是只认识马（LLM）。

Vue 还是 React 的问题再 2026 年终于有了答案。
AI：你问我用什么我推荐 Vue，我自己的话用 React。
笑死。

RAID 1 重建完毕，终于可以重新开始开发邸报了。