chatbot-flow-design

聊天机器人流程设计

资深增长从业者为网站聊天机器人和 AI Agent 设计对话流程的实战指南。涵盖意图识别架构、分支逻辑、兜底处理、转接人工以及对话分析。核心在于打造一个清楚自身能力边界、并能在超出能力范围时恰当转接的机器人。

网络上的大多数聊天机器人都以两种方式之一失败。脚本式机器人一旦遇到用户以脚本未预料到的方式提问，就会失效；用户会被推入不适合其情况的决策树。没有结构的大模型驱动机器人则会产生幻觉；它们会自信地回答有关定价、政策或能力的问题，却经常编造答案，从而增加支持负担、损害信任。

好用的聊天机器人会采用不同做法。它们有一套意图架构，明确界定机器人能够和不能处理的内容。它们以知识库为依据生成回复，因此不会凭空编造事实。对于不明确或超出范围的意图，它们会设置明确的兜底路径。机器人的工作完成后，它们能顺畅地转接人工。受众信任这类机器人，因为它们会坦诚说明自身的能力范围。

本指南以一位资深增长从业者的视角展开：他见证过聊天机器人如何成为值得信赖的品牌窗口，也见证过它们如何沦为风险源。他注重实用，明确主张区分这两种结果的架构设计；在聊天机器人并非合适投资，或现有聊天机器人需要重新设计而非微调时，也会直言不讳。

适用场景：首次规划聊天机器人、审查会产生幻觉或无法处理边界情况的聊天机器人、设计意图架构和兜底模式，或决定何时转接人工。

---

本技能涵盖内容

本技能涵盖将聊天机器人设计为对话流程架构，而非聊天机器人的实现。与增长工具相关的区别如下：

• ai-content-collaboration 涵盖内容工作流中的 AI。本技能涵盖面向客户对话中的 AI。
• integration-orchestrator 涵盖聊天机器人部署中的跨团队协作。本技能关注对话设计本身。
• pm-spec-writing 涵盖供工程师构建机器人的规格说明。本技能关注对话应该是什么样；pm-spec-writing 关注如何传达这一点。
• discovery-research-synthesis 涵盖为意图架构提供依据的客户研究。它是本技能的输入，而非本技能的一部分。
• **chatbot-flow-design（本技能）**涵盖意图架构、以知识库为依据生成回复、兜底模式和转接规范。

适用对象：负责推出聊天机器人增长工具的增长营销人员和产品营销人员、为营销或支持场景设计对话流程的内部团队，以及为客户提供聊天机器人服务的代理机构。

范围之外：内容工作流中的 AI（由 ai-content-collaboration 涵盖）；聊天机器人的工程实现（通过 pm-spec-writing 交接）；特定平台的机器人配置（属于实现环节）；语音 Agent 和 IVR 流程（方法不同，但相关原则也适用）。

---

聊天机器人的部署决策：何时值得部署聊天机器人

在设计聊天机器人之前，先判断聊天机器人是否是合适的工具。

以下情况值得部署聊天机器人：

• 受众会反复提出相同的问题。例如常见问题支持、产品功能咨询、资格筛选转接。机器人处理大量请求；人工处理例外情况。
• 受众访问网站的时间段内，人工无法及时回复。机器人能有效填补服务覆盖时段的空缺。
• 机器人可以依据真实知识（文档、产品规格、定价页面）生成回答。没有知识依据时，机器人的回答轻则流于笼统，重则凭空捏造。
• 团队有能力维护机器人。聊天机器人会逐渐失效；意图会发生变化；知识库需要更新。如果不承诺持续维护，机器人就会变成过时的负担。

以下情况不值得部署聊天机器人：

• 受众期待与真人交谈。销售沟通、复杂的故障排查和敏感话题通常更适合优先由人工处理。
• 团队无法让机器人依据真实知识作答。没有知识依据的机器人要么产生幻觉，要么回答过于笼统，毫无价值。
• 部署机器人会取代现有的有效人工渠道。用低质量机器人取代高质量的销售聊天会降低体验。
• 受众规模足够小，直接与人工沟通更高效。
• 团队无法维护机器人。过时的机器人会给出错误答案。

