用 AI 做产品驱动增长（PLG）：先算销售容量，再谈模型

上了机器学习，AUC 也调到了 0.8（AUC 衡量模型把会付费和不会付费的账号分开的能力，满分为 1），付费却没怎么涨。问题常常不在模型准不准，而在模型算出来的排序，你到底有没有人力去执行。

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

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

模型的价值等于排序质量乘以你能对排序施加的动作量。销售一个月能跟进 3000 个账号、而新账号一共只有 3000 个，排序不值钱；容量是 300、账号是 8000，排序就是全部。先量容量，再谈模型。

反过来，容量本身也能撬动：加一个人、把跟进流程标准化、给销售配好开场话术，都会直接放大排序的价值。容量和账号数接近时，先把容量从 300 扩到 500，往往比把 AUC 从 0.80 抠到 0.83 更划算。

这条乘法关系可以直接算成一笔账。假设条件：每月新增自助工作区 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% 上下，整笔账可能就不成立了。

所以先给这两个数各做一个区间估计，再决定要不要投人做模型。

很多团队的第一反应是：与其花一个季度做打分，不如让销售按“席位数不少于 5 个，或访问过定价页”两条规则直接跟进，其余账号全部交给自助流程。新增账号每月不到 2000 个、销售不超过 3 人时，这条路几乎总是更划算。

粗算一下（示意）：2000 个账号、容量 180 个，就算模型把名单内的自然转化率从 4% 抬到 15%，销售介入在这 180 个账号上多带来的也只是几个到十来个付费账号，撑不起一个数据工程师的工时。

规则路线撑不住的条件也很清楚：账号数是销售容量的 10 倍以上，而且两三条强信号规则已经挑不满名单。到了这一步，排序才开始值钱。

二、什么样的账号才配叫 PQL

PQL 的定义权不在数据团队，在销售。销售拒绝跟进的那一刻，标签就失效了。可行的做法是请两位销售人工标注最近 3 个月的 400 个账号，只回答一个问题：这个账号当时值不值得打电话。用这 400 条做第一版标签，比拿“是否付费”当标签更贴近真实决策。

拿付费当标签有个隐患：付费本身受销售介入影响，模型会把“被销售跟进过”学成特征，然后向你推荐一批销售已经跟进过的账号。

标注还有个时效问题常被忽略：三个月前值得打的账号，和今天值得打的账号，判断标准可能已经变了，因为产品变了、定价变了、理想客户画像也在漂。所以这 400 条标签不是标一次就一劳永逸，而应该每季度补标一批，让标签跟着销售当下的判断走。

一个粗略的下限是：低于 300 条人工标签时，模型几乎不可能稳定地跑赢一套拍脑袋的加权规则，这时候把人力花在补标签上，比花在调模型上划算得多。

标签的第二个来源比专门组织的标注更持久：销售在名单上的每一次操作。名单界面上只需要三个按钮，“已联系”“不值得打”“联系不上”，每点一次就是一条带上下文的标签，成本为零，而且天然跟着当下的判断走。三个月下来这条通道攒下的标签量，通常远超一次集中标注。

要注意三个按钮的语义要分开存：不值得打是负样本，联系不上不是，它只说明联系方式有问题；混在一起，模型会把“留了公司邮箱但没留电话”学成不值得跟进的特征。

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

PQL 这个概念本身来自产品驱动增长（PLG）的实践。“产品驱动增长”一词通常归功于风投机构 OpenView 的 Blake Bartlett，他在 2016 年前后用它来描述 Slack、Dropbox 这类先让用户在产品里获得价值、再由销售跟进的公司。

PQL 和传统 MQL 的根本差别在于证据：MQL 看的是用户对营销内容的兴趣，PQL 看的是用户在产品里已经做过的事，比如邀请了几位同事、是否触达了免费版的上限。

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

