AI 在产品增长黑客中的应用：更智能、更可扩展的 PLG

自助增长里真正缺的不是模型

跑通 PLG 的团队通常已经有注册、激活、付费墙、试用到期这几段流程，也有埋点。这时候引入机器学习，收益不在于预测得更准，而在于把销售、客服、增长这三种稀缺人力按概率重新排一遍队。

模型的价值等于排序质量乘以你能对排序施加的动作量。销售一个月能跟进 3000 个账号、而新账号一共只有 3000 个，排序不值钱；容量是 300、账号是 8000，排序就是全部。先量容量，再谈模型。这条乘法关系还解释了一个常见的资源错配：团队把预算全砸在模型上，却没人去谈销售能不能多接几个账号。可施加的动作量本身是可以撬动的变量：加一个人、把跟进流程标准化、给销售配好开场话术，都能直接放大排序的价值。当容量和账号数接近时，与其把 AUC 从 0.80 抠到 0.83，不如先把容量从 300 扩到 500，后者对最终付费数的影响往往大得多，成本却未必更高。

这条乘法关系可以直接算成一笔账。假设条件：每月新增自助工作区 8000 个，自然付费转化率 4%，即 320 个账号最终付费；销售 6 人，每人每月认真跟进 60 个，总容量 360 个。不排序、随机抽 360 个跟进，其中天然会付费的约 14 个；销售介入把这批账号转化率从 4% 抬到 7%，增量约 360 × 3% ≈ 11 个。模型排序后取前 360 名，假设模型把 320 个付费账号中的 25% 装进了这份名单，名单内自然转化率为 80 ÷ 360 ≈ 22%，销售介入抬到 32%，增量为 360 × 10% ≈ 36 个。差值是每月 25 个付费账号，年化 300 个；ACV 按 1.2 万元计，模型每年多带来约 360 万元 ARR。

这笔账最脆弱的是那两个提升幅度假设（3 个百分点与 10 个百分点），它们必须靠留出对照组实测，不能拍脑袋。值得把这两个假设再往下压一压看。如果销售介入的提升不是 10 个百分点而只有 5 个，名单内的增量就从 36 个掉到约 18 个，年化收益直接腰斩；如果模型只装进了 15% 而不是 25% 的付费账号，前 360 名的自然转化率会从 22% 降到 13% 上下，整笔账可能就不成立了。这说明真正决定成败的不是模型精度那零点几个 AUC，而是两个乘数：销售能把转化抬多高，以及模型能把多少真付费账号塞进容量之内。先分别给这两个数做区间估计，再决定要不要投人做模型，比一上来就比算法靠谱。

什么样的账号才配叫 PQL

PQL 的定义权不在数据团队，在销售。销售拒绝跟进的那一刻，标签就失效了。可行的做法是请两位销售人工标注最近 3 个月的 400 个账号，只回答一个问题：这个账号当时值不值得打电话。用这 400 条做第一版标签，比拿“是否付费”当标签更贴近真实决策。拿付费当标签有个隐患：付费本身受销售介入影响，模型会把“被销售跟进过”学成特征，然后向你推荐一批销售已经跟进过的账号。

标注还有个时效问题常被忽略：三个月前值得打的账号，和今天值得打的账号，判断标准可能已经变了，因为产品变了、定价变了、理想客户画像也在漂。所以这 400 条标签不是标一次就一劳永逸，而应该每季度补标一批，让标签跟着销售当下的判断走。一个粗略的下限是：低于 300 条人工标签时，模型几乎不可能稳定地跑赢一套拍脑袋的加权规则，这时候把人力花在补标签上，比花在调模型上划算得多。

标签的第二个来源比专门组织的标注更持久：销售在名单上的每一次操作。名单界面上只需要三个按钮，"已联系""不值得打""联系不上"，每点一次就是一条带上下文的标签，成本为零，而且天然跟着当下的判断走。三个月下来这条通道攒下的标签量，通常远超一次集中标注。要注意三个按钮的语义要分开存：不值得打是负样本，联系不上不是，它只说明联系方式有问题；混在一起，模型会把"留了公司邮箱但没留电话"学成不值得跟进的特征。

