Bilibili Trace 设计笔记

Bilibili Trace 来自一个很小的烦恼：视频数据一直在变化，但大多数页面只展示当前数值，好像当前值就是完整故事。

对创作者或者观察者来说，更有意思的往往是变化。一个视频是否接近目标、是否变慢、是否有新评论、是否和另一个视频走势不同，这些信息比一个静态数字更有用。

1. 把指标当成时间，而不是标签

点赞、评论、投币和播放通常只是页面上的标签。随便看看时这够用，但追踪时不够。

这个项目的设计想法，是把每个指标都当成随时间变化的东西。只要数据有了时间维度，产品就可以回答更好的问题：

• 这个视频还在增长吗？
• 它到目标了吗？
• 哪个指标先变化？
• 变化正常还是异常？
• 哪些追踪视频需要注意？

这样产品就不再只是一个数字表格，而是一个监控界面。

2. 第一个版本先保持可运转

一开始很容易想做图表、预测、通知规则和仪表盘。它们以后可能有用，但不是基础。

第一个有价值的循环更小：

add a video -> store its metrics -> compare current values -> make the change visible

如果这个循环可靠，分析功能才有东西可以依赖。如果这个循环很弱，更漂亮的图表只会让不可靠的数据显得更精致。

3. 围绕目标值设计

目标值能让原始指标更容易理解。

像 923 这样的数字本身信息不多。但 923 / 1000 马上就有了上下文。它告诉我这个视频离目标还有多远，也告诉我下一次刷新是否值得关注。

所以目标对比应该靠近产品核心。它让追踪页有一个简单理由：不只是“现在是多少”，而是“离我关心的东西还有多近”。

4. 数据访问保持朴素

对这个项目来说，朴素的后端选择是一种优点。

Spring Boot、MySQL、MyBatis-Plus，以及清晰的 controller-service-entity 结构，让系统更容易检查。重点不是发明聪明架构，而是让指标采集、存储和展示都足够可预测。

普通查询能用结构化 query wrapper 解决时，我也更愿意避免手写 SQL。这样常见读取会更一致，也能减少小错误。这个项目里，数据模型的重要性高于查询技巧。

5. 给账号系统留空间，但先不要依赖它

用户账号、订阅和通知规则都是自然的后续功能。但最早的版本不应该依赖它们才能有价值。

早期产品仍然可以追踪一组共享视频，并证明数据循环可以跑通。等这个稳定后，账号系统才是个性化追踪的方式，而不是基础价值的前提。

我现在的规则

对于 Bilibili Trace，设计规则是：

make changing numbers easier to notice

这个项目应该继续聚焦在一件事上：把分散的视频指标变成一个小而可读的监控流程。