需要决定的不是“我们是否应该部署聊天机器人”，而是“聊天机器人是否适合这类特定受众和对话”。

详情见 references/chatbot-decision-criteria.md。

---

脚本式机器人、产生幻觉的机器人与结构化引导式对话

这是核心框架。

脚本式机器人。 僵化的决策树。“按 1 选择 X，按 2 选择 Y。”用户的表达一旦超出脚本预设，就会失效。这相当于自动电话语音菜单。代价：用户真正的问题得不到回答；机器人将用户推入不合适的流程；受众离开时的体验比没有机器人更差。

产生幻觉的机器人。 由大模型驱动，但没有结构。它会自信地回答有关定价、政策和功能的问题，而且经常编造答案。存在责任风险，会侵蚀信任；错误答案传到客户手中时，还会增加支持负担。代价：机器人自信地给出错误答案，对品牌造成的损害可能比不部署机器人更大；团队只能通过客户投诉才发现这些幻觉。

结构化引导式对话。 由大模型驱动，并配有意图架构、基于知识库的依据、明确的回退路径，以及转接人工的明确机制。机器人清楚自己知道什么、不知道什么，并会恰当地进行转接。代价：前期设计工作量很大；维护工作确实存在；由于机器人会坦诚说明自身能力范围，受众愿意信任它。

检验标准：向机器人提出一个超出其预定范围的问题。它会自信地编造答案（产生幻觉）、僵硬地拒绝（脚本式），还是坦诚地将用户转接给人工或引导其使用其他资源（结构化引导式）？第三种才是目标。

---

意图架构

定义机器人能够和不能处理的内容。

原则。 机器人能处理的意图是明确限定的。每种意图都对应一种对话模式（要提出的问题、作为依据的知识、要提供的回复）。超出意图范围的内容会进入回退流程。

意图设计模式。

• 命名意图。“价格问题”“功能对比”“集成问题”“支持升级”“演示请求”。每种意图都有明确名称。
• **意图层级。**顶层类别下设子意图。“价格问题”包含“套餐对比”“折扣咨询”“账单问题”等子意图。
• **意图边界。**每种意图都有明确范围。超出范围的话题会转入回退流程。

**意图覆盖率。**机器人的意图应覆盖 70-90% 的预期对话，其余部分进入回退流程。试图覆盖 100% 往往会导致意图集臃肿，使机器人无法可靠处理。

**意图维护。**随着产品演进、受众变化和对话内容改变，意图也会逐渐偏移。定期审查可以发现哪些意图有用，哪些需要调整。

详见 references/intent-architecture-patterns.md。

---

知识库 grounding

机器人的回复必须源自真实知识，而不是凭空编造出自信的答案。

**原则。**机器人的回复生成应参考结构化知识库（文档、产品规格、定价页面、支持文章）。机器人不编造答案，而是检索并呈现答案。

Grounding 模式。

• **检索增强生成（RAG）。**机器人会先在知识库中搜索相关内容，再生成回复。回复以检索到的内容为依据。
• **事实来源设计。**知识库是权威信息源。机器人回答时会指出底层信息来源。
• **引用规范。**机器人可以引用来源（“根据我们的定价页面，……”）。了解答案的出处对受众有帮助。
• **知识库维护。**随着产品演进，知识库也会持续维护；机器人的答案始终保持最新。

**产生幻觉的机器人导致的失败。**没有 grounding。大模型凭空生成听起来很自信的答案。团队通过客户投诉才发现答案有误。

**结构化引导带来的成功。**答案有据可依。机器人的回复与权威信息源一致，并能保持面向客户的信息准确性。

详见 references/knowledge-base-grounding-patterns.md。

---

分支与条件逻辑

机器人如何根据用户输入调整对话。

**原则。**机器人的对话可以根据用户输入（识别到的意图、先前的回答、用户属性）进行分支。分支能让对话显得更灵活。

分支模式。

• **意图驱动的分支。**不同意图会进入不同的对话流程。
• 上下文驱动的分支。“您想了解套餐 A 还是套餐 B？”会将对话引向对应套餐的信息。
• **用户属性驱动的分支。**登录用户可能会看到不同于匿名用户的回复；企业访客可能会看到不同于 SMB 用户的回复。
• **多轮分支。**对话会随着轮次逐步深入；后续轮次会基于先前的上下文展开。

