小村软件有限公司
日本語 English 한국어 繁體中文 简体中文 العربية
联系我们
菜单

面向实际业务的聊天机器人设计最佳实践

· · AI, 聊天机器人, 网站建设, 咨询转化路径优化, 知识库

2026年04月08日 10:00 · 小村豪 · AI、聊天机器人、网站建设、咨询转化路径优化、知识库

本文整理的是制作面向网站的咨询聊天机器人、企业内部FAQ机器人、初次应答机器人时的通用原则。 一个能真正发挥作用的聊天机器人，比”模型有多聪明”更早已经把角色定位、知识来源、权限、转交条件、评估方法梳理清楚。

一谈到聊天机器人，很容易从”用哪个模型”“要不要做成RAG”“要不要做成多智能体”开始讨论。 但在实务中真正有效的顺序稍有不同。

应该先确定的是：要减少谁的哪项工作、减少到什么程度。 一旦这个顺序被打乱，对话即便看起来像模像样，也不会真正转化为咨询或提升业务效率。

在技术型、B2B类型的网站上，这种倾向尤为明显。 真正有价值的，不是让闲聊持续得更久。 而是准确地介绍服务内容，并在必要时把用户引导到合适的页面或负责人那里。 当前主流的开发指南中，也强烈体现出在生产级质量下，应该把评估、知识落地（grounding）、护栏（guardrail）、转交这几项分开设计的前提。123456

目录

  1. 先说结论
  2. 先建立整体框架
  3. 最先要确定的是”要减少谁的哪项工作”
  4. 对话设计比模型选择更靠前
  5. 知识设计决定了质量的大半
  6. 提示词与其做成长篇人格设定，不如做成简短的运营规则
  7. 安全设计不能只靠”拦截危险问题”
  8. 从一开始就确定转交给人工的条件
  9. 没有评估的改进几乎等于凭运气
  10. 如果部署在网站上，就要和咨询转化路径一体化设计
  11. 用90天打好基础的推进方式
  12. 常见的失败
  13. 总结
  14. 相关文章
  15. 参考资料

1. 先说结论

用比较粗略但在实务中好用的说法概括，大致是这样。

  1. 聊天机器人最初先确定一个用途，效果会更扎实。
  2. 比选择模型更靠前，需要先确定回答所依据的信息来源。
  3. 需要区分”无法给出依据的回答”和”应该转交给人工的回答”。
  4. 风险越高的处理环节，权限和确认环节越不能被削减。
  5. 在生产环境中运营时，如果没有对话日志和评估集，改进几乎全凭直觉。
  6. 如果部署在网站上，比起让对话持续得更久，帮助用户理解页面内容、引导用户走向咨询转化路径更容易产生价值。

聊天机器人只要设计得当，就会很方便。 但是，如果把它扩展成什么都能回答的综合窗口，精度、运营、责任范围会一下子全面崩溃。 一开始把范围做窄，从确实能发挥作用的领域再逐步扩展，结果反而会更快。7

2. 先建立整体框架

首先来看整体框架。

是否是否用户提问是否在支持范围内知识检索 / 工具调用咨询页面 / 负责人引导是否满足权限与安全条件附带依据的回答 + 下一步行动转交给人工日志 / 评估 / 改进

这张图的要点在于，聊天机器人并不是一段提示词，而是包含引导路径、知识、权限、评估的一整套机制。 设计时不能止步于”回答问题”，而要连同回答的条件、不回答的条件、以及接下来该引导用户去哪里一起考虑进去。

当前主流的工具生态，也是基于这种思路来构建的。 Google Cloud把webhook、转交规则（handoff rules）、评估（evaluation）作为独立的功能模块，OpenAI则把固定model snapshot和构建evals作为生产环境运营的基本做法。12834 也就是说，不要试图仅凭一段提示词解决所有问题，这是最初的最佳实践。

3. 最先要确定的是”要减少谁的哪项工作”

在制作聊天机器人之前，先把用途收窄为一个。 如果这一点含糊不清，评估标准和知识设计都无法确定。

把用途大致整理成表格，如下所示。

