Stellar 的功能大多是从混乱里长出来的：先遇到一个问题，再想办法把它理顺。这篇记录知识库、动态时间线和几次工程重构的设计过程。
Stellar 的产品设计原则
Stellar 没有走“超越者”的发展路线，我更在意问题本身：这个功能要解决什么？现有的方案真的解决了吗？除了常规做法，还有没有别的路径？后面几个功能大致都是这么长出来的。
为什么要集成知识库系统？
目前市面上有不少优秀的博客模板，但大多缺少知识库功能；而很多专业的知识库系统，又往往博客功能简陋甚至缺失。结果就是，用户只能在不同体系中切换，博客是博客，作品集是作品集，体验难以统一。但一些注重细节的博主其实希望在一套体系内完成这些功能，以获得更高的一致性体验。
就像“东市买骏马，西市买鞍鞯，南市买辔头，北市买长鞭”，零散拼凑也能用，但终究割裂和繁琐。我更倾向于把同一场景下需要的东西放到一起，用统一的设计语言交付出去。
也正因如此，在后来的版本中，知识库系统在社区用户的贡献下衍生出了笔记系统。
动态时间线的设计与实践
知识库的集成重点解决了“体系割裂”的问题，而动态时间线的设计，则是在延续体验一致性原则基础上，去解决发布简短内容的体验痛点。
静态博客的一个常见痛点是：发一篇文章的流程冗长。哪怕借助自动化工具能省去不少人工操作，但前置的配置和环境要求依然复杂，一般用户并不容易上手。于是，当用户只是想发布一条简短的消息时，动用整套“标准流程”就显得过于繁琐。另一种常见做法是集成第三方插件，但正如前文所说，这会带来体验割裂，不是博客体系的一部分。
那么，便捷的发布流程与一致的用户体验能否兼得呢？关键在数据与 UI 分离：数据的流动和界面的展示各做一个模块，中间用接口连接。基于这一思路，我想到使用 GitHub Issues 的开放 API，它相比自建方案门槛更低——不需要服务器也不需要前置操作，因为静态博客的用户群体未必有服务器，同时相比第三方插件体验一致性更好。
前端访问页面时用 API 拉取 Issue 内容，再套上和文章相同的样式渲染出来：发布只需要提交一个 Issue，观感还是博客自己的。
应用示例：
- 展现项目近期计划（通过发布 issue 方式提交计划，并通过特定标签筛选）
- 展示项目最新的版本变更内容（可通过标签筛选，或更换数据源）
- 展示项目热度最高的需求建议或问题反馈（根据评论数排序并筛选）
这套数据与 UI 分离的思路后来被用在了很多地方：动态友链、GitHub 项目更新日志，还有社区用户自己开发的各种玩法。
Stellar 是我的业余开源作品，没有外部时间表。下面从工程重构的角度，讲讲这些设计是怎么在现实条件下落地的。
Stellar 的工程重构
Stellar 自 2021 年诞生以来，一直处于渐进式的重构之中。它就像忒修斯之船：每次替换一块板，每次更新一根桅杆，在持续航行的同时完成整艘船的重建。作为业余开源项目，Stellar 没有外部时间表，却有另一重约束——投入的精力有限，因此每一次重构都必须把力气用在刀刃上：想清楚问题本质，用最低成本验证，再把成果沉淀为可复用的能力。
动态友链重构：从 Issues API 到可复用工作流
动态友链是「数据与 UI 分离」思路的早期实践。2020 年，我实现了通过 GitHub Issue 提交友链信息、前端拉取数据并渲染的方案，发布友链不再需要重新部署站点；这个能力后来被集成进 Stellar，成为动态数据组件的起点。
但受限于我当时的技能积累，这个项目一直处于“勉强能用”的状态：配置和更新流程繁琐，无法自动检测友链的在线状态，朋友有没有更新博客只能逐个手动访问，排序方式也只有创建和更新时间两种，体验不佳。这些痛点积压了五年，直到 2025 年，我借助 AI 对它进行了彻底重构。
重构的成果，是三个可以独立复用、也可以组合成完整工作流的开源项目：
- issues2json：抓取 GitHub Issue 中的第一段 JSON 并保存为数据文件，支持多种排序和过滤规则
- links-checker：自动检测友链的存活状态，并为不同状态的链接打上标签
- feed-posts-parser：解析友链的 RSS 地址，抓取最新文章并写回 Issue，再结合 issues2json 生成数据
三个工具组合起来，过去的痛点被逐一击破：配置大幅简化，友链状态自动检测，朋友的最新文章自动同步并按更新时间排序。更重要的是，这次重构不再是为了某一个页面服务，而是把「数据与 UI 分离」沉淀成了一条通用的数据管线——GitHub 项目更新日志、需求反馈等玩法，都可以在这条管线上快速搭建。在 AI 时代，只要解决方案的思路是对的，大部分实现工作都可以交给 AI 辅助完成，但仍需自己验证结果。详细过程和配置说明，可以参考《动态友链重构：借助 AI 获重磅升级》。
主题版本检测：预埋两年半的数据终于用上了
另一个工程决策，是 Stellar 1.13.0 引入的主题信息标签。当时我的初衷是：等用户群体广泛升级后，通过解析这个标签，在前端清晰展示用户当前使用的主题版本，方便用户查阅文档时对照最新版本的部署效果。
但当时没有现成的数据可用。要么现在就投入精力做一套能分析数据的方案，要么先按最低成本把数据点埋下去、以后再推进。我选了后者：人的精力有限，先把不紧急的事挂起来，等条件成熟再动手。
两年半后，示例博客中的最低版本号也到了 1.18.5，这个功能在 2025 年端午节做了出来。不急着一次解决所有问题，先把数据点埋好，等合适的时机它自己会发挥作用。完整的决策过程，可以参考《Stellar 主题版本检测：预埋两年半的数据终于用上了》。
结语
这几次重构都不是提前规划好的。遇到问题就先把能做的部分做掉，埋下的数据点、拆开的小工具，过一阵子总会在别处派上用场。
