模型产品PMF度量框架：四层漏斗、五个指标与落地改造

某团队花了小半年把模型效果往上推离线评测分数涨了一大截内部演示也很顺可上线三个月周活没涨付费转化几乎贴在零线上。评审会上有人问了一句我们到底有没有 PMF会议室安静了几秒因为没人能给出一个不带主观判断的答案。这就是模型类产品最别扭的地方——效果指标是清楚的产品市场契合度PMF却是模糊的。做过几轮类似的事情之后我慢慢收敛出一套自己用的判断框架不谈玄学只谈能在两周内跑完、能用数字说话、能让团队在“继续加投入”和“换方向”之间吵出结论的东西。这里说的“模型产品”既包括把模型能力封装成接口对外提供也包括把模型塞进某个具体业务场景里做成工具或系统PMF 就是这套东西到底有没有真实市场需求的答案。这篇内容写给正在做模型能力落地的人产品、算法、业务侧都能看因为契合度从来不是算法团队单独能回答的问题。1. 模型类产品的PMF为什么比普通SaaS更难判定最核心的原因是价值的概率性。普通工具的承诺是明确的点了这个按钮流程往前走一步价值是可描述、可预期的。模型能力的承诺是统计意义上的平均准确率 92%这句话在单个用户眼里没有任何意义他只关心“我手上这一条输入进去出来的东西我能不能直接用”。离线指标涨 5 个点用户完全无感但一个高频场景上的翻车会让用户整体失去信任。信任这个东西在模型产品里是一次性消耗品。用户第一次用错了会想“再试试”第二次又错会开始手动校对第三次还错他就再也不会打开。所以模型产品的留存曲线往往不是平滑下滑而是断崖式的——断崖的位置往往就对应着用户第一次遇到无法容忍的错误。这也解释了为什么很多团队明明把均值指标做上去了留存却毫无起色均值掩盖了长尾而长尾才是用户真实输入分布里的主体。1.1 从“能跑通”到“愿意用”之间隔着一整个任务我自己踩得最深的一个认知误区是把“模型能把这件事做出来”等同于“用户会愿意用模型做这件事”。这两件事之间隔着的是一整个完整任务而不是一个模型调用。举个例子。某团队做了一个文本结构化的能力能把一段非结构化的记录抽取成十几个字段评测集上字段级准确率超过九成。技术上讲很漂亮。但真实场景里用户拿到结果之后还要核对、补漏、按业务规则改写、再导入系统——整套动作走下来比他自己从头录还慢。他试了两次就不用了而产品侧的埋点只记录了“调用成功”看板上一片绿色。问题出在哪我们度量的是模型调用的成功与否用户度量的是任务是否完成。这两者之间隔着的所有环节——核对、修正、导出、录入——都是产品该承担但没承担的活。所以我后来养成一个习惯任何模型能力的价值评估先画出用户完整任务的步骤图标出哪些步被模型替代了、哪些步被模型增加或复杂化了。如果被复杂化的步数不比被替代的多这个能力就还没有到能谈 PMF 的阶段。1.2 “能力过剩”和“任务缺口”的错配模型团队天然有把能力做全的冲动多轮、长文、结构化、多模态样样都想覆盖。但用户实际要的往往只是一件非常具体的事而且这件事的边界比想象中窄得多。我见过一个做得挺用心的产品能力列表拉出来十几项结果用户使用数据一拉八成调用集中在其中一项上而这一项恰恰是最早做的、最粗糙的那个。这个现象背后的逻辑不复杂用户不会因为你有十项能力就来用他只会因为有一件事你能稳定搞定而来用。能力越全边界越模糊用户在“这件事该不该交给它”上的判断成本就越高用着犹豫用着用着就不用了。所以我现在的倾向是先做窄再做深能做深的前提是边界清楚。一个能明确告诉你“这件事我做不了请自己处理”的产品比一个什么都说“可以试试”的产品更容易形成稳定使用习惯。1.3 三类典型的伪PMF信号识别假信号比寻找真信号更重要因为假信号会让团队在错误方向上多投入半年的资源。我总结下来最常见的三类伪信号表面特征真实含义低成本验证方式演示型热情内部评审叫好、试用用户夸好对“可能性”的兴奋不是对“日常可用”的认可两周后回访问“上次到今天用了几次”免费额度驱动用量曲线陡峭、日活好看零成本试错不是真实需求设一个小额付费门槛看用量掉多少大客户定制幻觉一两个客户深度使用、反馈极好定制化交付的成功不是通用需求的验证看这两家之外有没有自然增长的同类客户演示型热情最迷惑人因为反馈是即时且正向的。我的处理办法很简单任何一次演示之后不做即时满意度调查改成两周后的一次简短回访只问一个问题——这两周里你在真实工作里用过几次答案经常是零而零比任何好评都真实。免费额度驱动也是同理把“能用”和“值得花钱”分开测用量掉到原来的三成以下是常态掉到一成以下就该重新审视需求假设了。2. 把“契合”拆成可测量的四层漏斗“PMF 到没到”这种问题太大了大到没法回答。我的做法是把它拆成一个四层漏斗每一层单独设问题、单独取数、单独判读然后看漏斗的形状。形状比单点数值有信息量得多——某一层突然收窄问题往往就出在那一层附近。2.1 触发层真实任务发生时有没有人想起你触发层问的是一个很朴素的问题在目标场景真实发生的那些时刻你的产品被选中了多少次。注意分母是目标任务的真实发生次数不是访问次数不是注册用户数。这个数字往往需要靠客户访谈加日志外推来估算不精确但够用——比如访谈十来个客户问他们“这类任务你们一周大概处理多少件”取中位数乘以客户总量得到一个大致的量级。这一层是模型产品最容易忽略的因为大家习惯看自己系统里的绝对量。日调用一万次听起来不少但如果目标场景每天发生二十万次你的渗透率只有 5%说明绝大多数人还在用原来的方式干活你根本没有进入他们的选择集。这时候优化模型效果是无效的得先解决“为什么他们不选你”。我常用的一个访谈问题是回想最近三次遇到这类任务时你是怎么处理的。别问“你会不会用某类工具”那只会得到礼貌性的肯定回答问具体发生过的行为得到的才是真实路径。如果三次里有两次是“我自己弄一下”那说明触发层根本没打通。2.2 采纳层从第一次试用到第一次可用产出传统产品看“注册到首次使用”的转化模型产品得看更靠后的一步从首次使用到第一次拿到不用返工的产出。我把它叫作首次可用产出First Usable Output。定义必须严格比如“产出被用户直接采用人工修改比例低于 15%”具体阈值按场景定但一定要有量化标准否则这个指标会退化成一句感觉。这一步的耗时和成功率直接决定了用户会不会有第二次。模型产品的首次价值时间经常被高估很多团队以为用户第一次点下去看到结果就算成功了其实用户真正的判断发生在“这个结果我敢不敢直接用”。如果每次都要手动改掉一大半他心里的结论就是“这东西不靠谱”只是不好意思说。实测下来有个规律首次可用产出达成率低于 40% 的场景几乎没有自然留存40% 到 60% 之间需要靠产品设计比如提供候选、提供校对视图来补超过 60% 才开始出现自发传播。这个数字不是绝对标准不同容错度的场景差别很大但用来判断“该不该继续投入这个场景”挺好使。2.3 留存层效果留存和行为留存要分开算模型产品必须把留存拆成两个行为留存是“用户还会回来”效果留存是“回来之后产出依然可用”。只看行为留存会得出过于乐观的结论因为用户在“赌”——他可能只是在试你还行不行。组合现象判读动作行为留存高 效果留存高稳定复用真契合扩场景、涨价测试行为留存高 效果留存低反复试错用户在赌耐心有限立刻查长尾失败样本行为留存低 效果留存高用一次就够触发层或频次问题查任务频次、查触达路径双低无价值需求假设不成立停或换场景第二行是最危险的因为它表面上一切正常甚至看板还挺好看。我遇到过一次行为留存看着不错把效果留存拉出来一看四周之后可用产出比例掉到三成以下等于用户在反复试、反复失望只是还没放弃。这种状态撑不过两个月。2.4 付费层把省下的时间换成钱模型产品的付费逻辑通常落在“省时间”或“少用人”上但“省时间”是个很虚的说法得换算成钱才能做判断。换算方法不复杂单次任务节省的分钟数乘以对应岗位的综合人力成本得到单次任务的价值。这个价值要和单次推理加基础设施成本放在一起看得到价值成本比。这一步很多人跳过觉得反正是 To B 卖订阅算那么细干嘛。但模型产品的成本结构和传统软件差别很大边际成本不为零而且随输入长度、调用次数、重试次数波动。一个用得越深亏得越多的产品就算留存再好也不是好生意。我见过毛利被推理成本吃到个位数的项目用户很爱用团队很痛苦。另一个必做的动作是舍弃测试找一批真实用户问如果这个产品明天消失你会有多失望。选“非常失望”的比例超过四成通常说明需求是比较硬的低于两成基本可以判定为可有可无。这个测试的问题在于样本容易失真所以我一律要求面对面或电话做不看问卷回收率。3. 一套我实际在用的PMF度量模型前面四层是骨架这一节讲怎么把它变成一个能算、能对比、能吵架的数字。先说明这套东西不是学术模型它解决的是团队内部对齐问题别拿去当行业标准。3.1 指标选型从十几个砍到五个最开始我什么都想看看板上挂了十七个指标结果没人看开会还是靠感觉吵。后来一路砍最后只留五个理由是这五个各自对应漏斗的一层而且互不冗余触发渗透率目标任务发生次数中被产品承接的比例首次可用产出达成率首次使用就拿到可用产出的比例效果留存率首次可用产出的人群中第四周产出依然可用的比例价值成本比单次任务价值除以单次推理加基础设施成本舍弃测试非常失望占比定性验证防止数字自嗨砍指标的逻辑是指标一多团队就会不自觉地去挑那个正在涨的看然后拿它证明方向对。模型产品的数据噪声本来就大指标越多找到“看起来在涨”的那一个就越容易。五个指标里只要有两个同时在掉就该停下来查而不是去找第三个在涨的安慰自己。3.2 分母是魔鬼三个常见口径错误同一套公式口径不同能算出两倍差距所以口径必须写进文档、写进脚本、写进周会模板。第一个错误是把注册用户当分母算渗透率。注册用户数是个存量任务发生次数是个流量两个东西不能相除。第二个是把会话数当分母。用户完成一次任务可能产生三到五次会话反复追问、改输入、重试拿会话数当分母会把渗透率算低也会掩盖“一次任务要折腾好几次”这个真问题。第三个是内部测试账号、爬虫、演示流量混进分子这个最容易发生也最容易被忽略上线初期尤其严重。提示任何对外汇报的 PMF 数字先问一句“分母是什么、怎么估的”答不上来的数字不要用。3.3 一个完整的计算过程模拟项目X拿一个模拟项目做演示数字是我按真实项目的量级编的逻辑是真的。假设这是个把非结构化记录转成业务字段的工具服务对象是几十个中小团队。取一周的数据环节数值说明目标场景周任务发生次数40,000访谈 12 个客户取中位数乘以客户总量外推产品被调用次数6,000剔除内部账号、演示流量后的真实调用首次可用产出次数3,600人工修改比例低于 15% 的调用第四周仍可用次数1,800在 3,600 这批人里的回溯单次任务节省时间12 分钟用户访谈计时取中位数综合人力成本60 元/小时按岗位综合成本折算单次推理与基础设施成本1.2 元含重试与失败调用摊销按这些数字往下算触发渗透率 6,000 / 40,000 15.0%首次可用产出达成率 3,600 / 6,000 60.0%效果留存率 1,800 / 3,600 50.0%单次任务价值 12 分钟 × 1 元/分钟 12 元价值成本比 12 / 1.2 10:1。舍弃测试访谈 30 位有效用户12 位表示非常失望占比 40%。把这些塞进一个简单的打分脚本方便每周跑一次横向对比# 模拟项目X 的 PMF 打分脚本示意版 STAGE_TARGET { # 当前所处阶段的目标值 trigger_rate: 0.30, usable_rate: 0.75, retention_w4: 0.65, value_cost_ratio: 15.0, disappoint_share: 0.40, } WEIGHTS { trigger_rate: 0.25, usable_rate: 0.30, retention_w4: 0.25, value_cost_ratio: 0.10, disappoint_share: 0.10, } def normalize(value, target, cap1.5): # 超过目标的部分最多计 1.5 倍避免单项拉爆总分 return min(value / target, cap) def pmf_score(metrics): total 0.0 detail {} for key, weight in WEIGHTS.items(): n normalize(metrics[key], STAGE_TARGET[key]) detail[key] round(n, 3) total n * weight detail[pmf_score] round(total, 3) return detail current { trigger_rate: 0.15, usable_rate: 0.60, retention_w4: 0.50, value_cost_ratio: 10.0, disappoint_share: 0.40, } print(pmf_score(current)) # 结果大致是trigger 0.5, usable 0.8, retention 0.769, # value_cost 0.667, disappoint 1.0 → 综合 0.706综合分 0.706 意味着什么按我这套粗糙的标度0.5 以下是需求未经证实0.5 到 0.8 是方向对但支撑不足0.8 以上才有底气加投入扩规模。这个项目卡在中间偏上掉分最狠的是触发渗透率也就是说问题不在“用得爽不爽”而在“压根没多少人想起来用它”。这个结论直接改变了后续三个月的优先级排序从优化模型转到解决触达路径。3.4 阈值要按阶段设不是按好坏设同一组数字在不同阶段的意义完全不同。刚上线的产品触发渗透率低是正常的因为渠道还没铺但成熟产品触发渗透率还低那就是需求假设的问题。所以我把阈值分成三个阶段来设阶段关注重点触发渗透率首次可用产出效果留存 W4探索期有没有人愿意用5% 以上40% 以上30% 以上验证期用了能不能留住15% 以上60% 以上50% 以上扩张期留住了能不能放大30% 以上75% 以上65% 以上这张表最大的用处不是判断好坏是逼团队先回答“我们现在到底在哪个阶段”。我见过不少团队在探索期就拿着扩张期的标准要求自己指标怎么都够不上最后把方向改乱了也见过在验证期还用探索期的标准自我安慰迟迟不下判断。4. 从“能用”到“非用不可”四条结构性改造指标只能告诉你缺什么改不了什么。我把过去几轮里真正起过作用的动作归成四类都属于产品结构层面的调整不是调模型参数能替代的。4.1 收窄任务边界给模型划一个明确的工位第一个动作永远是把范围砍小。具体做法是明确三件事输入长什么样、输出长什么样、什么情况下拒绝处理。第三条最反直觉——很多人不敢让模型拒答觉得拒答就是失败。但实测下来明确的拒答比含糊的硬答更能建立信任。用户被错误结果坑过之后会全盘不信任被礼貌拒绝之后反而会建立合理预期。落地上可以做得非常具体。输入侧给固定模板和字段校验不满足条件的直接拦住告诉用户缺什么输出侧固定结构让用户知道每次拿到的东西形状一样方便直接进入下游流程拒绝侧定义清楚边界比如输入不完整、涉及无法判断的内容、超出置信区间一律返回“需要人工处理”并说明原因。这三条做完用户对产品的心理模型就稳定了稳定之后才谈得上形成习惯。4.2 把不确定性摆到台面上用户不怕模型出错怕的是不知道自己什么时候被错。所以我一直主张把不确定性显性化置信度分级、多候选、可回退、版本可追溯。这四样东西加起来能让用户的校对成本下降很多因为他知道该重点看哪几处。置信度分级不需要很精确分成高、中、低三档就够用关键是分档规则要稳定不能今天按这个分明天按那个分。多候选适合输出有多个合理答案的场景给两到三个选项让用户选一个比让他改一个快得多。可回退是指任何一次自动处理都能撤销并恢复原状这条在涉及数据写入的场景里几乎是必需品。版本可追溯是为了排错出了问题能查到当时用的是哪个版本、什么输入、走了哪条逻辑这在客户投诉时救命。4.3 人机协作的节奏设计很多团队把“全自动”当成目标觉得有人工介入就是能力不足。我的经验恰好相反在多数场景里部分自动化的留存明显好于全自动因为用户需要的是一个可控的节奏而不是一个黑盒。关键是审核点放哪里。放在产出之后用户是校对者心理负担是“我要检查一遍”放在关键节点之前用户是决策者心理负担变成“我确认一下这一步”。同样的工作量后者的体验好太多因为决策比校对更符合人的自我定位。实操上就是把流程切成几段模型处理完一段先停下来确认确认完再往下走。这看起来牺牲了效率但用户的接受度和持续使用意愿都会更好。4.4 嵌进既有工作流而不是新开一个页面这一条对触发渗透率的影响最大。一个需要用户主动打开的工具天然要跟“记不记得打开”这件事搏斗而一个嵌在既有流程里的步骤触发是自动发生的。改造方向很明确把调用点放到用户已经在工作的地方而不是让他切换窗口。具体做法比如在现有系统的操作界面里加一个处理入口、把结果直接写进用户已有的待办列表、或者让上游系统在数据产生时自动触发。判断标准很简单用户完成这个任务时需不需要额外想起你。如果答案是“需要”触发渗透率就很难上去这条我在模拟项目X里验证过——把入口从独立页面挪进现有流程之后两周内调用量涨了近两倍模型一行没改。5. 验证期最容易踩的四个坑有些坑我踩过不止一次写下来是为了省别人时间。这四个的共同点是当时都觉得没问题事后看全是明显的判断失误。5.1 用小样本的热情用户推全局结论产品早期能接触到的用户往往是关系最好的、最愿意配合的、需求最迫切的。这批人的反馈极好很容易让人以为需求被验证了。但他们的需求强度是分布里最右边的那一小撮不代表主体。排查链路其实不复杂先按使用频次分层看高频用户和低频用户的指标差异有多大再看分布而不看均值特别是首次可用产出达成率这种指标均值 60% 可能意味着四成用户接近零最后做一次随机抽样回访不看名单上的人看系统里随机抽的人。这三步走完通常就能看出之前的结论有多脆。5.2 把演示效果当成生产能力演示用的是挑过的输入生产面对的是完整长尾。这个道理谁都懂但真正做的时候演示和上线之间的落差还是经常超出预期。我印象最深的一次演示时十来个样例全对上线第一周真实输入里近三成触发了各种边界情况其中一半处理得很难看。应对办法是在上线前专门做一轮“恶心输入”测试找一线的人让他们提供各种不规范、缺字段、格式混乱的真实样本不做任何清洗直接灌进去。这一轮测试的通过率才是接近生产环境的真实数字。演示阶段的指标只用来确认方向不用来做承诺。5.3 指标定得太早把迭代方向锁死一个常见的情况是产品刚立项就定了一堆考核指标然后整个团队围着指标转慢慢忘了指标当初是为什么定的。指标本来是为了验证某个假设假设变了指标就该跟着变但实际执行里很少有人敢改。我的处理办法是给每个核心指标标注它对应的假设和有效期。比如“首次可用产出达成率”背后的假设是“用户卡在产出不可用上”如果三个月后访谈发现用户其实卡在“不知道该不该用”这个指标就该降权甚至替换。指标是工具不是目标这句话说起来容易做起来要靠在评审会上反复提醒。5.4 只看契合不看成本用得起但赚不到前面提过成本结构的问题这里再强调一次模型产品的单位经济模型必须在早期就搭起来不能等规模化之后再说。因为推理成本随用量线性甚至超线性增长如果一个场景的价值成本比只有两三倍规模越大越难受。具体要看的是三件事单次任务的平均成本和峰值成本长输入、重试、多轮会把峰值拉得很高、成本随用量的变化曲线、以及有没有降本路径比如分级处理、缓存、小模型兜底。如果这三件事都答不上来说明还没到能扩张的时候。6. 模拟项目X的三轮迭代复盘把前面的框架落到一个具体过程里更能看出指标怎么驱动决策。这里的数字都是模拟的节奏是真实的。6.1 第一轮功能全铺开留存惨淡第一版做了七八个能力覆盖各类输入宣传的时候主打“什么都能处理”。上线一个月注册量还行但行为留存和第二周就掉了七成。效果留存更低四周之后可用产出比例不到两成。看板上一片红团队的第一反应是模型不够强准备加大训练投入。后来做了分层分析发现八成调用集中在两个能力上其余几乎没人碰而这八成里又有大半是抱着试试的心态来的。真正把这件事当日常任务用的人极少。这次复盘的结论是不是模型不够强是产品根本没有对准任何一个具体任务。6.2 第二轮砍到单任务留存起来了付费没动第二版砍到只剩一个任务围绕这个任务把输入输出都固定死加了拒答边界和产出校对视图。改完之后效果留存从不到两成涨到五成左右首次可用产出达成率到了六成。但付费转化依然贴地用户用得很勤就是不愿意掏钱。这一轮的问题在价值量化上。访谈下来发现用户确实省了时间但省下来的时间被分摊到很多零碎的地方他自己也说不清到底省了多少自然不愿意为它单独付一笔钱。这时候才意识到价值必须是可被用户自己感知到的否则再大的实际节省也换不来付费。6.3 第三轮流程嵌入加复核节奏付费开始动第三版做了两件事一是把入口嵌进客户已有的工作流不再需要单独打开二是在关键节点加了人工确认把流程切成两段模型处理完先给结果确认后再写入。同时把“本环节节省工作量”这个数字直接展示在界面上让用户自己看到。这一轮触发渗透率从 6% 左右涨到 20% 上下价值成本比从 4:1 提到 10:1付费转化开始有起色。最有意思的是加了人工确认之后效率看着降低了用户满意度反而上去了因为心理负担从“要检查”变成了“要确认”。6.4 复盘哪三个动作真正起了作用回头排优先级真正起作用的只有三个动作砍窄任务边界、把入口嵌进流程、把价值可视化成用户能看懂的数字。模型本身在这一轮里的改动很小主要是边界处理和拒答逻辑。我个人的体会是模型产品的 PMF 大部分时候不是靠模型能力突破解决的而是靠把不确定性管理好、把任务边界划清楚、把价值摆到用户眼前。模型能力当然重要但它是必要不充分条件——能力上来之前谈 PMF 没意义能力上来之后不谈产品结构同样没意义。最后分享一个我自己一直在用的小办法每隔一个季度把产品当成一个陌生人第一次见从头走一遍完整任务全程不做任何补正把每一步的卡顿、犹豫、返工都记下来。这份记录比任何看板都更接近真实的契合度因为用户每天面对的就是这个没有被补正过的版本。