检查一至二：边界与部署
写清系统覆盖哪些问题、不覆盖哪些；确认数据是否出内网、模型调用是否留存。边界模糊会让用户把系统当万能客服，几次答不上来就失去信任，之后再推广也很难。
检查三至四：知识与约束
检查是否要求引用来源、无依据时是否拒答、禁用表述是否生效。缺少拒答能力的系统，遇到超出知识范围的问题会编造答案，风险远高于直接说不知道。
检查五：评测集与基线
确认评测集覆盖高频、边界与高风险问题，并有上一版的基线结果。没有基线的评测只能说明看起来还行，无法支持上线决策，也无法在出问题时判断影响范围。
检查六至七：接管与标识
明确转人工的触发条件与响应人；对外内容按标识办法处理，导出与转发场景也要覆盖。两项都属于上线前必须完成的动作，留到运营期补往往已经产生对外影响。
检查八：监控与回滚
确认日志留存、失败率与延迟监控、模型版本锁定与回滚步骤。生成式系统的异常常表现为质量缓慢下降，没有监控很难察觉，等业务反馈时已经积累了大量错误输出。
适用与不适用
适合谁
- 准备上线生成式应用的团队
- 负责上线评审的技术与合规人员
- 需要编写验收材料的外包项目甲方
不适合谁
- 仍处于想法阶段、无具体场景的项目
- 不接受任何上线前检查的临时试验
典型场景
某企业的合同摘要助手内测阶段表现良好，上线评审时发现没有拒答规则，日志也未留存输入。补齐后重新内测，遇到知识范围外的问题会明确提示转法务，而不是给出推测性结论。
可执行步骤
- 把八项检查做成评审表并指定举证责任人
- 先用评测集跑一次完整基线
- 验证拒答与转人工是否真的触发
- 核对导出与转发场景的内容标识
- 演练一次回滚并记录耗时
常见坑
- 只测知识范围内的问题，忽略越界提问，上线后出现编造答案。
- 日志只存输出不存输入与依据，出问题无法复现，也无法定位。
- 标识只做在网页上，导出的文档与图片没有标识。
- 未锁定模型版本，供应商升级后质量波动无法解释。
- 回滚方案未演练，真正需要时找不到上一版配置。
自检与验收清单
- 边界与不覆盖范围是否书面化
- 拒答与转人工是否实测触发
- 评测集是否有基线结果
- 导出场景的标识是否覆盖
- 回滚是否演练并记录耗时
常见问题
内测效果好还需要全套检查吗？
需要，但可按风险裁剪。内测样本通常偏简单，越界提问、导出标识与日志留存是被忽略又最容易出问题的三项。
拒答会不会影响体验？
会略微降低有问必答的感觉，但能显著降低错误外发风险。可通过提示语与转人工入口让体验更平滑。
标识由谁负责？
由内容发布方负责落实，具体标识方式与位置应经法务确认。技术服务方可以提供能力，但不承担发布主体责任。