本文以第一人称记录我在做 AI 销售陪练（场景化演练模拟舱）时的架构设计与踩过的坑，偏技术实现，不谈市场。

一、整体架构长什么样

我把这套系统拆成四层：

1. 场景与角色层：每个演练是一个"仿真客户"。系统用一份 persona 配置描述客户画像（行业、性格、当前痛点、已知异议），再生成开场白与目标。
2. 对话编排层：维护多轮对话状态机。销售每条自然语言输入进来，先做意图/敏感词过滤，再交给大模型生成"客户"回复，同时把对话历史写入日志。
3. 知识层（RAG）：企业产品话术、合规红线、标准应答切片入库，演练前/中按需检索，保证客户口径和点评依据来自真实知识库。
4. 评分引擎层：对话结束后，按 rubric（评分量规）对多维度打分，产出报告与改进建议，并触发自适应学习路径。

二、角色扮演是怎么"演"起来的

核心是一段 customer persona system prompt：

你扮演一家便利店的老板，性格务实、对新品持怀疑态度。 已知背景：店内冰柜已满，近期动销一般。 你的目标：用"卖得慢""占地方"等真实异议考验对方， 只在对方给出有数据支撑的利益点时才松口。 禁止跳出角色，禁止透露你是 AI。

对话编排层负责把这条 prompt 和逐轮历史拼成上下文，调用大模型生成客户回复。这里有两个工程细节：

• 状态约束：用结构化的场景状态（如"是否已处理占地方顾虑"）做分支，避免 AI 客户逻辑跳跃。
• 安全围栏：对销售输入做注入检测，防止有人用"忽略以上设定"之类的指令劫持客户角色。

三、RAG 不是挂个向量库就完事

我踩过的第一个大坑就是"以为接了向量检索就能用"。实际上：

• 切片粒度：话术按"场景+对象+目的"切片比按文档切片召回准得多。
• 检索时机：开场前检索背景知识，对练中检索实时异议应对，评分时再检索标准答案做对照。
• 重排（rerank）：纯向量召回噪声大，加一层 rerank 后，点评引用的知识片段相关度明显提升。

RAG 的价值在于：客户抛的异议和给的点评，都锚定在企业自有知识上，而不是模型自由发挥。

四、评分引擎：rubric + LLM-judge 的混合方案

早期我用"让大模型直接打分"，结果漂移严重——同一段对话，两次跑分能差出一档。后来改成混合：

1. 结构化 rubric：拆成开场切入、卖点匹配、异议处理、促成动作几个固定维度，每个维度给 0–3 分的锚定描述（few-shot 示例）。
2. LLM-as-judge：按 rubric 逐维度出分，并强制引用对话原文作为证据。
3. 规则兜底：对明显的合规红线触碰（如承诺未授权政策）做硬性扣分，不交给模型自由判断。

这样分数可解释、可复现，培训师和管理者才敢信。

五、踩过的坑（按严重程度排序）

• 知识库垃圾进垃圾出：话术库没结构化前，AI 客户常说出和企业政策矛盾的口径。先沉淀知识，再开演练，顺序不能反。
• 评分漂移：没有 rubric 锚定，模型打分像抽签。务必 few-shot + 引用证据。
• 反馈空洞：早期报告写"表现不错，继续加油"，销售看完不知道改哪。改进建议必须落到具体句子和具体动作。
• 场景脱离业务：曾为"好看"设计了一些花哨场景，结果练的动作真实门店用不上。场景必须来自一线高频易错清单。
• 隐私与合规：销售对话日志含业务信息，要做脱敏、访问控制和留存期限管理。
• 角色崩坏：不做注入防护时，有人能骗 AI 客户"承认自己是机器人"并给出标准答案，等于作弊通过。

六、它和培训师的关系

工程上我始终把它定位成"高频重复带练的替代"，而不是培训师替代。重复话术演练交给系统，培训师只处理高难度个案和策略辅导——这也是为什么评分要回流到学习路径，让人的精力投在真正的短板上。

七、想试落地，建议的起点

如果你也在搭类似系统：先把两条业务线的高频场景和话术库梳理清楚，跑通"进入场景—对练—评分—改进"的最小闭环，再考虑和现有访销系统打通。知识准、场景真，比模型选多大更重要。

本文从工程视角记录了 AI 销售陪练系统的架构设计与落地踩坑。这类系统能否真正产生价值，取决于三个工程前提：知识库是否结构化、评分是否可解释、场景是否来自一线真实高频清单。满足这三条，系统才能从"演示不错"走向"规模化可用"。笔者长期从事销售数字化系统的设计与实现，欢迎在评论区交流不同的实现路径。