几年前我接了一个展会自动客服的需求，当时团队的第一反应是"多写点关键词规则不就行了"。结果真实用户一句"明天几点能进场"和"开放时间是几点"，在规则系统里就是两条完全不相干的逻辑，而且语料越多，规则之间越容易互相打架。后来我换用 Recast.AI 来做，把意图识别、实体抽取、对话管理都交给这套平台，自己只需要喂样本、画对话流、挂 API，一个周末就做出了一个具备基本人工智能能力的聊天机器人，效果比之前的规则引擎好了一个量级。

现在不少人做人工智能大作业、毕业设计也会选"聊天机器人"这个方向，其实思路完全一样：与其从分词、意图分类算法一步步造轮子，不如先用 Recast.AI 这类平台把整条链路跑通，真正理解"意图—实体—对话—记忆"这套组合拳是怎么回事，之后再深入底层算法时会有方向得多。这篇文章就围绕"使用 Recast.AI 创建具有人工智能的聊天机器人"这条主线，把选型理由、核心概念、天气查询机器人的完整实现、模型调优、多渠道接入和实战踩坑一次讲透，适合准备做任务型机器人、又不想从零写 NLP 算法的同学参考。

1. 为什么我选 Recast.AI：聊天机器人难的不是答话，是听懂

1.1 关键词匹配为什么撑不住

我见过太多第一次做聊天机器人的人，第一反应都是 if-else 加关键词。"天气"就触发天气，"订座"就触发订座，乍一看逻辑清晰。等语料一多就露馅了："今天北京天气怎么样"和"北京今天冷吗"明明是同一个意思，关键词覆盖漏掉一个说法，用户就觉得机器人在装傻。更麻烦的是省略句，"明天呢"这种依赖上下文的问题，关键词系统根本无从下手。这也是我在第一个规则引擎项目里交过学费才想明白的事：聊天机器人的核心难点从来不是"答话"，而是"听懂"。

而 Recast.AI 这类产品的思路，是把"听懂"这件事做成了一个可训练的 NLP 服务。你给每个意图提供一批示例句子，它自己学出一个分类模型，下次来新句子时按概率告诉你属于哪个意图、置信度多高。同时它还能从句子里抽实体。这个"基于样本学习"的模式，和我之前手写规则引擎的经验完全不同——规则是死的，模型是会泛化的。

1.2 Recast.AI 的整体工作方式

Recast.AI 给我的第一印象是"麻雀虽小五脏俱全"。网页控制台里，Build 页签管意图和实体，Train 页签触发模型训练，Test 页签直接试句子，Connect 页签接各种渠道。完整的建模链路是这样：先在 Build 里定义意图和实体，给每个意图写一批训练样本，标注好实体位置，点 Train 让模型学习，然后进入 Dialog Flow 画回复逻辑。Dialog 里的节点除了回消息，还能挂 Code 节点，本质上是一个 webhook，让你去调外部 API。整个平台把机器人拆成了"理解（NLU）、决策（Dialog）、行动（API/Code）"三层，这个分层我现在回头看依然非常经典。

后来这产品被 SAP 收购，更名为 SAP Conversational AI，前几年官方也宣布逐步停服。但这套"喂样本训练意图 + 抽实体 + 画对话流"的框架，放在 Dialogflow、Rasa、百度 UNIT 这些平台上基本是同一个套路。我后来迁移项目时，把意图和实体一搬、对话逻辑重画一遍，半天就完事了，学它的方法论完全不会白费。

1.3 它适合什么项目，不适合什么项目

从我自己的使用经验看，Recast.AI 特别适合任务型机器人：查天气、订座位、查订单、FAQ 问答、展会咨询这类有明确"目的"的场景，天然可以用意图加实体建模。反过来，如果你要的是泛闲聊机器人，或者有硬性要求必须本地部署、对话数据不能出内网，那当时的云平台模式就不合适，得换 Rasa 这类开源方案自己训练。选型时还有个被忽略的点：平台虽然支持多语言，但中文的系统实体覆盖并不完美，后面实战部分我会专门讲。先把这三点想清楚，能省掉大量返工。