用途 主要价值 主要指标 最初不应该做的事
网站的咨询转化路径 不让访客感到迷茫，引导至合适的页面或咨询入口 关键页面到达率、咨询转化率、跳出率 让闲聊持续得太久
支持类初次应答 提高FAQ和操作步骤的自助解决比例 自助解决率、平均处理时长、重复咨询率 一开始就把例外情况全部自动化处理
企业内部知识检索 缩短信息查找时间 回答到达时长、重复检索率、工时削减量 在权限尚未梳理清楚的情况下就跨部门检索全公司文档

在这些用途中，最容易作为第一个项目来实现的，是对象范围窄、答案正本容易确定的场景。 例如：

  • 产品FAQ的初次答复
  • 咨询前的服务介绍
  • 企业内部操作手册的检索

这类场景比较容易起步。

反过来，

  • 合同判断
  • 金额确定
  • 例外审批
  • 因客户而异、个别条件较强的咨询

这类场景，最好一开始就不要作为主战场。

此外，从一开始就需要采用多智能体（multi-agent）架构的场景其实并不多。 Microsoft也整理指出，单智能体（single-agent）架构能让实现更简单、降低运营负担、形成更容易预测的执行模型，在没有明确的分离理由之前，建议先用single-agent进行验证。7

4. 对话设计比模型选择更靠前

聊天机器人容易失败的原因之一，是对话的入口和出口没有被定义清楚。 如果做成”总之自由输入，什么都可以问”，能做的事和不能做的事之间的边界就会变得模糊。

4.1 固定对话的入口

在首条消息中先展示支持范围，会让对话更稳定。 例如面向网站场景，可以先展示：

  • 可以处理的咨询内容
  • 可以立即引导的页面
  • 咨询时所需的最小信息

把这些先呈现出来，对话的偏差就会减少。

如果能使用按钮或快捷回复，比如：

  • 想了解费用
  • 想知道能否处理某类需求
  • 想看案例
  • 想直接咨询

像这样设置最初的分支选项，会比纯自由输入稳定得多。

4.2 询问的信息应保持最小化

向用户询问的项目，只应限于会改变回答或路由方向的内容。 如果因为”顺便问一下比较好”而增加询问项，会导致跳出率上升。

例如：

  • 所属行业
  • 咨询类型
  • 是否已有既有系统
  • 紧急程度

如果这些信息会改变接下来的引导方向，那么询问是有意义的。 反之，暂时用不到的信息应该放到后面再问。

4.3 确定回答的结束方式

好的回答不应止步于正文本身。

  1. 结论
  2. 依据或参考来源
  3. 接下来可以采取的行动

按这个顺序结束，对话才更容易与业务衔接。

特别是在网站场景中，比起在对话内部就把一切说完，更有价值的往往是：

  • 引导前往相关服务页面
  • 查看案例
  • 引导前往咨询表单

这类明确的下一步。

4.4 把高风险话题分流到专用路径

身份验证、个人信息、金额、合同、例外审批这类高风险领域，最好不要与常规的引导流程走同一条路径。 Google Cloud的转交规则（handoff rules）中，也明确给出了把高风险请求转交给特定agent的示例。3

5. 知识设计决定了质量的大半

聊天机器人的质量更容易因知识管理不善而崩溃，而不是因为模型本身。 如果作为回答依据的信息本身含糊不清，无论用哪个模型都难以稳定。

5.1 首先确定”以什么作为正本”

至少应该提前确定以下几点。

  • 以哪些文档或页面作为正本
  • 谁是更新负责人
  • 以怎样的频率更新
  • 何时废弃过时信息

如果没有这一层规则，机器人就会同时捡起旧信息和新信息。 而这种不一致，很大概率会被用户直接察觉到。

5.2 不要按页面单位切分，而要按语义单位切分

在RAG场景中常见的失败，是直接把PDF或页面原样塞进去就结束了。 实际上，按照

  • 一项制度说明
  • 一个操作步骤
  • 一条FAQ
  • 一项注意事项

这样以语义为单位来处理，回答才会更稳定。

Microsoft指出，RAG的质量取决于内容准备工作，并把chunking、向量化（vectorization）、混合检索（hybrid search）、语义排序（semantic ranking）作为基本准则来介绍。5 OpenAI的file search同样以查询重写、多次检索、关键词+语义检索、重排序（reranking）为前提。9 也就是说，最佳实践不是”把文档放进去”，而是”把文档转换为可检索的知识”。

