AI产品拆解，从需求到落地的全流程

产品正在从标准化服务向个性化、持续性的情绪价值迁移。

举个教育行业的例子：

过去：买一套教辅书，做完题就结束，没人关心你开不开心、有没有动力。

现在：产品不仅能根据你的错题推荐练习，还能在你深夜emo时陪你聊天，在你焦虑时给你打气，甚至记住你的生日和喜好，像朋友一样陪伴你成长。

就像马云说的，未来是一个CTOB的时代，是一个个性化服务的时代，产品的除了提供正常的功能以外，能够提供个性化、定制化的服务对用户更加友好，也就会获得更多的用户。

AI的能力就是做到个性化、定制化的基石，AI产品的需求挖掘、落地、迭代，还有很多朋友不了解，接下来给大家演示一个AI产品的落地全流程。

新产品的需求挖掘

后面做内容脱敏，我们暂且叫它《AI伴学》项目。

《AI伴学》是一个标准的AI产品，核心能力完全依靠AI的能力。

这个产品将会是一个主动式的AI，其目的是为了让高中学子从高一开始，就有一个功力深厚的专家跟随指导，用AI的力量，把冷冰冰的教育工具变成有温度的成长伙伴。

在这个信息爆炸的时代，谁能提供个性化、持续性、有温度的服务，谁就能赢得用户的心。而《AI伴学》，正是朝着这个方向迈出的第一步。

解决痛点

在当下多元化升学的时代，太多学子和家长因为没有接触渠道，没有信息来源，导致错过自己的最佳升学路径。
当下学子压力太大，没有"良师"引导、没有树洞宣泄情绪，

市场分析

接下来十年，参加高考的年龄所对应的出生人口, 最少也有一千五百多万，市场足够大，AI Agent又是元年，竞争没有那么激烈。

用户调研

全国范围内选择6000+高中家庭调研，不清楚高中升学规划的比例高达69%

核心功能设计

生涯规划，根据学生兴趣、成绩、性格等，推荐适合的目标院校，升学路径等。
学习诊断，分析成绩、测试。最终定位知识薄弱点，进行辅导 + 学习路径规划。
学生端提供情感陪伴系统，心理咨询、树洞、陪聊。
家长端提供政策解读、规划，缓解家长焦虑。

随着学业的推进，月考成绩，测试成绩等用户的信息越多，这位专家也越来越了解用户，也就能给出越来越多的定制化建议和规划。

agent流程设计

此处贴一个功能的流程设计，如图：

这套流程的核心是一套RAG系统、一套function call、一套大模型的兜底回复。

在RAG中，我们加入了上下文的判断，这是因为RAG本身是不支持上下文的，进入到RAG的query只用来和向量数据库中的知识做语义理解匹配。

为了解决不匹配问题，所以我们利用大模型添加了上下文分析的能力。提示词大致如下：

md 复制代码

## 业务知识

【这里根据自己的业务场景，添加必须让大模型知道的业务知识，例如对某些名词的解释】

## 要求

- 根据user的上下文对话，分析出user本次对话的真实意图。
- 必要的知识放在【业务知识】中，查询业务知识的信息与user对齐概念。
- 把user最终的真实意图转化成与上下文文风一致的问题后直接输出，不要输出分析过程
- 输出格式为{user:真实意图}

## 上下文

question：【上一次分析的结果query】
answer：【回复内容】
question:【用户本次query】

## 输出

示例如下：

function call系统用来解决用户的真实意图与我们的系统接口之间的调用。

function call是用的模型的tool功能，模型可以根据提示词进行使用工具的自动筛选：

json 复制代码

{
  name: '查学校基本信息',
  description: `学校基本信息查询plugin，当用户查询学校的基本信息时，
  给定学校名称【school_name】，返回用户问题中给定的相关信息。
  学校名称【school_name】指高等教育中的院校名称。
  例子1：query=山西学校在哪，输出{"school_name":"山西大学"}，
  例子2：query=北京大学招生网站，输出{"school_name":"北京大学"}，
  `,
  parameters: {
    type: 'object',
    properties: {
      school_name: {
      type: 'string',
      description: '学校名称',
      },
    },
    required: [],
  },
}

