人人向往秩序井然，却总被现实的混乱裹挟前行。那么，如何在混乱中逐步建立秩序呢？本文将结合我的亲身经历，从产品设计和技术实现的方面，分享我的方法与思考。
Stellar 的产品设计原则
Stellar 自诞生之初，就没有走“超越者”的发展路线，而是更加注重与内在本质——一个功能要解决的问题是什么？现有的方案是否真的解决了问题？除了常规做法，是否存在更好的路径？
每一次产品迭代，都是在这些问题和答案的指引下，逐步验证和完善设计。
为什么要集成知识库系统？
目前市面上有不少优秀的博客模板，但大多缺少知识库功能；而很多专业的知识库系统，又往往博客功能简陋甚至缺失。结果就是，用户只能在不同体系中切换，博客是博客，作品集是作品集，体验难以统一。但一些注重细节的博主其实希望在一套体系内完成这些功能，以获得更高的一致性体验。
就像“东市买骏马，西市买鞍鞯，南市买辔头，北市买长鞭”，零散拼凑虽也行，却终归割裂和繁琐。而我更倾向于把同一场景下需要的要素，用统一的设计语言交付给用户，让体验从分散走向整体。
要想真正提供更佳的用户体验，系统需要做到集成化、模块化和规范化。
- 集成化让用户体验保持统一，避免割裂。
- 模块化让用户按需定制功能，减少冗余。
- 规范化则让后续功能迭代与衍生变得高效、有序而可靠。
也正因如此，在后来的版本中，知识库系统在社区用户的贡献下衍生出了笔记系统。
动态时间线的设计与实践
知识库的集成重点解决了“体系割裂”的问题，而动态时间线的设计，则是在延续体验一致性原则基础上，去解决发布简短内容的体验痛点。
静态博客的一个常见痛点是：发一篇文章的流程冗长。哪怕借助自动化工具能省去不少人工操作，但前置的配置和环境要求依然复杂，一般用户并不容易上手。于是，当用户只是想发布一条简短的消息时，动用整套“标准流程”就显得过于繁琐。另一种常见做法是集成第三方插件，但正如前文所说，这会带来体验割裂，不是博客体系的一部分。
那么，便捷的发布流程与一致的用户体验能否兼得呢？其实，解决的关键在于数据与 UI 分离。一个重点是数据的流动，另一个重点是 UI 的展示，它们其实可以是两个独立的模块，通过接口实现分离。基于这一思路，我想到使用 GitHub Issues 的开放 API，它相比自建方案门槛更低——不需要服务器也不需要前置操作，因为静态博客的用户群体未必有服务器，同时相比第三方插件体验一致性更好。
通过 GitHub Issues API，用户只需要提交一个 Issue，前端用户访问页面时便能通过 API 自动拉取内容，并以与博客文章相同的设计语言渲染出来。这样一来，用户既能轻松发布动态，又能保持体验的一致性和连贯性。
应用示例：
- 展现项目近期计划（通过发布 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 主题版本检测：预埋两年半的数据终于用上了》。
结语
山重水复疑无路，柳暗花明又一村。混乱不是深渊，而是阶梯，它鞭策我们去探寻问题的本质，找到通往秩序之路。