2. 上手必须先搞懂的三个核心：意图、实体、对话流

2.1 Intents（意图）：把用户的话归个类

意图说白了就是"用户说这句话想干嘛"的分类。比如"今天北京天气怎么样"的意图是查天气，"帮我订明天晚上六点的位子"的意图是订座。Recast.AI 不靠关键词匹配，它靠你给的样例句子自动学习，所以每个意图至少要给 5 到 10 条表达方式不一样的句子。拿查天气来说，我会放"今天天气怎么样""北京明天多少度""上海后天会下雨吗""帮我看看深圳的温度"这样一组样本，让模型知道同一个目的可以有这么多说法。

命名上我建议用动词开头的 snake_case，比如 weather_query 、 book_table 、 check_order ，团队协作时一眼就能看懂这个意图对应什么动作。对于"你叫什么名字"这类闲聊，可以建一个 smalltalk 意图兜着，但不要让它干扰核心意图。我的习惯是每个业务目的独立成一个意图，宁可数量多一点，也别把一个意图塞得太杂，否则模型学着学着就分裂了。

2.2 Entities（实体）：从话里抽出关键信息

意图解决"你想干嘛"，实体解决"这件事具体是哪个对象"。还是拿查天气举例："北京"是城市实体，"明天"是时间实体。Recast.AI 自带一批系统实体，比如 @location 、 @datetime 、 @number 、 @ordinal 、 @email ，标注时直接选中文字关联即可。但中文环境下的系统实体不一定全部好用，尤其"明天""下周一"这类相对时间表达，需要实际测试验证。

更常用的做法是自己建自定义实体。我给 city 建了两个 value："北京"（同义词：帝都、首都、Beijing）和"上海"（同义词：魔都、Shanghai）。这样用户说"帝都明天天气"，模型也能抽出 city=北京 。标注实体有个很重要的技巧：永远只标最短的完整语义单位。"北京天气"要标"北京"，千万别把"北京天气"整体标进去，否则实体值里带着一堆杂质，后面代码处理起来非常痛苦。另外，一个句子可能同时有多个同类实体，处理时要按数组看待，别默认只有一个值。

2.3 Dialog（对话流）：听懂之后怎么接话

理解完句子后，机器人怎么回复就是 Dialog 的活。Recast.AI 的 Dialog Flow 是可视化画布，节点之间用连线表示走向。常用节点有三类：发消息、跳转条件分支、Code 节点。比如命中 weather_query 意图后，先判断城市实体有没有，没有就先回问一句"你想查哪个城市的天气"，拿到答案后再去调天气 API。

这里要特别理解一点：Dialog 不是简单 if-else，因为 NLP 的判断结果是带置信度的。规则引擎是"条件命中就执行"，这里是"概率最高且超过阈值的意图才执行"。所以整个对话流必须额外考虑"没听懂怎么办""置信度不高怎么办"，至少要预留一个兜底分支接住所有识别不到的情况，不能让流程走到死胡同里。

3. 初始化项目：注册、建 Bot，先给机器人划好地盘

3.1 注册账号，创建第一个 Bot

Recast.AI 的注册门槛很低，邮箱注册完直接进入控制台，"Create a Bot"之后第一件事是选语言。这里要提醒一句：不要随手乱选，后续训练、实体、 Dialog 都跟语言绑定，项目做到一半再改语言，基本等于从头再来。我当时选了中文，平台随即生成一个空 Bot，所有内容都要从零定义。这个空壳其实在逼你想清楚一个更根本的问题：你这个机器人到底要管哪些事？工具只是给你提供了脚手架，能不能做出好产品，取决于你怎么定义问题。

3.2 先给机器人划地盘

