想在官网或小程序上接一个 AI 对话框，从哪一步开始做？

第一步不是选模型或画聊天框，而是收集真实问题，确定机器人为谁回答、依据什么回答、答不到如何转人工，再决定官网、小程序及技术路线。

如果手里只有“想做一个 AI 客服”这句话，先不要接 API。用客服聊天、搜索词、销售咨询和售后工单整理一份问题样本，给每个问题标注正确答案、知识来源、用户身份、是否允许公开以及答错后果。没有历史记录时，可让销售、客服和产品各列出最常见问题，再用真实用户访谈补齐；模型选型要排在任务边界之后。

在确定模型、数据与上线边界时，还可以对照 如果要做 AI 知识库或企业 AI 助手，前期需要准备什么资料？ 和 工作流型 AI 智能体是什么？和普通聊天机器人有什么区别？；这些内容补充了需要放在同一项决策中考虑的上下文。

先确定对话框到底承担哪一层工作

首期类型	典型任务	所需数据与接口	风险	建议
导航与固定 FAQ	找页面、营业时间、固定政策	结构化答案或站内搜索	低	规则或 SaaS 可能已经够用
企业知识问答	产品、方案、制度、售后说明	有版本和权限的文档	会引用错或使用旧资料	检索后带来源回答
线索收集	识别意向并创建联系方式	表单、CRM、同意记录	个人信息和垃圾线索	明示用途并减少必填字段
业务办理	查订单、预约、改工单	登录身份、业务 API、审批	越权与错误执行	问答稳定后再单独建设

官网适合公开内容、搜索流量和跨渠道访问，更新不受小程序发版节奏限制；小程序适合已有微信用户、扫码入口和账号服务，但要遵守平台审核、隐私声明和接口限制。两端不必同时首发。若首要用户从官网来，先做网页嵌入；若服务必须结合微信身份或线下二维码，再验证小程序。共享的应是后端知识、评测和会话服务，而不是强求两端界面完全一致。

一份最小知识包比一堆文档更有用

首期选择一个主题，例如“售前产品咨询”，每条资料注明标题、正文、产品或地区范围、发布日期、失效日期、负责人和访问级别。删除重复旧版，把相互冲突的口径交给业务负责人裁决。RAG 研究表明，外部可检索知识可与生成模型结合，参见 NeurIPS 2020 原始论文；但检索到相关片段只是前提，答案仍需用企业问题评测。

对话规则应明确：资料没有答案就说不知道；价格、时效和政策显示来源与更新时间；用户要求人工时立即转接；不得向未登录用户暴露内部资料。需要留资时，先说明用途，再采集完成任务所需的最少字段。聊天记录、手机号和订单号的收集、保存、供应商传输和删除，应依据适用的个人信息规则由业务方确认，不能默认“用户发进聊天框就等于可永久保存”。

上线前用真实问题过三道检查

第一道是答案检查：从样本中划出未参与配置的测试集，统计有证据正确率、严重错答率、正确拒答率和引用一致率。第二道是体验检查：手机弱网、连续追问、返回重试、键盘遮挡、长答案展开和转人工都要测试；动态返回的“正在回答、失败、已转人工”等状态要能被辅助技术识别，可参考 W3C 的 WCAG 状态消息说明。第三道是运营检查：知识负责人能更新内容，客服能看到上下文并接管，技术人员能按会话定位检索和模型日志。

首发后按业务量和风险设定复盘频率，查看问题覆盖率、正确解决率、人工接管率、未命中问题、严重错答、P95 响应时间和单次成本；不要把对话次数当成功。若首期核心高频问题仍不能稳定回答，就不要急着增加查单和退款。测试集规模应覆盖业务种类和主要风险，并随新增问题持续扩充。

滚水科技官网已有对话入口，可作为交互样例，但自有产品不能替代客户业务的效果证明。滚水科技的合理首期交付应包括问题集、知识清单、回答边界、原型、评测报告、数据流和运营后台，而不只是一个可聊天页面。