先说一个我反复见到的场面：团队花了两三个月把一个模型能力调到很不错的状态，内部 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% 就值得排查。

重试率：同一意图在短时间内重复提交的次数。重试率高通常不是模型能力问题，而是"输出不对但用户不知道怎么改输入"，属于交互设计问题。

边界误答率：用户问了明显超出产品能力范围的问题，模型硬答了。这个指标衡量的是产品诚实度，它对长期留存的影响被严重低估——用户被硬答坑一次，对这个产品的信任会掉一大截。

注意：上面这些区间是经验参考值，不同任务类型差异很大，创意类任务的采纳率天然比结构化任务低。别拿别的产品的数字直接套，先把自己产品上线首月的基线跑出来，后面所有对比都以自己的基线为准。

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, encoding="utf-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 量。然后按当前主流档位的单价折算单次成本。接着估日均调用次数，乘出单用户日成本。最后跟用户的付费意愿做对比：

算完之后大概率会发现重度用户的成本远超预期。这时候不要急着限流，先看能不能做分级路由：把简单任务交给小模型或者规则，复杂任务才走大模型。我实测下来，一个设计良好的路由层能把综合成本压掉一半以上，而用户感知几乎不变。

四周结束，判断标准我一般这么定：首次任务完成率过 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 分钟，你觉得这个产品快吗？用户不觉得。所以我所有的体验指标都用"人机协作总耗时"来衡量：从用户开始输入，到最终拿到可用产出，中间包括模型响应、用户阅读、用户修改、用户再次提交的全部时间。

这个指标能在早期就暴露出很多问题。有一次我们发现某个功能的协作总耗时比纯手工还长，拆开看是输出结构设计得太复杂，用户要在三段内容里来回比对。后来改成单段流水式输出，总耗时直接降了一半，用户反馈"变快了"——其实模型响应时间一点没变。

最后分享一个我最近在用的笨办法：每做一个新场景，先自己手工做二十遍这件事，用秒表计时，把每一步的痛点记下来。做完这二十遍，你就大概知道这个场景值不值得做模型产品了。这个方法很花时间，但它比任何市场分析都准，因为你自己就成了那个"返工成本尺"的持有者。