把付费当标签的问题还有一层时间上的。付费发生在注册后几十天，等标签成熟才能训练，这意味着一次产品改版之后要等一到两个月才有新标签可用。销售的"值不值得打"当天就有，用它做主标签、付费做校验，模型的更新周期能从季度压到月。

阈值、分数与销售看到的东西

分数是连续的，容量是离散的。正确顺序是先问销售本周能吃下多少个，再把阈值倒推成名额。定成固定分数（比如 0.7 以上都推给销售）的团队，会在产品发版后遇到分数整体漂移，名单一夜之间从 300 涨到 900，销售当周就放弃使用。按名额切分还有一个副作用需要接受：模型好不好，看的是前 N 名里的命中率，而不是整体 AUC——AUC 从 0.78 提到 0.83 却对前 360 名毫无改善，是常见情况。

分数漂移不是偶发事故，而是必然。每次产品改版都会改变用户行为的分布，特征的取值范围跟着变，同一个绝对分数在两个月后代表的已经不是同一类账号。按名额切分之所以更稳，正是因为它对整体平移不敏感：不管分数整体涨了还是跌了，前 360 名永远是相对最像付费的那批。真要用绝对阈值，就得配一套监控：每周看分数分布的均值和分位数有没有跳变，跳了就重新校准，否则销售会先于你发现名单不对劲，然后彻底不再打开它。

名额定下来之后，还剩一个问题：销售拿到手的到底该是什么。给销售一个 0.83，他不知道该说什么；给他三条证据（本周新增 9 个席位、两次访问了权限管理页、导出接口调用了 140 次），他能直接写进开场白。分数负责排序，证据负责让人相信排序。实现上不需要复杂的可解释性框架，把贡献最高的 3 个特征映射成人话模板就够用，销售对模型的信任度几乎全部由这三行字决定。

有一点要提醒：贡献最高的三个特征是相关性排序，不是因果解释，别把它们当成"这个账号会付费的原因"写进话术。更稳妥的措辞是陈述客观事实——新增了几个席位、访问过哪个页面、调了多少次接口——把"所以他很可能要买"这层推断留给销售自己去下。一旦模板里写死了因果断言，遇到一个明显的反例，销售会连人带模型一起不信。

用什么模型：这类问题轮不到深度学习

PQL 打分的输入是几十个账号级的行为特征，样本量是每月几千个账号、总共几万条。这个规模下逻辑回归和梯度提升树是合理的上限，再复杂的模型不会更准，只会更难解释、更难回放。逻辑回归的好处是每个特征一个系数，销售问"为什么这个账号排第 17"时，答案能当场算给他看；梯度提升树在前 N 名命中率上通常好一些，代价是解释要靠事后归因。两者都能在一台普通机器上几分钟训完，不需要 GPU，也不需要专门的机器学习平台。团队如果为这件事去采购一套 MLOps 工具，多半是被供应商说服了，不是被问题说服了。

大语言模型在这条流程里有位置，但不在打分这一环。它适合做的是把非结构化信息变成特征：把用户注册时填的"公司描述"归成行业类别，把工单文本归成问题类型，把销售通话记录提炼成"提到了预算""提到了竞品"这样的标签。这些特征再喂给表格模型去打分。反过来让大语言模型直接判断"这个账号该不该打"，会遇到三个问题：每次判断的成本比表格模型高几个数量级，结果不可复现，无法用前 N 名命中率去系统评估。把它放在特征生产这一层，既用上了它读文本的能力，又避开了它做排序的短板。

还有一类问题连表格模型都不需要：只有一两个强信号的场景。席位从 3 涨到 12 这种事，一条规则就够。判断该不该上模型的实际标准是特征数：超过 10 个互相有交互的弱信号，人手调不出稳定权重，才轮到模型；低于这个数，规则更快、更可审计，出了问题周二下午就能改。

引导个性化的分寸