创建完 Bot，先别急着写意图，我的习惯是离线画一张"对话边界图"。把用户可能问的问题分成三类：机器人必须处理的、可以简单回应但不用做完整流程的、完全不能处理需要转人工的。拿展会客服举例，必须处理的是展会时间地点、交通方式、展商名单、登记入口；可以简单回应的是住宿推荐；完全不能处理的是合同纠纷、票务退款。把边界画清楚之后，再为每一类写意图，意图的数量从一开始就是可控的。

这一步看似只花了半小时，实际上避开了项目里最大的坑——意图膨胀。好多项目做着做着，机器人变成了一个什么都想接、但什么都接不准的大杂烩。范围越清晰，样本越好写，准确率越好调，这是一个正向循环。

3.3 用一张表当施工图

动手前我会做一张表，每一行一个意图：意图名、用户可能怎么问（至少写三条例句）、需要抽哪些实体、期望返回什么信息或调用什么动作。这张表既是给团队的沟通文档，也是训练数据的来源清单，后续所有工作都是这张表的展开。

比如 weather_query 这一行会写：意图名 weather_query；例句"今天北京天气""北京明天多少度""上海会下雨吗"；实体 city 、 datetime ；动作是调天气接口。有了这张表，测试时就有据可依，而不是凭感觉判断"机器人好像聪明了一点"。特别是团队多人协作时，这张表能统一大家对意图边界的理解，减少大量沟通成本。

4. 核心实战：让机器人真正学会查天气的完整链路

4.1 建意图、喂样本、标注实体

我用天气查询当例子，因为它的复杂度刚刚好。先在 Build 页新建意图 weather_query ，把下面这些样本贴进去："今天天气怎么样""北京今天多少度""明天上海会下雨吗""帮我查一下深圳的天气""周末成都气温"。保存之后，逐条选中"北京""上海""深圳"这些词标成自定义实体 city ，再选中"今天""明天""周末"标成系统实体 datetime 。全部标完点 Train，等模型训练完成。

样本数量给一个经验值：一个意图最少 8 条，理想是 15 到 20 条。中文口语表达太丰富，5 条太少模型学不出泛化能力，但 50 条又没必要，会把维护成本拖高。另外，每加一个新意图，都要把旧意图的样本过一遍，确认新旧样本之间没有相互干扰。这个回归习惯越早养成，后面调优阶段越省心。

4.2 实体配置：系统实体和自定义实体怎么配合

自定义实体必须自己维护词表。我在 Recast.AI 里给 city 建了两个 value："北京"（同义词：帝都、首都、Beijing），"上海"（同义词：魔都、Shanghai）。建词表时有条铁律：同义词不能乱扩，"都"这种单字词千万别加进去，否则用户说"都挺好的"都可能被误抽成城市。 datetime 我一开始直接用系统实体，但测试发现"后天""下周五"这种中文相对时间，系统实体偶尔抽不出来，或者返回的格式很奇怪。

被实际语料逼出来的方案是"系统实体为主、自定义实体兜底"： datetime 继续用系统实体，但 Dialog 里不依赖它的具体格式，统一在 Code 节点里做一次时间归一化；如果实测发现某些常用词覆盖率太低，就单独建一个 timeword 自定义实体，把"今天、明天、后天、这周五、下周一"做成同义词表。这个取舍的思路是：模型负责把话听明白，具体的数据清洗和格式转换交给代码，各干各擅长的活。

4.3 用 Dialog Flow 搭整个对话流程

对话流的设计思路如下：起始节点进入后先匹配 weather_query 意图，命中后进入 Code 节点。Code 节点里先看实体解析结果中有没有 city ，没有就回问"你想查哪个城市的天气"；有 city 但没有时间，就默认查今天。用户回答了缺失信息后，下一轮还是会命中 weather_query ，但这时候 memory 里已经记住 city ，所以第二次进 Code 节点就不会再重复提问。这就是 Dialog 和 if-else 的分水岭：状态存在 memory 里，可以跨轮次使用，机器人开始有"记性"了。

