企业官网建设流程全解析

做模型产品这几年，我最怕听到的一句话是“我们这个功能特别惊艳”。惊艳和产品市场契合度（PMF）之间隔着的不是一层窗户纸，而是一整条峡谷。模型 PMF 这个词最近被提得很多，但多数讨论停留在“找个高频场景”“做深工作流”这种正确但没用的层面。真正下场做的人都知道，模型类产品的 PMF 判定比传统软件难得多：能力边界会漂移、边际成本不为零、用户的需求还得靠你先做出来他才能看见。这篇就按我自己跑过几轮验证的顺序，把模型 PMF 的拆解方式、指标体系、实操流程和踩过的坑一次讲透，适合正在做模型应用、算法产品，或者准备把模型能力塞进现有业务里的同学参考。

1. 模型 PMF 到底特殊在哪

1.1 从“有人爱用”到“用得起还爱用”

传统 SaaS 的 PMF 判定相对干净：有人愿意持续用，有人愿意为此付钱，获客成本能被生命周期价值覆盖，三条线交叉基本就能下结论。模型产品多了一条硬约束——每次调用都在烧钱。这意味着 PMF 不再是一个单纯的需求侧问题，而是需求强度与推理成本之间的一场持续博弈。

我一般把模型 PMF 写成这样一个不等式：用户感知价值 > 替代方案成本 + 推理成本 + 信任成本。四项里任何一项失控，产品都撑不住。用户感知价值好理解；替代方案成本指用户不用你会用啥，可能是人工、可能是通用工具、可能是干脆忍着；推理成本是模型特有的，长上下文、多次重试、复杂链路都会把它顶上去；信任成本最容易被忽略，模型输出的不确定性会让用户多做一步核验，这一步的人力如果比你省下的还多，产品就没有净价值。

举个我实际遇到的例子。某团队做合同条款审查助手，内部试用阶段 40 多个人天天用，反馈极好，团队一度认为 PMF 已经拿到了。推到外部客户那边，付费转化只有 3%。后来拆开看，内部同事用是因为“反正不要钱，还能省点事”，外部法务用的时候必须逐条复核模型给出的修改建议，复核时间比自己看还长。感知价值被信任成本吃掉了，这就是典型的内部视角偏差。所以判断模型 PMF，第一步不是看有多少人夸，而是看用户在你的产品里有没有形成“净省时间”。

1.2 四类伪 PMF，先排雷再谈增长

我见过太多团队把伪信号当成 PMF 达成，然后一头扎进增长，钱烧完了才发现地基是空的。按出现频率排，大概有这四类：

这四类里，演示型和猎奇型最难识别，因为数据在短期内非常好看。我的经验是盯住一个指标：同一用户在一周内发起同类任务的次数。如果这个数字低于 1.5，基本可以判定还没有形成使用惯性。真正拿到 PMF 的产品，用户不是“想起来用一下”，而是“这件事不用它我反而别扭”。

还有一类更隐蔽的伪信号，我称之为“KPI 型 PMF”——指标是被定义出来的，不是被用户行为验证出来的。比如把“对话轮次”当核心指标，用户跟模型瞎聊二十轮也算活跃，这种指标涨得越快，离真实需求越远。指标一定要锚定在“任务完成”上，而不是“交互发生”上。

2. 搭一套能落地的模型 PMF 评估框架

2.1 四层指标体系与阈值参考

我把模型产品的 PMF 指标分成四层，从浅到深依次是激活、留存、付费、口碑。四层不是并列关系，而是漏斗关系，任何一层断裂，后面的数据都不值得看。

激活层看的是用户能不能在最短时间内拿到第一个有效结果。核心指标有两个：首次任务完成率，以及首次获得有效结果的时间。前者衡量产品能不能用，后者衡量好不好用。我的经验阈值是首次任务完成率不低于 70%，首次有效结果时间控制在 3 分钟以内。超过 5 分钟，大部分用户会在这个环节流失，尤其是 C 端。

留存层是模型产品最诚实的一层。D1、D7、D30 三个点足够说明问题。消费级工具类产品的参考区间大概是 D1 35% 到 45%、D7 18% 到 25%、D30 10% 到 15%；企业侧的判定方式不同，看的是周活跃席位占比和任务完成率，周活跃席位占比能稳定在 60% 以上算健康。需要强调的是，模型产品的留存曲线经常出现“假性回升”——模型版本更新后老用户回流，一周后又掉下去。所以看留存至少要跨两个版本周期，别被单点数据骗了。

