理由提高可预测性与接受度
别名: 推荐理由 · 可预测性 · explanation acceptance
概念解释
推荐列表里多出来的那一行字——「因为你听过《蓝色列车》」——真正改的不是点击率口号，而是用户能不能预先想象「下一首大概会是什么」。理由辅助的可预测性（reason-aided predictability）指：一条指向具体依据的理由，让人把系统从黑盒改写成可模拟的规则，从而更愿意把条目当作合法建议来对待。
接受度在这里是「我承认这是冲着我来的」，不是「我被说服去点开」。点开决策是另一层问题。
机制
人用内部模型预测系统下一步。没有理由时，模型只能从位置和封面去猜，猜错一次就变成噪声；有理由时，用户可以做一次条件推理：「如果依据是听过的爵士，那下一首也应落在附近」。预测命中降低了「这是不是乱推」的警戒，接受就发生在警戒下降之后。
理由同时提供跨条目的稳定性：同一条规则在第三条、第十条上还成立，用户才敢把规则记下来。偶发的漂亮理由帮不了下一次预测，所以可预测性是对规则的信任，不是对单条文案的喜欢。
怎么研究
推荐解释研究的常用做法是：同一套排序，有理由 vs 无理由，再测用户对「下一条会是什么」的预测准确度、是否把条目视为针对自己的建议、以及打开/跳过是否与自评相关度一致。自变量：理由是否出现、理由指向的特征是否用户可识别、列表长度。因变量：下一首/下一部的预测命中、接受（视为合法建议）、决策时间。
不要用点击率当接受度的代理。点击会被位置、封面、标题带跑；可预测性要单独问「你觉得系统下次还会用同一条规则吗」。解释忠实度、事后编造、句式重复都不是这一问要回答的。
边界
封闭任务（下一班车、验证码、库存是否有货）不需要理由来建立可预测性，规则本身已经公开。高风险决策里，理由提高接受可能是危险的——接受先于核验。新用户还没有可被引用的历史时，理由无从落地，空理由会反向破坏可预测性。这条只论证「具体依据让规则可被模拟」，不规定理由必须出现在每一行，也不处理追踪反感。
怎么落地
- 在条目旁给出一条可被下次复用的规则，而不是一句恭维。「因为你最近在听硬波普」比「为你精选」更能支撑预测。
- 同一屏上的理由应指向同一类依据，让用户能做跨条目检验：三条都说「硬波普」而混进流行热歌，预测立即破产。
- 验证：遮住封面与标题，只留理由，让用户猜下一条的类型。猜中率应明显高于无理由对照组。再问「这是不是冲着你来的」——接受应随猜中率一起升，而不是随点击一起升。