新手引导做成上百条个性化路径，维护成本会吃掉全部收益。可控的做法是把分叉压到 3 条以内，且分叉依据必须是用户自己填过或做过的：注册时选的角色、邀请没邀请同事、有没有连数据源。模型在这里的位置不是决定给谁看什么，而是决定顺序：把最可能被这类账号采用的那一步提到第一屏。判定标准也只有一个：第 7 天的激活率，不是首屏点击率。

为什么只放三条、且必须基于用户自己填过或做过的东西？因为个性化的收益会被两样成本吃掉：分叉越多，维护和回归测试的组合就越爆炸；依据越隐晦，猜错时对用户的冒犯就越大。基于显式动作的三条分叉，恰好落在收益还在、成本可控的那一段。用第 7 天激活率而不是首屏点击来判定，是因为点击只证明文案吸引人，激活才证明你把对的那一步排到了对的人面前——前者可以靠标题党刷出来，后者骗不了人。

个性化推进到某一步就会开始让人不适，这条界限值得单独划清，而它不在数据来源，在用户能不能自己解释。系统说"你还没连数据源，先连这个"，用户认；系统说"看起来你在评估我们和某竞品"，用户会退出。安全的一侧是用户在本产品内的显式动作；危险的一侧是跨站行为、由邮箱域名推断出的公司规模，以及任何暗示你在观察他犹豫的措辞。文案上避开"我们注意到你……"这种开头，改成陈述事实加下一步。

产品内答疑

产品内答疑通常有两条技术路线。一条是检索加生成：把帮助中心切块、做向量索引，用户提问时检索出 5 段再让模型改写，它的失败模式是文档本身过期，模型会用流畅的语气复述错误答案。另一条是意图分类加固定回复：把最高频的 30 个问题手写答案，模型只负责判断问的是哪一个，判不准就转人工，准确率天花板更低，但错得可控。前 20 个高频问题通常覆盖 55% 到 65% 的会话量，先把这部分做成第二条路线，剩下的长尾再交给第一条。

两条路线其实最好叠着用，而不是二选一。前台先跑意图分类，命中那 30 个高频问题就走人工审过的固定答案，命中不了再降级到检索加生成，检索的置信度也不够就直接转人工。这样把错得可控留给高频、高风险的问题，把覆盖面广留给长尾。上线前一定要先攒一份至少 200 条真实问题的评测集，人工标好正确答案，每次改动都拿它回归，否则你根本不知道一次 prompt 调整到底是修好了，还是又弄坏了另一批。

答疑同样可以算一笔账。每月人工工单 4000 张，平均处理 11 分钟，客服时薪按 80 元计，人力成本约 4000 × 11 ÷ 60 × 80 ≈ 5.9 万元；检索加生成方案覆盖 40% 的会话，其中 70% 真正解决了问题，减少工单 4000 × 40% × 70% ≈ 1120 张，省下约 1.6 万元。模型侧的开销是每月 1600 万 token，加上向量库和文档同步的维护工时，合计约 6000 元，净省 1 万元每月，同时把客服从重复问题里挪出来做别的事。工单量低于 1500 张时这笔账就不成立，别照抄。

这里最容易被做假的指标是拦截率。把"用户看完文章后没有再点提交工单"记成拦截成功，这个数字可以轻松做到 70%，因为放弃和满意在日志里长得一模一样。替换成两个更难作弊的口径：会话结束后 24 小时内，同一用户是否就同一主题开出工单；以及人工工单总量的绝对值变化。如果拦截率涨了 20 个百分点而工单绝对量没降，那是用户被劝退了，不是问题被解决了。还有一种更隐蔽的做法：把答疑入口摆得很显眼、把工单入口藏得很深，拦截率照样好看，但你只是在制造摩擦，代价会滞后地落到续费和口碑上。所以看拦截率时，永远要同时盯住工单的绝对量和一个独立的满意度信号；任何单拎出来的拦截率，都可以被产品布局悄悄做出来。

什么归规则，什么归模型

