边界体系的第 9 章。前八章全是「方法」，但方法有个宿命：没人负责就会荒废。评测集没人维护会过期，能力声明表没人更新会失真，降级预案没人演练会变成纸面文件。这一章把边界从「方法论」升级成「组织机制」——方法会被人遗忘，机制不会。
谁为边界负责：三个角色（小团队可以一人多角，但角不能缺）
- AI 产品负责人：对能力声明表负责——承诺什么、不承诺什么，它随着需求变更而更新；它是业务与技术之间的「边界守门人」。
- 评测责任人：对评测集与度量负责——定期跑评测、出报告、拦截回归（效果度量的机制要有人执行）。这个角色最容易被省略，省略的后果是「升级漂移」无人发现。
- 稳定性/兜底 owner：对降级链、人工接管通道、故障演练负责——AI 服务也是服务，稳定性那套（稳定性建设）要有明确的人接管。
信号：如果团队里「谁知道评测集在哪」要问三个人，说明角色没落地。边界机制的负责人，应该能一句话说清「我负责什么、多久检查一次」。
边界进评审：把 AI 变更纳入评审流程
传统评审看代码与架构，AI 变更要额外过四个检查点（可以挂在现有架构评审流程上）：
- 能力声明有没有（新功能）：承诺/不承诺/度量目标写没写。
- 评测回归有没有跑（变更功能）：变更前后基线对比报告在不在。
- 降级与转人工设计没：AI 失效时的表现、人工通道的通路。
- 安全与合规过没过：数据、权限、内容（对照LLM 安全清单）。
评审没过的 AI 功能，和代码没评审一样——不上线。
边界进事故复盘：AI 事故用既有机制，加三问
AI 事故（答错被投诉、幻觉上线、成本爆炸）不用另起炉灶，走故障沟通与复盘的机制，但复盘时加三个问题：
- 边界为什么没拦住：是承诺写漏了、评测没覆盖、还是降级没触发？（定位到哪一层失效）
- 回放能还原吗：如果连链路追踪都查不到，先补追踪再谈改进。
- 案例回流了吗：这条事故案例有没有进评测集，防止同类问题复发（幻觉治理的闭环）。
变更管理：给「小改动」上规矩
AI 系统最危险的是「顺手改」：顺手调个温度、顺手换个小模型、顺手改句提示词——每次都「感觉没事」，累积起来边界就没了。规矩就一条：影响行为的变更，一律走「回归 → 灰度 → 锁定」（升级回归的纪律），没有例外。提示词也是代码，改它也是发版。
组织成熟的信号（对照自查）
- 三个角色都有人认领，且能说出自己负责什么
- 新 AI 功能评审有固定检查点，不过不上线
- AI 事故复盘会问「边界为什么没拦住」
- 影响行为的变更全走回归灰度流程
- 季度有 AI 专项回顾（边界、评测、成本一起过）
相关：架构评审怎么做 ｜ 效果度量 ｜ 下一章：从 POC 到生产：边界验收清单