5.3 展示依据来源和更新日期

能让用户安心的，不是很会说话的机器人，而是依据可以被追溯的机器人。

  • 参照了哪个页面来回答
  • 出自哪份文档的哪个条目
  • 信息的更新时间是什么时候

如果能展示这些信息，出错时的排查也会更容易。

OpenAI的web search本身就以返回带依据的回答为设计前提，Microsoft Copilot Studio也提倡有据可查、带引用的回答（grounded, cited responses）。1011 即便是从网站内部或企业内部文档中检索答案，也应以这种”依据可追溯”的状态为目标，运营起来才会更顺畅。

5.4 把最新信息分流到外部检索

对时效性要求较高的主题，不应仅依赖固定知识来回答。

例如：

  • 营业日
  • 价格调整
  • 招聘信息
  • 故障信息
  • 法律修订或制度变更

这类内容。

对于这类问题，比较安全的做法是通过另一条路径参照信息源网站或API，或者明确回复”最新信息请查看该页面”。 如果把公开网站作为知识来源，也应先明确信任哪些域名。Copilot Studio也以限定在已配置域名范围内的检索，以及引用（citations）、相关性检查（relevance check）为前提。11

6. 提示词与其做成长篇人格设定，不如做成简短的运营规则

聊天机器人提示词中真正起作用的，不是冗长的人格设定，而是简短且明确的运营规则。

至少分成以下4层来整理，会更容易梳理清楚。

  1. 角色定位
  2. 可以参照的知识和工具
  3. 可以回答的条件 / 需要转交的条件
  4. 回答的格式

例如，角色定位可以简短地写成”负责咨询前的服务介绍”或”负责引导企业内部操作步骤”。 回答格式也只需要”结论 → 依据 → 下一步行动”即可。

反之，效果不佳的提示词往往会呈现出以下特征。

  • 只有人格设定写得很长
  • 回答的依据含糊不清
  • 使用工具的条件不明确
  • 没有写明转交条件

6.1 使用结构化输出

在订单状态、预约名额、咨询分类这类需要衔接到后续处理的场景中，最好不要只依赖自由文本。 OpenAI也介绍了使用结构化输出（Structured Outputs）返回JSON的做法。1

给用户看的文字和机器接收的值应该分开处理。 例如：

  • 展示文本：给用户看的说明
  • intent：咨询类型
  • confidence：判断的置信度
  • next_action：下一步引导方向

仅仅做到这一层区分，运营就会稳定不少。

6.2 固定model version，评估之后再更换

在生产系统中，”昨天和今天的回答方式略有不同”这种情况会成为事故。 OpenAI建议在生产应用中固定（pin）model snapshot，并构建用于衡量提示词行为的evals。1 此外，也明确了应以evals → 提示词工程 → 微调（fine-tuning）的持续循环来进行优化。2

6.3 按任务区分使用不同model

不需要让单一model承担全部任务。 OpenAI也介绍了这样的区分方式：低延迟且明确的处理使用GPT系列model，复杂且模糊度较高的判断使用reasoning系列model。12

在实务中，

  • FAQ回答或分类使用较轻量的model
  • 例外判断或复杂摘要使用reasoning model
  • 高风险判断交给人工

这样区分，成本和质量都会更容易保持稳定。

7. 安全设计不能只靠”拦截危险问题”

一提到安全设计，很容易只联想到对有害问题的拦截。 但在实务中，真正重要的并不止这一点。

7.1 以prompt injection为前提

在基于LLM的机器人中，最好以存在prompt injection风险为前提来设计。 Microsoft整理出direct和indirect两种类型，并指出通过外部网站或文件中嵌入的隐藏指令（hidden instruction），会话（session）有可能被劫持。613

也就是说，在会读取外部文档或网页内容的机器人中，需要做到：

  • 不把外部内容与系统指令（system instruction）同等对待
  • 将工具执行权限降到最小
  • 在高风险处理之前加入确认环节

7.2 将权限降到最小

