我们在做的服务 · 客服智能体

先出稿，人来发

我们要的是：每位客户有一个了解他全部背景的智能体，接待、交付、售后三段都接得上，换班也不断。它只出稿，发不发、怎么改，由人定。

这一篇不在评审一圈里。

在做· 正在做考卷，架构方案在考卷之后

一、七条已经定了的

定了什么	为什么
人审闸是设计本身	智能体只出稿，人看、人改、人发。不做自动发送，也没有「部分场景自动回」。这不是暂时的保守，是这项服务的形状。
一套框架，每位客户一份案卷	方法共用；调用时把这位客户的案卷和这类问题的方法装在一起。不为每位客户单独起一个程序。
硬信息现查，不进案卷	订单、到期日、售后记录以业务系统为准，每次现查。案卷里只放系统里没有的背景。
案卷要人确认才写	模型只能提议写入，人确认后才写。每条带来源、日期、确认人、复核日。
发出去之前说清楚	哪些内容会发给模型，设计里写明；手机号、邮箱、单号发出前替换，回来再换回。
模型可以换	型号固定写明，但框架不绑任何一家。先用一家验证，跑不好就换。
整体能搬走	从第一天起按「将来交付给别的公司」的标准建：目录能整体搬走，不写死路径，不另建第二份知识库。

我们没有先画架构图。第一步是做一套考卷：从真实对话里抽题，按问题类型分组，每题写清什么算好答案，另设一组出过错的历史案例。考卷出来之前，不出方案。

抽哪些对话，由数据决定，不由人挑。请当班的人自己挑，又慢，又会漏掉出过问题和跨班断掉的那几段。改成由业务系统按原因（售后、退款、跨班、变更）全收，再随机抽一批，人只负责把完整对话复制下来，名单和文件逐一对账。

取材只走确定、安全的路：不用任何第三方导出工具，客户的原文不离开那一台电脑。

它出稿，没人看。只为攒下「它会怎么答」和「人实际怎么答」的差距。

人先看它的稿，改了再发。记下改了多少、改在哪。

差距稳定缩小以后，才成为当班的默认起点。仍然是人发。

有几类情形永远不出稿、直接转人：退款、改价、承诺时效、碰到合规词、客户情绪升级。

除了设计它的人，还要有别的东西能说它对不对：

还没定的

客服用手机也能调用、电脑待机时也能响应，这两条要实测，设计里只写方案和判据，不下结论。模型最终选哪一家，等考卷跑过再定。

先有脑，再长手脚

这项服务长在中枢上：客户的背景、每一次交接，先进脑，再给智能体读。

找我们做

想让自己公司的客服也这样接上背景，先把客户的背景收进一颗脑。从一次诊断开始。

回流登记

这一篇讲的，是我们每天在用的方法。