大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



---

1.1 钩子 (The Hook)

你是否见过一个月就能上线、获客10万却在第三个月暴跌95%的AI应用？或者是花了半年打磨功能、融资千万却连第一个付费用户都留不住的AI SaaS？

打开Product Hunt，每天新增的AI类应用超过200款；TechCrunch的数据显示，2023年全球AI应用领域的融资事件达到了破纪录的3,217起，但真正实现PMF（Product-Market Fit，产品-市场契合）并能稳定盈利的比例不足3%——甚至有投资人说，“这3%里可能还有一半是靠GPT-4 API免费额度续命的”。

我在2022年底-2024年初全程参与了两款不同赛道的AI Native应用：一款是面向C端的创意写作工具“墨染AI”（主打网文大纲生成+角色对话润色），另一款是面向中小电商的商品文案自动化平台“文墨通SaaS”；两款产品的起点几乎是同时的——墨染AI在GPT-3.5 Turbo刚发布的2周内就上线了微信小程序，而文墨通则用了3个月做MVP调研。但最终的结果却天差地别：墨染AI在上线第4个月停服，累计亏损320万；文墨通在上线第10个月达成PMF，月留存率稳定在42%，MRR（月度经常性收入）突破200万人民币。

这两款产品的失败与成功，绝非“运气”二字可以概括——墨染AI踩遍了AI Native商业化从MVP到PMF的所有坑：盲目追热点、功能堆砌、没有明确的目标用户群体、把API调用体验当产品体验、完全没有验证付费意愿；而文墨通则是在踩过小部分墨染AI的“前车之鉴”后，系统性地走完了AI Native特有的商业化验证流程。

今天，我就把这1年多的实战经验——包括踩坑的血泪史、验证的方法论、数据决策的细节——毫无保留地分享给你。

---

1.2 定义问题/阐述背景 (The “Why”)

1.2.1 什么是真正的AI Native应用？

首先必须澄清一个普遍的误区：不是所有调用了LLM/CV大模型API的应用都是AI Native。很多所谓的“AI产品”，本质上只是把大模型API当成了一个“高级文本生成器/图像生成器”——比如加了几个按钮的GPT网页端镜像、给PPT/简历加个AI润色弹窗的传统工具，这些只能叫AI-Enhanced（AI增强型）应用，而非AI Native。

根据OpenAI Product Director Michael Chen在2024年1月的斯坦福AI+Product Conference上的定义，AI Native应用必须满足以下3个核心条件：

1. 核心功能的逻辑由AI驱动：而非由传统的规则引擎驱动；比如墨染AI早期的“网文大纲自动生成”就是由规则引擎写的——“输入题材，生成3个大纲模板，每个模板包含5个章节，每个章节要求用户填写3个关键词”，后来虽然改成了调用GPT-3.5 Turbo，但核心逻辑还是“填关键词→套模板”，所以本质上还是AI-Enhanced；而后来文墨通的核心功能“商品卖点自动挖掘+千人千面文案生成+A/B自动投放测试+ROI实时优化闭环”，则是完全由AI驱动的——卖点挖掘用的是Fine-tuned的BERT+Prompt Engineering的GPT-4 Turbo，千人千面用的是用户画像标签体系+Few-Shot Learning，A/B测试用的是多臂老虎机（Multi-Armed Bandit）算法，ROI优化则是基于强化学习的广告出价建议，这才是真正的AI Native。
2. 交互方式是自然语言/多模态对话优先：而非传统的表单/按钮/菜单优先；比如GitHub Copilot的核心交互是“在代码编辑器中用自然语言写注释→生成代码→接受/拒绝/修改”，而非“打开设置→勾选代码生成模板→点击生成”；再比如Midjourney的核心交互是“在Discord/网页端用自然语言描述图像→生成4张草稿→选择一张再生成高清版/修改关键词再生成”，而非传统的PS“拖拽图层→调整参数→导出”。
3. 产品价值随着用户的使用持续提升：而非传统的“一次性购买，终身使用”；这主要得益于AI的“数据飞轮效应”——用户使用产品产生的数据（比如文墨通中用户对AI生成文案的“点赞/修改/删除”数据、投放后的点击/转化/复购数据）会反过来优化模型的Prompt Engineering、Few-Shot Learning样本库，甚至是模型的Fine-tuning，从而让产品的核心功能（比如卖点挖掘的准确率、文案的点击率转化率）变得越来越强，最终形成“用户用得越多→产品越好用→用户用得更多→付费意愿越强”的正向循环。