试用到期是一个日历事件，不是概率问题。谁在第 12 天、谁在第 14 天，数据库里写得清清楚楚，用模型去预测只会引入噪声。模型在这一段能做的是另一件事：判断这个账号到期时更可能卡在哪一步——没导入数据、没邀请同事、还是没跑通第一个工作流——再决定延期提醒里放哪一段内容。触发时机归规则，内容选择归模型，这条分工在整个 PLG 流程里都成立。把它再说透一点：凡是数据库里写着确定答案的事（到期日、席位数、是否付费）都该由规则来判，用模型去预测一个已知的事实只会平白引入误差；凡是要在多个模糊选项里挑一个最合适的（推哪篇文档、发哪段文案、先引导哪一步）才轮到模型上场。团队里一半关于该不该用模型的争论，套这条线进去就能当场了结。

这条线落到具体场景上，大致是这样一张表。

一条经验：能用不超过 5 个条件写清楚的判断，就不要用模型。规则可以在周二下午改完上线，模型不行。

付费墙卡在哪一格，同样不由模型说了算。免费额度定在 3 个席位还是 5 个席位，是定价决策，需要跨群体的价格弹性数据，而模型手里只有已经通过这道墙的人留下的行为；用留存模型去反推额度，会得到一个当期转化最高、12 个月留存最差的答案。能交给模型的是提醒节奏：额度还剩 20% 时提示，比用满之后再拦少激怒一批人——位置由定价决定，节奏可以由数据决定。这里有个反直觉的地方：额度墙触发得早一点，转化反而可能更好。用满之后才弹窗，用户是在被打断、被拦下的负面情绪里做决定；剩 20% 时提示，用户还在顺畅使用、正体会到价值，这时给他一条升级路径，接受度明显更高。模型能学的就是这个提示点对不同使用节奏的账号该提前到什么程度：高频账号可能剩 30% 就该提醒，低频账号拖到 10% 也不迟。但记住，这只是在挪提醒的时机，额度设几个席位仍然是定价的事，模型不该也无权替它决定。

扩容与流失是两回事

扩容看的是边界被撑破：席位接近上限、API 调用触到配额、开始有人查阅计费页面、新部门的邮箱后缀第一次出现。这类信号稀疏、突发、与时间强相关，用近 14 天的变化率比用累计值有用。流失看的是常规行为的衰减：周活跃席位连续三周下滑、核心动作从每周 12 次掉到 3 次、管理员账号 30 天未登录。它平缓、连续，用滑动窗口的斜率更稳。同一套特征同时喂这两个任务，两边都会做不好。具体到特征工程，扩容更吃变化率和首次出现这类突变型信号：把近 14 天的席位增速、配额触顶次数、计费页访问做成斜率或计数，比用累计总量灵敏得多；流失正相反，要的是平滑趋势，用 4 到 8 周的滑动窗口去看核心动作的衰减斜率，短窗口只会被一次假期或一次发版的波动带偏。两个任务连特征的时间尺度都不一样，硬塞进一个模型，等于逼它同时学两种互相打架的时间观。

流失还有一个更根本的难点：预测出来往往没有动作可做。模型提前 45 天告诉你这个账号会走，团队能做什么？多数情况下只剩发一封邮件和排一次客户成功会议，而这两件事本来就按合同周期在做，预测准确率再高也换不来新动作。值得投入的是把预测切成有对应动作的子类：因为没接完数据源而流失，对应实施支持；因为主推动者离职而流失，对应补第二个管理员；因为价格而流失，对应降配方案；没有对应动作的那一类，别预测，省下人力。换个角度说，流失预测的价值不由准确率决定，而由预测出来之后有没有一个和它一一对应、且平时不会默认执行的动作决定。如果某一类流失你唯一能做的还是那封本来就会发的邮件，那这个预测的边际价值接近零，做得再准也一样。先把手上真正能打的牌列清楚，再回头决定哪几类流失值得预测，顺序反过来，就会做出一堆没人接得住的漂亮预测。

数据地基、冷启动与模型拆分