付费层不能只看转化率，必须和毛利一起看。付费转化率 5% 配上 80% 毛利，和转化率 15% 配上负毛利，前者是生意，后者是慈善。这一层我后面单独展开算。

口碑层看两个数：自然推荐带来的新用户占比，以及用户主动向外提及的频次。前者低于 15% 说明产品还没有形成自传播，后者可以通过一个很土但有效的办法测——在访谈里问“你上次跟同事提这个工具是什么时候，怎么说的”。答得出来且描述具体的，才是真口碑。

2.2 把成本算进 PMF：单位经济模型

这一节是我认为最该被重视、但被讨论最少的部分。模型产品的 PMF 必须包含成本可行性，否则就是空中楼阁。

先建立一个基础模型。假设你的产品平均每个活跃用户每月发起 60 次任务，每次任务平均消耗 3500 输入 token 和 1200 输出 token，按当前主流的调用成本折算，单次任务成本大约 0.18 元，那么每用户每月推理成本约 10.8 元。如果你的定价是 39 元每月，毛利 28.2 元，毛利率 72%，看起来还不错。

但真实分布从来不是平均值。我实测过的一批数据里，头部 8% 的重度用户贡献了 45% 的调用量，他们每天跑 20 次以上任务，单月成本能顶到 60 元。这批用户会把整体毛利率从 72% 拉到 40% 以下。这个时候你有三个选择：

1. 分层定价。给重度用户单独设档，按用量阶梯计价。这是最直接的办法，但要注意别把普通用户吓跑，入口设计得很关键。
2. 模型路由。简单任务走小模型，复杂任务才上大模型。我做过一次粗略统计，在客服问答类场景里，约 65% 的请求用轻量模型就能达到可接受的完成质量，整体成本能降 40% 左右。路由的判定逻辑可以基于输入长度、意图分类、历史成功率，不必做得很复杂。
3. 缓存与结果复用。同类问题在高频场景里重复率惊人，尤其是知识问答类。命中缓存直接返回，成本趋近于零。缓存命中率做到 25% 就已经很可观了。

还有一个常被忽略的成本项：失败重试。模型输出不符合格式要求时，系统自动重试一次，成本直接翻倍。我建议把重试率作为成本监控的一级指标，超过 12% 就要回头查提示词设计和输出约束，而不是硬扛。

把这三件事做完，再回头看毛利率。我的判断标准是：稳定期的毛利率低于 50%，说明成本结构还没理顺，此时谈 PMF 为时尚早。不是不能做，而是这个状态下不适合放大规模。

2.3 定性侧：访谈怎么问才不失灵

模型产品有个特殊性，很多需求是能力创造出来的，用户在被你做出来之前根本不知道自己需要。这意味着纯靠“你需要什么功能”的访谈会大面积失灵，用户只会告诉你他现有流程里的痛点，不会告诉你模型能怎么改造这个流程。

我调整后的访谈方式是这样的，分三步：

第一步，还原现场而不是询问需求。让用户打开他现在的工作界面，现场做一次真实任务，你在旁边看。看他打开几个窗口、复制粘贴几次、在哪里停下来皱眉。这些动作比任何需求描述都值钱。我印象最深的一次，看某位运营同学做数据周报，她在一个表格和文档之间来回切了 11 次，每次都在手动对齐口径，这个环节后来成了产品的核心切入点。

第二步，问行为不问态度。“你觉得这个功能有用吗”得到的答案永远是“有用”，因为没人想打击你。换成“你上一次遇到这个问题是什么时候，当时怎么解决的，花了多久”，答案立刻具体起来。再补一句“如果这个工具明天关掉，你会怎么办”，回答“那就还按老办法”的，基本没形成依赖；回答“那我得赶紧找个替代”的，才是真需求。

第三步，给半成品，不给概念。概念阶段用户无法想象，给一个能跑通的最简流程，让他用两天。用完之后问三个问题：哪一步最别扭、哪一步你不敢信、哪一步你会推荐给同事。这三个问题对应产品的可用性、可信度、传播性，正好是 PMF 的三个侧面。

访谈样本量的问题，我的经验是 12 到 15 个深度访谈就能看到明显的模式收敛，超过 20 个之后新增信息量急剧下降。与其做 50 个浅访谈，不如做 15 个深的。

3. 从 0 到 1 跑一轮 PMF 验证的完整流程

3.1 场景筛选：窄口切入的筛选清单

模型能力很强，但这个“强”恰恰是陷阱——什么都能做，等于什么都没做透。我筛选场景一般用四个条件卡：