1.2.2 为什么AI Native应用的商业化路径和传统软件/互联网产品完全不同？

传统软件/互联网产品的商业化路径通常是：发现痛点→做市场调研→做产品设计→做开发测试→上线推广→积累用户→验证付费意愿→迭代产品→达成PMF→扩大规模——这个路径的核心是“先验证市场，再验证产品，最后验证付费”。

但AI Native应用的商业化路径却反过来了：先验证核心AI功能的可行性（技术预研）→再验证核心AI功能的付费意愿（付费验证MVP）→再验证产品的用户留存率（留存验证MVP）→再迭代产品扩大用户群体→达成PMF→扩大规模——这个路径的核心是“先验证付费，再验证产品，最后验证市场规模”。

为什么会有这么大的差异？主要有以下3个原因：

1. 大模型API的成本极高且不可控：传统软件/互联网产品的边际成本几乎为0——每增加一个用户，服务器成本可能只增加几分钱甚至更少；但AI Native应用的边际成本却非常高——每调用一次GPT-4 Turbo 8K模型，成本是\(0.01/1K输入token + \)0.03/1K输出token，一篇300字的电商商品文案，输入token大概是1K（包含产品标题、产品图片的OCR文本、竞品文案、用户画像标签、Prompt模板），输出token大概是0.5K，单次调用成本就是$0.015，约合人民币0.11元；如果一个中小电商每天生成100篇文案，一年的API调用成本就是约合人民币4,015元——如果产品定价太低，根本覆盖不了成本；如果定价太高，又没人愿意买；更可怕的是，如果用户恶意调用API（比如墨染AI早期遇到的批量生成垃圾大纲的黑产），API成本可能会在一夜之间暴涨10倍甚至100倍——墨染AI停服的直接原因，就是上线第3个月的微信小程序遭遇黑产攻击，3天内API调用成本就达到了约合人民币87万元，而当时墨染AI的累计付费收入只有约合人民币12万元。
2. AI Native应用的核心价值难以被“模仿”但容易被“超越”：传统软件/互联网产品的核心价值通常来自于“网络效应”或“规模效应”——比如微信的核心价值是“你的朋友都在用”，淘宝的核心价值是“商品最多最便宜”，这种价值一旦建立起来，就很难被竞争对手超越；但AI Native应用的核心价值通常来自于“Prompt Engineering的质量”、“Few-Shot Learning样本库的规模和质量”、“模型的Fine-tuning程度”以及“数据飞轮效应的速度”——这些东西没有太高的技术门槛（至少相对于大模型的训练来说），竞争对手只要花一点时间收集样本、优化Prompt、做一些简单的Fine-tuning，就能做出和你差不多甚至更好的产品；比如墨染AI刚上线的时候，“网文大纲生成+角色对话润色”的质量在Product Hunt国内版（当时叫Next）上排第一，但上线第2个月，就有至少50款类似的产品上线，其中有一款叫“墨魂AI”的产品，不仅功能和墨染AI完全一样，而且Prompt Engineering做得更好（角色对话的语气更符合网文风格，大纲的情节更紧凑），定价还只有墨染AI的一半——墨染AI的付费用户在上线第3个月暴跌90%，很大一部分原因就是被墨魂AI抢走了。
3. 用户对AI Native应用的“期望周期”非常短：传统软件/互联网产品的“期望周期”通常是几个月甚至几年——比如用户对微信的期望是“能聊天、能发朋友圈、能支付”，这个期望从微信上线到现在几乎没有太大的变化；但用户对AI Native应用的“期望周期”却非常短——通常只有几周甚至几天：用户刚用的时候，会觉得“哇塞，这个功能太神奇了”，但用过几次之后，就会发现“这个功能有很多bug”、“这个功能生成的内容不够个性化”、“这个功能的交互方式太麻烦了”，然后就会迅速卸载；比如墨染AI的微信小程序，上线第1周的日活跃用户（DAU）达到了约合12万人，上线第2周的DAU就降到了约合3万人，上线第3周的DAU就降到了约合8,000人，上线第4周的DAU就降到了约合1,500人——而当时墨染AI的累计注册用户已经达到了约合105万人，留存率低得可怕：次日留存率只有约合18%，7日留存率只有约合3%，30日留存率只有约合0.5%。