分数是连续的，容量是离散的。正确顺序是先问销售本周能吃下多少个，再把阈值倒推成名额。定成固定分数（比如 0.7 以上都推给销售）的团队，会在产品发版后遇到分数整体漂移，名单一夜之间从 300 涨到 900，销售当周就放弃使用。

按名额切分还有一个副作用需要接受：模型好不好，看的是前 N 名里的命中率，而不是整体 AUC。AUC 从 0.78 提到 0.83、前 360 名的命中率却纹丝不动，是常见情况。

分数漂移几乎是必然的：每次改版都会改变用户行为的分布，同一个分数两个月后代表的已经不是同一类账号。按名额切分对整体平移不敏感，前 360 名永远是相对最像付费的那批，所以更稳。真要用绝对阈值，就每周看分数分布的均值和分位数，跳变了马上重新校准，否则销售会先于你发现名单不对劲，然后再也不打开它。

名额定下来之后，还剩一个问题：销售拿到手的到底该是什么。给销售一个 0.83，他不知道该说什么；给他三条证据（本周新增 9 个席位、两次访问了权限管理页、导出接口调用了 140 次），他能直接写进开场白。分数负责排序，证据负责让人相信排序。

实现上不需要复杂的可解释性框架，把贡献最高的 3 个特征映射成人话模板就够用，销售对模型的信任度几乎全部由这三行字决定。

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

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

PQL 打分的输入是几十个账号级的行为特征，样本量是每月几千个账号、总共几万条。这个规模下逻辑回归和梯度提升树是合理的上限，再复杂的模型不会更准，只会更难解释、更难回放。

逻辑回归的好处是每个特征一个系数，销售问“为什么这个账号排第 17”时，答案能当场算给他看；梯度提升树在前 N 名命中率上通常好一些，代价是解释要靠事后归因。两者都能在一台普通机器上几分钟训完，不需要 GPU，也不需要专门的机器学习平台。团队如果为这件事去采购一套 MLOps 工具，多半是被供应商说服了，不是被问题说服了。

大语言模型在这条流程里有位置，但不在打分这一环。它适合做的是把非结构化信息变成特征：把用户注册时填的“公司描述”归成行业类别，把工单文本归成问题类型，把销售通话记录提炼成“提到了预算”“提到了竞品”这样的标签。这些特征再喂给表格模型去打分。

反过来让大语言模型直接判断“这个账号该不该打”，会遇到三个问题：每次判断的成本比表格模型高几个数量级，结果不可复现，无法用前 N 名命中率去系统评估。把它放在特征生产这一层，既用上了它读文本的能力，又避开了它做排序的短板。

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

三、引导个性化的分寸

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

原因有两个。分叉越多，维护和回归测试的组合就越多；分叉依据越隐晦，猜错时越冒犯用户。用第 7 天激活率而不是首屏点击率来判定，是因为点击可以靠标题党刷出来，激活骗不了人。

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

3.1 产品内答疑

产品内答疑通常有两条技术路线。一条是检索加生成：把帮助中心切块、做向量索引，用户提问时检索出 5 段再让模型改写，它的失败模式是文档本身过期，模型会用流畅的语气复述错误答案。

另一条是意图分类加固定回复：把最高频的 30 个问题手写答案，模型只负责判断问的是哪一个，判不准就转人工，准确率天花板更低，但错得可控。在很多产品里，前 20 个高频问题就能覆盖过半的会话量（具体比例以自家工单数据为准），先把这部分做成第二条路线，剩下的长尾再交给第一条。

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

答疑同样可以算一笔账。每月人工工单 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 个百分点而工单绝对量没降，那是用户被劝退了，不是问题被解决了。

还有一种更隐蔽的做法：把答疑入口摆得很显眼、把工单入口藏得很深，拦截率照样好看，但你只是在制造摩擦，代价会滞后地落到续费和口碑上。所以看拦截率时，永远要同时盯住工单的绝对量和一个独立的满意度信号；任何单拎出来的拦截率，都可以被产品布局悄悄做出来。