另外一定要在 Dialog 最外层留一个 fallback 节点，挂在"没有任何意图被可靠识别"的分支上。我给这个节点准备了两三套不同话术轮着用，比机器人每次都机械地重复"我没听懂"舒服太多。这个兜底写得好不好，直接决定用户被逼到什么程度才会放弃。

4.4 挂 Code 节点接天气 API：机器人从"会聊"变"会做"

真正让机器人干活的是 Code 节点。简单理解，这个节点就是一个 webhook：用户说话后，平台把 NLP 解析结果和 memory 以 JSON 形式 POST 给你部署的接口，你的代码处理完业务，再把回复内容和 memory 变更返回给平台。当时收到的请求结构大致长这样（参数名以平台文档为准，核心思路是这个）：

{
  "nlp": {
    "intents": [{ "slug": "weather_query", "confidence": 0.98 }],
    "entities": {
      "city": [{ "value": "北京" }],
      "datetime": [{ "formatted": "2025-07-20T00:00:00.000Z" }]
    }
  },
  "memory": { "city": "北京" },
  "message": { "type": "text", "content": "北京明天天气怎么样" }
}

我的 Code 节点逻辑大概长这样：

async function getWeather(city, date) {
  // 换成你真实要调的天气接口
  const r = await fetch(
    `https://api.example-weather.com/v1/weather?city=${encodeURIComponent(city)}&date=${encodeURIComponent(date)}`
  );
  const j = await r.json();
  return `${j.condition}，${j.low}~${j.high}℃`;
}

module.exports = async ({ nlp, memory }) => {
  const entities = nlp.entities || {};
  const city = (entities.city && entities.city[0].value) || memory.city;
  const date = (entities.datetime && entities.datetime[0].formatted) || memory.date;

  if (!city) {
    return {
      replies: [{ type: "text", content: "你想查哪个城市的天气？" }],
      memory: { ...memory }
    };
  }

  try {
    const weather = await getWeather(city, date || "今天");
    return {
      replies: [{ type: "text", content: `${city} ${date || "今天"}：${weather}` }],
      memory: { ...memory, city, date }
    };
  } catch (e) {
    return {
      replies: [{ type: "text", content: "天气接口暂时不可用，稍后再试试吧。" }],
      memory: { ...memory }
    };
  }
};

这段代码最核心的动作有四个：从实体里取 city 和 date 、从 memory 里取上一轮记住的值、生成回复文本、把 city 和 date 写回 memory。写回 memory 这一行尤其关键，它让用户下一句"那后天呢"能被接住——因为下一轮再次进入同一个 Code 节点时， city 从 memory 里拿到了，新句子又提供了新的时间，用户完全不需要重复城市名。

5. 训练与调优：把识别准确率从"能用"打磨成"好用"

5.1 训练样本的质量比数量更重要

很多新手以为一个意图给 50 条样本就一定比 10 条强，实际上 50 条高度相似的样本只会让模型过拟合到那几种固定写法上。我给团队定的规矩是：每个意图 10 到 20 条，但句型和词汇要刻意拉开差距。查天气要覆盖陈述式"北京今天多少度"、疑问式"上海明天会下雨吗"、省略式"明天呢"，动词也要换着来：查、看、问、想知道、告诉我。这些句子最好来自真实用户聊天记录，而不是自己坐在工位上拍脑袋编。没有现成记录时，我习惯找身边朋友用"如果是你，你会怎么问"的方式口述一批，真实度比凭空想高很多。

自己编样本还有一个隐蔽问题：你很自然会用书面语，但真实用户开口就是"今儿北京啥天气啊""魔都明天冷吗"，这两种表达风格差异极大。所以样本来源的真实性，某种程度上比样本数量更重要。

5.2 置信度阈值怎么设

Recast.AI 给每个意图的识别结果都带一个 confidence ，范围 0 到 1。平台允许设一个置信度阈值，低于阈值的输入会被当成"没把握"，直接走 fallback 分支。这个值的调参逻辑很直白：设太低，什么话都会被硬接住，答非所问；设太高，稍微换种说法就全部 fallback，用户觉得机器人特别笨。我的起始经验值是 0.6 到 0.7，上线之后看日志里的实际分数分布再微调。判断标准就两个数：误判率太高就往上调阈值，接不住率太高就往下调。这是标准的看数据调参，而不是拍脑袋调参。

