普通 FAQ 页面的逻辑是"人找答案"：用户自己判断该点开哪一条，读完整段，再对照自己的情况。而企业真正接到的提问往往是"我们这个版本支持私有化部署吗，数据不能出内网"这类组合问法，FAQ 里只躺着一条"支持私有化部署"，用户看完仍然不确定。
AI 客服的差别在于答案是按问题现场组织的。它把官网内容、产品文档和 FAQ 列表一并作为知识库，用户提问时先检索相关资料，再由大模型组织成一段直接回答问题的话（阿里云 AI 客服文档）。对售前咨询、功能指引、网站信息服务这类高频重复场景，这个差别决定用户是继续读下去，还是直接关掉页面去问竞品。
因此要交付的不是一个聊天框，而是一份能被检索到、且足够准确的知识资产。窗口样式是最后一步，前两步决定了它到底有没有用。
让 AI 客服"读懂自家产品"的技术骨架：RAG
让聊天机器人依据企业自己的资料作答，主流做法是检索增强生成（RAG）。它的核心不是让模型"记住"你的产品，而是在每次回答前先去知识库里找出相关片段，再基于这些片段写答案。Cloudera 的 RAG Studio 文档把这类系统描述为：聊天机器人访问知识库，检索与用户问题相关的内容，再生成贴合该问题的回答（RAG Studio 用例说明）。
一条最小可用的链路包含五步：
- 切分：把手册、条款、产品页拆成可检索的小块；
- 索引：为每个块建立向量或关键词索引；
- 检索：用户提问时召回最相关的若干块；
- 生成：把召回内容连同用户问题一起交给模型组织答案；
- 引用：答案旁边给出处，让用户能点进去核对。
第 5 步常被忽略，但它同时解决两个问题：用户信任，以及你事后追查"这句话是从哪份文档里出来的"。资料更新后，模型不需要重新训练，改知识库就够了，这也是 RAG 比微调更适合产品资料频繁迭代的原因。
第一步：盘点知识来源，分清哪些内容该进知识库
接入前先把资料摊开分类。不是所有内容都适合直接丢进去，也不是所有内容都该公开展示。
| 知识来源 | 适合承载的内容 | 接入时要注意什么 |
|---|---|---|
| 官网页面 | 产品介绍、功能页、价格页、帮助中心文章 | 可自动抓取，但要确保线上页面就是最新版本 |
| PDF / Word 文档 | 产品手册、规格书、接口说明、服务条款 | 扫描件需先做文字识别，否则检索不到 |
| FAQ 标准问答 | 政策、时效、退换、发票、售后流程 | 命中优先级最高，答案最可控 |
| 内部资料 | 报价规则、销售 SOP、故障处理手册 | 涉及权限，不能与公开知识混在同一检索范围 |
一个常见失误是把所有资料无差别上传，结果模型检索到三份不同时期的规格书，答案互相矛盾。先做去重和版本收敛，比调提示词有效得多。
第二步：把知识库建起来，并让它可检索
知识库的构建方式通常有三类：网站导入、文件上传、FAQ 录入。以阿里云 AI 客服的实现为例，开启服务后系统会自动解析网站公开内容作为初始知识库，抓取耗时取决于站点内容量；文件上传支持 pdf、doc、docx、txt、markdown 和 excel 六种格式；FAQ 则用于录入标准问答对，当用户问题同时匹配到多个知识来源时，系统会优先采用 FAQ 中的标准答案（阿里云 AI 客服文档）。
落到执行层面，有几个动作值得当成流程固定下来：
- 网站导入完成后，把抓取到的页面列表过一遍，删掉过期的活动页和草稿页；
- 内容更新时手动点一次重新抓取，或开启定时自动同步，避免知识库停在三个月前；
- 把最容易答错的十组问题写成 FAQ，用标准答案覆盖模型自由发挥的空间；
- 为每个知识条目留下负责人，否则半年后没人敢删旧文档。
第三步：把客服窗口挂到网站上
知识库通了，才轮到外围配置。窗口颜色、服务名称、服务介绍和开场问题这些字段看似装饰，实际影响首轮对话质量：服务介绍写清能力边界，用户就不会问"帮我写一份合同"这类超出范围的问题；开场问题给出高频入口，能显著降低用户第一句话的犹豫成本（阿里云 AI 客服文档）。
还有一个容易被漏掉的配置：联系方式。当 AI 无法解决用户问题时，界面需要提供电话、邮箱或其他替代渠道，否则用户在被"我不知道"挡住之后，就真的离开了。
如果网站本身有登录体系，把公开知识与登录后可见的知识分开是两个独立的知识范围。为方便这种分层，底层站点最好具备账号能力——例如 we0 的网站能力里包含邮箱验证、Google 与 GitHub 登录的基础账户体系，以及从用户管理到内容维护的 CMS 后台（we0 功能总览），这类底座能省掉自己拼装登录和内容维护的成本。
如何避免 AI 编造不存在的产品信息
这是接入过程中最实际的风险：客户问"你们支持 SAML 单点登录吗"，模型为了让对话继续下去，很可能给出一个听起来合理的"支持"。
降低这类错误，靠的是约束而不是祈祷。可用的手段按性价比排序：
- 限定回答范围：明确要求模型只依据检索到的片段作答，检索为空时直接说明知识库暂无此项。
- 给兜底话术：没有命中时不要空转，而是提示用户换一种问法或转人工，并保留评价按钮收集负反馈。
- FAQ 优先：把参数、价格、合规这类不能出错的点写成标准问答，让它们压过模型的自由表述。
- 强制给出处：回答附带来源链接，用户能核对，你也能复盘。
- 上线前抽检：用真实客服工单里的历史问题造一份测试集，逐条比对答案与文档，别用"你好""你们公司在哪"这种问题验收。
一段可用的系统指令大致是这样的：
你是本网站的产品客服。仅使用下方检索片段回答问题。
若片段中没有答案，直接回复“知识库暂无相关信息”，并提示用户查看联系方式。
不得推测未在片段中出现的功能、价格、版本或承诺。
回答末尾以列表形式给出来源页面标题。
能不能根据用户的问题推荐产品
可以，但推荐必须建立在资料里真实存在的条件上。可行的做法是把"推荐"降级为"按条件筛选"：从用户描述中提取场景、规模、部署方式等要素，再映射到文档中明确写出的版本差异或套餐划分，最后给出对应的产品页。这样做出来的推荐句句可追溯；反过来说，让模型自由发挥"最适合你的方案"，就等于让它替你做出未经确认的商业承诺。
数据侧也能帮上忙。一些客服系统的数据面板会把问题按类别归集，产品推荐是其中一类，同时统计会话数、用户数、已答问题数和问题解决率（已答问题数 ÷ 总提问数 × 100%）（阿里云 AI 客服文档）。如果推荐类问题的解决率长期偏低，通常不是模型不行，而是产品页里缺少决策所需的信息——比较维度、价格区间、适用与不适用的场景。
复杂问题怎么转给人工客服
AI 客服的价值不是把人挡在外面，而是把简单问题消化掉，把复杂问题带着上下文交出去。触发转人工的条件建议写成清单，避免"看情况"：
几分钟搭建展示站并增长获客
输入一句想法，We0 AI 即可生成展示站、页面与 CMS。发布上线后并帮你获取客户和流量。
用户注册赠送一次完整项目生成
适合先体验一次完整生成流程，快速看到项目初稿。
- 话题命中高价值或高风险关键词：报价、合同条款、定制开发、故障与数据安全、投诉；
- 连续两轮未解决，或用户主动要求人工；
- 用户情绪明显负面，出现明确的不满表达；
- 知识库命中率为空且问题涉及账户、订单等需要查后台的事项。
转接时把对话摘要、已检索到的来源和用户所在页面一并传给人工，客户不必从头复述。这一步技术难度不高，却是体验落差最大的一环——很多企业做了 AI 客服却把转人工做成了"请您重新描述您的问题"。
把对话记录下来，变成知识库的更新依据
客服对话是最便宜的需求调研。系统通常会保留会话历史，包含用户问题、AI 回答以及该回答所依据的知识来源，并支持按状态（如已解答、部分解答）筛选（阿里云 AI 客服文档）。这批数据每周花二十分钟看一遍，能拿到三类信号：
- 重复出现却答不好的问题：知识库缺条目，补 FAQ；
- 答得含糊的问题：文档写得抽象，需要补具体参数或示例；
- 客户主动问但你没准备的问题：售前需求信号，值得反馈给产品和市场。
有些系统提供"问题优化"入口，把未解决的问题一键转成新的 FAQ 条目，只需补上标准答案。把它纳入周会流程，知识库才会自己长大。
上线之后：知识库的更新节奏与责任人
AI 客服上线三个月后开始答错，几乎都是因为知识库没人管。建议按固定节奏维护：
- 每周：清理未解决问题清单，补 3–5 条 FAQ；
- 每月：核对价格页、套餐页与文档的一致性，下线过期活动内容；
- 每次发版：发布当天同步更新功能文档与更新日志，不要让 AI 成为旧版本的代言人；
- 每季度：抽检 30 条真实对话，重跑一次测试集，记录解决率变化。
责任人不一定是客服主管，但必须是一个人，而不是"团队"。多人共管等于无人负责。
一个 SaaS 公司的完整链路示例
假设一家做数据看板的 SaaS 公司刚上线新官网，产品有免费版、团队版和私有化部署三种形态，文档散在帮助中心和 PDF 手册里。
- 用户提问：访客在定价页右下的窗口输入"我们 80 人的分析团队，数据不能出内网，你们怎么收费？"
- 检索：系统在帮助中心、私有化部署说明和 PDF 报价手册中召回相关内容。
- 组织答案：先回答部署形态是否满足"数据不出内网"，再说明私有化方案的计价维度，语气克制，不承诺具体金额。
- 提供相关页面：附上私有化部署说明页和联系销售的入口。
- 无法解决时转人工：用户追问合同条款与实施周期，命中高风险关键词，直接转人工并附上对话摘要。
- 沉淀：这条问题进入未解决清单，运营补一条"私有化部署如何计价"的 FAQ。
整个链路里，AI 没有"猜"，每一步都能追到一份文档。
we0 在这条链路上能承担什么，哪些需要自建
如果企业官网本身还在搭建阶段，把客服能力一起规划会更省事。we0 的定位是面向正式交付的网站能力集合，官方能力清单里包含 AI 能力接入（文本、图像、视频、音频等生成能力，适合扩展为对话产品）、CMS 与管理后台、认证体系、多语言组织和发布上线，适用场景中明确提到智能客服与知识库类应用（we0 功能总览）。
需要说清边界：这些是建站与 AI 接入的底座能力，不等于开箱即用的企业知识库客服。文档切分与索引、检索策略、按用户权限过滤知识、人工客服转接与工单联动，通常仍需要基于其全栈代码生成能力自行开发，或集成第三方的 RAG 与客服系统。评估时把"能生成网站"和"能运营知识库客服"当成两件事，可以避免上线后才发现缺半条链路。
合规与内容边界：哪些资料不能抓
知识来源越广，越要注意内容是怎么进来的。只导入公开、允许抓取的自有内容与已授权资料，不要通过绕过付费墙、登录限制或反爬机制去获取第三方内容。欧盟法院的一则顾问意见在这方面给出了参考：聊天机器人在回答中实时检索并复用新闻出版内容，在内容系非法获取、或答案措辞几可替代原文时，可能构成对出版者权利的侵害；而以自己的语言做事实性摘要并给出原文链接，风险显著更低（相关案件解读）。
对企业官网客服而言，这条原则翻译过来很简单：知识库里放的是自有资料和授权内容，回答以摘要和出处为主，不整段复述他人内容。
常见问题
AI 客服能直接读 PDF 和 Word 吗？
可以。以常见的建站与客服平台为例，文件上传支持 pdf、doc、docx、txt、markdown 和 excel 等格式，上传后会经历解析过程，解析成功后即可参与检索（阿里云 AI 客服文档）。扫描版 PDF 需要先转成可检索文字。
知识库里的价格经常变，怎么保证答对？
价格、套餐这类高频变更信息单独做成 FAQ 标准答案，并指定每月核对一次；不要把价格分散写在多份 PDF 里，否则模型会检索到不同版本。
AI 客服会不会把内部资料泄露给客户？
取决于知识范围怎么划。公开知识与内部资料应放在不同的知识集里，内部资料只对已登录的特定角色开放，而不是靠提示词请模型"不要说出来"。
回答要不要附来源链接？
建议附。它既提升可信度，也让你在复盘时能确认答案依据的是哪一版文档。
多久能上线？
主要耗时在资料整理和测试集抽检，而非技术接入。先上线覆盖度 70% 的版本、再按周补 FAQ，比一次追求全覆盖更现实。
Related Tools
- 知识库与客服控制台：管理网站导入、文件上传、FAQ 与问题优化
- CMS 与内容后台：维护帮助中心、产品文档与价格页的版本
- 站点分析工具：观察对话入口的点击与转化路径
- 工单 / IM 系统：承接 AI 转来的人工会话与对话摘要
- RAG 与向量检索服务：自建检索层时使用
Related Links
Summary
在企业网站接入 AI 客服，真正的工程不在聊天窗口，而在知识库：先把产品资料按网页、文档、FAQ 三类盘清并收敛版本，再用 RAG 建立"检索—生成—引用"的链路，把窗口挂上去只是最后一步。上线后靠限定回答范围、FAQ 优先、强制出处与测试集抽检压住编造风险，靠转人工清单守住复杂问题，靠每周的未解决清单让知识库持续生长。把这几件事变成有责任人的固定节奏，AI 客服才会真正减少重复咨询，而不是把错误答案说得更流利。