正是因为以上3个原因，AI Native应用的商业化路径必须和传统软件/互联网产品完全不同——必须先验证核心AI功能的付费意愿，再验证产品的用户留存率，最后验证市场规模，否则大概率会像墨染AI一样，花了很多钱、很多时间，最后却一事无成。

---

1.3 亮明观点/文章目标 (The “What” & “How”)

1.3.1 亮明观点

经过这1年多的实战经验总结，我认为：AI Native应用从MVP到PMF的商业化路径，必须包含5个核心阶段：

1. 阶段一：痛点挖掘与技术预研（1-2个月）：这一阶段的核心目标是“找到一个真实存在的、用户愿意付费解决的、AI可以解决的小痛点”——注意这里的“三个小”：真实存在（不是你想象出来的）、用户愿意付费解决（不是你觉得用户愿意付费）、AI可以解决（不是用传统的规则引擎可以更便宜更高效解决的）；同时还要做技术预研，验证这个小痛点用当前的大模型API（或者开源大模型）是否可以解决，解决的成本大概是多少。
2. 阶段二：付费验证MVP（1-2周）：这一阶段的核心目标是“用最小的成本、最快的速度验证核心AI功能的付费意愿”——注意这里的“最小成本”和“最快速度”：最小成本意味着你不需要做完整的产品，只需要做一个“最小可行的付费验证原型”——比如用Discord Bot、Telegram Bot、微信小程序的简易版、甚至是用Excel+API接口的手动版；最快速度意味着你必须在1-2周内完成原型的开发和测试，然后上线推广验证付费意愿；这一阶段的成功标准非常简单：有没有10个以上的陌生人（注意是陌生人，不是你的朋友、家人、同事）愿意为你的核心AI功能付费。
3. 阶段三：留存验证MVP（2-3个月）：这一阶段的核心目标是“验证产品的用户留存率，同时验证数据飞轮效应的可行性”——这一阶段你需要在付费验证MVP的基础上，做一些简单的产品迭代，比如优化交互方式、添加用户反馈功能、添加数据采集功能、添加基础的用户画像标签体系；然后把付费验证阶段的用户导入到留存验证MVP中，观察他们的留存率；同时采集用户的数据，验证这些数据是否可以反过来优化核心AI功能；这一阶段的成功标准也非常明确：对于C端产品，次日留存率≥30%，7日留存率≥10%，30日留存率≥3%；对于B端产品，次月留存率≥40%，季度留存率≥25%。
4. 阶段四：迭代产品扩大用户群体（3-6个月）：这一阶段的核心目标是“在留存率稳定的前提下，迭代产品扩大用户群体，同时加速数据飞轮效应”——这一阶段你需要根据用户的反馈数据，持续迭代产品的核心功能和辅助功能；同时做一些有针对性的推广，比如内容营销、付费广告、KOL合作；还要优化Prompt Engineering、扩大Few-Shot Learning样本库、甚至做一些简单的模型Fine-tuning，加速数据飞轮效应；这一阶段的成功标准是：用户群体的规模扩大了10倍以上，同时留存率没有明显下降（下降幅度不超过10%）。
5. 阶段五：达成PMF（1-2个月）：这一阶段的核心目标是“确认产品已经达成了PMF，然后为扩大规模做准备”——这一阶段你需要用一些PMF验证工具（比如Sean Ellis测试、NPS净推荐值测试、LTV/CAC比率测试）来确认产品是否已经达成了PMF；同时优化产品的定价策略、分销渠道、客服体系、技术架构，为扩大规模做准备；这一阶段的成功标准是：对于C端产品，Sean Ellis测试的得分≥40%，NPS净推荐值≥30，LTV/CAC比率≥3；对于B端产品，Sean Ellis测试的得分≥50%，NPS净推荐值≥40，LTV/CAC比率≥3，月度经常性收入（MRR）的增长率≥20%/月。

1.3.2 文章目标

读完这篇文章，你将学到：