**分支规范。**每条分支都应带来价值。装饰性分支（在不需要确认时仍要求确认）会增加阻碍。

**分支限制。**分支过深的机器人会导致用户流失。通常，进行 3-5 轮对话后，用户就会希望得到解决方案。

详见 references/branching-and-conditional-logic.md。

回退模式

当意图不明确或超出范围时会发生什么。

原则。 每段对话都有回退路径。机器人会针对“我不知道”“我不确定能否帮上忙”“让我为你联系人工人员”等情况，预先准备好回应。

回退模式。

• 澄清问题。“能告诉我更多关于你想找什么的信息吗？”请用户进一步说明；有时能解决问题。
• 建议意图。“我可以帮你处理 X、Y 或 Z。你问的是其中一项吗？”展示机器人能做什么。
• 资源转交。“我无法回答这个问题，但这里有一份介绍相关内容的[文档页面]。”
• 转接人工人员。“让我为你联系一位可以提供帮助的人工人员。”

**回退纪律。**设置多个回退层级。首先尝试澄清。如果经过一轮后仍不明确，就提供替代方案或转接人工人员。不要让用户反复进行 5 轮澄清。

**将回退视为诚实的原则。**承认自己不知道的机器人，比假装自信的机器人更能赢得信任。受众会原谅事先告知的局限；但会责怪那些自信给出错误答案的机器人。

详情请参阅 references/fallback-pattern-design.md。

---

转接人工人员

何时转接、如何转接，以及交接哪些上下文。

原则。 有些对话需要人工人员处理。当机器人超出自身能力范围、用户提出请求，或对话模式表明用户感到沮丧时，机器人会转接人工人员。

转接触发条件。

• 用户主动提出。“和人工人员交谈。”机器人立即转接。
• **意图超出范围。**机器人识别到用户的意图超出自身能力范围；转接时附上意图上下文。
• **反复回退。**经过 2-3 轮含糊不清的交流后，机器人会转接，而不是陷入循环。
• **由情绪触发。**用户的情绪表明其感到沮丧；机器人会转接，而不是继续尝试。
• **高风险主题。**敏感主题（取消、投诉、安全）默认转接。

**转接时的上下文交接。**转接时，机器人会向人工人员传递对话历史和识别出的意图。人工人员不必从头开始，而是从机器人停止的地方继续处理。

**转接质量测试。**人工人员能否顺利接手上下文，还是必须要求用户重复所有内容？后一种情况表明交接出了问题。

详情请参阅 references/escalation-to-human-patterns.md。

---

对话分析

衡量机器人的表现优劣。

**原则。**按意图、回退和转接分别跟踪机器人的表现。这些数据有助于维护和改进设计。

对话指标。

• **意图识别率。**有多少比例的对话被正确归类为相应意图？
• **各意图解决率。**以意图 X 开始的对话中，有多少比例成功解决（用户获得了所需答案）？
• **回退率。**有多少比例的对话触发了回退？回退率高表明意图存在缺口。
• **各意图转接率。**每种意图下，有多少比例的对话被转接？转接率高可能表明该意图不适合由机器人处理。
• **用户满意度。**条件允许时进行对话后调查。调查虽有用，但也有局限；许多用户不会回复。

诊断用途。

• 回退率高：意图缺失或不明确；扩展或完善意图集。
• 各意图解决率低：知识库不足；改进信息依据。
• 各意图转接率高：该意图可能不适合由机器人处理。
• 对话中反复触发回退：澄清问题未能奏效；重新设计澄清方式。

详情请参阅 references/conversation-analytics-patterns.md。

---

常见故障模式

快速排查。诊断方法见 references/common-chatbot-failures.md。