3.2 什么归规则，什么归模型

试用到期是一个日历事件，不是概率问题。谁在第 12 天、谁在第 14 天，数据库里写得清清楚楚，用模型去预测只会引入噪声。模型在这一段能做的是另一件事：判断这个账号到期时更可能卡在哪一步，究竟是没导入数据、没邀请同事、还是没跑通第一个工作流，再决定延期提醒里放哪一段内容。触发时机归规则，内容选择归模型，这条分工在整个 PLG 流程里都成立。

判断标准就一条：数据库里有确定答案的，归规则；要在几个模糊选项里挑一个的，归模型。

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

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

付费墙卡在哪一格，同样不由模型说了算。免费额度定在 3 个席位还是 5 个席位，是定价决策，需要跨群体的价格弹性数据，而模型手里只有已经通过这道墙的人留下的行为；用留存模型去反推额度，会得到一个当期转化最高、12 个月留存最差的答案。能交给模型的是提醒节奏：额度还剩 20% 时提示，比用满之后再拦少激怒一批人，其位置由定价决定，节奏可以由数据决定。

这里有个反直觉的地方：额度墙提示得早一点，转化反而可能更好。用满之后才弹窗，用户是在被拦下的情绪里做决定；剩 20% 时提示，用户还在顺畅使用、正体会到价值，更愿意升级。

模型能学的是这个提示点该提前多少：高频账号可能剩 30% 就该提醒，低频账号拖到 10% 也不迟。额度设几个席位，仍然是定价的事。

四、扩容与流失是两回事

扩容看的是边界被撑破：席位接近上限、API 调用触到配额、开始有人查阅计费页面、新部门的邮箱后缀第一次出现。这类信号稀疏、突发、与时间强相关，用近 14 天的变化率比用累计值有用。

流失看的是常规行为的衰减：周活跃席位连续三周下滑、核心动作从每周 12 次掉到 3 次、管理员账号 30 天未登录。它平缓、连续，用滑动窗口的斜率更稳。同一套特征同时喂这两个任务，两边都会做不好。

具体到特征工程，扩容更吃变化率和首次出现这类突变型信号：把近 14 天的席位增速、配额触顶次数、计费页访问做成斜率或计数，比用累计总量灵敏得多；流失正相反，要的是平滑趋势，用 4 到 8 周的滑动窗口去看核心动作的衰减斜率，短窗口只会被一次假期或一次发版的波动带偏。

两个任务连时间尺度都不一样，别塞进同一个模型。

流失还有一个更根本的难点：预测出来往往没有动作可做。模型提前 45 天告诉你这个账号会走，团队能做什么？多数情况下只剩发一封邮件和排一次客户成功会议，而这两件事本来就按合同周期在做，预测准确率再高也换不来新动作。

值得投入的是把预测切成有对应动作的子类：因为没接完数据源而流失，对应实施支持；因为主推动者离职而流失，对应补第二个管理员；因为价格而流失，对应降配方案；没有对应动作的那一类，别预测，省下人力。

判断标准很简单：预测出来之后，有没有一个一一对应、平时又不会默认执行的动作。如果唯一能做的还是那封本来就会发的邮件，这个预测做得再准也没有价值。先列清手上能打的牌，再决定哪几类流失值得预测。

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

模型吃的是事件表。事件名在半年里改过三次、同一个动作在 Web 端和移动端叫不同名字、后端补发的事件时间戳用的是写入时间而非发生时间，这三件事任意一件成立，前 12 周的训练数据就不可信。

先做一件不性感的事：挑出与付费相关的 20 个事件，锁死命名和字段，写进代码评审清单，做完这一步再训练，比调参数换算法的收益大一个量级。

锁命名之外，还有两件容易埋雷的事：补发和回填的事件，务必用它真正发生的时间而不是写入库的时间，否则模型会在训练时偷看到未来，一到线上实时推理就打回原形；Web 端和移动端、新旧版本之间的同名不同义，最好在入库时就归一化，别指望在特征层临时打补丁。