“能读的资料全部都能读”“能执行的操作全部都能执行”是危险的。 Microsoft的安全指南中也强调了最小权限原则（least privilege），以及将外部内容的影响加以隔离的重要性。6

对于企业内部机器人来说尤其应该提前确定：

  • 各部门的查看权限
  • 各客户之间的信息隔离
  • 排除包含个人信息的文档

7.3 个人信息和身份验证应放在独立的层面处理

不应想着”机器人应该会自动做好遮蔽处理”，这样想并不安全。 Microsoft关于公开网站知识落地（public website grounding）的说明中也明确指出，用户输入的个人数据（personal data）并不会被自动清除或遮蔽（scrub / mask）。11

如果要处理个人信息或客户特定数据，需要具备以下设计：

  • 身份验证在应用层完成
  • 缩小可获取信息的范围
  • 保留审计日志
  • 在回答之前满足身份确认条件

7.4 安全不是开发的最后一步，而应从一开始就纳入循环

NIST的生成式AI风险管理框架（Generative AI Profile）也把风险管理设定为贯穿设计、开发、使用、评估各个阶段的前提。14 也就是说，安全设计不是发布前的最后一项检查条目，而应该从一开始就写入需求规格中。

8. 从一开始就确定转交给人工的条件

只写一句”如果无法回答就转交给负责人”，这样的设计是脆弱的。 实际上需要明确：在什么条件下、转交给谁、连同什么信息一起转交。

例如，以下这些条件比较适合从一开始就设为转交条件。

  • 需要身份验证的问题
  • 需要确定合同或金额的问题
  • 无法给出依据的问题
  • 连续两次以上未能妥善引导的问题
  • 投诉或紧急性较高的咨询
  • 法务、劳务、医疗等高风险领域的咨询

Google Cloud的转交规则（handoff rules）中也明确指出，相比基于指令（instruction）的转交，可以使用确定性（deterministic）的控制方式。3 风险越高的领域，比起”大概会转交”，”满足这个条件就一定转交”这样的运营方式更容易落地。

转交时应该交给人工的信息，也提前确定好会更省心。

  • 到目前为止的对话记录
  • 已经获取的信息项
  • 参照过的页面或文档
  • 机器人卡住的原因
  • 接下来希望人工确认的要点

只要这5项信息齐全，转交之后的返工就会明显减少。

9. 没有评估的改进几乎等于凭运气

聊天机器人改进过程中最危险的做法，是只看了几条对话就凭感觉觉得”好像变好了”，然后继续推进。 这样一来，每次调整提示词，其他部分都可能随之出问题。

OpenAI建议先编写evals，用接近实际运营场景的输入来运行测试。2 也就是说，改进的起点不是提示词，而是评估集。

9.1 至少应该关注的指标

角度 指标 关注的理由
对话成果 用户目标达成度（user goal satisfaction） 判断用户的目的是否得到实现
工具使用 工具调用正确率（tool correctness） 判断是否使用了正确的工具及正确的参数
依据性 是否有引用来源、幻觉（hallucination）率 减少看似合理却不准确的回答
运营 转交率（escalation rate）、跳出率、平均轮次数 判断对话体验是否过于沉重
业务成果 咨询转化率、自助解决率、处理时长 衡量机器人导入带来的价值

Google Cloud的CX Agent Studio中，也把用户目标达成度、工具调用正确率、幻觉等作为评估指标来整理。4 这种思路在几乎任何实现方式中都可以直接借用。

9.2 改进不是一次性的杀手招，而应作为循环持续运转

改进的顺序，大致按以下方式就足够了。

建立评估集测量当前的prompt / model表现对失败案例分类修正知识 / prompt / routing / handoff重新评估生产环境监控

如果没有这个循环，改进就会依赖个人的直觉。 反过来，有了这个循环，就能更容易追踪”哪里变好了、哪里变差了”。

10. 如果部署在网站上，就要和咨询转化路径一体化设计

部署在企业网站上的聊天机器人，聊天本身未必是主角。 在很多情况下，把它设计为以下这些环节的辅助线，会更自然。

  • 传达这是一家怎样的公司
  • 引导用户应该查看哪个服务页面
  • 展示案例或FAQ
  • 减少咨询前的不安

