帮你建一个既控得住变更、又不拖慢现场的评审机制。
文中核心拆解是 CAB 在 FDE 交付中的两个用途：技术侧控制生产变更节奏——改提示词、换模型版本、动集成接口都应过审；商业侧承接范围蔓延——一切超出工作说明书的诉求走变更请求流程。最容易出现误用的地方是把 CAB 做成官僚橡皮图章，紧急修复也排队审批，逼得现场团队绕流程，机制名存实亡。越早做变更分类越省事。变更评审在 AI 交付里不是可选品，而是必要品。
相比把 CAB 只当 ITIL 流程遗产的普遍认知，这篇强调 AI 交付里它的必要性更高：模型输出的非确定性让「变更影响」更难预判，评审比传统软件更不能省。
建议你为当前项目起草一张一页纸变更分类表，标明哪些必须过审，先从模型与提示词两类变更管起。
—— FDEChina编辑部 · 实战派
定义
CAB（Change Advisory Board，变更顾问委员会）是评估、批准与管理变更的跨职能决策机制，成员通常涵盖交付、客户、运维与安全代表。
展开
在 FDE 交付里，CAB 有两个用途：技术侧控制生产变更节奏——修改提示词、更换模型版本、调整集成接口都应过审留痕；商业侧承接范围蔓延——一切超出工作说明书的诉求转入变更请求流程，让「多做需求」有明确代价。两个用途共用一套评审，成本低、一致性强。评审频率应与发布节奏匹配，一周一次为宜，过密过疏都会失效。
常见误用是把 CAB 做成官僚橡皮图章：紧急修复也排队审批，逼得现场团队绕流程，机制名存实亡。好的 CAB 必须有明确的紧急变更通道与事后追认机制，让刹车与油门并存。与指导委员会的分工：CAB 管变更的「怎么做」，指导委员会管方向的「做不做」，层级不同、不可互相替代。在 AI 交付里，模型与提示词变更比传统代码更难预判影响，评审这道闸不能省。