地基没打好、标签还不够时，前六个月也得先跑起来。用加权规则打分开局：席位增长 30 分、邀请同事 20 分、连接数据源 25 分、访问定价页 15 分、管理员周活 10 分，权重由销售拍板，不装作科学。它的作用有两个：立刻给销售一份可用名单，以及在跑的过程中攒下带反馈的标签。

跑满 6 个月、积累到 800 条以上人工标注之后，再用模型和这套规则做离线对比；模型在前 360 名的命中率打不过规则，就继续用规则。

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

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

累计量给流失模型用，窗口量给扩容模型用，首次事件时间对 PQL 最有信息量，因为它编码的是账号的成熟阶段。

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

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

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

PLG 产品的行为数据大多在账号层面，但很多信号落在具体的人身上：谁邀请了同事、哪个管理员访问了定价页。把这些用于打分在多数场景下没有问题，因为它们是用户在产品内的显式动作，也是服务的一部分；一旦名单给到销售，销售看到的就是“某某公司的某某在看定价页”，这已经从产品分析滑向了对个人的观察。

分界线可以画在这里：账号级的聚合数据也不能随意使用，用到席位数、数据源数或周活跃席位之前，仍要确认处理目的、访问权限和适用的数据保护要求；个人级的动作用于打分可以，展示给销售时要聚合成账号级的陈述，“该工作区本周有成员访问过定价页”，而不是“张三周二下午看了定价页”。

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

面向中国用户还有一条硬约束。2021 年 11 月 1 日起施行的《个人信息保护法》第二十四条要求，利用个人信息进行自动化决策，应当保证决策的透明度和结果公平、公正，不得在交易价格等交易条件上实行不合理的差别待遇。打分只决定销售先打给谁，风险不大；一旦把分数接到折扣力度或报价上，就落进了这一条的范围，上线前要过法务。

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

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

名单推给销售之后，产品侧要不要停掉自助流程？默认继续跑的结果是同一个用户在 48 小时内收到自动升级邮件、产品内弹窗和一通电话。规则可以很简单：账号进入销售名单后，自动化营销消息静默 10 天，产品内引导保留，促销弹窗关掉。这条规则救回的转化，通常比模型多提升两个百分点带来的还多，而它一行 SQL 就能写完。

静默期从进入名单当天算起；销售标记为“不值得打”的账号要立即恢复自助流程，否则它们会在名单外再被冷落十天，这条例外最容易被忘掉。

还有一路自动化是模型喂给自己的回音壁。模型推荐前 360 名，销售只跟进这 360 名，只有这 360 名的结果被记录，下一轮训练数据全部来自这 360 名，三个月后模型会认定名单之外没有好账号，而这个结论无法被证伪。

机器学习工程里把这叫作直接反馈回路：模型会影响自己未来训练数据的选取。缓解办法也朴素，加入随机化，或者把一部分数据隔离在模型影响之外。解法是留一条随机通道：每月从阈值以下随机抽 5% 的账号照常跟进，专门给模型提供反例。这 5% 短期看是浪费，实际上是模型唯一的纠偏来源，同一条逻辑适用于引导个性化和答疑推荐。

这条随机通道还有一个用处：只有这 5% 的随机样本能回答“如果不跟进会怎样”，给出干净的对照基线。它既是纠偏来源，也是度量标尺，别当成纯成本砍掉。

5.1 排期、上线与验证

一个季度的排期可以这样排：第 1 至 3 周锁事件命名、补齐席位与配额字段；第 4 至 6 周上线加权规则打分，销售端展示三条证据，同时开随机通道；第 7 至 9 周做人工标注，目标 600 条，并把答疑的高频 30 问写完；第 10 至 12 周训练第一版模型，与规则做离线对比，只在前 360 名命中率上判胜负。第二个季度再谈扩容预测。

把顺序倒过来先做模型的团队，通常在第 8 周发现数据不能用。

