---

智能客服系统PRD设计实战：从需求分析到架构落地的效率提升指南

---

配图：一张白板贴满便利贴，Event Storming 现场

---

一、痛点分析：PRD 里那些“说不清”的坑

“客服机器人又答非所问了！”——产品、运营、研发三方一起背锅，根源往往是 PRD 里埋的雷。我把过去三年踩过的典型坑，按出现频率从高到低列了个清单：

1. 意图识别覆盖率不足
   业务方一口气甩过来 200+ 意图，PRD 却只写“支持多轮对话”，结果上线后用户问“我要退运费险”机器人直接沉默。
2. 对话流程僵化
   流程图用 Visio 画成一条笔直的“主流程”，没有分支、没有异常，导致用户一跳出关键词就掉线。
3. 上下文生命周期模糊
   需求文档里写“保留 30 分钟”，结果测试发现 Redis 里 key 的 TTL 被运维误改成 5 分钟，线上大面积重复问“请问您贵姓”。
4. 技术/业务语言断层
   研发嘴里的 Slot Filling、F1-score，产品听不懂；产品嘴里的“用户情绪值”，研发也不知道怎么量化。
5. 返工成本
   需求评审 → 开发 → 验收 → 改需求，平均返工 1.8 轮，按人日算就是 30% 的浪费。

---

二、技术方案：DDD + Event Storming 让 PRD 一次写对

2.1 Event Storming 快速对齐业务语言

把产品、运营、研发、甚至客服一线拉到一间会议室，40 分钟就能贴出一张“橘色指令风暴图”：

• 蓝色便利贴：用户命令（如“申请售后”）
• 绿色便利贴：领域事件（如“退货单已创建”）
• 黄色便利贴：策略规则（如“7 天无理由”）
• 红色便利贴：热点痛点（如“用户重复上传图片”）

产出物直接对应 PRD 的“用例池”，一张图 = 一份共识，后续返工率肉眼可见下降。

2.2 用状态模式做“可演化的”对话引擎

传统 if-else 硬编码在 500 行时还能忍，过 1000 行后就是“屎山”。把对话抽象成状态机：

• 状态：Greeting / Questioning / Confirming / Handoff
• 事件：IntentMatched / SlotMissing / Timeout / NegativeFeedback
• 动作：ReplyToUser / FetchOrder / CreateTicket

新增一条支线，只需加两个状态类，旧代码一行不动，完美符合开闭原则。

2.3 NLU 服务 API 设计规范

对外只暴露一个 /nlu/v1/parse 接口，内部却拆成三条流水线：

1. 意图识别（Intent Classification）
2. 槽位填充（Slot Filling）
3. 实体归一（Entity Normalization）

返回体统一用 CamelCase + 可选置信度，方便前端做“低置信转人工”兜底。

---

三、代码示例：Spring Boot 对话上下文管理

下面这段代码演示“状态机 + Redis 会话”的最小可运行模型，附带 JUnit5 测试，可直接粘进项目跑。

// 1. 领域模型：对话上下文
@RedisHash(value = "chat_ctx", timeToLive = 1800)
public class ChatContext implements Serializable {
    private String sessionId;   // 用户唯一会话
    private DialogState state;  // 当前状态枚举
    private Map<String, Object> slots = new HashMap<>();
    // getter / setter 省略
}

// 2. 状态机引擎
@Component
public class DialogEngine {
    private final Map<DialogState, DialogStateHandler> handlerMap = Map.of(
        DialogState.GREETING, new GreetingHandler(),
        DialogState.QUESTIONING, new QuestioningHandler(),
        DialogState.CONFIRMING, new ConfirmingHandler()
    );

    public ChatContext handle(ChatContext ctx, String userUtterance) {
        DialogStateHandler h = handlerMap.get(ctx.getState());
        return h.handle(ctx, userUtterance);   // 可能返回新状态
    }
}

// 3. 控制器
@RestController
@RequestMapping("/chat")
@RequiredArgsConstructor
public class ChatController {
    private final DialogEngine engine;
    private final ChatContextRepo repo;

    @PostMapping("/{sessionId}")
    public ResponseEntity<Reply> reply(@PathVariable String sessionId,
                                       @RequestBody UserInput input) {
        ChatContext ctx = repo.findById(sessionId).orElse(new ChatContext(sessionId));
        ChatContext next = engine.handle(ctx, input.getText());
        repo.save(next);
        return ResponseEntity.ok(new Reply(next.getReplyText(), next.getState()));
    }
}

// 4. JUnit5 测试：验证超时后幂等重试
@SpringBootTest
class TimeoutIdempotencyTest {
    @Autowired ChatContextRepo repo;
    @Test
    void whenTimeout_thenReEnterShouldNotDuplicateSlot() {
        String sid = "test-123";
        ChatContext ctx = new ChatContext(sid);
        ctx.setState(DialogState.QUESTIONING);
        ctx.getSlots().put("orderId", "OID-999");
        repo.save(ctx);
        // 模拟超时后用户重发同一句话
        ChatContext reloaded = repo.findById(sid).get();
        assertEquals("OID-999", reloaded.getSlots().get("orderId"));
        assertEquals(DialogState.QUESTIONING, reloaded.getState());
    }
}

---

四、避坑指南：超时、幂等、上下文清理

1. 对话超时处理的幂等性设计

   • 使用 Redis + Lua 脚本保证“get + expire”原子性；
   • 用户重试同一句话时，用 sessionId + messageId 去重，避免重复扣积分或建单。

2. 多轮对话的上下文清理策略

   • 正常结束：状态机进入 END 后显式 repo.delete(ctx)；
   • 异常退出：Spring @RedisHash(timeToLive) 兜底 30min；
   • 内存告警：通过 RedisMemoryPolicy=allkeys-lru 把冷会话优先淘汰。

---

五、性能考量：压测下的 Redis 存储优化

1000 QPS 压测时，Redis 只跑 3 个节点就 CPU 打满，排查后发现是 KEYS * 被运维脚本误调。优化三板斧：

1. 键名压缩
   原 chat_ctx:{sessionId} 改成 c:{md5(sessionId)}，每条省 20 字节，千万级 key 能省 200MB。

2. Hash 结构代替整存整取
   把 ChatContext 拆成 hmset，只更新变动的 slot，网络包大小降 40%。

3. 本地二级缓存
   引入 Caffeine 缓存 5 秒 TTL，读多写少场景命中率 60%，Redis QPS 直接降到 400。

---

六、互动思考：方言识别怎么做？

留一道开放题，欢迎在评论区贴思路：

如果要在意图分类模块里支持粤语、四川话等方言，但 NLU 官方训练数据只有普通话，你会如何设计“低成本、可扩展”的方言识别子系统？
提示：可从“语音转文字→文本标准化→领域迁移学习→置信度融合”任一环节展开。

---

七、小结：效率提升看得见

用 Event Storming 对齐语言，用 DDD 分层写 PRD，用状态机落地对话引擎，再加上 Redis 优化与幂等设计，我们团队最近两个客服项目里，需求返工从 1.8 轮降到 0.6 轮，整体人日节省 30% 左右。代码直接复用，测试用例自动生成，上线后 F1-score 稳定在 0.91，运营同学终于不再拉我们通宵修“答非所问”的 bug。希望这套思路也能帮你把智能客服的 PRD 一次写对、一次做对。

---