预测模型做完，最尴尬的时刻是业务人员问一句「这个预测数我该怎么用」。模型输出的是概率与趋势，业务要的是决策依据。两者之间缺的不是更漂亮的图表，而是一张能把模型输出、业务口径与随访记录放在一起的对照表。
预测值不是结论
模型的输出天然带着不确定性，但业务汇报需要的是「结论感」。直接把预测值搬上汇报材料，业务人员要么全信、要么不信，两种反应都说明这个数字没有被正确地翻译。正确的做法是把预测值翻译成业务语言：在什么条件下、预计会发生什么、置信程度如何、建议关注什么信号。
同一张表解决翻译问题
我们把三类数据放进同一张对照表：模型输出（预测值、置信区间）、业务口径（这个指标在业务上的定义与当前口径）、随访记录（周期结束后实际发生了什么）。业务人员看这张表，能看到的不只是预测，还有上一次预测兑现得怎么样、偏差出在哪里。预测的价值在随访里兑现，信任也在随访里积累。
随访表的字段设计
随访表的设计有几个不能省的字段：预测周期与预测时点的快照（防止事后调整预测口径）、业务口径版本号（口径变更后历史预测要能按旧口径复核）、实际值及其取数来源、偏差原因的分类编码。字段齐了，随访才是可累积的资产；字段缺了，随访就成了每次汇报前的临时补数。
让业务参与解释
对照表做完之后，解释权要交还给业务：偏差是模型错了还是口径变了？是外部环境变了还是数据没跟上？这些判断需要业务经验，模型团队不应该替业务下结论。我们见过的最健康的协作模式，是业务人员主动用这张表向管理层汇报预测的兑现情况——那一刻，预测模型才算真正进入了业务流程。
写给算法团队
预测模型的交付物不是模型文件，而是这套让业务敢用的对照机制。花在随访表结构设计上的时间，回报比再调一轮参数高得多。
延伸：口径变更的触达
业务口径不是一成不变的，变更之后随访表怎么处理要有预案：变更时点之后的随访按新口径记录，之前的保留旧口径并打上版本标记；正在进行中的预测周期，要在表里标注「口径已变更、本周期数据不可直接对比」。口径变更本身也要写进随访原因的分类编码，让每一次断点都有据可查。