先说一个我反复见到的场面团队花了两三个月把一个模型能力调到很不错的状态内部 demo 演示时全场鼓掌上线两周后日活掉了一半运营开始怀疑是不是模型不够强于是继续加数据、换更大的底座、加更长上下文——然后数据还是不动。问题几乎从来不在模型本身而在没人认真回答过一个朴素的问题这个东西用户到底在什么时刻、因为什么原因、愿意拿它替代掉手里的哪件旧工具。这就是**模型 PMF产品市场契合度**要回答的事。我这里说的模型 PMF指的是以模型能力为核心交付物的产品在真实用户工作流中扎下根的程度。它跟传统 SaaS 的 PMF 有重合但判定逻辑差别很大传统产品卖的是流程效率模型产品卖的是这一次输出能不能直接用。前者可以靠培训和习惯养成慢慢磨后者第一次输出不对用户就走了。所以下面这些内容适合正在做模型类产品、AI 功能模块、或者准备把模型能力塞进既有产品的同学参考无论你是产品、算法还是工程都能对号入座。1. 先搞清楚模型 PMF 到底在问什么1.1 模型强和产品对是两件独立的事我见过太多团队把模型评测榜单的分数当成 PMF 的证据。榜单测的是通用能力PMF 测的是特定人群在特定任务上的替代意愿这两个东西的相关性远比想象中低。一个在通用推理上很能打的模型放到某类合同条款比对的任务里可能因为格式不稳定、术语不统一而完全不可用反过来一个能力中等的模型如果把输出结构、拒答边界、追问话术都设计对了用户会觉得很顺手。原因在于用户评估模型产品时用的不是能力刻度尺而是返工成本尺。他心里算的账是我自己做要 40 分钟用它做要 5 分钟输入加 15 分钟修改净省 20 分钟那就用如果修改要花 35 分钟净省 5 分钟还担着出错风险那就不用。所以模型 PMF 的第一性问题不是能不能做对而是做对的比例加上错的代价合起来是否低于用户的心理阈值。这就解释了一个常见现象某团队把准确率从 78% 提到 86%用户量没变化后来把输出格式改成可一键复制的结构化块把不确定的地方主动标注出来让用户复核用户量涨了一倍多。前者动的是能力后者动的是返工成本。做模型 PMF 的人眼睛要一直盯在返工成本上。1.2 三层契合能力、场景、经济缺一层都不成立我在实际项目里习惯把模型 PMF 拆成三层来判定任何一层不成立整体就不成立而且是乘法关系不是加法关系。能力契合指的是模型输出在真实任务上的可用率。注意是可用不是正确一条输出哪怕内容正确如果格式需要用户手动排版十分钟也不算可用。可用率我一般用无需修改直接采用加小幅修改后采用两个口径分别统计前者是硬指标后者是软指标。场景契合指的是这个任务在用户工作流中出现的频次和痛感强度。低频高痛的任务比如一年一次的资质材料撰写做 PMF 很难因为用户形不成使用习惯每次都要重新学习高频低痛的任务比如每天写日报也难因为用户迁移成本高于收益。真正容易跑出来的是高频中高痛、且现有方案明显笨重的场景。经济契合是最容易被忽略的一层。模型产品有推理成本这个硬支出单次调用成本乘以调用频次很容易吃掉全部毛利。我见过一个内部工具用户很喜欢但重度用户日均调用上百次算下来单个用户月成本远超其带来的价值最后只能限流一限流留存就崩了。这不是产品失败是经济层没算清楚就开始放量。层级核心问题典型失效信号主要抓手能力契合输出能不能直接用采纳率低、改写幅度大、重试频繁任务切片、输出结构、拒答边界场景契合用户多久用一次、有多痛激活高但次周留存断崖场景选择、入口位置、触发时机经济契合单用户成本是否低于价值用量越大亏得越多分级路由、缓存、额度设计三层里我先看经济层因为它最硬算不平的方案没必要往下推。很多团队反过来先死磕能力做完发现成本结构不成立前面的投入全打水漂。1.3 一个反直觉的判断PMF 早期要看窄不看宽早期最容易犯的错是把场景铺得太宽。因为模型能力看起来是通用的团队自然想覆盖尽可能多的使用意图。但 PMF 早期的资源极其有限你不可能同时把十个场景的返工成本都压到阈值以下结果就是每个场景都做到 70 分每个都差一口气用户每个都试一下然后都不用了。我自己的做法是找一个意图簇比如把散乱的技术记录整理成结构化周报把这一簇做到 90 分以上让这批用户形成这件事就用它的条件反射再横向扩。窄场景跑通的价值不只是数据更重要的是你能拿到一批愿意深度访谈的用户而深度访谈是后面所有判断的信息源。2. 度量体系把感觉不错变成能看的数字2.1 前置指标和滞后指标必须分层看模型产品有个特点从用户第一次接触到产生商业结果之间的链路很长中间任何一环断了滞后指标都反映不出来原因。所以我把指标体系分两层前置层看行为滞后层看钱和留存。前置层用来做日常调优滞后层用来做阶段性判断混着看会得出很混乱的结论。前置层我关注这几个首次任务完成率新用户第一次会话里有没有拿到一个他自己认可的输出、任务放弃率开始输入但没等到输出或中途退出、采纳率输出被直接使用或小幅修改后使用的比例、重试率同一意图重复提交的次数、兜底率转人工、转规则、转其他工具的比例。这五个指标基本能定位到链路上是哪一环出了问题。滞后层看次周留存、四周留存、付费转化、席位扩张和自然推荐。这里有个经验值可以参考模型类工具产品的次周留存如果低于 25%别急着优化付费先回去查场景频次很可能是选了个用户一个月才用一次的场景。2.2 留存曲线的形状比绝对值信息量大得多我特别建议所有做模型产品的人把留存曲线按天画出来看形状而不是只看第七天那个数字。常见的形状有三种每种指向的问题完全不同。一种是断崖后归零第一天很高第三天掉到很低之后趋近于零。这基本可以判定为尝鲜型使用用户是出于好奇来的任务本身不在他的常规工作流里。这时候优化模型质量没用得换场景或者换入口位置。另一种是断崖后长尾掉到一个不高的水平但稳住了比如稳定在 15% 左右。这说明有一小撮人真的在用通常是重度需求人群。这种情况的正确动作不是想办法把大盘拉起来而是把这一小撮人找出来做深访搞清楚他们的使用节奏然后围绕他们的工作流把产品做厚。还有一种是微笑曲线中途掉下去后来又回来了。这在模型产品里其实挺常见多半是因为用户在某个任务上被坑过一次就走了过一段时间遇到类似任务又回来试。这种情况下要重点查那批回流用户回来时用的是不是同一个功能如果是说明那个场景的痛感足够强值得投入把它做稳。2.3 模型侧特有的四个指标别和通用指标混为一谈通用 SaaS 的指标体系搬过来会漏掉很多东西因为模型输出是概率性的用没用和好不好用之间的灰色地带特别宽。我补四个模型侧特有的指标。采纳率输出内容未被修改直接采用的比例。这是最硬的指标但要注意口径有些产品里用户采用的动作是隐性的比如直接复制走了得靠埋点捕捉复制、导出、发送这些动作。改写幅度用户采用但做了修改时修改的比例有多大。可以用编辑距离或者段落级替换率来估。这个指标比采纳率更敏感能提前发现质量下滑。我一般看它的移动平均值涨幅超过 20% 就值得排查。重试率同一意图在短时间内重复提交的次数。重试率高通常不是模型能力问题而是输出不对但用户不知道怎么改输入属于交互设计问题。边界误答率用户问了明显超出产品能力范围的问题模型硬答了。这个指标衡量的是产品诚实度它对长期留存的影响被严重低估——用户被硬答坑一次对这个产品的信任会掉一大截。指标观测口径健康区间参考异常时优先排查首次任务完成率新用户首会话拿到认可输出60% 以上首次成功时间、引导设计采纳率输出未被修改直接使用45% 以上输出格式、术语一致性改写幅度段落级替换比例均值低于 25%上下文理解、约束遵循重试率5 分钟内同意图重复提交低于 12%输入引导、错误提示边界误答率越界请求中被硬答的比例低于 5%拒答策略、能力声明次周留存第 7 天仍有有效使用25% 以上场景频次、入口位置注意上面这些区间是经验参考值不同任务类型差异很大创意类任务的采纳率天然比结构化任务低。别拿别的产品的数字直接套先把自己产品上线首月的基线跑出来后面所有对比都以自己的基线为准。3. 评测集怎么建小样本、真任务、能回归3.1 别自己编测试题去日志里捞金种子我见过最典型的一个错误做法是产品经理坐在会议室里想了一下午编了 50 条测试用例然后拿这个当评测集。这些题目的问题在于它们是想象中的用户问题语法工整、意图明确、上下文完整而真实用户输入是错别字连篇、上下文断裂、意图藏在三句话里面。正确做法是从真实日志里捞。三个稳定的来源客服工单里用户抱怨最多的那批问题、线上日志里被反复重试的请求、销售或售前在做演示时被客户追着问的问题。这三类样本自带真实性和痛感比编出来的题有价值得多。捞出来的原始样本要做清洗和脱敏然后补上期望要点。这里有个关键点期望不要写成唯一答案要写成评分要点。模型输出天然有多样性如果你把标准答案写死评测就会变成像不像标准答案而不是管不管用。我通常给每条样本写 3 到 5 条要点标注哪些是必须满足的硬要点哪些是加分项。3.2 分层抽样让评测集的分布贴近真实流量样本捞完之后要做分层否则评测集会严重偏离真实分布——因为你捞的时候天然会捞到有趣的、难看的样本而真实流量里大部分是平淡无奇的常规请求。评测集里难样本比例过高会导致你对模型能力的判断持续偏悲观做出的决策也会偏保守。我的分层维度一般四个任务意图簇、输入长度档位、用户角色、难度等级。意图簇决定覆盖面我一般起步覆盖 8 到 12 个簇长度档位影响成本和稳定性短中长三档都要有用户角色影响表达习惯新手和老手提问方式差别巨大难度等级按真实分布配比难样本控制在 20% 到 30%。起步规模我建议 200 到 500 条。低于 200 条评测结果的抖动会大到没法做版本对比高于 500 条人工判定成本会拖垮迭代节奏。等产品跑起来之后把线上失败样本持续回流规模会自然长到千条量级。3.3 评测集要有纪律不然三个月就废了评测集最大的敌人不是难是被解释。一旦团队发现某个版本评测分数掉了第一反应往往是这条样本本身就有问题然后去改样本。改上三次这个评测集就变成了一个只能证明我们现在做得挺好的摆设。所以我在项目里会定几条死规矩评测集分版本管理每次改动都要记录改了什么、为什么改任何样本的修改必须由不参与模型调优的人审批每周固定回流一次线上失败样本新增的样本只进下一个版本不影响当前版本的对比结论每次发版前跑完整评测结果存档半年后回看这些存档能看出很多当时没意识到的问题。下面这个是我常用的评测脚本骨架核心思路是要点判定 版本对比不是简单的对错判断# 评测回归骨架按评分要点判定输出可对比的版本报告 import json from statistics import mean def score_case(output, rubric): rubric: {must: [...], nice: [...]}返回 0~1 的得分 must_hit sum(1 for item in rubric[must] if item in output) nice_hit sum(1 for item in rubric[nice] if item in output) if must_hit len(rubric[must]): return 0.0 # 硬要点未满足直接判 0 return min(1.0, 0.8 0.2 * nice_hit / max(1, len(rubric[nice]))) def run(dataset_path, infer_fn): rows json.load(open(dataset_path, encodingutf-8)) detail, by_cluster [], {} for row in rows: out infer_fn(row[input]) s score_case(out, row[rubric]) detail.append({**row, output: out, score: s}) by_cluster.setdefault(row[cluster], []).append(s) return { overall: round(mean(d[score] for d in detail), 4), by_cluster: {k: round(mean(v), 4) for k, v in by_cluster.items()}, zero_cases: [d[id] for d in detail if d[score] 0.0], detail: detail, }跑完把 overall 和 by_cluster 存一份 JSON跟上一版对比。我重点看的不是总分涨了多少而是 by_cluster 里有没有哪个簇掉得厉害——总分涨 2 个点但某个簇掉 15 个点通常意味着这次改动把某一类用户得罪了。4. 从 0 到 1 的实操路径四周跑通一次 PMF 验证4.1 第一周场景切片和用户访谈别急着写代码这一周的目标只有一个把我们觉得用户需要变成用户确实在某件事上卡住了。我一般会做 8 到 12 个深访找人的标准不是我们的用户而是最近一个月在这件事上花过超过两小时的人。访谈的时候千万别问你会不会用这样一个工具这个问题拿不到任何有用信息所有人都说会用。要问的是过去时上次做这件事是什么时候、花了多久、卡在哪一步、最后怎么解决的、当时手边有哪些工具。把每一步的耗时记下来回来画一张流程图标出耗时最长和出错最多的环节。这一周结束的时候你应该能回答三个问题这件事多久发生一次、单次耗时多少、现在的替代方案是什么。如果答案是一个月一次、十分钟、随手就做了直接换场景不用往下走。4.2 第二周搭最小可跑链路重点在设计第一次成功链路要薄薄到什么程度用户从一个明确的入口进来输入一些东西三十秒内拿到一个能直接用的输出。中间不要有多余的选项、配置、模式切换。所有未来会很有用的功能这一周全部砍掉。这一周真正的难点不是接模型而是设计第一次成功。用户第一次用的三十秒决定了他会不会有第二次。我的做法是把输入侧做窄——不要让用户自由输入而是给几个带示例的输入框甚至预填一段真实样例用户改两个字就能跑。这样做的代价是覆盖面变窄但换来的是首会话成功率的大幅提升非常值。同时要把兜底做出来。模型不确定的时候不能硬答要明确告诉用户这个问题我不确定建议你这样核对。这句话看起来是在认输实际上是建立信任最快的方式。4.3 第三周灰度放量埋点比功能重要灰度不要随机抽样要按用户分层。我一般分三层高频目标用户每周都会遇到这个任务的人、中频用户、以及一小批内部同事。内部同事那批的作用是快速收集定性反馈高频那批用来验证留存中频那批用来看边界。埋点这块有几个容易漏的输出被复制的动作、输出被编辑的动作、会话被中断的位置、重试发生的时间间隔。这几个点能让你后面复盘的时候区分没用和用了但没成。只埋点击生成按钮是不够的那个数据只能告诉你流量告诉不了你价值。4.4 第四周算笔账然后决定继续、转向还是停这一周要做两件事一件是读数据一件是算成本。数据这块前面说过重点看首次任务完成率、采纳率、次周留存这三个。成本这块我给一个具体的算法框架。先测单次任务的 token 消耗输入平均长度、输出平均长度、加上系统提示和上下文得到一个总 token 量。然后按当前主流档位的单价折算单次成本。接着估日均调用次数乘出单用户日成本。最后跟用户的付费意愿做对比测算项示例值说明单次任务输入 token1800含系统提示与上下文单次任务输出 token700结构化输出偏长单次综合成本记为 C按当前档位单价折算日均调用次数6 次来自灰度期实测别拍脑袋单用户日成本6C重度用户可能到 20C 以上单用户月成本180C按 30 天计目标毛利率60% 以上低于此值要重新设计额度算完之后大概率会发现重度用户的成本远超预期。这时候不要急着限流先看能不能做分级路由把简单任务交给小模型或者规则复杂任务才走大模型。我实测下来一个设计良好的路由层能把综合成本压掉一半以上而用户感知几乎不变。四周结束判断标准我一般这么定首次任务完成率过 60%、采纳率过 45%、次周留存过 25%、成本结构能跑正毛利四条全中才算初步成立缺一条就往下查是哪一层的问题查不出来就停。停掉一个场景不是失败把资源耗在一个不成立的场景上才是。5. 常见误判与排查技巧实录5.1 数据好看但没人真用通常是这几种情况第一种是内部流量污染。灰度期把内部同事也算进了分母这帮人出于工作需要会反复使用把指标撑得很好看。解决办法很简单埋点里加一个身份标记报表里永远把内部账号剔掉。这个坑我踩过一个功能上线三周数据漂亮得不像话剔掉内部账号之后留存直接腰斩。第二种是尝鲜流量的滞后效应。上线首周通常有一波尝鲜这批人的留存曲线很差会把整体数据拉低。所以看留存要切 cohort看首周之外的稳定 cohort别拿全量数据做判断。第三种是激活口径太松。很多产品把打开了页面算激活这个口径下激活率能到 90%但毫无意义。激活的定义应该是完成了一次有实质输出的任务且输出被使用或采纳。口径收紧之后数字会难看很多但那个数字才是真的。第四种是留存口径太宽。只要登录过就算留存这对模型产品特别不合适——用户可能只是回来看看有没有更新。我一般要求当天有一次有效调用且输出了结果才算留存日。5.2 用户说挺好用但就是不付费问题往往不在价格这个现象我在三个不同的项目里都遇到过。深访之后发现的原因高度一致用户觉得好用但他没法向自己的上级说明这个工具带来了什么。也就是说价值是真的但价值不可归因、不可汇报。解决办法不是降价是帮用户把价值显性化。我试过几个有效的手段在产品里加一个本月为你节省的时间的粗略估算基于任务数和单次节省时间的保守值、生成可导出的使用记录、以及在输出侧留下能被追溯到来源的标注方便用户拿去汇报。还有一种情况是真的价格错位。用户觉得好用但使用频次撑不起这个价格。这时候正确的动作是设计按次或按量的阶梯而不是硬推月度订阅。模型产品的成本结构天然适合按量计费别被订阅制的惯性带偏。5.3 一份可以贴在墙上的排查速查表现象最可能的原因第一步排查动作处理方向试用多、激活少首次成功时间太长看首会话中断位置分布预填示例、缩短输入路径激活高、次周留存断崖任务频次太低统计用户两次使用间隔中位数换场景或找高频入口留存稳、付费低价值不可归因访谈付费用户的决策依据做价值显性化、改计费方式付费高、退订高质量波动或越界硬答看退订前三次会话的采纳率加拒答、加质量分级重试率突增输入引导不足抽样看重试请求的输入文本改提示词、加示例成本超预算无路由、无缓存按任务类型拆分成本占比分级路由、结果缓存采纳率缓慢下滑上下文理解退化对比改写幅度的时间序列查上下文拼装、查知识更新提示这张表我建议打印出来贴在工位上。排查的顺序很重要永远从最上游的环节开始查——先看首次成功再看留存最后看付费。倒着查会浪费大量时间在错误的假设上。6. 踩过的坑与几条实操心得6.1 别用 demo 数据判断 PMF一个字都别信demo 环境里的输入是精心挑选的长度适中、意图清晰、没有错别字。真实用户输入会把你所有的假设打碎。我现在的规矩是任何 PMF 判断只认可来自真实流量的数据demo 和内部测试只能用来验证链路通不通不能用来验证有没有人要。这个规矩救过我一次。某个功能内部跑了三周同事反馈都很好我坚持要先上灰度看真实数据。结果真实环境下采纳率只有内部测试的三分之一原因是内部同事知道怎么提问真实用户不知道。问题出在输入引导上跟模型能力一点关系没有。如果按内部数据判断我们会去调模型那是完全错误的方向。6.2 把模型不行和产品没设计好严格分开这两类问题在数据上表现得很像都是采纳率低、重试率高但解决路径完全相反。判断方法我一般用人工上限测试把同样的输入交给一个熟练的人配上同样的模型让他手动调几轮提示词看能达到什么水平。如果人工调过之后采纳率能到 80%说明模型够用问题在产品设计如果怎么调都到不了 60%那才是模型能力问题。这个测试很土但极其有效一两个小时就能做完能省掉几周的瞎折腾。我在一个项目里用它拦下了一次大规模的模型替换那次替换预算不小做完测试发现换模型只能带来 4 个点的提升而把输出去掉多余的客套话能带来 20 个点的提升。6.3 边界提示比能力提升便宜得多这句话我逢人就说。让模型在不确定的时候明确说我不确定成本几乎为零但对用户信任的贡献极大。反过来把不确定的情况硬答对需要的数据和算力投入是数量级的。具体做法是在系统提示里明确列出能力边界并且在输出结构里留一个置信度或者需要你确认的点字段。用户看到这个字段会觉得你诚实而且他会主动去核对那些点——这恰恰降低了出错概率。我做过一个对比加了边界提示之后幻觉相关的投诉下降了六成多而采纳率没有下降因为用户对整体输出的信任反而提高了。6.4 别过早微调先把提示词和上下文拼装做到极致微调看起来很专业但它有个隐藏成本一旦微调你就把模型和特定数据分布绑定了后面换底座、加能力、改场景都要重来。而且微调的效果很容易被更好的上下文拼装覆盖掉。我的一般路径是先把系统提示、few-shot 示例、输出格式约束、上下文检索这四件事做到极致看能不能达到目标。这四件事做满之后通常能拿到一个相当不错的基线。如果还差得远再考虑微调而且微调的目标要定得很具体——比如统一输出术语而不是提升整体质量后者太大了微调搞不定。6.5 记录人机协作耗时别只记模型响应耗时模型响应 2 秒但用户改输出改了 8 分钟你觉得这个产品快吗用户不觉得。所以我所有的体验指标都用人机协作总耗时来衡量从用户开始输入到最终拿到可用产出中间包括模型响应、用户阅读、用户修改、用户再次提交的全部时间。这个指标能在早期就暴露出很多问题。有一次我们发现某个功能的协作总耗时比纯手工还长拆开看是输出结构设计得太复杂用户要在三段内容里来回比对。后来改成单段流水式输出总耗时直接降了一半用户反馈变快了——其实模型响应时间一点没变。最后分享一个我最近在用的笨办法每做一个新场景先自己手工做二十遍这件事用秒表计时把每一步的痛点记下来。做完这二十遍你就大概知道这个场景值不值得做模型产品了。这个方法很花时间但它比任何市场分析都准因为你自己就成了那个返工成本尺的持有者。