模型吃的是事件表。事件名在半年里改过三次、同一个动作在 Web 端和移动端叫不同名字、后端补发的事件时间戳用的是写入时间而非发生时间，这三件事任意一件成立，前 12 周的训练数据就不可信。先做一件不性感的事：挑出与付费相关的 20 个事件，锁死命名和字段，写进代码评审清单，做完这一步再训练，比调参数换算法的收益大一个量级。锁命名之外，还有两件容易埋雷的事：补发和回填的事件，务必用它真正发生的时间而不是写入库的时间，否则模型会在训练时偷看到未来，一到线上实时推理就打回原形；Web 端和移动端、新旧版本之间的同名不同义，最好在入库时就归一化，别指望在特征层临时打补丁。数据这一层每省一分力气，后面都会在线下很好、线上崩掉的复盘里连本带利还回来。

地基没打好、标签还不够时，前六个月也得先跑起来。用加权规则打分开局：席位增长 30 分、邀请同事 20 分、连接数据源 25 分、访问定价页 15 分、管理员周活 10 分，权重由销售拍板，不装作科学。它的作用有两个：立刻给销售一份可用名单，以及在跑的过程中攒下带反馈的标签。跑满 6 个月、积累到 800 条以上人工标注之后，再用模型和这套规则做离线对比；模型在前 360 名的命中率打不过规则，就继续用规则。

真到了上模型的时候，也别把三件事塞进同一个。PQL 打分、引导个性化、扩容预测，这三件事的正样本定义、时间窗口和更新频率都不同：PQL 看注册后 30 天，引导看前 7 天，扩容看签约后 90 天。合成一个多目标模型之后，任何一项的改善都会以其余两项为代价，排查时又看不出是谁拖累了谁。三个小模型加一张共享特征表，训练成本高不了多少，出问题能单独回滚；人手紧张就先做 PQL，剩下两个用规则顶着。

共享特征表的具体形态值得写清楚，因为它是三个模型之间唯一的公共资产。表的粒度是"账号 × 日期"，每天为每个活跃账号生成一行，列分四类：静态属性（注册渠道、自填角色、公司邮箱域名类型）、累计量（总席位、总文档数、接入的数据源数）、近期窗口量（近 7 天与近 14 天的核心动作次数、席位增量、计费页访问次数）、首次事件时间（首次邀请、首次导出、首次访问定价页距今天数）。累计量给流失模型用，窗口量给扩容模型用，首次事件时间对 PQL 最有信息量，因为它编码的是账号的成熟阶段。

三个模型各取所需，但列的定义只有一份，这是共享的意义。事件名改了，只改特征表的生成逻辑，三个模型不用动。反过来，如果每个模型各自从原始事件表算特征，同一个"核心动作次数"会在三处有三种算法，排查线上问题时永远对不上。特征表每天跑一次，按日期分区存下来，还有一个附带好处：训练时能严格按日期取特征，避免用到当天之后才发生的事件，这是线下线上不一致最常见的根源。

表的列数控制在 40 到 60 个之间。少了不够用，多了维护不动，而且每加一列都要回答"这一列从哪个事件算、事件名锁死了没有"，这个问题本身就是筛子。

用哪些数据：账号级与个人级的分界

PLG 产品的行为数据大多在账号层面，但很多信号落在具体的人身上：谁邀请了同事、哪个管理员访问了定价页。把这些用于打分在多数场景下没有问题，因为它们是用户在产品内的显式动作，也是服务的一部分；一旦名单给到销售，销售看到的就是"某某公司的某某在看定价页"，这已经从产品分析滑向了对个人的观察。分界线可以画在这里：账号级聚合并不意味着可以任意使用。使用席位数、数据源数或周活跃席位前，仍需确认处理目的、访问权限和适用的数据保护要求。；个人级的动作用于打分可以，展示给销售时要聚合成账号级的陈述，"该工作区本周有成员访问过定价页"，而不是"张三周二下午看了定价页"。

第二条线在数据来源。产品内的行为是用户知道你会记录的；从第三方数据源补充的公司规模、融资信息、技术栈，用户不知道也没同意，用在打分里的法律边界随地区差异很大，用在销售话术里则几乎一定会引起反感。稳妥的做法是第三方数据只进模型不进界面，并在隐私政策里写明用途。

