边界体系的第 8 章。前面立了边界（能力声明）、设了度量（评测集）、装了追踪，但还有一个隐蔽的敌人：变更漂移。模型不是代码，你升级一个版本，它不会告诉你「我改了什么行为」——可能答得更好了，也可能拒绝率悄悄掉了、风格悄悄变了、幻觉率悄悄涨了。AI 系统的边界，就是在一次次的「顺手升级」里被磨掉的。
先理解：为什么 AI 变更特别容易翻车
- 不可 diff：代码升级能看 diff，模型升级只有一个 release note，行为差异要靠测才知道。
- 连锁效应：换模型会影响下游一切——检索相关性判断、工具调用格式、引用习惯、拒绝倾向。
- 边界漂移是渐进的：成功率没掉，但「不该答的答了」「该拒的没拒」这类边界行为在变——普通指标抓不住，只有针对性的评测能抓住。
升级纪律：先回归、再灰度、后锁定
第一步：变更前，锁定基线
- 凡是影响行为的变更（模型版本、提示词、检索策略、参数），先冻结一版基线：跑一遍评测集，记录成功率、拒绝率、错误分布、成本。
第二步：离线回归——用同一套题考新模型
- 新版本跑同一套评测集，逐类对比：简单/困难题分别涨跌？拒绝行为变化？引用质量？
- 特别盯三类「边界题」：模糊问法（它会不会硬答）、越界请求（它会不会乱承诺）、高风险场景（会不会替人做决定）——边界漂移主要发生在这些题上，普通题测不出来。
- 回归不过（承诺线被突破）就打回；过了才进灰度。
第三步：灰度上线——用真实流量验证
- 小流量（5%–10%）放新版本，对照在线度量的代理指标：转人工率、投诉率、功能留存、成本。
- 灰度期要能一键回滚到旧版本——模型变更必须留回滚能力，这是和代码发布一样的底线。
- 灰度观察期建议覆盖一个完整业务周期（比如一周），别只跑一天。
第四步：锁定与复盘
- 全量后更新能力声明表（如果实际表现优于承诺，可以上调承诺；劣于则要么回滚要么改承诺）。
- 把「这次升级改变了什么行为」写进变更记录——三个月后有人问「为什么这个功能好像变了」，这就是答案。
变更范围清单（不止换模型）
| 变更类型 | 风险点 | 动作 |
|---|---|---|
| 模型版本升级 | 行为不可 diff | 全量回归 + 灰度 |
| 提示词修改 | 常被当「小改动」 | 同样走回归（提示词是逻辑，不是文案） |
| 检索策略/数据更新 | 召回分布变化 | 检索质量回归 + 引用抽查 |
| 温度等参数 | 影响稳定性 | 简单对比即可，别轻视 |
| 工具 schema 修改 | Agent 调用行为变化 | Agent 场景专项回归 |
落地清单
- 变更前冻结基线（评测集 + 指标）
- 离线回归含「边界题」专项（模糊/越界/高风险）
- 灰度 5%–10% + 一键回滚能力
- 灰度观察覆盖完整业务周期
- 变更记录归档，声明表随之更新