• 高频：目标用户每周至少遇到 2 次。低频场景做不出留存，哪怕单次价值很高，也很难形成产品。
• 高痛：现有解决方式要么慢、要么贵、要么压根没有。判断方法很土，问用户“这件事你上个月花了多少时间”，超过 3 小时/月的才值得做。
• 可验证：模型输出的正确性能被用户快速判断。这个条件极其关键。如果用户判断不了对不对，他就不会用，因为风险不可控。合同审查、代码生成都属于“能验证”的，医疗建议、投资决策属于“难验证”的，后者需要的信任建设成本高一个数量级。
• 低容错风险：出错的代价可承受。同样是写文案，写营销邮件出错了改一版就行，写对外公告出错了可能要担责。优先选前者。

我见过一个反例，某团队做的是一个“全能型工作助手”，什么都能干。上线三个月，注册用户不少，但没人能说清楚它到底解决什么问题，D30 留存 4%。后来砍到只做“会议录音转结构化纪要 + 待办提取”，留存直接翻了三倍。窄口不是妥协，是让用户能一句话记住你。

3.2 最小闭环搭建与评测集准备

场景定下来之后，第一步不是写代码，是建评测集。这是我踩过最多次坑的地方。

很多团队的评测集是从自己手里那几十条精心准备的样例里出的，跑出来准确率 95%，一上线掉到 60%。原因很简单，真实用户的输入分布和演示样例差太远了。我后来强制要求评测集必须来自真实分布：从历史工单、真实对话、实际文档里抽样，至少 200 条，覆盖长尾、错别字、多意图混杂、信息缺失这几种情况。

举个具体数字。某客服场景，演示集 20 条干净问题，完成率 95%；换成 300 条真实工单之后，完成率只有 62%。差的这 33 个百分点，40% 来自错别字和口语化表达，35% 来自一条消息里包含多个问题，剩下的是信息不全需要追问。这些问题在演示集里根本不会出现，但它们在真实场景里是常态。

评测集建好之后，最小闭环可以先用“人机混合”的方式跑。模型负责初稿，人工负责兜底修正。这样能最快验证需求真实性，而不必等到模型效果完美。我称之为“先验证有人要，再验证模型行”。顺序反了，容易在技术优化上耗掉三个月，最后发现没人用。

3.3 灰度四周：数据回收节奏与判读

种子用户我一般找 30 到 50 个，来源是真实目标用户，不是熟人。灰度周期四周，每周看三个核心数：

第二周是我最看重的节点。次周回访率低于 30%，说明产品没有进入用户的日常路径；30% 到 50% 之间属于“有用但可有可无”，需要继续打磨工作流嵌入；超过 50% 才有资格谈放大。这个阈值不是绝对的，B 端场景可以适当下调，但方向不会错。

第三周要特别区分“忘了用”和“不想用”。前者是提醒机制的问题，后者是价值问题，两者处理方式完全不同。区分方法很简单，发一条提醒，看召回率。召回率高于 40% 的是忘了用，低于 15% 的是不想用。我曾经在一个产品上花了两个月优化推送策略，最后发现是价值问题，白白浪费了时间。

第四周做小范围收费测试，这一步很多人不敢做，怕吓跑用户。我的看法正相反，早收费早暴露问题。收费测试不需要真的收钱，可以设计成“预付 1 元锁定早鸟价”，看转化率。转化率高于 8% 说明价值感知已经形成，低于 3% 说明还差得远。

3.4 加码、转向还是止损的决策标准

灰度结束之后要做决策，最怕的是“再观察观察”。我给自己定的标准是这样的，用一张表卡住：

这套标准的价值在于避免用努力掩盖判断。我见过太多团队在“各项都低”的情况下，选择再优化三个月模型，实际上是把一个战略问题当成了战术问题。

还有一个判断维度经常被忽略：用户是否开始自发地把你推荐给别人。这个信号比任何指标都硬。产品刚有点起色的时候，如果开始有用户主动拉同事进来，或者在其他群里提到你，说明价值已经溢出了。反过来，如果所有增长都靠投放和运营推，PMF 大概率还没到。

4. 实操中最容易踩的坑与排查方法

4.1 演示惊艳但留存崩盘

这是最高频的问题。演示阶段用户看到的是模型能力的上限，实际使用中遇到的是下限。两者的落差会直接摧毁信任。

排查路径我一般走三步。第一步，看用户流失发生在第几次任务。如果集中在第 1 到 2 次，说明首次体验有问题，重点查首次任务的输入引导和结果呈现。如果集中在第 5 到 8 次，说明用户已经用出了能力边界，撞上了“这个它做不好”的墙。