调阈值时我还会顺便看"意图置信度和实体抽取置信度"是不是一致。遇到过一种情况：意图识别分数挺高，但实体抽得很稳的平台，天气域名识别没问题；也有反过来，意图飘忽不定但实体正常的。这种不一致往往意味着某个方向的样本质量有问题，需要回去补样本，而不是单纯调一个数字。

5.3 用错误样本做反向优化

上线后的用户日志是最值钱的训练资料。我每周会固定花半天时间，把日志里被误判的句子捞出来分成两类。第一类是"该识别却没识别出来"，直接把它加进对应意图的训练样本里；第二类是"不该识别却识别到了"，比如用户说"我不想查天气了"被识别成 weather_query ，这种情况我会给另一个意图补上类似的样本，让模型知道这句话有别的归属。这样持续两三周，识别率的提升会非常明显，比你在 Test 面板里反复测自己编的句子有效得多。

这里要强调一个态度问题：Test 面板自嗨是没意义的。真实语料的分布永远比你以为的歪，用户会用各种你没想到的说法轰炸你的机器人。把日志里的误判当成免费的标注数据，保持每周围绕错误做迭代，模型效果才会进入正向循环。

6. 多渠道接入：网页嵌入、REST API 与会话状态细节

6.1 内置渠道：一分钟网页嵌入

Recast.AI 自带不少渠道，最省事的是网页嵌入。控制台会生成一段脚本，贴到页面上就是一个可聊天的浮窗组件，还能配置欢迎语。团队内部验收、给领导看 Demo、给用户做内测，用这个就够了，不需要自己写任何前端交互代码。除网页之外，像 Facebook Messenger、Slack 这类国际渠道也有内置对接，主要工作是去对应平台申请 token 再填进配置里。这里要提醒一句：平台官方的渠道列表未必覆盖国内常用平台，如果要接微信公众号这类渠道，通常得自己走 API 包一层，不要指望有现成的一键接入配置可以用。

6.2 REST API 做自定义接入

自定义接入的核心其实就一个接口：把用户说的一句话 POST 过去，拿到机器人的回复。当时调用的方式大致是这样（真实 URL 以后台 API 文档为准，这里看思路）：

const res = await fetch("https://api.recast.ai/v2/converse", {
  method: "POST",
  headers: {
    Authorization: "Bearer 你的Token",
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    conversation_id: "user_123",
    message: { type: "text", content: "北京明天天气怎么样" }
  })
});
const data = await res.json();
data.results.replies.forEach((r) => console.log(r.content));

这段代码里最要紧的是 conversation_id 。同一个用户的多次消息必须传同一个 id，平台才能把多轮对话串起来，memory 也才能正常工作。如果不传或者每次都不一样，用户说"那后天呢"这种省略句时，机器人完全接不住上下文。我的做法是用自己的用户 ID 拼上渠道前缀做映射，比如 wechat_123 、 web_456 ，这样同一个用户无论从哪里进来都有独立的会话上下文，不会互相串场。

6.3 会话状态管理的细节

会话状态的另一个细节是 memory 的生命周期。Recast.AI 的 memory 是跟 conversation_id 绑定的，只要 id 不变，中间变量就会一直存在。我的习惯是业务结束时显式清空：比如天气查完之后，把 city 和 date 从 memory 里删掉，只保留真正需要跨轮次的字段。另外，跨业务切换时也要重新初始化，否则用户早上订了座，下午问"帮我看看天气"，机器人还带着餐厅的上下文，很容易答非所问。

如果你做的是纯一次性问答，完全不需要多轮记忆，最简单的做法是每次请求都用新的 conversation_id 。省心，但代价是用户一旦追问"为什么"或者"那别的呢"，机器人就完全接不住。所以这个选择本质上是"你到底要不要让机器人有记性"的产品决策，不是技术问题。

