周一的评审会上，业务负责人问：“模型没换，只改了一句提示词，为什么还要重新验收？”技术团队知道提示词会改变检索、工具选择和最终动作，却拿不出统一的变更单。功能看起来更聪明，就直接覆盖生产版本；出现错单、漏报或权限越界时，又说不清当时运行的是哪组模型、知识、工具和规则。
AI生产系统不是一个模型文件。模型、提示词、知识库、工具Schema、权限策略和业务规则共同决定结果。任一组件变化，原验收结论都可能失效。本方法把每次AI修改变成一次受控发布：生成release_id，跑风险加权回归，在影子流量中与旧版并行比较，再按风险逐级放量。
一、六类组件共同组成发布单元
每个release_id至少绑定模型、提示词、知识库、工具、权限和业务规则的版本指纹，以及创建人、批准人、回退目标和生效时间。
| 组件 | 最低登记内容 | 常见漏项 |
|---|---|---|
| 模型 | provider、model_id、参数、区域 | 只记“某大模型” |
| 提示词 | system prompt、few-shot、模板SHA256 | 在线编辑无版本 |
| 知识库 | 文档清单、有效日期、切片与索引版本 | 只记向量库名称 |
| 工具 | API版本、Schema、幂等规则 | 字段变化未回归 |
| 权限 | 服务账号、资源范围、限额、批准门 | 沿用管理员权限 |
| 业务规则 | 阈值、禁区、路由、接管条件 | 规则散落在口头约定 |
Google Cloud的生成式AI运维架构把谱系扩展到数据、模型、代码和评测数据；MLflow Model Registry提供谱系、版本、别名和元数据能力。企业不必照搬某个产品，但必须保留同等证据。
二、平均准确率不能覆盖低频高损失错误
变更评审先算风险，再谈总分。可用简化公式：风险成本 = Σ（错误发生频率 × 单次业务损失 × 暴露动作数） + 恢复成本。
回归结果至少拆成质量、风险、运行三栏。越权、重复写入、关键联锁误判等红线不参加平均；一次红线事件就可以No-Go。
三、三层回归集：固定、挑战、最近失败
固定集判断主流程是否退化，挑战集覆盖罕见但高损失边界，最近失败集确保已修复问题不再复发。样本按真实业务分布抽取，同时对高风险场景过采样，避免大量简单任务稀释风险。
每条样本保存输入、期望终态、允许副作用、禁止动作、严重度、判定人和证据链接。可调用工具的Agent还要核对数据库终态、业务回执和副作用，不能只比文本相似度。GitHub ReviewBench关于代表性任务、多源真值和严重度的公开方法可以借鉴，但其代码审查结论不能外推到企业工单、视觉或设备控制。
四、四级变更决定测试强度
- S0 展示：不改变数据、检索、工具或权限，跑固定集和页面检查。
- S1 知识：提示词、知识库、检索和阈值变化，跑三层回归并做影子比较。
- S2 工具：Schema、流程路由、写入规则变化，增加幂等、回执、超时和补偿验证。
- S3 权限与控制：权限、关键决策、设备控制或安全联锁变化，由业务、现场、IT安全共同批准并演练回退。
多项同时变化时按最高风险项定级，不能拆成几个低等级变更来降低门槛。
五、五道闸门：登记、回归、影子、放量、签字
- 登记与冻结：生成release_id，冻结旧版基线。六类指纹不全，停止。
- 离线回归：同批样本运行旧版和候选版，输出逐样本差异、严重度、风险成本、延迟和成本。红线失败，停止。
- 影子运行：新旧版本接收同一生产输入，候选版禁止写生产。未覆盖完整班次、产品切换或月末流程时，只能记录“未覆盖”。
- 分级放量：从5%%低风险流量开始，经20%%、50%%到100%%，每一级都有观察窗与回退阈值。
- 签字归档：业务签损失边界，现场签人工SOP，安全签权限日志，研发签版本与恢复。
NIST AI RMF的Manage部分要求上线后持续监测，并覆盖覆盖/申诉、退役、事件响应、恢复和变更管理。它不替代企业验收表，但明确了上线后继续治理的责任。
六、Go/No-Go表
| 检查项 | Go门槛示例 | No-Go条件 |
|---|---|---|
| 发布单元 | 六类指纹齐全、release_id唯一 | 任一版本不明 |
| 高风险样本 | 0次禁止动作、0次越权写入 | 任意红线事件 |
| 业务质量 | 关键任务不低于旧版且达合同门槛 | 关键任务退化 |
| 影子差异 | 重大差异有解释和签字 | 差异来源不明 |
| 运行性能 | P95、成本、队列在预算内 | 持续超预算且无降级 |
| 回退 | 规定时间恢复旧版并对账 | 无旧版或无法对账 |
| 责任 | 四类角色签字 | 责任人缺失 |
门槛必须在测试前签署，不能看完结果再修改及格线。
七、7天建立最小变更控制
Day 1：盘点六类组件，建立release_id格式。
Day 2—3：整理固定集、挑战集和最近失败集，标严重度与损失。
Day 4：跑新旧对照，输出逐样本差异与风险成本。
Day 5—6：用影子流量覆盖主要班次或业务周期，验证日志与回退。
Day 7：召开Go/No-Go评审；不满足条件的版本停在影子环境。
Git仓库可以保存提示词和规则，制品库或注册表保存模型，数据库保存release_id与评测结果，发布平台维护别名和回退目标。关键是所有生产判断能追溯到同一发布单元。
八、适用边界与停止条件
涉及人身安全、设备联锁、财务付款、身份授权和监管决定时，AI回归不能替代法定检验、功能安全评估或人工批准。测试集只能证明“在这批样本上通过”；分布变化、传感器漂移、制度更新和接口升级都应触发复评。
若旧版本没有基线、日志不完整或无法回退，首要任务是补齐可观测性与恢复能力。下一步从一张表开始：给当前生产AI补一个release_id，并尝试在30分钟内恢复旧版。做不到，就先停在只读或影子模式。
FAQ
只改提示词，需要全部重测吗？
会影响检索、工具、字段或判断时，至少按S1运行三层回归和影子比较。纯展示措辞可按S0缩小范围，但仍要登记版本。
影子运行多久才够？
至少覆盖一个完整业务周期及主要班次、产品切换和异常类型。关键场景未出现时，记录未覆盖，不能用时间到了代替证据。
release_id由谁维护？
研发负责技术完整性，业务负责用途和损失边界，IT安全负责权限审计，现场负责接管恢复。任何一方都不能独自批准生产放量。
参考来源
把AI变更做成可签字的发布
白泽智能可协助制造企业梳理发布单元、评测集、影子运行、权限边界和回退证据，让AI从试点进入可验证的生产流程。
预约AI落地评估