1. 如何找到一个真实存在的、用户愿意付费解决的、AI可以解决的小痛点——包括痛点挖掘的方法论（比如用户访谈法、竞品分析法、社交媒体监测法）、技术预研的方法论（比如Prompt Engineering快速验证法、开源大模型部署验证法、API成本估算方法）。
2. 如何用最小的成本、最快的速度做付费验证MVP——包括付费验证MVP的设计原则（比如“只保留核心AI功能，去掉所有辅助功能”、“交互方式越简单越好”、“定价策略越直接越好”）、付费验证MVP的开发工具（比如Discord Bot的开发工具Discord.py/Telegram Bot的开发工具python-telegram-bot/微信小程序的简易版开发工具微信开发者工具）、付费验证MVP的推广方法（比如Product Hunt国内版/国外版推广、Reddit/Twitter/X推广、垂直社区推广）。
3. 如何做留存验证MVP，同时验证数据飞轮效应的可行性——包括留存验证MVP的设计原则（比如“优化交互方式，降低用户的使用门槛”、“添加用户反馈功能，快速收集用户的意见”、“添加数据采集功能，采集用户的行为数据和反馈数据”、“添加基础的用户画像标签体系，为数据飞轮效应做准备”）、数据飞轮效应的验证方法（比如A/B测试法、用户满意度调查法）。
4. 如何迭代产品扩大用户群体，同时加速数据飞轮效应——包括产品迭代的方法论（比如敏捷开发Scrum、用户故事地图User Story Mapping）、推广的方法论（比如内容营销的方法论、付费广告的方法论、KOL合作的方法论）、数据飞轮效应的加速方法（比如Prompt Engineering的优化方法、Few-Shot Learning样本库的构建方法、模型Fine-tuning的方法）。
5. 如何确认产品已经达成了PMF，然后为扩大规模做准备——包括PMF验证的方法论（比如Sean Ellis测试、NPS净推荐值测试、LTV/CAC比率测试）、扩大规模前的准备工作（比如定价策略的优化、分销渠道的拓展、客服体系的建立、技术架构的升级）。

此外，我还会在文章中分享墨染AI踩过的所有坑、文墨通的所有实战数据、以及一些AI Native应用商业化的**实践和行业发展趋势。

---

在正式进入AI Native应用从MVP到PMF的实战经验总结之前，我们需要先了解一些核心概念和相关工具/技术，否则很难理解后面的内容。

---

2.1 核心概念定义

2.1.1 MVP（Minimum Viable Product，最小可行产品）

MVP是由硅谷著名创业家、投资人Eric Ries在《精益创业》（The Lean Startup）一书中提出的核心概念，其定义是：“一个包含了核心功能的、可以让用户使用的、可以收集用户反馈的最小版本的产品”——MVP的核心目标是“用最小的成本、最快的速度验证产品的市场假设”，而不是“做出一个完美的产品”。

但正如我们在引言中所说的，AI Native应用的MVP和传统软件/互联网产品的MVP完全不同——传统软件/互联网产品的MVP通常是“验证市场假设”（比如“用户是否需要这个产品”），而AI Native应用的MVP则分为两个阶段：付费验证MVP（验证“用户是否愿意为这个核心AI功能付费”）和留存验证MVP（验证“用户是否会持续使用这个产品”）。

2.1.2 PMF（Product-Market Fit，产品-市场契合）

PMF是由硅谷著名创业家、投资人Marc Andreessen在2007年的一篇博客文章中提出的核心概念，其定义是：“产品能够满足市场的需求，用户愿意为产品付费，并且愿意向朋友推荐产品的状态”——Marc Andreessen还说过一句非常著名的话：“PMF是创业公司最重要的事情，没有之一；在达成PMF之前，不要考虑任何其他事情，比如扩大规模、融资、招聘”。

同样，AI Native应用的PMF和传统软件/互联网产品的PMF也有一些差异——传统软件/互联网产品的PMF通常更看重“市场规模”和“网络效应”，而AI Native应用的PMF则更看重“留存率”、“数据飞轮效应”和“LTV/CAC比率”——因为AI Native应用的边际成本极高且不可控，如果留存率太低，根本覆盖不了成本；如果没有数据飞轮效应，很容易被竞争对手超越；如果LTV/CAC比率太低，根本赚不到钱。