这个排期的用意是：每一周的产出都不依赖后面几周。锁完事件命名，即使模型永远不上线，加权规则也能马上给销售一份名单；随机通道从第一天就开，等模型训好时反例已经攒了一个季度。先训模型的团队，常常调了六周 AUC，到第 8 周才发现事件名改过三次、时间戳用的是写入时间，整批数据作废。

上线第一个月几乎一定会发生三件事。销售会挑出两三个明显不合理的账号，据此判定整套系统不可信，你要准备好按账号回放特征值，当场解释清楚它为什么排在第 17 名。

名单会集中在某一个行业或某一种注册来源，因为历史标签本身带偏，就要把名单的来源分布与整体新增分布比一比，差距超过两倍就要动手修正。还有人会提议把分数直接接进营销自动化去群发邮件，这时先别接，等对照组数据出来再说，否则回音壁会提前半年到来。

这三件事都是人的问题，不是技术问题，再训练一版模型也解决不了。能解决它们的是可回放的解释、对名单分布的持续监控，以及守住对照组的纪律。

盯住的数字只要四个：名单命中率，即前 N 名中最终付费的比例；销售对名单的采纳率，推了多少、真打了多少，低于 60% 说明证据不够；激活率的对照差值，个性化组与对照组在第 7 天的差；以及人工工单的绝对量。这四个数字里没有 AUC，也没有模型调用次数，其中前者与业务动作的关系太松，后者是成本而不是成果。

四个数字有先后顺序：采纳率是命中率的前提，命中率又是对照差值的前提。出了问题先沿这条链往回查，多半卡在采纳率或证据质量上，而不是算法。工单绝对量是独立口径，只给答疑那条线做体检，别和 PQL 的数字放在一张看板上比。

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

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

别预设一定会有提升。多数产品实验本来就测不出正向结果，销售跟进 PQL 名单也是一种干预，同样可能测出零；把这种可能提前写进计划，复盘时才不会把零结果当成执行失败。

要证明这套东西真的有用，就得留出对照。每月 360 个名单，抽 20% 做留出组、不给销售跟进，即 72 个；基线转化按 22% 算，期望提升到 32%，要在 80% 功效下稳定检出这 10 个百分点，每组需要约 300 个样本，也就是要攒满 4 个月才能给出结论。想更快只有两条路：把留出组扩到 30%，或者只在最高分的前 120 名上做对比，因为那一段的提升幅度更大，需要的样本更少。

两条捷径都有代价。扩到 30% 意味着每月多放走一批本可以跟进的账号，换来早一两个月的结论；只看前 120 名，就说不清 120 到 360 名这一段模型有没有用，而容量扩张后最需要看清的正是这一段。先想清楚你现在缺的是时间还是全景，再排期。

上线之前，团队还应该互相把几个问题问清楚。

销售容量是多少，谁能给出准确数字？ 拿不到这个数就没法定阈值，它决定了模型该优化前 200 名还是前 2000 名，这两件事的最优解不一样，用错了目标，模型越准反而越浪费。

标签是谁标的，标了多少条？ 少于 300 条人工标签时，模型的表现无法与加权规则拉开距离，先补标签。

随机对照组留了吗？ 没有对照组，所有提升幅度都是估出来的，前面那笔 360 万元的账也就无法验证。

答疑答错了会怎样？ 计费、权限、数据删除这三类问题答错的代价远高于其他，应当强制转人工，不进入生成路径。

模型下线一周，业务会停吗？ 如果会停，说明规则兜底缺失，任何模型都该有一条降级路径，退回加权规则继续出名单。

这个功能三个月后谁来维护？ 特征会漂移、事件会改名、销售会换人，找不到长期负责人的模型项目，第二个季度就会烂在那里，最后没人敢删、也没人敢信。

六个问题里有两个答不上来，就先别训练模型，把那份加权规则名单交给销售，从第一周开始攒标签。