7. 实战踩坑清单：五个最容易翻车的问题和排查思路

7.1 意图互相打架：一次完整的排查过程

项目上线第二周，日志里出现一个怪现象：用户问"你们几点关门"，机器人一会儿回答营业时间，一会儿又跳转人工客服入口。我一开始以为是 Dialog 节点画错了，把节点和连线检查了半天没发现问题。回到 Test 面板反复试同一句话，才注意到它命中 store_hours 意图的置信度有时是 0.71，有时是 0.68，而 contact_human 的置信度紧跟其后是 0.69。问题一下就清楚了：这两个意图的训练样本里都包含"几点""关门""在吗"这些词，模型在它们之间摇摆不定。

修复过程分三步：先给 store_hours 补上更多强调时间信息、位置信息的样本，比如"晚上营业到几点""周末开门时间是""你们在南门还是北门"；然后删掉 contact_human 里面和营业时间相关的错误正样本，比如"你们几点上班有人吗"这类模棱两可的句子；最后重新训练并跑回归测试集。修复后这个摇摆基本消失。这个案例给我的教训是：遇到识别不稳定，先不要一股脑怀疑代码结构，回 Test 面板把同一句话多试几遍，看置信度分布才是定位问题的第一步。

7.2 实体识别的边界：别把半个句子标进去

实体标注的颗粒度是最容易被忽略的坑。有一次我发现 city 实体返回的值是"北京天"，一开始还以为是模型抽错了，排查下来发现是团队里有人在标注样本时把"北京天气"整段选中标成了 city 。模型照着学，自然会把"北京天"当城市。修复方法很笨但很有效：逐条检查训练样本里的高亮标注区域，确保实体边界准确，同时给同义词补上常见组合。

另一个相关问题是实体缺失。自定义实体如果没有命中，返回结果就是空的，很多新手在 Dialog 里想当然地"有实体就怎么样，没实体就怎么样"，结果漏了"实体值存在但为空字符串"的情况。我的建议是：所有核心实体的使用都要做一次空值判断，并且把判断逻辑放在 Dialog 分支之前，或者干脆扔进 Code 节点统一处理，别在画布上做太多手工判断，否则分支数量会快速失控。

7.3 兜底话术写太死，用户被绕晕

第一版 fallback 节点只会说一句"抱歉，我不太明白"，结果用户随便说几句没被识别的话，就会陷入机器人连续道歉的死循环，整个对话体验非常劝退。后来我把 fallback 改成了有限次数策略：第一次没听懂，问一句"你是不是想问天气、订座或者展会信息"；第二次还听不懂，提示"转人工请回复人工"；连续三次没成功就主动结束对话，并给出转人工入口。这样既给了用户出路，也给了对话流出口，不会再在分支里无限转圈。

这个策略的通用性很强。无论你做什么类型的机器人，连续两次识别失败后，用户的耐心基本就到极限了。与其让机器人和用户互相折磨，不如早点把"接不住的情况"变成产品里的一条正常流程，例如转人工、留电话、发表单链接，都算是对用户负责的处理方式。

7.4 模型改完没生效：版本发布机制的坑

这是我困惑了一整天的坑。明明在 Build 里改了十几个样本，Test 面板测起来也完全正确，但线上机器人行为还是旧版本。后来发现问题是两步叠加导致的：一是样本改完没点 Train 重新训练，二是 Train 完之后还要把对应的模型版本发布到线上渠道，Recast.AI 的训练和发布是分开的两件事。控制台 Test 用的可能是最新训练结果，但线上渠道绑定的还是上一个已发布版本，两边数据不一致，现象就是"测试对、线上错"。

从那以后我养成了一个固定习惯：每次改完样本，按"改样本 -> Train -> Test -> 发布"四步走，并且在项目文档里记录发布版本号和改动内容。这套流程后来迁移到其他 NLP 平台时也完全适用，凡是模型和线上配置之间隔着"发布"这一环的产品，都必须把发布当做一个显式动作对待，不能默认改完就生效。

