AI 自动回复上线前，别只加一行标识：还要补 5 道生产门禁-开发者社区

最近不少团队开始给客服、销售咨询、内部知识助手接入自动回复。第一步通常做得很快：调用模型，拼接上下文，把答案发回用户。

等到准备上线，团队才发现“能回复”只解决了最表层的问题。真正进入生产后，还要回答这些问题：

用户能不能明确知道当前内容由 AI 生成；
系统是否保留了输入、模型版本、知识依据和工具调用记录；
AI 能看到哪些数据、能触发哪些动作；
回答不确定、命中高风险问题或用户拒绝 AI 时，谁来接管；
出现误答、越权或批量异常时，能不能立刻停用并复盘影响范围。

因此，“加一行 AI 标识”不等于完成合规，也不等于系统已经具备生产条件。更稳的做法，是把标识、审计、权限、接管和停用做成五道发布门禁。

门禁一：标识必须跟着内容走

显著标识不应该只出现在产品说明页、隐私政策或首次弹窗里。用户每次接触生成内容时，都应能明确识别它的来源。

最简单的实现，是在服务端统一拼接标识，而不是让模型自己决定要不要写：

typeReplyKind="fixed"|"generated"|"human";functionpresentReply(reply:string,kind:ReplyKind){if(kind==="generated"){return`【AI 自动回复】${reply}`;}returnreply;}

为什么要在代码层处理？因为提示词不是稳定控制面。模型可能省略、改写或把标识放到不显眼的位置；服务端统一处理，才能保证不同模型、不同渠道和不同回复模板口径一致。

还要注意三个边界：

固定规则回复和人工回复不要错误标成 AI 生成；
多轮会话不能只在第一条消息出现一次；
微信、网页、短信等不同渠道都要检查最终用户看到的渲染结果。

门禁二：日志要能还原一次回复

自动回复系统最危险的状态，不是偶尔答错，而是答错以后查不清为什么。

每次生成至少应保留以下字段：

{"traceId":"cs_20260712_001","channel":"wechat","replyKind":"generated","model":"model-route-a","promptVersion":"cs-v4","knowledgeRefs":["faq:service-scope:v3"],"toolCalls":[],"moderation":{"input":"pass","output":"pass"},"handoffRequired":false,"createdAt":"2026-07-12T09:30:00+08:00"}

日志不应该保存明文密码、API Key、完整身份证号或不必要的聊天原文。更合理的做法是保存脱敏摘要、引用标识、哈希和可控权限下的审计链接。

判断日志是否够用，可以做一个简单演练：随机抽一条七天前的回复，让没有参与开发的人只看日志，回答“用户问了什么类别的问题、系统用了哪个版本、依据来自哪里、有没有调用外部工具、为什么没有转人工”。如果回答不了，日志还不具备审计价值。

门禁三：模型只能提动作，代码决定能不能做

自动回复一旦接上 CRM、工单、订单或企业微信，就不再只是文本生成系统。

这时需要把“模型建议做什么”和“系统允许做什么”拆开：

模型可以提出“查询订单”“创建工单”“发送资料”等候选动作，但最终是否执行，应由代码层根据用户身份、渠道、风险等级、数据范围和审批状态决定。

第一版建议保持非常窄的权限：

允许查询公开服务说明；
允许检索经过审核的知识库；
允许生成回复草稿；
不允许直接承诺价格、交付周期或法律结论；
不允许修改订单、退款、删除数据或变更生产配置；
涉及个人信息、合同、支付和投诉时默认转人工。

门禁四：人工接管要有明确触发条件

“必要时转人工”不是可执行规则。生产系统需要明确什么叫必要，以及转给谁、带哪些上下文、多久必须响应。

常见触发条件可以写成配置：

consthandoffRules={topics:["合同","退款","投诉","个人信息","安全事件"],lowConfidenceThreshold:0.65,repeatedFailureLimit:2,userCanRequestHuman:true,outsideScopeAction:"fixed_reply_and_queue",}asconst;

接管队列里至少要带上：会话摘要、触发原因、已引用知识、已调用工具、用户联系方式是否已授权收集，以及建议的下一步。否则人工接到的只是一个没有上下文的“请处理”，接管成本会很高。

还要给用户一个清晰出口。用户说“不要 AI”“转人工”或表达明显不满时，系统不应继续用更多生成内容说服对方。

门禁五：停用、降级和复盘必须在上线前演练

自动回复出现异常时，团队通常有三种选择：

停止生成，全部切到固定回复；
保留内部草稿，但不自动发送；
只关闭某个模型、知识源、工具或渠道。

这三种能力最好由独立开关控制，而不是临时改代码发布。一次完整演练应验证：

开关由谁操作；
多久能生效；
已在队列中的消息如何处理；
用户会看到什么降级提示；
如何定位受影响会话；
修复后需要重跑哪些回归样本。

复盘也不应只统计“模型回答正确率”。至少还要看人工接管率、高风险命中、用户主动拒绝 AI 的比例、重复失败、发送延迟、工具异常和线索授权率。

一张上线前检查表

维度	上线前必须回答的问题
显著标识	每条生成内容是否都能被用户识别？
输入输出审计	能否还原模型、提示版本、知识依据和工具调用？
数据权限	模型能看到什么，代码允许它做什么？
人工接管	哪些主题和失败模式必须转人工？
用户选择	用户能否拒绝 AI 并获得人工渠道？
停用降级	是否能按模型、知识源、工具或渠道快速关闭？
复盘回归	出现问题后能否定位影响范围并重跑样本？