尤其是在技术型、B2B类型的网站上，服务说明往往比较复杂。 因此，与其试图在聊天中把一切都说清楚，不如引导用户前往合适的页面，这样往往效果更好。

例如，以下这个流程的适配度相当高。

  1. 确认咨询类型
  2. 引导前往相关服务页面
  3. 必要时展示相关案例或FAQ
  4. 如果还有不明确的地方，只做最小限度的追问
  5. 引导前往咨询表单

采用这种形式，聊天就能成为营销或咨询转化路径的辅助手段。 反过来，如果把它和页面引导路径割裂开来单独部署，就容易变成”能说话，但推不动业务的盒子”。

11. 用90天打好基础的推进方式

没有必要一开始就做得很大。 如果要用90天打好基础，比较现实的顺序如下。

第0-2周：确定用途和正本

  • 确定想要减少哪类咨询
  • 确定目标用户
  • 确定正本文档和更新负责人
  • 确定转交给人工的条件

第3-6周：小规模试做

  • 只针对主要场景制作原型（prototype）
  • 制作入口消息和分支选项
  • 使其能够返回带依据的回答
  • 制作20到50个案例的评估集

第7-10周：通过试点打磨细节

  • 查看真实用户的日志
  • 对卡壳的问题进行分类
  • 优先修正知识和路由（routing），而不是先改提示词
  • 对效果不佳的领域强化转交条件

第11-12周：确定生产运营的固定模式

  • 确定每周要关注的指标
  • 对prompt / model version进行固定管理
  • 确定更新流程和负责人
  • 判断是否要扩展到第二个用途

按这个顺序推进，可以降低一开始就做得过大而导致崩溃的概率。

12. 常见的失败

最后，汇总一些相当常见的失败案例。

12.1 做成什么都能回答的综合窗口

一开始就把范围扩得太大，精度和责任范围都会变得含糊不清。 把用途收窄为一个，效果会更扎实。

12.2 没有正本和更新负责人

即便有RAG机制，如果原始信息没有整理好，也难以稳定运营。 知识运营本身是一项独立的工作。

12.3 没有依据就直接断言

看似合理的回答，恰恰是运营中最危险的部分。 无法追溯依据的回答，事后也很难修正。

12.4 让高风险操作直接执行

转账、合同更新、查询个人信息这类操作，不能省略确认环节或人工审批。

12.5 转交给人工的条件模糊

只写一句”必要时转交给负责人”，现场实际操作起来会卡壳。 需要明确条件、接收对象、以及需要附带的信息。

12.6 没有建立评估集

每次改进时都无法判断是变好了还是变差了。 这种情况相当常见。

12.7 一开始就采用多智能体（multi-agent）架构

增加agent数量确实能提升设计自由度。 但同时，延迟（latency）、状态管理、监控、调试、权限管理的负担也会随之加重。如果没有明确的分离理由，先用单一agent来验证会更安全。7

13. 总结

如果用一句话概括制作聊天机器人的最佳实践，那就是 比选择模型更早，先确定角色定位、知识、权限、转交、评估。

其中尤其重要的是以下5点。

  • 把用途收窄为一个
  • 确定正本和依据来源
  • 把高风险领域分离出来
  • 把转交给人工的条件写清楚
  • 运行接近实际运营场景的评估

无论是面向网站，还是面向企业内部，这个顺序都是相当共通的。 不要把聊天机器人当作”很会聊天的东西”，而应把它设计为”梳理业务中哪些环节可以被缩短、哪些环节应该转接给人”的工具，这样才不容易走向失败。

相关文章

参考资料

与本主题相关的服务

本文与以下服务页面相关，欢迎从最贴近您需求的入口进一步了解。

网站咨询转化路径优化

网站上的聊天机器人，如果能够连同FAQ、服务页面、咨询入口的引导一起设计，往往更容易发挥效果。

查看网站咨询转化路径优化 咨询

网站建设

网站上的聊天机器人，如果能够连同页面结构、行动号召（CTA）、咨询页面一起设计，往往更容易发挥效果。

查看网站建设 咨询

网站建设（SEO与咨询转化路径优化）

