先说结论
只看用户当前的 karma 值，你几乎无法做排错，也无法解释历史。Odoo 单独做一张 gamification.karma.tracking，就是为了把“变化轨迹”从结果值里剥离出来。
第一层：为什么要同时存 old_value、new_value 和 gain
_compute_gain() 用 old/new 推导 gain，而 create() 也能反过来根据 gain 自动补 new_value。这说明 Karma 追踪不是简单记录最终值，而是始终试图保留“变化前、变化后、变化量”三种视角。这样无论你做审计、回放还是查错，都有足够语义。
第二层：来源引用为什么很关键
origin_ref 与 origin_ref_model_name 让 Karma 变化能挂回某个来源对象。产品层面，这相当于在回答：“这次积分变动到底是人工补的，还是某个业务动作触发的？” 没有来源引用，分数变化再准确，也很难被信任。
第三层：为什么 create 要主动补 old_value
在 create() 中，如果没有传 old_value，系统会读取用户当前 karma 作为基线。这种做法很重要，因为日志如果不保留变化前状态，后续就只剩一串孤立的新值。那样你顶多知道“改过”，却不知道是从多少改到多少。
第四层：consolidation 为什么会牺牲细节
_process_consolidate() 会把两个月前的一批历史 tracking 汇总成“最早 old_value + 最晚 new_value”的一条 consolidated 记录，同时删除中间细粒度记录。也就是说，Odoo 这里在做一笔清晰的交换：保留趋势可读性，牺牲逐条细节，以换取数据量可控。
第五层：这条链最适合解决什么问题
当社区、学习或论坛类场景里 Karma 变动频繁时，如果完全不清理，历史表会迅速膨胀；如果完全不留痕，又无法审计。Tracking + consolidation 的组合，正是兼顾“可追溯”和“可维护”的折中方案。
最容易误解的三个点
- 误区一：Karma 只是一个展示分。实际上它往往影响权限、排序或激励。
- 误区二：日志越细越好。长期看，不做 consolidation 的成本会越来越高。
- 误区三：只要保存 gain 就够了。没有 old/new，排错时会缺关键上下文。
实战上怎么用更稳
- 当用户抱怨积分异常时，先查 tracking，而不是先改用户主表。
- 扩展 Karma 来源时，尽量补全 origin_ref，别只写一段 reason 文本。
- 如果你做类似积分系统，consolidation 一开始就该设计，不要等表炸了再补。
最后总结
Karma 的价值不只在“现在多少分”，更在“这分是怎么一步步变成现在的”。Odoo 的 tracking 设计，就是在为这件事兜底。
DISCUSSION
评论区