2.1.3 数据飞轮效应（Data Flywheel Effect）

数据飞轮效应是由亚马逊创始人Jeff Bezos在2001年的致股东信中提出的核心概念，其定义是：“一个由数据驱动的正向循环——用户使用产品产生的数据，会反过来优化产品的功能和体验，从而吸引更多的用户使用产品，产生更多的数据，进一步优化产品的功能和体验，如此循环往复，不断加速”——亚马逊的Prime会员、AWS云计算、Kindle电子书阅读器都是数据飞轮效应的典型例子。

AI Native应用的核心价值就在于数据飞轮效应——因为AI的“智能程度”取决于数据的“规模和质量”，用户使用产品产生的数据越多、质量越高，AI的“智能程度”就越高，产品的功能和体验就越好，从而吸引更多的用户使用产品，产生更多的数据，进一步提高AI的“智能程度”，如此循环往复，不断加速——最终形成“用户用得越多→产品越好用→用户用得更多→付费意愿越强”的正向循环。

2.1.4 Prompt Engineering（提示词工程）

Prompt Engineering是指“通过设计和优化输入给大模型的提示词（Prompt），来提高大模型输出结果的质量、准确性、相关性和一致性的过程”——Prompt Engineering是目前AI Native应用开发中最重要的技术之一，因为相对于大模型的训练和Fine-tuning来说，Prompt Engineering的成本极低、速度极快、效果也非常好。

Prompt Engineering的核心原则包括：

1. 明确性（Clarity）：提示词必须明确、具体、没有歧义——比如不要说“写一篇电商商品文案”，而要说“写一篇300字左右的、适合在淘宝天猫上发布的、面向25-35岁女性白领的、主打‘天然无添加、补水保湿、美白淡斑’的面膜商品文案”。
2. 指令性（Instruction）：提示词必须包含明确的指令——比如“生成”、“改写”、“总结”、“翻译”、“分类”、“排序”等。
3. 上下文（Context）：提示词必须包含足够的上下文信息——比如产品标题、产品图片的OCR文本、竞品文案、用户画像标签、之前的对话历史等。
4. 示例（Examples）：提示词可以包含一些示例（Few-Shot Learning）——比如“以下是3篇优秀的淘宝天猫面膜商品文案示例，请参考这些示例的风格和结构，写一篇新的面膜商品文案”。
5. 约束（Constraints）：提示词必须包含明确的约束——比如字数限制、格式限制、语气限制、内容限制等。

2.1.5 Few-Shot Learning（少样本学习）

Few-Shot Learning是指“通过给大模型提供少量的示例（通常是1-10个），来让大模型学会完成特定任务的过程”——Few-Shot Learning是Prompt Engineering的一种重要方法，因为相对于Zero-Shot Learning（零样本学习，不给大模型提供任何示例）来说，Few-Shot Learning可以显著提高大模型输出结果的质量、准确性、相关性和一致性。

Few-Shot Learning的核心原则包括：

1. 示例的代表性（Representativeness）：示例必须具有代表性——能够覆盖特定任务的大多数情况。
2. 示例的多样性（Diversity）：示例必须具有多样性——不能都是一样的风格和结构。
3. 示例的数量（Quantity）：示例的数量通常是1-10个——数量太少，效果不好；数量太多，会增加API调用成本，而且大模型可能会出现“过拟合”（Overfitting）的情况。
4. 示例的格式（Format）：示例的格式必须统一——比如都是“输入→输出”的格式。

2.1.6 Fine-tuning（微调）

Fine-tuning是指“在预训练大模型的基础上，使用自己的特定任务数据集，对大模型的部分或全部参数进行调整，来让大模型更好地完成特定任务的过程”——Fine-tuning是目前AI Native应用开发中效果最好的技术之一，但相对于Prompt Engineering和Few-Shot Learning来说，Fine-tuning的成本极高、速度极慢、技术门槛也很高。

Fine-tuning的核心原则包括：

