模型、提示词、知识库、规则或工具变化后，怎样连接回归评测、灰度、监控和撤回？

AI 应用里，一个很小的改动也可能影响大量结果。换模型、加一份制度、调整提示词、修改工具参数，都可能修好旧问题，同时破坏原本正确的能力。

靠上线前随手试几次，很难看见这种连锁变化。

所有影响输出或动作的变更，都要穿过同一条发布链：版本记录、风险判断、回归评测、有限灰度、生产监控和可执行撤回。

一次知识更新怎样走完整条链

假设客服系统加入新版退款制度。团队先为制度文件、切片配置和提示词生成版本号，记录这次变更影响哪些问题。随后运行回归集，既测试新版规则，也检查旧的物流、发票和会员问题有没有被破坏。

评测通过后，只向内部客服或少量咨询开放，暂时保留人工确认。生产监控重点看新版制度相关回答、拒答、人工修改、投诉和转人工。若严重错误突破停止条件，立即切回旧版本，并检查已经发出的错误回复需要怎样更正。

这条链路跑通，团队才算具备持续更新能力。

回归集必须保护旧能力

评测集除了新增功能，还要包含历史正确样本、已经修复的错误、难例、拒答和高风险边界。线上人工修改、投诉与事故持续补入，防止同类问题反复出现。

模型、提示词、知识、规则、工具接口和参数都要有版本。一次任务使用了哪套组合必须可追溯，否则出事后既找不到原因，也无法恢复。

灰度按照风险切分

用户数量只是一个维度。还可以限制地区、客户类型、任务类型、数据范围和动作权限。高风险用途先在影子模式比较，低风险功能可以小范围开放。

灰度前写明扩大和停止条件。没有结束标准的“先上了再观察”，很容易变成长期带风险运行。

监控必须能够触发动作

调用量和延迟只能说明系统还在运转。生产监控还要看失败类型、严重错误、人工接管、重复执行、成本、用户放弃和最终业务结果。

指标越线后，要能触发告警、降级、限流、关闭工具权限、切回旧版本或完全停止。撤回也要提前演练。

代码与模型版本可以回滚，已经发送的消息、修改的数据和对外动作未必能自动恢复。企业需要区分技术回滚与业务补救，明确修正、通知和后续责任。

第 37 问解决项目第一次怎样验收。本篇处理上线以后每一次变更怎样避免把生产系统重新变成试验场。

可靠发布不要求每次改动都正确，但要求改错以后能快速发现、控制范围并恢复。

本问行动：挑最近一次线上改动，沿着六个环节复盘；少一环，就是下一次事故可能扩大的位置。