1. 从20%转化异常说起：一个被低估的决策断点转化率从预期水平掉到20%异常区间，这件事在任何一个做增长或做产品的团队里都算得上"一级警报"。但真正让我决定把这次经历完整写下来的原因，不是异常本身，而是我们复盘时发现：问题根本不在转化环节，而在决策环节。换句话说，数据早就把答案摆在那里了，只是没有人把它翻译成一个可以执行的方案。Coomia DIP 这个项目，就是在这个背景下被推到台前的。DIP 在我的理解里，是一套"决策智能平台"的思路——它不负责帮你拉数据，也不负责帮你做AB实验，它负责的是把散落在各个系统里的信号，收敛成一个带评分、带优先级、带行动建议的方案。标题里那个"1,833.56分方案"，听起来像是一个很精确的数字，实际上它确实精确到小数点后两位，因为这套评分体系本身就是用加权模型算出来的，不是拍脑袋给的。我先说清楚这篇内容适合谁看。如果你正在被"数据一大堆、结论没几个"困扰，如果你所在的团队每次开会都在争论"到底哪个环节出了问题"，如果你手上有一堆指标但不知道怎么排优先级，那这篇内容会对你有用。如果你只是想找一个现成的工具装上去就完事，那可能会失望，因为决策闭环这件事，工具只占三成，剩下七成是流程和判断逻辑。我尽量把这次从异常发现到方案落地的完整链路写清楚，包括我们踩过的坑、走过的弯路、以及最后为什么是1,833.56这个数字而不是别的。文中涉及的具体业务数据我会做脱敏处理，但方法论和计算逻辑会尽量还原。2. 20%转化异常到底异常在哪：先定义问题再谈方案2.1 异常不是"低了"，而是"偏离了基线"很多人一看到转化率下降，第一反应是"赶紧优化落地页"。但我在实际排查中发现，没有基线的异常判断都是耍流氓。我们当时做的第一件事，是把过去90天的转化数据按渠道、按设备、按用户分层拉出来，建立了一个动态基线。具体做法是这样的：以7天为一个滑动窗口，计算每个维度的转化率均值和标准差，然后设定一个阈值——偏离均值超过1.5个标准差就算异常。这个1.5不是随便定的，是我们试了1.0、1.5、2.0之后，发现1.5的误报率和漏报率比较平衡。1.0太敏感，天天报警；2.0太迟钝，等它报警的时候已经晚了。结果一跑出来，问题就很清楚了：整体转化率确实掉到了20%附近，但拆开看，移动端新用户的转化率掉了将近40%，而老用户和桌面端几乎没动。这就意味着，问题不在全局，而在某个特定人群的特定路径上。2.2 为什么20%这个数字容易误导人20%这个数字本身没有意义，有意义的是它和谁比、在什么条件下比。我们当时犯的一个错误，就是一开始把20%当成了"整体转化率"，然后所有人都在讨论整体优化。后来才发现，这个20%其实是某个特定渠道的转化率，而那个渠道的流量占比只有15%。这里我想分享一个经验：看转化率一定要看"加权转化率"和"分层转化率"两个口径。加权转化率是把所有渠道按流量占比加权算出来的，它反映的是大盘；分层转化率是每个渠道单独算的，它反映的是结构。大盘没怎么变但分层变化很大，说明是结构问题；大盘和分层一起变，说明是系统问题。我们当时的情况是：加权转化率从28%掉到了22%，分层里移动端新用户从25%掉到了15%，其他分层基本没变。所以结论很明确——问题集中在移动端新用户的首次转化路径上。2.3 把"异常"翻译成"可决策的问题"发现异常只是第一步，真正难的是把异常翻译成一个可以被决策的问题。我们当时用了三个问题来收敛：这个问题影响多少人？（移动端新用户占比约35%，影响面不小）这个问题影响多少钱？（按客单价和转化损失算，每天大约损失X）这个问题有没有已知的解法？（有，但需要排优先级）这三个问题一问，决策的轮廓就出来了：这不是一个"要不要修"的问题，而是一个"先修哪个"的问题。而"先修哪个"正是 Coomia DIP 要解决的核心问题。3. Coomia DIP 的评分逻辑：1,833.56分是怎么算出来的3.1 评分模型的四个输入维度Coomia DIP 的评分不是单一指标，而是四个维度的加权结果。我把这四个维度拆开讲：第一个维度是影响面（Impact）。这个维度衡量的是问题影响多少用户、多少收入、多少核心指标。我们当时用的计算方式是：影响用户数 × 影响系数 + 影响收入 × 收入系数。影响系数和收入系数是根据业务阶段动态调整的，早期业务收入系数低，成熟业务收入系数高。第二个维度是紧急度（Urgency）。这个维度衡量的是问题随时间恶化的速度。有些问题今天不修明天更严重，有些问题放一周也没事。我们用的判断标准是：如果问题每天恶化超过1%，紧急度就高；如果基本稳定，紧急度就低。第三个维度是解决成本（Effort）。这个维度衡量的是修复这个问题需要多少人天、多少资源、多少协调成本。成本越高，评分越低，因为同样的收益下，成本低的方案应该优先。第四个维度是确定性（Confidence）。这个维度衡量的是"我们有多确定这个方案能解决问题"。确定性低的方案，即使影响面大，也要打折，因为可能白干。3.2 加权公式与参数选择四个维度确定之后，就是加权求和。我们用的公式大致是这样的：Score = (Impact × 0.4 + Urgency × 0.25 + Confidence × 0.2 - Effort × 0.15) × 100这个权重不是拍脑袋定的，是我们用历史数据回测出来的。具体做法是：把过去半年做过的所有优化项拉出来，看哪些真正带来了提升，然后用逻辑回归去拟合权重。拟合出来的结果和我们的直觉基本一致——影响面最重要，紧急度次之，确定性再次，成本是减分项。1,833.56这个数字，就是某个具体方案代入这个公式之后算出来的结果。它不是一个绝对值，而是一个相对值，用来和其他方案比较。我们当时同时评估了7个方案，最高分是1,833.56，最低分是420多，差距还是很明显的。3.3 为什么精确到小数点后两位有人可能会问，评分有必要精确到小数点后两位吗？我的回答是：有必要，但不是因为精度本身，而是因为排序需要。当两个方案的评分分别是1,833.56和1,833.12的时候，你确实需要小数点后两位来区分。当然，如果差距很大，小数点后一位就够了。但这里有个坑我要提醒：不要为了精确而精确。评分的输入数据本身就有误差，输出精确到后两位只是一种排序手段，不代表这个方案真的值1,833.56分。我在汇报的时候从来不说"这个方案值1,833分"，而是说"这个方案在当前的评估体系下排第一"。4. 从评分到行动：决策闭环的最后一公里4.1 评分高不等于直接执行拿到评分之后，最容易犯的错误就是"谁分高做谁"。但实际决策中，还要考虑三个额外因素：第一是依赖关系。有些方案必须先做A才能做B，这时候即使B分高，也要先做A。我们当时就遇到这种情况：移动端新用户转化优化分很高，但它依赖一个埋点修复，而埋点修复分不高但必须先行。第二是资源冲突。两个高分方案可能抢同一个开发资源，这时候要么串行要么换人。我们当时的做法是：把方案按资源类型分组，同组内按评分排序，不同组可以并行。第三是战略匹配度。有些方案评分高但和当前战略方向不一致，这时候要慎重。比如当时有个方案是优化一个边缘渠道的转化，评分不低，但那个渠道我们已经在考虑收缩了，所以最后没做。4.2 执行过程中的监控与回滚方案确定之后，执行阶段最重要的是监控和回滚机制。我们当时定了一个规矩：任何优化上线之后，必须监控三个指标——核心转化率、辅助指标、异常报警。核心转化率是判断成败的，辅助指标是判断有没有副作用的，异常报警是兜底的。监控周期是7天，前3天每天看一次，后4天隔天看一次。如果核心转化率没有提升或者辅助指标恶化超过阈值，就回滚。这个阈值我们定的是5%，超过5%的恶化就回滚，不超过就继续观察。这里有个经验：回滚不是失败，不回滚才是。我见过太多团队因为"已经投入了这么多"而不愿意回滚，结果越陷越深。决策闭环的意义就在于，它允许你试错，但要求你及时止损。4.3 闭环的最后一环：复盘与知识沉淀方案执行完之后，一定要做复盘。复盘不是写报告，而是回答三个问题：评分和实际结果匹配吗？（如果评分高但效果差，说明评分模型有问题）执行过程中有没有意外？（如果有，说明评估时漏了因素）这个经验能不能复用？（如果能，就沉淀成规则）我们当时把这次复盘的结论沉淀成了三条规则：第一，移动端新用户的首次转化路径要单独监控；第二，埋点修复类方案要前置评估；第三，评分模型的确定性维度要加入"历史类似方案成功率"作为参考。5. 踩过的坑：那些评分模型不会告诉你的事5.1 数据延迟导致的误判我们当时遇到的一个大坑是数据延迟。移动端的数据上报有延迟，导致我们看到的转化率其实是2小时前的。这个延迟在平时不明显，但在异常排查时会导致误判——你以为问题还在恶化，其实已经恢复了。解决办法是：在评分模型里加入数据新鲜度作为修正因子。数据延迟超过1小时的，评分打9折；超过2小时的，打8折。这个折扣不是随便打的，是根据历史数据里延迟和误判的相关性算出来的。5.2 部门博弈对评分的影响评分模型是客观的，但输入数据可能是主观的。我们当时就遇到这种情况：两个部门对同一个问题的"影响面"给出了不同的估算，一个说影响10万用户，一个说影响3万用户。差距这么大，评分自然差很多。解决办法是：建立数据仲裁机制。所有关键输入数据必须来自统一的数据源，如果数据源本身有争议，就由中立的数据团队裁定。这个机制听起来简单，但推行起来阻力不小，因为有些部门习惯了"数据为我所用"。5.3 评分模型的过拟合风险我们用历史数据拟合权重，这本身没问题，但有个风险是过拟合——模型在历史数据上表现很好，在新数据上表现很差。我们当时的做法是：留出20%的历史数据作为验证集，拟合出来的权重必须在验证集上也表现良好才能用。另外，权重不是一成不变的。我们每个季度会重新拟合一次，确保模型跟得上业务变化。但重新拟合的频率也不能太高，太高会导致评分不稳定，团队无所适从。6. 这套方法能复用到哪些场景6.1 产品迭代优先级排序这套评分逻辑最直接的复用场景就是产品迭代优先级排序。把每个需求当成一个"方案"，用影响面、紧急度、成本、确定性四个维度打分，然后排序。我们后来把这套方法用在了季度规划上，效果比之前拍脑袋好很多。但要注意：产品迭代的"确定性"维度比故障修复更难评估，因为产品需求的效果往往需要更长时间才能验证。我们的做法是：对产品需求，确定性维度参考"历史类似需求的成功率"，而不是拍脑袋给分。6.2 运营活动效果评估运营活动的效果评估也可以用这套逻辑。把每个活动当成一个方案，评估它的影响面（覆盖多少用户）、紧急度（活动窗口期多长）、成本（投入多少资源）、确定性（历史类似活动效果如何），然后决定要不要做、先做哪个。这里有个经验：运营活动的"紧急度"维度要特别小心，因为很多活动是"人为制造紧急"，比如"限时优惠"其实不限时。评估时要区分"真紧急"和"假紧急"，否则会被运营节奏带着走。6.3 技术债务清理技术债务清理是最难排优先级的，因为它的影响面往往不直接体现在业务指标上。我们当时的做法是：把技术债务的"影响面"翻译成"故障风险"，用历史故障数据来估算。比如某个模块过去半年出过3次故障，每次影响X用户，那它的影响面就是3X。这套方法用下来，技术债务的优先级排序清晰了很多，开发团队也更容易接受，因为评分是数据驱动的，不是"谁嗓门大谁先做"。7. 我在实操中总结的几条硬经验第一条经验是：评分模型要简单到能解释清楚。我们一开始设计了一个很复杂的模型，有十几个维度，结果没人能解释清楚为什么A方案比B方案分高。后来砍到四个维度，大家都能理解，推行起来顺畅多了。第二条经验是：评分只是决策的输入，不是决策本身。我见过团队把评分当成圣旨，分高就做分低就不做，结果错过了很多"分不高但必须做"的事。评分是帮你排序的，不是帮你做决定的。第三条经验是：闭环的关键在于反馈。没有反馈的决策是开环的，开环的决策做多了，团队就会失去判断力。我们当时坚持每个方案执行后都做复盘，哪怕复盘结论是"评分模型需要调整"，也是有价值的。第四条经验是：不要追求一次做对。决策闭环是一个迭代过程，第一次评分可能不准，第一次执行可能不顺利，但只要闭环在转，就会越来越准。我们当时的第一个方案评分和实际效果差了30%，但到第五个方案的时候，差距已经缩小到10%以内了。最后再分享一个小技巧：把评分和实际结果的偏差记录下来，每季度看一次偏差趋势。如果偏差在缩小，说明模型在进步；如果偏差在扩大，说明业务变了，模型该调了。这个习惯我们坚持了两年，效果很好。
1. 从20%转化异常说起：一个被低估的决策断点转化率从预期水平掉到20%异常区间，这件事在任何一个做增长或做产品的团队里都算得上"一级警报"。但真正让我决定把这次经历完整写下来的原因，不是异常本身，而是我们复盘时发现：问题根本不在转化环节，而在决策环节。换句话说，数据早就把答案摆在那里了，只是没有人把它翻译成一个可以执行的方案。Coomia DIP 这个项目，就是在这个背景下被推到台前的。DIP 在我的理解里，是一套"决策智能平台"的思路——它不负责帮你拉数据，也不负责帮你做AB实验，它负责的是把散落在各个系统里的信号，收敛成一个带评分、带优先级、带行动建议的方案。标题里那个"1,833.56分方案"，听起来像是一个很精确的数字，实际上它确实精确到小数点后两位，因为这套评分体系本身就是用加权模型算出来的，不是拍脑袋给的。我先说清楚这篇内容适合谁看。如果你正在被"数据一大堆、结论没几个"困扰，如果你所在的团队每次开会都在争论"到底哪个环节出了问题"，如果你手上有一堆指标但不知道怎么排优先级，那这篇内容会对你有用。如果你只是想找一个现成的工具装上去就完事，那可能会失望，因为决策闭环这件事，工具只占三成，剩下七成是流程和判断逻辑。我尽量把这次从异常发现到方案落地的完整链路写清楚，包括我们踩过的坑、走过的弯路、以及最后为什么是1,833.56这个数字而不是别的。文中涉及的具体业务数据我会做脱敏处理，但方法论和计算逻辑会尽量还原。2. 20%转化异常到底异常在哪：先定义问题再谈方案2.1 异常不是"低了"，而是"偏离了基线"很多人一看到转化率下降，第一反应是"赶紧优化落地页"。但我在实际排查中发现，没有基线的异常判断都是耍流氓。我们当时做的第一件事，是把过去90天的转化数据按渠道、按设备、按用户分层拉出来，建立了一个动态基线。具体做法是这样的：以7天为一个滑动窗口，计算每个维度的转化率均值和标准差，然后设定一个阈值——偏离均值超过1.5个标准差就算异常。这个1.5不是随便定的，是我们试了1.0、1.5、2.0之后，发现1.5的误报率和漏报率比较平衡。1.0太敏感，天天报警；2.0太迟钝，等它报警的时候已经晚了。结果一跑出来，问题就很清楚了：整体转化率确实掉到了20%附近，但拆开看，移动端新用户的转化率掉了将近40%，而老用户和桌面端几乎没动。这就意味着，问题不在全局，而在某个特定人群的特定路径上。2.2 为什么20%这个数字容易误导人20%这个数字本身没有意义，有意义的是它和谁比、在什么条件下比。我们当时犯的一个错误，就是一开始把20%当成了"整体转化率"，然后所有人都在讨论整体优化。后来才发现，这个20%其实是某个特定渠道的转化率，而那个渠道的流量占比只有15%。这里我想分享一个经验：看转化率一定要看"加权转化率"和"分层转化率"两个口径。加权转化率是把所有渠道按流量占比加权算出来的，它反映的是大盘；分层转化率是每个渠道单独算的，它反映的是结构。大盘没怎么变但分层变化很大，说明是结构问题；大盘和分层一起变，说明是系统问题。我们当时的情况是：加权转化率从28%掉到了22%，分层里移动端新用户从25%掉到了15%，其他分层基本没变。所以结论很明确——问题集中在移动端新用户的首次转化路径上。2.3 把"异常"翻译成"可决策的问题"发现异常只是第一步，真正难的是把异常翻译成一个可以被决策的问题。我们当时用了三个问题来收敛：这个问题影响多少人？（移动端新用户占比约35%，影响面不小）这个问题影响多少钱？（按客单价和转化损失算，每天大约损失X）这个问题有没有已知的解法？（有，但需要排优先级）这三个问题一问，决策的轮廓就出来了：这不是一个"要不要修"的问题，而是一个"先修哪个"的问题。而"先修哪个"正是 Coomia DIP 要解决的核心问题。3. Coomia DIP 的评分逻辑：1,833.56分是怎么算出来的3.1 评分模型的四个输入维度Coomia DIP 的评分不是单一指标，而是四个维度的加权结果。我把这四个维度拆开讲：第一个维度是影响面（Impact）。这个维度衡量的是问题影响多少用户、多少收入、多少核心指标。我们当时用的计算方式是：影响用户数 × 影响系数 + 影响收入 × 收入系数。影响系数和收入系数是根据业务阶段动态调整的，早期业务收入系数低，成熟业务收入系数高。第二个维度是紧急度（Urgency）。这个维度衡量的是问题随时间恶化的速度。有些问题今天不修明天更严重，有些问题放一周也没事。我们用的判断标准是：如果问题每天恶化超过1%，紧急度就高；如果基本稳定，紧急度就低。第三个维度是解决成本（Effort）。这个维度衡量的是修复这个问题需要多少人天、多少资源、多少协调成本。成本越高，评分越低，因为同样的收益下，成本低的方案应该优先。第四个维度是确定性（Confidence）。这个维度衡量的是"我们有多确定这个方案能解决问题"。确定性低的方案，即使影响面大，也要打折，因为可能白干。3.2 加权公式与参数选择四个维度确定之后，就是加权求和。我们用的公式大致是这样的：Score = (Impact × 0.4 + Urgency × 0.25 + Confidence × 0.2 - Effort × 0.15) × 100这个权重不是拍脑袋定的，是我们用历史数据回测出来的。具体做法是：把过去半年做过的所有优化项拉出来，看哪些真正带来了提升，然后用逻辑回归去拟合权重。拟合出来的结果和我们的直觉基本一致——影响面最重要，紧急度次之，确定性再次，成本是减分项。1,833.56这个数字，就是某个具体方案代入这个公式之后算出来的结果。它不是一个绝对值，而是一个相对值，用来和其他方案比较。我们当时同时评估了7个方案，最高分是1,833.56，最低分是420多，差距还是很明显的。3.3 为什么精确到小数点后两位有人可能会问，评分有必要精确到小数点后两位吗？我的回答是：有必要，但不是因为精度本身，而是因为排序需要。当两个方案的评分分别是1,833.56和1,833.12的时候，你确实需要小数点后两位来区分。当然，如果差距很大，小数点后一位就够了。但这里有个坑我要提醒：不要为了精确而精确。评分的输入数据本身就有误差，输出精确到后两位只是一种排序手段，不代表这个方案真的值1,833.56分。我在汇报的时候从来不说"这个方案值1,833分"，而是说"这个方案在当前的评估体系下排第一"。4. 从评分到行动：决策闭环的最后一公里4.1 评分高不等于直接执行拿到评分之后，最容易犯的错误就是"谁分高做谁"。但实际决策中，还要考虑三个额外因素：第一是依赖关系。有些方案必须先做A才能做B，这时候即使B分高，也要先做A。我们当时就遇到这种情况：移动端新用户转化优化分很高，但它依赖一个埋点修复，而埋点修复分不高但必须先行。第二是资源冲突。两个高分方案可能抢同一个开发资源，这时候要么串行要么换人。我们当时的做法是：把方案按资源类型分组，同组内按评分排序，不同组可以并行。第三是战略匹配度。有些方案评分高但和当前战略方向不一致，这时候要慎重。比如当时有个方案是优化一个边缘渠道的转化，评分不低，但那个渠道我们已经在考虑收缩了，所以最后没做。4.2 执行过程中的监控与回滚方案确定之后，执行阶段最重要的是监控和回滚机制。我们当时定了一个规矩：任何优化上线之后，必须监控三个指标——核心转化率、辅助指标、异常报警。核心转化率是判断成败的，辅助指标是判断有没有副作用的，异常报警是兜底的。监控周期是7天，前3天每天看一次，后4天隔天看一次。如果核心转化率没有提升或者辅助指标恶化超过阈值，就回滚。这个阈值我们定的是5%，超过5%的恶化就回滚，不超过就继续观察。这里有个经验：回滚不是失败，不回滚才是。我见过太多团队因为"已经投入了这么多"而不愿意回滚，结果越陷越深。决策闭环的意义就在于，它允许你试错，但要求你及时止损。4.3 闭环的最后一环：复盘与知识沉淀方案执行完之后，一定要做复盘。复盘不是写报告，而是回答三个问题：评分和实际结果匹配吗？（如果评分高但效果差，说明评分模型有问题）执行过程中有没有意外？（如果有，说明评估时漏了因素）这个经验能不能复用？（如果能，就沉淀成规则）我们当时把这次复盘的结论沉淀成了三条规则：第一，移动端新用户的首次转化路径要单独监控；第二，埋点修复类方案要前置评估；第三，评分模型的确定性维度要加入"历史类似方案成功率"作为参考。5. 踩过的坑：那些评分模型不会告诉你的事5.1 数据延迟导致的误判我们当时遇到的一个大坑是数据延迟。移动端的数据上报有延迟，导致我们看到的转化率其实是2小时前的。这个延迟在平时不明显，但在异常排查时会导致误判——你以为问题还在恶化，其实已经恢复了。解决办法是：在评分模型里加入数据新鲜度作为修正因子。数据延迟超过1小时的，评分打9折；超过2小时的，打8折。这个折扣不是随便打的，是根据历史数据里延迟和误判的相关性算出来的。5.2 部门博弈对评分的影响评分模型是客观的，但输入数据可能是主观的。我们当时就遇到这种情况：两个部门对同一个问题的"影响面"给出了不同的估算，一个说影响10万用户，一个说影响3万用户。差距这么大，评分自然差很多。解决办法是：建立数据仲裁机制。所有关键输入数据必须来自统一的数据源，如果数据源本身有争议，就由中立的数据团队裁定。这个机制听起来简单，但推行起来阻力不小，因为有些部门习惯了"数据为我所用"。5.3 评分模型的过拟合风险我们用历史数据拟合权重，这本身没问题，但有个风险是过拟合——模型在历史数据上表现很好，在新数据上表现很差。我们当时的做法是：留出20%的历史数据作为验证集，拟合出来的权重必须在验证集上也表现良好才能用。另外，权重不是一成不变的。我们每个季度会重新拟合一次，确保模型跟得上业务变化。但重新拟合的频率也不能太高，太高会导致评分不稳定，团队无所适从。6. 这套方法能复用到哪些场景6.1 产品迭代优先级排序这套评分逻辑最直接的复用场景就是产品迭代优先级排序。把每个需求当成一个"方案"，用影响面、紧急度、成本、确定性四个维度打分，然后排序。我们后来把这套方法用在了季度规划上，效果比之前拍脑袋好很多。但要注意：产品迭代的"确定性"维度比故障修复更难评估，因为产品需求的效果往往需要更长时间才能验证。我们的做法是：对产品需求，确定性维度参考"历史类似需求的成功率"，而不是拍脑袋给分。6.2 运营活动效果评估运营活动的效果评估也可以用这套逻辑。把每个活动当成一个方案，评估它的影响面（覆盖多少用户）、紧急度（活动窗口期多长）、成本（投入多少资源）、确定性（历史类似活动效果如何），然后决定要不要做、先做哪个。这里有个经验：运营活动的"紧急度"维度要特别小心，因为很多活动是"人为制造紧急"，比如"限时优惠"其实不限时。评估时要区分"真紧急"和"假紧急"，否则会被运营节奏带着走。6.3 技术债务清理技术债务清理是最难排优先级的，因为它的影响面往往不直接体现在业务指标上。我们当时的做法是：把技术债务的"影响面"翻译成"故障风险"，用历史故障数据来估算。比如某个模块过去半年出过3次故障，每次影响X用户，那它的影响面就是3X。这套方法用下来，技术债务的优先级排序清晰了很多，开发团队也更容易接受，因为评分是数据驱动的，不是"谁嗓门大谁先做"。7. 我在实操中总结的几条硬经验第一条经验是：评分模型要简单到能解释清楚。我们一开始设计了一个很复杂的模型，有十几个维度，结果没人能解释清楚为什么A方案比B方案分高。后来砍到四个维度，大家都能理解，推行起来顺畅多了。第二条经验是：评分只是决策的输入，不是决策本身。我见过团队把评分当成圣旨，分高就做分低就不做，结果错过了很多"分不高但必须做"的事。评分是帮你排序的，不是帮你做决定的。第三条经验是：闭环的关键在于反馈。没有反馈的决策是开环的，开环的决策做多了，团队就会失去判断力。我们当时坚持每个方案执行后都做复盘，哪怕复盘结论是"评分模型需要调整"，也是有价值的。第四条经验是：不要追求一次做对。决策闭环是一个迭代过程，第一次评分可能不准，第一次执行可能不顺利，但只要闭环在转，就会越来越准。我们当时的第一个方案评分和实际效果差了30%，但到第五个方案的时候，差距已经缩小到10%以内了。最后再分享一个小技巧：把评分和实际结果的偏差记录下来，每季度看一次偏差趋势。如果偏差在缩小，说明模型在进步；如果偏差在扩大，说明业务变了，模型该调了。这个习惯我们坚持了两年，效果很好。