• “机器人编造关于定价的答案。” 属于幻觉机器人模式；没有基于定价的事实来源。
• “用户说机器人刻板又无济于事。” 属于脚本机器人模式；意图未涵盖真实问题。
• “销售团队对机器人错误判定潜在客户感到愤怒。” 意图识别或路由逻辑出错；检查潜在客户资格判定流程。
• “聊天机器人上线后，支持工单增加了。” 机器人给出错误答案，导致用户转而寻求支持；检查答案依据和问题解决情况。
• “用户在对话中途放弃。” 机器人陷入循环，或备用处理模式不完善。
• “我们无法判断机器人实际在做什么。” 缺少分析数据；在进一步更改前先添加监测。
• “机器人刚上线时表现出色；质量却下降了。” 维护不到位；知识库或意图集已过时。
• “机器人什么事都转给人工处理。” 升级逻辑过于宽松；机器人应该处理更多问题。
• “机器人试图独自处理所有问题。” 升级逻辑过于严格；机器人应该更频繁地升级处理。
• “用户抱怨机器人不记得五分钟前问过什么。” 多轮对话之间未保留上下文。

---

框架：聊天机器人流程设计的 12 项考量

设计或审核聊天机器人时，请逐项检查以下 12 项考量。

1. 是否选择聊天机器人。 对于这个受众和对话，聊天机器人是否合适？还是其他渠道更好？
2. 采用结构化引导式对话，而非脚本式对话或幻觉式回答。 意图架构；以知识库为依据；严格管理备用处理。
3. 意图架构合理。 为意图命名并明确其范围；预期对话的覆盖率目标为 70-90%。
4. 以知识库为依据。 从事实来源检索回答；机器人不编造答案。
5. 分支设计有价值。 每个分支都满足真实需求；对话深度限制在 3-5 轮。
6. 备用处理模式分层设计。 澄清问题、推荐意图、转交资源、升级至人工处理。
7. 明确升级触发条件。 用户主动提出、超出范围、反复触发备用处理、基于情绪判断、高风险情况。
8. 顺畅交接升级处理的上下文。 人工人员能够接续机器人未完成的对话。
9. 添加分析监测。 按意图统计识别率、解决率、备用处理率和升级率。
10. 明确维护周期。 定期更新知识库；审核意图集；验证机器人质量。
11. 品牌语气保持一致。 机器人的表达符合其所代表的品牌。
12. 如实评估受众适配度。 机器人服务其真正能够帮助的受众；对于不适配的受众，及时升级处理。

采用该框架后，聊天机器人能够清楚自己的知识范围，基于真实知识回答问题，适时升级处理，并通过坦诚说明自身能力范围赢得信任。

---

参考文件

• references/chatbot-decision-criteria.md - 聊天机器人何时值得部署，何时不值得。哪些条件足以支持构建。
• references/intent-architecture-patterns.md - 定义机器人能处理什么、不能处理什么。命名意图、层级、边界和覆盖范围。
• references/knowledge-base-grounding-patterns.md - 检索增强生成、事实来源设计、引用规范、知识库维护。
• references/branching-and-conditional-logic.md - 机器人如何适应对话。由意图、上下文、用户属性驱动的分支，以及多轮分支。
• references/fallback-pattern-design.md - 意图不明确或超出范围时的处理方式。多层回退模式。
• references/escalation-to-human-patterns.md - 何时、如何升级，以及需要提供哪些上下文。升级触发条件与交接质量。
• references/conversation-analytics-patterns.md - 按意图统计指标、诊断用途，以及为维护提供依据的数据。
• references/chatbot-anti-patterns.md - 看似聊天机器人，实则会削弱信任的模式。
• references/common-chatbot-failures.md - 10+ 种失败模式及其诊断与补救方法。

---

结语：当聊天机器人知道自己不知道什么时，才值得部署

能持续创造价值的聊天机器人，都是受众信任的机器人。不是因为它们能回答所有问题，也不是因为它们能力无限，而是因为它们坦诚说明自身范围，以真实知识为回答提供依据，并在机器人的工作完成时升级给人工处理。

这就是标准。低于标准的是脚本式机器人（僵化的流程树无法处理边缘情况）和幻觉式机器人（缺乏结构的大模型会编造信息）。高于标准的是结构化引导式对话：机器人的意图架构、知识库依据、回退规范和升级模式相结合，成为受众可以信赖的工具。

关键在于设计选择：定义机器人能做什么的意图；防止产生幻觉的知识库依据；妥善处理未知情况的回退模式；懂得何时退让的升级逻辑；揭示哪些做法有效、哪些无效的分析；以及确保机器人始终与其代表的品牌保持同步的维护规范。