在家装业务中，一次客户接待可能持续几十分钟，录音转写后通常会产生上万字文本。内容涉及家庭情况、房屋信息、装修需求、预算、材料偏好、入住计划和决策关系等。
如果直接让大模型对整段文本进行摘要，虽然能够生成一段通顺的内容，但很容易出现信息遗漏、销售与客户角色混淆、重点不突出等问题。
旺小家基于录音转写文本和大模型，设计了一套面向家装场景的客户概览生成流程，将非结构化对话转化为可以直接供销售、设计师和店长使用的客户信息。
一、整体处理流程
客户概览的整体流程如下：
接待录音
↓
语音转写
↓
文本清洗与角色区分
↓
长文本分段
↓
客户关键信息提取
↓
结合历史客户数据
↓
大模型生成客户概览
↓
结果校验与结构化存储
整个过程可以划分为数据预处理、信息提取、概览生成和结果校验四个阶段。
二、录音转写与文本预处理
录音首先通过语音识别服务转换为文本。转写结果一般包含说话人、开始时间、结束时间和文本内容。
示例数据如下：
[
{
"speaker": "销售",
"startTime": 12.5,
"endTime": 18.6,
"text": "您家这个房子准备什么时候开始装修？"
},
{
"speaker": "客户",
"startTime": 18.8,
"endTime": 25.3,
"text": "已经交房了，想最近两个月定下来。"
}
]
原始转写文本通常会包含口头语、重复内容、识别错误和无效对话，因此不能直接进入客户概览生成环节。
预处理阶段主要完成以下工作：
清理无意义语气词和重复文本
合并连续且角色相同的对话
保留时间戳，支持分析结果回溯
标记客户、销售和其他参与人
过滤长时间静音及无业务价值内容
对明显的转写错误进行修正或降权处理
处理后的文本需要尽量保留原始语义，不能为了内容简洁而改变客户表达。
三、为什么需要区分
客户概览生成中，一个常见问题是把销售介绍的内容误认为客户需求。
例如：
销售：我们使用的板材环保等级比较高。
客户：我主要还是担心入住以后有味道，因为家里有小孩。
正确的分析结果应该是：
{
"关注点": "材料环保",
"判断依据": "客户担心装修后存在异味，并提到家中有小孩"
}
不能仅因为销售介绍了环保板材，就直接判断客户关注环保。
因此，在提交给大模型时，需要保留明确的角色标签：
【销售】：我们使用的板材环保等级比较高。
【客户】：我主要还是担心入住以后有味道，因为家里有小孩。
同时在提示词中明确要求：
客户需求必须优先来自客户本人表达
销售介绍不能直接作为客户需求
推断信息必须有对话依据
无法确认的信息应标记为“未明确”
四、长录音的分段处理
一次完整接待可能包含几万字转写内容。如果直接将全部文本提交给大模型，可能面临上下文过长、重要信息被忽略和调用成本较高等问题。
旺小家会先对长文本进行分段处理。
分段方式可以结合：
文本长度
说话时间
语义完整性
话题变化
接待环节
常见的话题包括：
家庭与居住情况
房屋基本信息
装修计划
空间功能需求
风格偏好
材料与环保
预算与报价
施工周期
竞品对比
签约及优惠
每个片段先独立提取客户信息，再将各片段的结果进行合并。这样可以降低长文本中关键信息被遗漏的概率。
分段结果示例：
{
"segmentId": "segment_01",
"topic": "装修计划",
"startTime": 320.5,
"endTime": 465.8,
"content": "……",
"extractedFacts": [
{
"field": "交房状态",
"value": "已交房",
"evidence": "房子已经交了",
"speaker": "客户"
},
{
"field": "装修时间",
"value": "计划两个月内确定",
"evidence": "想最近两个月定下来",
"speaker": "客户"
}
]
}
五、先提取事实，再生成概览
如果直接要求大模型“生成客户概览”，模型容易一边理解信息，一边组织文字，可能出现重要事实遗漏或推断过度。
更稳定的方式是分两步处理。
第一步：结构化提取
先从文本中提取客户事实：
{
"familyStructure": {
"value": "一家三口，有一名儿童",
"evidence": "家里有小孩，我们一家三口住"
},
"houseStatus": {
"value": "已交房",
"evidence": "房子已经交了"
},
"decorationTime": {
"value": "计划两个月内确定",
"evidence": "想最近两个月定下来"
},
"focusPoints": [
{
"value": "材料环保",
"evidence": "担心入住以后有味道"
}
],
"resistancePoints": [
{
"value": "担心后期增项",
"evidence": "后面会不会还有其他收费"
}
]
}
第二步：概览生成
再将提取后的结构化事实交给大模型，生成适合业务人员阅读的客户概览。
这种方式的优势是：
事实提取和文字生成相互分离
方便检查信息是否遗漏
可以对关键字段单独验证
便于后续扩展客户画像、意向分析等功能
可以保留每个结论对应的原始证据
六、多片段信息的合并与去重
同一个客户信息可能在录音中被多次提及。
例如：
客户：预算大概十五万左右。
客户：如果包含柜子，十八万以内也能接受。
系统不能简单保留第一个预算，也不能把它们当成两个互相冲突的信息。需要结合上下文进行合并：
{
"budget": {
"value": "基础预算约15万元，包含定制柜后最高可接受18万元",
"evidence": [
"预算大概十五万左右",
"如果包含柜子，十八万以内也能接受"
]
}
}
信息合并时可以采用以下规则：
客户明确表达优先于销售推测
后续确认的信息优先于前期模糊表达
多次重复出现的信息提高可信度
相互冲突的信息不强行合并
无法判断时保留多个版本并标记待确认
七、结合历史数据生成客户全量概览
客户概览不应只关注单次录音。客户可能经历电话咨询、首次到店、量房、方案沟通和报价谈判等多个阶段。
因此，生成概览时还可以引入：
历史录音分析结果
客户基础档案
历史关注点
历史抗性点
销售跟进记录
人工评论
当前业务阶段
在合并历史数据时，需要为每条信息保留时间和来源：
{
"field": "核心顾虑",
"value": "担心施工增项",
"source": "第二次到店录音",
"recordTime": "2026-07-10 15:30:00",
"evidence": "合同之外后面还会不会增加费用"
}
通过时间信息，可以识别客户变化：
首次沟通：主要关注设计效果
量房阶段：新增收纳和空间布局需求
报价阶段：开始关注整体预算
谈单阶段：核心顾虑变为后期增项
最终概览应优先展示客户当前状态，同时保留有业务价值的历史变化。
八、提示词设计中的关键约束
客户概览提示词需要明确模型的角色、输入范围、分析规则和输出格式。
简化后的提示词结构如下：
你是一名家装行业客户分析助手。
请基于录音转写文本和客户历史资料，生成客户概览。
分析规则：
- 优先使用客户本人明确表达的信息。
- 不得将销售介绍的内容直接认定为客户需求。
- 不得编造预算、房屋面积、家庭成员等信息。
- 推断内容必须有对话依据，并标记为“推测”或“需确认”。
- 出现冲突信息时，优先使用客户后续明确确认的内容。
- 没有提及的信息输出“未明确”，不得自行补充。
- 概览应突出当前需求、关注点、顾虑和决策状态。
- 避免按录音顺序进行流水账式复述。
输出内容：
- 客户基本情况
- 房屋与装修阶段
- 核心装修需求
- 关注点
- 抗性点
- 决策关系
- 当前推进状态
- 待确认信息
- 客户概览正文
为了便于系统解析，可以要求模型按照JSON格式返回：
{
"customerProfile": "",
"houseAndStage": "",
"coreNeeds": [],
"focusPoints": [],
"resistancePoints": [],
"decisionRelationship": "",
"currentStage": "",
"pendingConfirmation": [],
"overview": ""
}
九、结果校验与异常处理
大模型输出后，系统还需要进行基础校验，不能直接将所有内容展示给用户。
主要校验项包括：
JSON格式是否正确
必填字段是否存在
字段类型是否符合要求
输出是否为空
内容长度是否超出限制
是否出现输入中不存在的金额、日期或面积
是否混淆客户和销售角色
是否输出无关内容
是否包含异常字符或模型说明
如果模型输出失败，可以根据异常类型采取不同策略：
格式错误 → 修复JSON或重新生成
字段缺失 → 针对缺失字段补充生成
内容为空 → 检查转写文本有效性
文本过长 → 重新分段后生成
信息不足 → 返回“当前信息不足”
模型调用失败 → 记录任务状态并支持重试
对于金额、面积、时间等容易产生错误的字段，还可以将模型输出与原始提取结果进行二次比对。
十、客户概览示例
输入内容：
【销售】：房子现在交付了吗？
【客户】：上个月已经交了，想两个月内把装修定下来。
【销售】：平时几个人住？
【客户】：我们夫妻和一个孩子，老人偶尔过来。
【客户】：我比较看重收纳，孩子东西多。材料也要环保一点，
装完不能有太大味道。
【客户】：预算大概十五万，如果柜子全部包含，十八万以内可以接受。
【客户】：就是担心现在报价低，后面施工的时候一直加钱。
结构化提取结果：
{
"familyStructure": "夫妻与一名孩子常住，老人偶尔居住",
"houseStatus": "已交房",
"decorationTime": "计划两个月内确定装修",
"budget": "基础预算约15万元，包含定制柜后最高可接受18万元",
"coreNeeds": [
"增加家庭收纳空间",
"满足儿童用品收纳需求"
],
"focusPoints": [
"材料环保",
"装修后室内异味"
],
"resistancePoints": [
"担心施工过程中产生持续增项"
]
}
最终客户概览：
客户为三口之家，夫妻与孩子常住，老人偶尔居住。房屋已经交付，计划在两个月内确定装修方案。客户重点关注家庭收纳，尤其希望解决儿童用品较多的问题，同时对材料环保和装修后异味较为敏感。基础预算约15万元，如包含定制柜，最高可接受18万元。当前主要顾虑是前期报价与实际施工费用不一致，担心后期持续增项。后续应重点明确报价范围、材料清单及增项规则。
十一、总结
旺小家的客户概览生成并不是简单地将录音转写文本提交给大模型进行摘要，而是经过以下处理：
录音转写
→ 角色区分
→ 长文本分段
→ 客户事实提取
→ 信息合并去重
→ 历史数据融合
→ 客户概览生成
→ 输出结果校验
其中最重要的不是让模型生成一段语言流畅的文字，而是保证客户概览中的每个关键结论都能够找到对应依据。
通过这种方式，原本分散在长录音中的客户信息，可以被转化为结构清晰、能够追溯并可以直接用于后续跟进的客户概览，为销售、设计师和管理人员提供更高效的客户理解方式。