聊天机器人与转化路径设计密切相关：如何引导通过搜索或广告而来的用户，以及如何把他们引导至咨询，都是同一个课题。

查看网站建设 咨询

作者简介

这是本文作者的个人主页。

小村豪

小村软件有限公司 代表

以Windows软件开发、技术咨询、故障排查为核心，擅长处理保留现有资产的项目，以及原因难以查明的故障调查。 也擅长把技术背景复杂的业务，梳理成易于理解的页面结构与文案表达。

查看个人主页 咨询

公开链接

返回博客列表

咨询

  1. OpenAI, Prompt engineering ↩ ↩2 ↩3 ↩4

  2. OpenAI, Model optimization ↩ ↩2 ↩3 ↩4

  3. Google Cloud, Handoff rules ↩ ↩2 ↩3 ↩4

  4. Google Cloud, Evaluation ↩ ↩2 ↩3

  5. Microsoft Learn, RAG and Generative AI - Azure AI Search ↩ ↩2

  6. Microsoft Learn, Security planning for LLM-based applications ↩ ↩2 ↩3

  7. Microsoft Learn, Single agent or multiple agents ↩ ↩2 ↩3

  8. Google Cloud, General agent design best practices ↩

  9. OpenAI, File search。关于检索行为的细节，Assistants File Search中也整理了查询重写、多次检索、关键词+语义检索、重排序等机制 ↩

  10. OpenAI, Web search ↩

  11. Microsoft Learn, Use public websites to improve generative answers ↩ ↩2 ↩3

  12. OpenAI, Reasoning best practices ↩

  13. Microsoft Learn, Prompt Shields in Microsoft Foundry ↩

  14. NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1) ↩

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

面向 BtoB 企业的 Google 广告小预算运营 ── 用每月数万日元做出成果的设计与每周操作流程

本文面向希望以每月数万日元预算启动 Google 广告的 BtoB 企业，是一份实务指南。内容整理了平均每日预算与结算上限的运作原理、转化跟踪的搭建、聚焦高意向关键词、否定关键词与搜索字词报告的每周运营方法，以及小预算下的出价策略选择，均以 Google 官方资料为依据。

阅读文章

常见问题

汇总了咨询这一主题时常见的问题。

导入聊天机器人时，最先应该确定什么？
比模型选择更早，应该先把'要减少谁的哪项工作、减少到什么程度'这个用途收窄为一个。如果这一点含糊不清，评估标准和知识设计都无法确定。作为第一个项目，比较容易上手的是对象范围窄、答案的正本容易确定的场景，例如产品FAQ的初次答复、咨询前的服务介绍、企业内部操作手册的检索。像合同判断或金额确定这类高风险领域，最好一开始就不要作为主战场。
怎样才能让聊天机器人的回答质量保持稳定？
回答质量更容易因知识管理不善而崩溃，而不是因为模型本身。首先要确定哪些文档或页面作为正本、由谁负责更新、以怎样的频率更新。在RAG场景中，不要把PDF或页面原样塞进去，而应按照一个步骤、一个FAQ这样的语义单元来处理，回答才会更稳定。此外，如果能展示是参照了哪个页面、以及信息的更新日期，出错时的排查也会更容易。
从聊天机器人转交给人工时应该如何设计？
仅写一句'如果无法回答就转交给负责人'的设计是脆弱的，需要明确在什么条件下、转交给谁、连同什么信息一起转交。需要身份验证的问题、需要确定合同或金额的问题、无法给出依据的问题、连续两次以上未能妥善引导的问题等，都比较适合从一开始就设为转交条件。转交时如果能把对话记录、已获取的信息项、参照过的文档、机器人卡住的原因、接下来希望确认的要点这5项一起交给人工，可以减少后续的返工。
导入聊天机器人时常见的失败是什么？
具有代表性的失败包括：把范围扩得太大，做成什么都能回答的综合窗口；没有确定正本和更新负责人；在没有依据的情况下断言式地回答；让高风险操作直接执行；转交给人工的条件模糊不清；没有建立评估集；以及一开始就采用多智能体（multi-agent）架构。如果没有评估集，每次调整提示词后都无法判断到底是变好了还是变差了，改进就几乎全凭运气。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。

联系我们
返回博客列表