第三条线是留存期限。行为特征只需要近 90 天的窗口，训练集也不需要保留两年前的原始事件。给特征表设一个自动过期，既降低了合规风险，也逼着团队不去依赖那些早就漂移的旧数据。这三条线画清楚之后，法务审核通常会快很多，因为他们要看的不再是"你们用了什么数据"，而是"你们的边界写在哪里"。

让几路自动化彼此知道对方

名单推给销售之后，产品侧要不要停掉自助流程？默认继续跑的结果是同一个用户在 48 小时内收到自动升级邮件、产品内弹窗和一通电话。规则可以很简单：账号进入销售名单后，自动化营销消息静默 10 天，产品内引导保留，促销弹窗关掉。这条规则救回的转化，通常比模型多提升两个百分点带来的还多，而它一行 SQL 就能写完。这类消息节流规则性价比高得离谱，是因为它修的是一个纯粹的协同 bug，而不是预测问题：同一个账号被自动化营销、产品内引导和销售电话同时轰炸，转化不升反降，靠的不是更聪明的模型，而是让几路触达彼此知道对方的存在。在上模型之前，先把这类互相打架的自动化理顺，往往能白捡两三个百分点，成本几乎为零。

还有一路自动化是模型喂给自己的回音壁。模型推荐前 360 名，销售只跟进这 360 名，只有这 360 名的结果被记录，下一轮训练数据全部来自这 360 名，三个月后模型会认定名单之外没有好账号，而这个结论无法被证伪。解法是留一条随机通道：每月从阈值以下随机抽 5% 的账号照常跟进，专门给模型提供反例。这 5% 短期看是浪费，实际上是模型唯一的纠偏来源，同一条逻辑适用于引导个性化和答疑推荐。这条随机通道还有个常被忽略的用处：它是你唯一能诚实回答模型到底比不做强多少的地方。名单内的账号回答不了如果不跟进会怎样，只有那 5% 的随机样本能给出干净的反事实基线。所以别把它当纯成本，它同时是纠偏来源和度量标尺，砍掉它，你会一次性失去发现盲区和证明价值这两件事的能力。

排期、上线与验证

一个季度的排期可以这样排：第 1 至 3 周锁事件命名、补齐席位与配额字段；第 4 至 6 周上线加权规则打分，销售端展示三条证据，同时开随机通道；第 7 至 9 周做人工标注，目标 600 条，并把答疑的高频 30 问写完；第 10 至 12 周训练第一版模型，与规则做离线对比，只在前 360 名命中率上判胜负。第二个季度再谈扩容预测。把顺序倒过来先做模型的团队，通常在第 8 周发现数据不能用。这个排期背后有一条暗线：每一周的产出都不依赖后面几周成立。锁完事件命名，就算模型永远不上线，加权规则也能立刻给销售一份名单；随机通道从第一天就开，等模型训练好时反例已经攒了一个季度，不用再等。反过来先训模型的团队，往往是先花六周调 AUC，到第 8 周想接进流程时，才发现事件名改过三次、时间戳用的是写入时间，整批训练数据作废，六周白干。让每一步都能独立交付价值，才是这套排期真正的用意，而不是把它当成一张必须走完才见效的甘特图。

上线第一个月几乎一定会发生三件事。销售会挑出两三个明显不合理的账号，据此判定整套系统不可信——准备好按账号回放特征值，当场解释清楚它为什么排在第 17 名。名单会集中在某一个行业或某一种注册来源，因为历史标签本身带偏——把名单的来源分布与整体新增分布比一比，差距超过两倍就要动手修正。还有人会提议把分数直接接进营销自动化去群发邮件——先别接，等对照组数据出来再说，否则回音壁会提前半年到来。这三件事有个共同点：它们都是社会问题，不是技术问题。销售的信任、名单的偏斜、把分数一键群发的冲动，靠再训练一版模型都解决不了，只能靠可回放的解释、对分布的持续监控和一条守住的对照组纪律。第一个月真正在检验的，不是模型准不准，而是这套流程有没有人愿意用、敢不敢信、扛不扛得住内部要它立刻见效的压力。

