人人向往秩序井然，却总被现实的混乱裹挟前行。那么，如何在混乱中逐步建立秩序呢？本文将结合我的亲身经历，从产品设计和技术实现的方面，分享我的方法与思考。
Stellar 的产品设计原则
Stellar 自诞生之初，就没有走“超越者”的发展路线，而是更加注重与内在本质——一个功能要解决的问题是什么？现有的方案是否真的解决了问题？除了常规做法，是否存在更好的路径？
每一次产品迭代，都是在这些问题和答案的指引下，逐步验证和完善设计。
为什么要集成知识库系统？
目前市面上有不少优秀的博客模板，但大多缺少知识库功能；而很多专业的知识库系统，又往往博客功能简陋甚至缺失。结果就是，用户只能在不同体系中切换，博客是博客，作品集是作品集，体验难以统一。但一些注重细节的博主其实希望在一套体系内完成这些功能，以获得更高的一致性体验。
就像“东市买骏马，西市买鞍鞯，南市买辔头，北市买长鞭”，零散拼凑虽也行，却终归割裂和繁琐。而我更倾向于把同一场景下需要的要素，用统一的设计语言交付给用户，让体验从分散走向整体。
要想真正提供更佳的用户体验，系统需要做到集成化、模块化和规范化。
- 集成化让用户体验保持统一，避免割裂。
- 模块化让用户按需定制功能，减少冗余。
- 规范化则让后续功能迭代与衍生变得高效、有序而可靠。
也正因如此，在后来的版本中，知识库系统在社区用户的贡献下衍生出了笔记系统。
动态时间线的设计与实践
知识库的集成重点解决了“体系割裂”的问题，而动态时间线的设计，则是在延续体验一致性原则基础上，去解决发布简短内容的体验痛点。
静态博客的一个常见痛点是：发一篇文章的流程冗长。哪怕借助自动化工具能省去不少人工操作，但前置的配置和环境要求依然复杂，一般用户并不容易上手。于是，当用户只是想发布一条简短的消息时，动用整套“标准流程”就显得过于繁琐。另一种常见做法是集成第三方插件，但正如前文所说，这会带来体验割裂，不是博客体系的一部分。
那么，便捷的发布流程与一致的用户体验能否兼得呢？其实，解决的关键在于数据与 UI 分离。一个重点是数据的流动，另一个重点是 UI 的展示，它们其实可以是两个独立的模块，通过接口实现分离。基于这一思路，我想到使用 GitHub Issues 的开放 API，它相比自建方案门槛更低——不需要服务器也不需要前置操作，因为静态博客的用户群体未必有服务器，同时相比第三方插件体验一致性更好。
通过 GitHub Issues API，用户只需要提交一个 Issue，前端用户访问页面时便能通过 API 自动拉取内容，并以与博客文章相同的设计语言渲染出来。这样一来，用户既能轻松发布动态，又能保持体验的一致性和连贯性。
应用示例：
- 展现项目近期计划（通过发布 issue 方式提交计划，并通过特定标签筛选）
- 展示项目最新的版本变更内容（可通过标签筛选，或更换数据源）
- 展示项目热度最高的需求建议或问题反馈（根据评论数排序并筛选）
这种数据与 UI 分离的设计思路，不仅兼顾了便捷的发布流程与一致的用户体验，还为后续的演进开辟了新天地——比如动态友链、GitHub 项目更新日志，甚至社区用户自发开发的各种创意玩法。
Stellar 是我的业余开源作品，代表了在没有外部约束的情况下，我在混乱的用户体验现状中找到秩序化的解决方案。接下来的篇幅，我将重点讨论在工作中，如何面对混乱的条件限制中，找到一条稳定可靠的出路。
技术栈与直播架构演进
正如文章开头所说，我们一直在被现实的混乱裹挟前行——技术债务高筑，但互联网公司不可能停下迭代来专门重构。所以我制定了一个“五年计划”，在日常迭代中同步推进渐进式重构，就像忒修斯之船一样，每次替换一块板，每次更新一根桅杆，最终重建整艘船。
分层架构设计与渐进式重构
项目原本是标准 MVC 架构，但是没有约束力和缺少 Code Review 导致最终劣化成了“没有架构”，堪称“低内聚、高耦合”的典范：一个 ViewController 会出现业务逻辑代码、网络层代码、服务层代码，网络接口的类文件里面甚至也会见到写死的业务层逻辑。结果现状就是：即便解决一个很小的问题都会牵一发而动全身，影响范围大，维护成本高。
为了理顺依赖、降低耦合，我将原本盘根错节的网状依赖，改造成单向的树状依赖。结合项目实际需求，我将架构划分为三大层，从底层到顶层分别是：
- 基础工具层：提供跨项目通用功能，如环境切换、类扩展、日志等
- 抽象服务层：面向协议设计，封装公共服务接口，例如网络服务、消息服务
- 业务模块层：面向具体业务需求的封装，每个模块内部改进为 MVVM 架构
分层之后难点在于如何逐步接入以及防止后续劣化。我们采取了三步推进策略：
- 完成接入+试水：新功能用新架构实现。
- 小范围AB实验：一部分接口替换成新架构的实现，并通过AB开关实现新旧切换，有问题可以立即回退。
- 收尾工作：第二阶段验证可行后，逐步完成剩余替换工作。
实现方面，这个改造面临资源严重不足、历史代码兼容成本高等问题，但好在团队认同该方案，为了最终效果，短期内增加工作量是值得的。截止目前，工程总体完成度约 80%，虽然进度受限于资源支持，但重构带来的收益显著——代码质量和维护效率相比之前已经有了质的飞跃。
礼物播放率问题治理
接手项目时，礼物未显示一直是高频客诉问题。我对从赠送、接收消息到播放特效的全链路进行了排查，发现每个环节都存在问题。于是制定了一个系统性重构方案，并根据问题严重程度分阶段推进：
- 赠送阶段：原本通过 IM 消息发送，高 QPS 下容易被限流丢失，改为直接 API 调用，保障核心功能。
- 接收阶段：IM 消息接收与分发存在串房或误拦截问题，需在分层架构改造中优化消息服务。
- 播放阶段：播放队列健壮性差，偶尔中断导致后续礼物无法展示；同时播放器库兼容性差、存在崩溃。解决方案：更换稳定播放器 + 队列自唤醒机制，工作量约占总改造的 1/5，但解决了约 4/5 的客诉。
经过三个阶段的系统治理后，礼物未显示的客诉下降9成以上，已基本绝迹，客户体验和业务稳定性显著提升。
在下架风波中，稳步前进
直播行业在国内的审核机制严格，我在公司工作的五年期间，亲身经历了两次全平台下架的风波。第一次下架发生后，很快连内测分发平台也纷纷下架了我们的包，导致 iOS 正常的产研流程受阻。
面对这一突发情况，作为技术团队，我们自然不能坐以待毙，在整改期间也需要继续迭代的。遭遇政策因素被全平台下架时，无论选择哪个平台，或早或晚都会被下架，因此我很快意识到，换一家内测分发平台不能解决问题，唯一的出路是自部署。
好在自部署并不复杂。事实上，在我入职的第一家公司，我就出于兴趣为公司实现过一个简单的内测分发方案。因此这次，我们迅速完成了方案替换，并开始自主管理，使内部产研流程恢复正常运转。
新方案的优势不仅仅是不受外部政策影响，在持续迭代后，它在用户体验上也发生了巨大的飞跃。比如，打包完成后，系统会自动通过飞书@打包操作人，并在飞书消息卡片中提供一键安装按钮；同时，消息通知里还集成了这次打包的变更内容，极大地提高了开发和测试过程中信息的透明度。
这套方案后来也被广泛应用于公司的其他项目，不仅提升了工作效率，还为多个产品线提供了稳定的应急保障。
这是一件小事，分享它的重点不在于会不会做，而在于正确的决策。在 AI 时代，你甚至完全不知道怎么实现都没问题，只要解决方案的思路是对的，执行方面可以放心交给 AI 去完成。（如有读者感兴趣，可以参考《感谢 AI，动态友链获重磅升级！》这篇文章，后续我也会有其它案例分享。）
结语
山重水复疑无路，柳暗花明又一村。混乱不是深渊，而是阶梯，它鞭策我们去探寻问题的本质，找到通往秩序之路。