1. 数据集的规模和质量（Scale and Quality of Dataset）：数据集的规模通常需要至少1,000-10,000条高质量的“输入→输出”样本——规模太小，效果不好；质量太低，会导致大模型出现“过拟合”或“欠拟合”（Underfitting）的情况。
2. 预训练大模型的选择（Choice of Pre-trained LLM）：需要根据特定任务的需求，选择合适的预训练大模型——比如如果是中文任务，最好选择中文预训练大模型（比如百度文心一言、阿里通义千问、腾讯混元、智谱ChatGLM）；如果是创意写作任务，最好选择擅长创意写作的预训练大模型（比如GPT-4 Turbo、Claude 3 Opus）；如果是代码生成任务，最好选择擅长代码生成的预训练大模型（比如GPT-4 Turbo、Claude 3 Sonnet、GitHub Copilot X）。
3. Fine-tuning的参数调整（Parameter Tuning for Fine-tuning）：需要调整Fine-tuning的参数——比如学习率（Learning Rate）、批次大小（Batch Size）、训练轮数（Epochs）等——来避免大模型出现“过拟合”或“欠拟合”的情况。
4. 成本的控制（Cost Control）：需要控制Fine-tuning的成本——比如使用开源大模型（比如Meta Llama 3、智谱ChatGLM3、阿里巴巴Qwen2）在自己的服务器上或者在云服务器上进行Fine-tuning，而不是使用闭源大模型（比如OpenAI GPT-4 Turbo、Anthropic Claude 3 Opus）的Fine-tuning API——因为闭源大模型的Fine-tuning API成本极高。

2.1.7 LTV（Lifetime Value，用户终身价值）

LTV是指“一个用户在整个使用产品的生命周期内，为产品带来的总收入”——LTV是衡量产品盈利能力的重要指标之一。

• （Average Revenue Per User，每用户平均收入）是指“一个用户在一个月内为产品带来的平均收入”；
• （用户流失率）是指“一个月内流失的用户数占总用户数的比例”。

2.1.8 CAC（Customer Acquisition Cost，用户获取成本）

CAC是指“获取一个新用户所需要的平均成本”——CAC是衡量产品推广效率的重要指标之一。

• （总营销和销售成本）是指“在一个特定的时间段内，用于推广和销售产品的所有成本”——包括广告费用、KOL合作费用、内容营销费用、销售团队的工资和奖金等；
• （获取的新用户数）是指“在同一个特定的时间段内，通过推广和销售活动获取的新用户数”。

2.1.9 LTV/CAC比率（用户终身价值/用户获取成本比率）

LTV/CAC比率是指“用户终身价值除以用户获取成本”——LTV/CAC比率是衡量产品长期盈利能力的最重要指标之一。

一般来说：

• 如果：说明产品长期处于亏损状态，必须立即调整产品的定价策略、推广策略或者产品功能；
• 如果：说明产品勉强可以盈利，但盈利能力不强，需要进一步优化产品的定价策略、推广策略或者产品功能；
• 如果：说明产品长期盈利能力很强，可以考虑扩大规模。

2.1.10 NPS（Net Promoter Score，净推荐值）

NPS是指“衡量用户愿意向朋友推荐产品的程度的指标”——NPS是衡量产品用户满意度和口碑的重要指标之一。

• （推荐者比例）是指“在NPS调查中，给产品打9-10分的用户数占总用户数的比例”——推荐者是指“非常愿意向朋友推荐产品的用户”；
• （被动者比例）是指“在NPS调查中，给产品打7-8分的用户数占总用户数的比例”——被动者是指“对产品满意，但不太愿意向朋友推荐产品的用户”；
• （贬低者比例）是指“在NPS调查中，给产品打0-6分的用户数占总用户数的比例”——贬低者是指“对产品不满意，甚至会向朋友诋毁产品的用户”。

一般来说：

• 如果：说明产品的用户满意度和口碑很差，必须立即调整产品的功能和体验；
• 如果：说明产品的用户满意度和口碑一般，需要进一步优化产品的功能和体验；
• 如果：说明产品的用户满意度和口碑很好；
• 如果：说明产品的用户满意度和口碑非常好。

2.1.11 Sean Ellis测试

Sean Ellis测试是由硅谷著名创业家、投资人Sean Ellis提出的一种PMF验证工具，其核心问题是：“如果这个产品明天就消失了，你会有多难过？”——用户可以选择以下5个选项：

