本文以第一人称记录我在做 AI 销售陪练场景化演练模拟舱时的架构设计与踩过的坑偏技术实现不谈市场。一、整体架构长什么样我把这套系统拆成四层场景与角色层每个演练是一个仿真客户。系统用一份 persona 配置描述客户画像行业、性格、当前痛点、已知异议再生成开场白与目标。对话编排层维护多轮对话状态机。销售每条自然语言输入进来先做意图/敏感词过滤再交给大模型生成客户回复同时把对话历史写入日志。知识层RAG企业产品话术、合规红线、标准应答切片入库演练前/中按需检索保证客户口径和点评依据来自真实知识库。评分引擎层对话结束后按 rubric评分量规对多维度打分产出报告与改进建议并触发自适应学习路径。二、角色扮演是怎么演起来的核心是一段 customer persona system prompt你扮演一家便利店的老板性格务实、对新品持怀疑态度。 已知背景店内冰柜已满近期动销一般。 你的目标用卖得慢占地方等真实异议考验对方 只在对方给出有数据支撑的利益点时才松口。 禁止跳出角色禁止透露你是 AI。对话编排层负责把这条 prompt 和逐轮历史拼成上下文调用大模型生成客户回复。这里有两个工程细节状态约束用结构化的场景状态如是否已处理占地方顾虑做分支避免 AI 客户逻辑跳跃。安全围栏对销售输入做注入检测防止有人用忽略以上设定之类的指令劫持客户角色。三、RAG 不是挂个向量库就完事我踩过的第一个大坑就是以为接了向量检索就能用。实际上切片粒度话术按场景对象目的切片比按文档切片召回准得多。检索时机开场前检索背景知识对练中检索实时异议应对评分时再检索标准答案做对照。重排rerank纯向量召回噪声大加一层 rerank 后点评引用的知识片段相关度明显提升。RAG 的价值在于客户抛的异议和给的点评都锚定在企业自有知识上而不是模型自由发挥。四、评分引擎rubric LLM-judge 的混合方案早期我用让大模型直接打分结果漂移严重——同一段对话两次跑分能差出一档。后来改成混合结构化 rubric拆成开场切入、卖点匹配、异议处理、促成动作几个固定维度每个维度给 0–3 分的锚定描述few-shot 示例。LLM-as-judge按 rubric 逐维度出分并强制引用对话原文作为证据。规则兜底对明显的合规红线触碰如承诺未授权政策做硬性扣分不交给模型自由判断。这样分数可解释、可复现培训师和管理者才敢信。五、踩过的坑按严重程度排序知识库垃圾进垃圾出话术库没结构化前AI 客户常说出和企业政策矛盾的口径。先沉淀知识再开演练顺序不能反。评分漂移没有 rubric 锚定模型打分像抽签。务必 few-shot 引用证据。反馈空洞早期报告写表现不错继续加油销售看完不知道改哪。改进建议必须落到具体句子和具体动作。场景脱离业务曾为好看设计了一些花哨场景结果练的动作真实门店用不上。场景必须来自一线高频易错清单。隐私与合规销售对话日志含业务信息要做脱敏、访问控制和留存期限管理。角色崩坏不做注入防护时有人能骗 AI 客户承认自己是机器人并给出标准答案等于作弊通过。六、它和培训师的关系工程上我始终把它定位成高频重复带练的替代而不是培训师替代。重复话术演练交给系统培训师只处理高难度个案和策略辅导——这也是为什么评分要回流到学习路径让人的精力投在真正的短板上。七、想试落地建议的起点如果你也在搭类似系统先把两条业务线的高频场景和话术库梳理清楚跑通进入场景—对练—评分—改进的最小闭环再考虑和现有访销系统打通。知识准、场景真比模型选多大更重要。本文从工程视角记录了 AI 销售陪练系统的架构设计与落地踩坑。这类系统能否真正产生价值取决于三个工程前提知识库是否结构化、评分是否可解释、场景是否来自一线真实高频清单。满足这三条系统才能从演示不错走向规模化可用。笔者长期从事销售数字化系统的设计与实现欢迎在评论区交流不同的实现路径。