这篇复盘想回答一个问题：Stellar 为什么没能进入 Hexo 主题头部？数据面（2026-08-14 快照）的答案是——star 第 9、与第二梯队差约 4 倍、2024 年明显增长后增速回落、近一年发版几乎停摆；但同一组数据也显示 npm 月下载排第 3、近 12 个月 star 增速高于同梯队竞品。产品面补上另一半：在「轻博客为主流」的 Hexo 生态里，四系统这类「重功能、强差异」的定位没有形成品类心智，增长机制也没能把它转化为规模。落后是「定位错位」与「增长机制不足」叠加的结果。

前面的梦已经记不太清了，大多是一些无聊的小事，只是我发现这个世界并不完美，偶尔冒出一些解释不清的异象。

连续两个晚上做梦笑醒，不是因为有什么好事，只是睡眠变浅了。

OKR-2025 目标回顾

人人向往秩序井然，却总被现实的混乱裹挟前行。那么，如何在混乱中逐步建立秩序呢？本文将结合我的亲身经历，从产品设计和技术实现的方面，分享我的方法与思考。

本文内容可能已经过时，仅作参考。 书接上回，刚迁到服务器，东西还没完全配完，就从日志里看到不少不速之客了！虽然是静态博客，但看到这些扫描器反复试探还是很烦，果断禁掉。

2026-08-01飞书下线旧 webhook 机器人后，本文已同步更新至 open-api 方案。 由于近期网站速度不稳定，只好再把博客解析改到服务器上。博客源代码托管在 GitHub 上，每次更新的流程如下： 提交源码到私有仓库 私有仓库执行 Action 2.1. 执行 hexo g 生成静态文件 2.2. 部署到 xaoxuu.github.io 公开仓库 2.3. 触发服务器同步拉取 xaoxuu.github.io 更新 本文内容 Vercel/Netlify/Cloudflare等平台同步部署（基于 xaoxuu.github.io 静态内容） 2.3 曾经是 rsync 同步到服务器、也曾是同步到 oss，但前者配置复杂，这次我已经忘了怎么操作了；后者用了几天感觉同步速度极慢。rsync 方案： 服务器问题记录

博客图片存哪儿，看起来是小事，折腾起来却让人头大。

其实早在 Stellar 1.13.0 版本，我便引入了主题信息标签，初衷是待用户群体广泛升级后，通过解析此标签，在前端清晰展示用户当前所用的主题版本。

事情的起因在回访用户的过程中，我发现有不少用户用 wiki 当作专栏来使用，可见专栏确实是一个普遍的需求点，而现有的 wiki 系统并不是专门为此场景设计的，虽然能用，但是不够好用。 为什么需要用 wiki 作专栏？ 如果一个话题需要发多篇文章，且它们在归档页的顺序不是相邻的（即中间发布了不属于这个话题的其它文章），那么读者阅读的时候文末的「下一篇」会跳到此话题以外的文章中，没有办法连贯性地阅读此话题的全部文章。一个 wiki 项目就像一本书，其中的各个页面之间有较强的关联性，左侧有文档树，可以快速定位到上一篇、下一篇，因此很好的解决了这个痛点。

一、失落感贯穿全年的 2023其实从年初就知道了这将会是很难熬的一年，事实证明确实如此。

事情经过近日发现一个发通知时触发的 EXC_BAD_ACCESS 崩溃，在 DEBUG 时，崩溃指向这一行代码：