第二步，看失败任务的类型分布。把所有失败任务捞出来人工分类，通常会发现 2 到 3 类占了 70% 以上。集中攻这几类，比全面优化效率高得多。

第三步，检查预期管理。产品文案里有没有过度承诺？示例展示的是不是最优情况？我建议在首次使用时明确告诉用户“这类问题我处理得好，那类问题我可能需要你补充信息”，把边界说在前面，反而能提升信任。

有一个具体技巧很管用：在结果页给出置信度提示。不是给一个抽象分数，而是用自然语言说“这条建议基于文档第 3 节的明确条款”或者“这部分信息不完整，建议你核对原文”。用户知道自己该信到什么程度，核验成本就降下来了。

4.2 用户说好却不用

这是定性反馈和定量行为之间的经典背离。用户说好，可能是出于礼貌，也可能是产品确实有价值但没嵌入他的工作流。

排查的时候我会问三个具体问题，而不是泛泛地问满意度：

• “你上次用它是什么时候，做的是什么事？”——答不出具体时间的，基本没在用。
• “那次用完之后，你下一步做了什么？”——如果下一步是复制到别的地方继续加工，说明产品只完成了一半流程，价值被截断了。
• “有没有哪次你本来该用但忘了？”——这个问题的回答能直接指出触发机制的问题。

解决方向通常是两个：要么把产品嵌进用户已有的工具链里（比如做成浏览器插件、办公套件里的一个入口），要么建立主动触发（比如检测到用户打开某类文档时提示）。前者效果更持久，后者见效更快。

4.3 增长越快亏得越多

这个坑在模型产品里特别常见，因为成本随用量线性增长，而传统软件的边际成本趋近于零，很多团队的思维还停留在后者。

排查要看三个数：单用户成本分布、重试率、缓存命中率。单用户成本分布看 P95 和 P99，也就是最贵的那批用户成本是多少。如果 P99 的成本是均值的 8 倍以上，说明用量分布极度不均，必须做限额或分层。重试率超过 12%，先查提示词和输出格式约束。缓存命中率低于 15%，检查缓存键的设计是不是太细粒度了。

有个实操细节值得说：上下文长度是成本的隐形杀手。很多产品为了效果好，把历史对话全量塞进上下文，一次任务消耗几万 token。我做过对比，把历史压缩成结构化摘要之后，成本降了 55%，效果只掉了不到 3 个百分点。压缩策略可以是“保留最近 3 轮原文 + 更早的提炼成要点”，实现起来不复杂。

4.4 问题速查表

把上面这些整理成一张表，方便对照排查：

这张表我基本每次做新项目都会拿出来对一遍，能省掉不少瞎猜的时间。

5. 把这套方法沉淀成可复用的能力

单次验证跑通不难，难的是让团队具备持续验证的能力。我后来的做法是把三样东西固化下来：真实分布评测集、版本对比机制、反馈闭环。

评测集要持续更新，每月从真实流量里抽样补充，把新出现的失败案例加进去。这件事听起来枯燥，但它是所有判断的基础。没有可靠的评测集，模型效果的好坏全靠感觉，PMF 判定也就失去了依据。我一般要求评测集里“历史上失败过的案例”占比不低于 30%，这样每次版本迭代都能直接看到有没有把老问题修好。

版本对比机制指的是每次模型或提示词变更，都要在同一套评测集上跑一遍，记录完成率、平均耗时、成本三项。三项里任何一项明显退步，都不应该上线。我见过不少团队只看效果不看成本，结果版本越迭越贵，最后不得不回滚。

反馈闭环是把用户的“不满意”变成可执行信号。最简单的做法是在结果页放两个按钮，一个“有用”，一个“不对”，点“不对”的时候弹一个多选原因。这些数据积累三个月，就能画出失败类型的分布图，产品迭代的优先级自然就出来了。

还有一个我个人很看重但容易被忽略的点：把“不用”的用户也纳入观察。大部分团队只盯着活跃用户，实际上流失用户的访谈信息量更大。我一般每个月找 5 个流失用户聊 20 分钟，问的就一个问题：你当初为什么开始用，后来为什么不用了。这个问题的答案往往直指产品最核心的短板。

最后分享一个我用了很久的判断方法，很土但很准：如果你自己团队的人在非工作时间也会主动打开这个产品用，那 PMF 大概有戏；如果只有工作时间被要求用，那还差得远。工具类产品的终极形态是变成用户习惯的一部分，而不是一个需要被想起来的功能。这条标准没法写进报表，但它比任何指标都诚实。