例如上面示例中，我们问的是 北大呢？，但是我们最终拿到的用户的真实意图 北京大学在哪个城市？ 这时，如果我们的RAG系统没有匹配到对应的答案，function call系统就会匹配到大学地址的接口，从而获得信息，交给大模型进行回复，简略版流程如图：

节点测试

任何一个功能的流程设计中，流程节点我们都需要进行测试，例如前面提到的上下文分析，这就需要我们自己写提示词来验证可行性，包括响应时间、模型能力、稳定性。

提示词我们测试没问题之后，再测试提示词配合RAG系统是否能达到我们想要的效果。

这里的关键在于我们RAG中参与向量化的内容和query是否匹配，所以这里有一个重点：RAG系统中知识库的内容要尽可能覆盖业务场景中的query + 尽可能与大模型上下文改写的风格一致。

上下文改写除了处理多轮问题之外，还有一个作用就是提高与知识库的匹配度，所以知识库中的内容也要配合做优化。

此外，有很多人不知道一件事：RAG系统的本质是筛选内容而不是匹配答案。匹配答案是大模型依据在RAG筛选出的内容做的事情。

MVP测试

当我们把所有的节点测试没问题之后，我们需要把各个节点的内容组合起来，进行一遍完整的测试，这次测试关心的点在：整体响应时间、整体消耗的tokens、回复准确率

上述流程大概标准是：响应时间在4±1s, 一次6套提示词+10+意图消耗的tokens在7000tokens左右，回复准确率90%左右。

团队分工

一切准备就绪之后，要把需求文档、原型、流程图都提供给团队。

需求文档和原型不在本文中展现，我们说一下流程图中的内容是如何进行分工的

这其中，我们数据同事的工作量是非常大的，尤其是整理数据的问题提取、数据入库时的问题扩充。

此时我们可以利用大模型来帮助我们的同事优化工作流程。

利用大模型优化工作流程

当我们要基于一批文档准备QA数据时，靠人工整理的人效大约15篇/天。 3000个文档我要安排20个人做十天。

这个成本太高了，所以此时我们就可以让提示词工程师先开发一个基于文档内容提取QA的脚本。伪提示词：根据资料，提取问题和答案，确保答案内容保持原文，以JSON的形式返回

但是我们肯定是不能完全相信大模型的，所以还需要与之搭配有一个审查脚本，用来确认QA的准确性。伪提示词：根据资料，确认以下QA是否正确，正确回复Y，错误回复N

注意：数据人员仍然要保证对最终结果的抽查。

备注

产品上线之后，对于传统产品来说，大家可以聚餐欢聚了，后面按照固定周期的更新迭代就OK了。

但是对于AI产品来说，上线才是刚刚开始：

AI产品的迭代频率远超传统产品，产品的提示词改动可能是以小时为单位不断地上线。

按照过去产品的经验，为了解决监控系统上报的用户使用中遇到的各种bad case。我们曾经一天发了7次新版本提示词。

不过我们一定要珍惜这个快速迭代过程，这是我们更加了解我们用户的过程。

当我们更加了解我们的用户之后，我们的数据和思路将会更加匹配用户的需求，长期之后形成的护城河，就不是随便一个新产品能打的破的了。

结语

总的来说，AI想要落地到团队中，主要分为三个层次：

产品上下游工作流程的优化
产品中的部分AI功能化
全新的AI产品

这第三点又分为两种做法：

新壶装旧酒。

例如：AI记账本、AI笔记等，曾经就有的业务，利用AI重新做一遍，带来更好的体验和效率。

新壶装新酒。

例如：AI随诊、AI面试等，曾经没有的业务，如果没有AI的能力，就没法做到的。

《AI伴学》项目就是一个新壶装新酒的纯粹的AI产品，这类产品的发掘和传统产品不一样，传统产品是发现用户的痛点，解决用户的痛点。

而AI产品是制造用户的痛点，解决用户的痛点，因为对AI能力的认知缺陷，加上传统产品一直以来的能力范围，很多人无法想象AI会给他带来什么改变。

就像没见过天堂的人才能忍受地狱，挖掘AI产品的方法其实就是基于我们的认知更加超前，我们可以告诉用户天堂是什么样的。

☺️你好，我是华洛，如果你对程序员转型AI产品负责人感兴趣，请给我点个赞。

已入驻公众号【华洛AI转型纪实】，欢迎大家围观，后续会分享大量最近三年来的经验和踩过的坑。