盯住的数字只要四个：名单命中率，即前 N 名中最终付费的比例；销售对名单的采纳率，推了多少、真打了多少，低于 60% 说明证据不够；激活率的对照差值，个性化组与对照组在第 7 天的差；以及人工工单的绝对量。这四个数字里没有 AUC，也没有模型调用次数——前者与业务动作的关系太松，后者是成本而不是成果。它们之间还有一层因果顺序，值得连起来看：采纳率是命中率的前置条件，证据不够，销售不打，再准的名单也变不成收入；命中率又是留存差值的前置条件，名单不准，销售把精力浪费在不会付费的账号上，对照实验自然测不出提升。所以真出问题时，别一上来就怪模型，先沿着这条链往回查，多半会在采纳率或证据质量这一环卡住，而不是在算法上。工单绝对量是唯一和前三个脱钩的独立口径，专门用来给答疑那条线做体检，别把它和 PQL 的数字混在一张看板上比较。

模型上线后要盯的不只是那四个业务数字，还有两条运行状态的曲线。第一条是特征分布：每周比较各主要特征的均值和分位数与训练时的差异，某个特征突然整体平移，多半是埋点改了或产品发版了，要在销售发现名单不对之前先发现。第二条是前 N 名的构成：按行业、注册渠道、公司规模看名单的分布，和整体新增的分布比，比例差距持续扩大就是偏斜在加深。这两条曲线不需要仪表盘，一封每周自动发出的邮件、五六张图就够，关键是有人看，而且看到异常有权把名单退回到加权规则。

重训的节奏按标签积累来定，不按日历。攒够 200 条新标签就重训一次并做离线对比，前 N 名命中率没有下降才替换线上版本。固定按月重训的团队常遇到的情况是，新版本命中率还不如旧版本，却因为"到时间了"被推上线。命中率是唯一的替换标准，日期不是。

要证明这套东西真的有用，就得留出对照。每月 360 个名单，抽 20% 做留出组、不给销售跟进，即 72 个；基线转化按 22% 算，期望提升到 32%，要在 80% 功效下稳定检出这 10 个百分点，每组需要约 300 个样本，也就是要攒满 4 个月才能给出结论。想更快只有两条路：把留出组扩到 30%，或者只在最高分的前 120 名上做对比——那一段的提升幅度更大，需要的样本更少。这两条捷径各有代价，得心里有数。留出组扩到 30% 意味着每月多放走一批本可以跟进的账号，短期收入会肉眼可见地少一块，换来的是早一两个月拿到结论；只看前 120 名则牺牲了对名单中段的判断力，你会知道最尖那一撮很值，却说不清 120 到 360 名这一段模型有没有用，而这一段恰恰是容量扩张后最需要看清的地方。选哪条，取决于你现在最缺的是时间还是全景——先算这道题再排期，能省掉一次"做了三个月说不清有没有用"的复盘会。

上线之前，团队还应该互相把几个问题问清楚。销售容量是多少，谁能给出准确数字？ 拿不到这个数就没法定阈值，它决定了模型该优化前 200 名还是前 2000 名，这两件事的最优解不一样，用错了目标，模型越准反而越浪费。标签是谁标的，标了多少条？ 少于 300 条人工标签时，模型的表现无法与加权规则拉开距离，先补标签。随机对照组留了吗？ 没有对照组，所有提升幅度都是估出来的，前面那笔 360 万元的账也就无法验证。答疑答错了会怎样？ 计费、权限、数据删除这三类问题答错的代价远高于其他，应当强制转人工，不进入生成路径。模型下线一周，业务会停吗？ 如果会停，说明规则兜底缺失，任何模型都该有一条降级路径，退回加权规则继续出名单。这个功能三个月后谁来维护？ 特征会漂移、事件会改名、销售会换人，找不到长期负责人的模型项目，第二个季度就会烂在那里，最后没人敢删、也没人敢信。