“太聪明”Knowledge Base问题：当你的AI知道得太多反而有害
Source: Dev.to
我搞砸了。不是小问题，而是那种“客户在周五晚上11点给我打电话”的程度。
我们刚刚部署了一个医疗诊所的预约系统：语音 AI，配置相当高级。患者打电话，AI 安排预约，就这么简单。或者说，原本的计划是这样的。
客户把所有资料交给了我们——15 年的医学文档、治疗方案、药物相互作用指南、医学术语数据库、保险政策文件，以及超过 10 000 条常见问题解答。
我的绝妙想法很简单：把所有资料都喂进去。上下文越多，AI 越聪明，对吧？
错。非常错。
实际发生的情况
| 天 | 通话摘要 |
|---|---|
| 第1天 | 患者打电话想为她女儿的发烧预约。AI 解释了儿科发热管理方案、基于年龄的标准以及医学指南。患者挂断了电话。 |
| 第2天 | 另一位患者要求下周二预约。AI 开始讲解共付额、预防保健代码、保险条款和覆盖规则。患者怒斥：“我只想要一个预约。” |
| 第5天 | 客户来电：AI 在进行医学讲座而不是预约。通话量在一周内下降 40 %。 |
那一刻，我意识到自己做了什么。
我创建的问题
AI 已经变成了一个 全知全能。
- 我让它访问医学知识库，因为我担心患者在预约时会提出医学问题。
- 我没有考虑到一个简单的事实：仅仅因为你知道某件事并不意味着你应该说出来。
AI 的行为就像那种把每一句随意的评论都变成 TED 演讲的聚会客人。有人说：“外面很热”，他们就会开始讲过去五十年的气候数据。你不争辩——只会离开。这正是患者们的表现。
真正的问题：上下文混淆
当患者提到“发热”时，AI 查询了知识库，检索到 数百份文档——包括方案、药物相互作用、急诊标准、保险规则。它认为这些全部都有帮助并尝试分享。
患者并不是在寻找医学教育；他们想要的是星期二下午 3 点的预约时段。
AI 无法区分需要用于 安排 预约的信息和它仅仅能够获取的信息。
我的第一次失败的尝试
我尝试限制它：
“仅在明确请求时提供医疗信息。”
这并没有奏效。患者提到咳嗽并要求见医生。AI 回答说：“除非被要求，否则我不会解释咳嗽的处理方案，”随后 立即 又提供了解释。它变成了那种一边宣布不谈某件事 却 一边在谈的尴尬人物。
患者仍然挂断。
实际解决方案：基于角色的知识过滤
我围绕一个简单的想法重构了整个提示：
你是接待员，而不是医生。
我没有限制知识，而是 定义了身份。
- AI 成为了 Sarah，友好的接待员。
- 她唯一的工作：安排预约——温暖、高效、具有人情味。
- 她可以访问医学知识，但被指示 除非绝对必要用于预约，否则不使用。
- 她 不是 医疗顾问、诊断工具、保险专家或百科全书。
知识实际被允许的使用方式
| 允许的使用 | 示例 |
|---|---|
| 匹配医生专科 | “您需要一位儿科医生。” |
| 评估紧急程度 | “您的症状表明我们应该今天见您。” |
| 回答基本后勤信息（例如禁食要求） | “请在血液检查前禁食 8 小时。” |
绝不 用于：
- 解释疾病
- 讨论治疗方案
- 解释症状
- 深入保险细节
如果患者提出医学问题，AI 会礼貌地转移话题，表述为帮助而非回避：
“这是您在就诊时可以向医生提出的好问题。我在这里帮您安排时间。这个时间合适吗？”
对话流程变得简洁：
- 热情问候。
- 询问他们的需求。
- 找到合适的时间段。
- 确认。
- 完成。
目标： 在 两分钟以内 完成预约。
转变
相同的发热情景，第二次尝试：
AI 认可了担忧，提供了预约时间，确认了细节，并在 30 秒以内 完成通话。没有讲课，也没有解释流程。
胸痛来电：
AI 识别出紧急情况，提供了即时时段或护士转接，并适当安排。知识仅用于 仅 对紧急程度进行分类，而不是解释心脏护理。
这种区别改变了一切。
最难的部分：教它闭嘴
- 告诉它 不要 过度解释没有效果。
- 要求它简洁也没有效果。
- 将它定义为 接待员 开始起作用。
- 明确声明 解释医学概念等同于失败 最终让它明白。
突破在于将问题框定为 角色边界，而不是知识边界。
教会我最多的边缘案例
| 情境 | 成功做法 |
|---|---|
| 担忧的患者需要安慰 | 确认 → 重定向 → 安排 |
| 保险问题 | 确认 → 简要说明流程 → 转交 |
| 患者想讨论医学研究 | 确认好奇心 → “这是医生的好问题” → 安排 |
在每种情况下，模式都是 确认、重定向、安排。
The Results That Saved My Friday Nights
| 指标 | 在 Role‑Based Filtering 之前 | 在 Role‑Based Filtering 之后 |
|---|---|---|
| Average call time | >2 分钟（常常超过1 分钟的讲解） | <30 秒 |
| Abandonment rate | 高（多位数%） | 个位数% |
| Booking success rate | 低 | 显著提升 |
| Patient feedback | “AI 说得太多” | “感觉像在和真实的接待员交谈” |
客户问我们为何一开始没有这样做。我告诉他们实情：知识不等同于智慧.
我真正学到的
拥有信息的获取权并不等同于知道何时使用它。
为 AI 定义明确的角色——并将知识使用限制在该角色范围内——可以把喧闹的全知者转变为有帮助、高效的接待员。
我现在遵循的提示原则
最好的提示并不是让 AI 展示它知道多少。
而是让 AI 在不刻意炫耀的情况下，轻松地提供帮助——就像一位出色的前台：热情、高效，恰到好处地知道何时该说话、何时只需帮你安排好事务。
关键要点
- 专注胜于广度 – 更少的上下文往往能产生更好的结果。真实用户总会暴露出理想测试对话中隐藏的缺陷。
- 用一句话定义 AI 的工作 – 把这个定义当作法律。对哪些知识是必需的、哪些是噪音要毫不留情。
- 为超出范围的查询做好准备 – 事先决定当用户提出超出角色的问题时，AI 应该如何转向。
- 用结果来衡量成功 – 而不是 AI 听起来有多聪明。
轮到你了
- 你是否曾经构建过一个“知道太多”而适得其反的 AI？
- 你如何在提示中管理知识库的范围？
- 当你让 AI 接触海量信息时，你的策略是什么，以保持其回答的聚焦？
作者 Farhan Habib Faraz
PowerInAI 高级提示工程师 & 团队负责人
打造懂得何时保持沉默、专注完成任务的 AI。
Tags: knowledgebase, promptengineering, voiceai, rag, aidesign, llm