7.5 中文时间表达：别让系统实体背锅

中文时间词对系统实体真的不太友好。"明天"能识别，"后天"概率下降，"下周五"经常直接挂掉。这个问题的解法分三层。第一层：时间不是核心槽位时，干脆不识别，在 Code 节点里用简单的正则兜底；第二层：时间是核心槽位时（比如订座机器人），建一个自定义实体 timeword ，把"今天、明天、后天、这周五、下周一"这种常见词做成词表；第三层：拿到原始表达后，统一在代码里转成 yyyy-MM-dd 格式，再传给下游 API。

这套方案虽然土，但胜在稳定可控。它背后有一条更通用的原则：意图交给模型，细节交给代码。凡是解析规则明确、边界清晰的字段（比如日期、金额、编号），优先用代码处理；凡是语义模糊、说法多变的部分（比如用户到底想干嘛），才适合丢给 NLP 模型。这样分工，你和模型都不会被逼到极限。

8. 从 Demo 到上线：绕不开的增量迭代、兜底设计与数据原则

8.1 先跑通闭环，再膨胀功能

我见过太多项目死在"功能太多"上。第一版就想把天气、订座、退款、闲聊全上，结果每个功能都识别不准，团队精力被摊薄到十个方向上，哪个都没有打磨透。正确顺序是：先选一个核心场景，把意图、实体、Dialog、API、渠道全部跑通。哪怕只支持一个功能，也是完整闭环，用户能从入口问到答案，链路能验证产品价值。闭环跑通之后再逐步加第二个、第三个场景。

每加一个新意图，都要把之前的老用例回归一遍，确保新样本没有污染旧意图。这个"增量推进 + 回归测试"的习惯，是项目从 Demo 走向生产环境最关键的差异——Demo 只需要证明"能聊"，生产环境要做到"聊得稳"。回归测试集我会存在文档里，每次训练完手动跑一遍，虽然笨，但对小团队来说效率远高于写一整套自动化测试框架。

8.2 给机器人设计"接不住"时的体面

一个机器人给人留下的印象，往往取决于它不会回答的时候怎么表现。用户问了个冷门问题，机器人回"我不明白"，用户心里想的是"这机器人真弱智"；如果回"这个问题我暂时没有答案，我帮你转人工客服来跟进"，用户至少觉得它懂礼貌、有退路。所以在所有对话流的最外层，一定要设计一个"有尊严的兜底"：承认不会、给出替代方案、提供转人工入口。这个设计成本极低，但对体验的提升极为明显。

兜底话术也值得多备几套轮着用。我见过有的机器人每轮都回一模一样的"抱歉，我暂时无法理解你的意思"，用户连续问三次被同一句话打回来三次，体验瞬间崩塌。准备三四套措辞不同的兜底，配合 7.3 里的有限次数策略，整体体验会自然很多。这个小细节很多文档不写，但实际用户反馈里差别非常大。

8.3 用户数据要当回事

最后聊一个容易被忽略但必须重视的点：聊天记录既是训练资料，也是用户隐私。我在项目里定了两条铁律。第一，日志采集只记录意图 slug、置信度等模型特征，不落完整消息原文；需要保留原文做训练样本时，必须先做脱敏，去掉姓名、电话、地址等敏感字段。第二，memory 里绝不存敏感信息，对话结束后及时清理会话状态。Recast.AI 作为云平台，数据是存放在服务端的，这一点在选型时就要跟业务方讲清楚，尤其涉及企业客户信息时，不能等出事再补救。

也是因为平时有导出训练数据、记录配置文档的习惯，后来平台宣布停服时，我的项目迁移成本被压到了最低——把意图和实体导出，重新在别的平台建一遍，对话逻辑重画一下，就完成了转移。现在我做任何对话项目，都会把"训练数据可导出、平台依赖可控"当成一条默认要求。这个习惯救过我一次，以后大概率还会再救我一次。