先看这几处
先看
先别急着生成。把客服智能体先做建议回复，不要一开始自动发送涉及的材料、来源和不能触碰的内容列出来，后面会省很多返工。
做法
把信息分成三堆：已经确认的、还要追问的、不能直接用的。这个分类比提示词写得漂亮更重要。
检查
最后抽一条真实记录试跑。看结果有没有编造、漏掉限制，或者把内部口径写成对外承诺。
客服场景很容易让人想到自动回复，但自动回复并不是第一步。客户问题里经常带着上下文、情绪、历史订单和特殊承诺，直接自动发送容易把小问题变成大误会。
更稳的第一阶段，是让客服智能体只做建议回复。它可以从 FAQ、产品说明和历史口径里找到相关信息，整理成一段可编辑草稿，然后由客服人员确认后再发出。
例如客户问“这个问题是不是你们系统导致的”，智能体不能直接承认责任，也不能直接否认。比较合适的建议回复应该先说明需要核查哪些信息、请客户提供什么材料、预计什么时候给反馈。
工具在这里的价值，是减少客服查资料和组织语言的时间。它不应该越过客服去判断赔付、承诺处理结果或读取不该读取的客户资料。
人工确认时要看客户身份、历史沟通、问题严重程度和公司服务边界。如果客户已经有特殊承诺，通用 FAQ 就不能直接套用。
上线前还要保留日志。谁查看了什么资料，建议回复来自哪些内容，最终是谁发送的，都应该能追踪。这样出现争议时，团队能知道问题出在资料、建议还是人工确认。
如果建议回复里引用了知识库内容，页面上最好能看到来源标题或更新时间。客服人员知道答案从哪里来，才更容易判断它是不是适合当前客户。
客服智能体从建议回复开始，速度会慢一点，但风险小很多。等口径稳定、资料干净、权限清楚后，再考虑更自动化的流程。