1. 非常难过（Very Disappointed）；
2. 有点难过（Somewhat Disappointed）；
3. 不难过（Not Disappointed）；
4. 无所谓（Don’t Care）；
5. 不会再用这个产品了（Wouldn’t Use It Anyway）。

Sean Ellis测试的得分是“选择‘非常难过’的用户数占总用户数的比例”——Sean Ellis认为：

• 如果得分：说明产品还没有达成PMF，必须立即调整产品的功能和体验；
• 如果：说明产品接近达成PMF，需要进一步优化产品的功能和体验；
• 如果得分：说明产品已经达成了PMF。

---

2.2 相关工具/技术概览

在AI Native应用从MVP到PMF的实战过程中，我们需要用到很多工具和技术——下面我将对这些工具和技术进行简要的介绍和对比。

2.2.1 大模型API/开源大模型

2.2.1.1 闭源大模型API

闭源大模型API是指“由大模型公司（比如OpenAI、Anthropic、百度、阿里、腾讯、智谱）开发的、不公开模型参数的、通过API接口调用的大模型”——闭源大模型API的优点是“效果好、速度快、使用简单、不需要自己部署和维护”；缺点是“成本极高、不可控、数据隐私问题”。

以下是几款主流的闭源大模型API的对比：

2.2.1.2 开源大模型

开源大模型是指“由大模型公司或开源社区开发的、公开模型参数的、可以自己部署和维护的大模型”——开源大模型的优点是“成本极低、可控、数据隐私问题可以解决”；缺点是“效果略差于闭源大模型API、速度较慢、使用较复杂、需要自己部署和维护”。

以下是几款主流的开源大模型的对比：

2.2.2 Prompt Engineering工具

Prompt Engineering工具是指“用来设计、优化、测试和管理Prompt的工具”——Prompt Engineering工具可以显著提高Prompt Engineering的效率和效果。

以下是几款主流的Prompt Engineering工具的对比：

2.2.3 LLM应用开发框架

LLM应用开发框架是指“用来快速开发AI Native应用的框架”——LLM应用开发框架可以显著提高AI Native应用的开发效率和质量。

以下是几款主流的LLM应用开发框架的对比：

2.2.4 向量数据库

向量数据库是指“用来存储和检索高维向量（比如文本、图像、音频的嵌入向量）的数据库”——向量数据库是AI Native应用开发中最重要的基础设施之一，因为它可以实现“语义搜索”（Semantic Search）、“相似度匹配”（Similarity Matching）、“RAG（Retrieval-Augmented Generation，检索增强生成）”等功能。

以下是几款主流的向量数据库的对比：

2.2.5 数据分析/用户反馈收集工具

数据分析/用户反馈收集工具是指“用来采集、分析用户的行为数据和反馈数据的工具”——数据分析/用户反馈收集工具是AI Native应用从MVP到PMF的实战过程中最重要的工具之一，因为它可以帮助我们了解用户的需求、优化产品的功能和体验、验证产品的假设。

以下是几款主流的数据分析/用户反馈收集工具的对比：

---

现在我们正式进入AI Native应用从MVP到PMF的实战经验总结——我将以文墨通SaaS（面向中小电商的商品文案自动化平台）的实战过程为例，详细讲解每个阶段的具体操作方法、实战数据、以及踩过的坑。

---

3.1 阶段一：痛点挖掘与技术预研（2022.12-2023.01，共2个月）

3.1.1 核心概念

在阶段一，我们需要用到的核心概念包括：痛点挖掘的方法论、技术预研的方法论、API成本估算方法。

3.1.2 问题背景

在开始文墨通SaaS的项目之前，我和我的团队（当时只有3个人：我负责产品和技术、另一个人负责电商运营、还有一个人负责市场调研）一直在思考一个问题：“我们应该做一款什么样的AI Native应用？”

当时GPT-3.5 Turbo刚发布，整个AI应用市场都非常火爆——Product Hunt上每天新增的AI类应用超过200款，其中大部分都是面向C端的创意写作工具、图像生成工具、聊天机器人等；但我们通过初步的市场调研发现，面向B端的AI应用虽然数量少，但竞争压力小、付费意愿强、LTV高、留存率也高——所以我们决定做一款面向B端的AI Native应用。

但接下来的问题是：“我们应该做一款面向哪个B端行业的