AI 学习笔记（五十七）：LLM 平台默认配置分层发布、团队覆盖层版本兼容与误判回滚路径
上一篇讨论了季度治理投资组合：哪些治理资产应该扩大复用，哪些适合平台化，哪些必须留在团队覆盖层，哪些只能先进入观察窗口。
一项治理能力一旦进入 platformize，问题就会从“要不要复用”变成“如何安全地默认启用”。这一步很容易被低估。因为平台默认配置看起来只是把一组规则、阈值、审计字段和回滚动作沉淀成公共能力，但它真实影响的是所有接入团队的日常开发节奏。
如果默认配置发布得太激进，团队会被突然增加的门禁、复核和异常拦截打断；如果发布得太保守，平台化又只会变成一份共享文档，无法真正降低重复治理成本。
所以这一篇继续往运行层走，重点看三个问题：
- 平台默认配置应该怎样分层发布，而不是一次性全量压给所有团队
- 团队覆盖层怎样做版本兼容，避免平台升级后把本地治理经验冲掉
- 平台治理能力误判时，回滚路径应该如何设计，才能既快速止损又保留证据
1. 平台默认配置不是一份配置文件，而是一套发布纪律
很多团队第一次做治理平台化时，会自然地把重点放在配置结构上：字段怎么命名、规则怎么组合、阈值怎么覆盖、开关放在哪里。
这些当然重要，但更关键的是发布纪律。
因为默认配置一旦进入平台层，就不再只是“给大家一个参考”。它会变成新项目的默认行为、老项目升级时的基线、排查问题时的判断入口，也会影响后续审计和复盘。
所以平台默认配置至少要分成三层：
baseline：所有团队都应该具备的最低治理要求recommended：平台建议启用，但允许团队按场景延后或调整strict：只面向高风险场景或成熟团队开放的强约束策略
这三层的价值，不是把配置分得更复杂，而是把“默认启用”和“允许选择”分开。
比如证据回放字段、模型版本记录、输入输出摘要、人工复核结果，这类能力通常应该进入 baseline。没有它们，后面谈复盘、追责、ROI、误判回滚都很难落地。
但更强的自动拦截、强制二次复核、发布前大样本回放，则未必适合直接放进 baseline。它们可能很有价值，却会显著增加成本和交付阻力，更适合作为 recommended 或 strict 分层发布。
平台默认配置最怕的是一句“我们已经统一了”。真正要问的是：统一的是最低治理底线，还是统一了所有团队的运行方式？前者是平台能力，后者很可能是平台误判。
2. 分层发布要先定义生效范围，再定义升级节奏
默认配置发布时，常见做法是直接给一个版本号：v1.0、v1.1、v2.0。
这不够。版本号只能说明配置发生了变化，不能说明这次变化会影响哪些团队、哪些场景、哪些运行路径。
更稳妥的方式，是把每次发布都拆成四个维度：
scope：影响哪些团队、应用、模型调用链路layer：属于baseline、recommended还是strictmode：只记录、灰度提示、软拦截，还是强拦截window：观察多久、用什么指标判断是否扩大
例如一条“低置信度回答必须进入复核队列”的策略，如果直接强制进入所有团队，很容易造成复核队列爆掉。更合理的路径可能是：
1 | platform_default_release: |
这个配置并没有一开始就承诺“平台已经强治理”。它先承诺“平台开始收敛默认行为”，再用观察窗口判断是否升级成更强策略。
这种发布方式会慢一点，但它能避免把平台配置发布变成一次组织级惊吓。
3. 团队覆盖层不是例外清单，而是有边界的本地经验
平台化之后，团队覆盖层很容易被误解成“例外”。
一旦说成例外，就会自然走向两种极端：要么平台要求团队尽快清理所有覆盖；要么团队把所有不想接受的平台规则都塞进覆盖层。
这两种都不健康。
更准确的理解是：团队覆盖层保存的是本地经验，平台默认层保存的是跨团队共性。两者不是谁取代谁，而是要有明确边界。
团队覆盖层适合承载这些内容：
- 行业、客户、地区带来的特殊风险语义
- 团队独有的复核容量和专家排班约束
- 尚未被多团队验证的阈值调整
- 与特定业务流程绑定的提示词、工具调用和兜底动作
平台默认层则应该承载这些内容：
- 审计字段和证据回放结构
- 通用风险分级和复盘入口
- 跨团队稳定复用的门禁模式
- 标准化的回滚、降级和告警协议
如果边界不清，平台升级会不断冲击团队覆盖层；团队覆盖层也会不断绕开平台默认层。最后看似配置很多，实际没有一个层级能承担稳定责任。
4. 版本兼容要兼容行为，不只是兼容字段
做平台配置升级时，很多兼容性检查只看字段：旧字段还在不在，新字段有没有默认值，枚举有没有变化。
这还不够。LLM 治理配置的兼容性，重点不是“能不能解析”，而是“行为有没有被悄悄改掉”。
例如平台把某个策略从 warning_only 改成 soft_block，字段结构可能完全没有变化，但团队的交付体验已经变了。再比如平台把低风险场景的抽样比例从 5% 调到 20%，配置可以正常加载，但人工复核容量可能会被快速吃光。
所以团队覆盖层的版本兼容检查至少要包含三类：
schema_compatibility：字段、类型、枚举、默认值能否兼容behavior_compatibility：拦截模式、抽样比例、复核路由是否改变capacity_compatibility：新增治理动作是否超过团队可承接容量
可以把兼容检查写成发布前的简单台账：
1 | overlay_compatibility_check: |
这里的 hold_rollout 不是反对平台升级，而是提醒平台：这次升级已经不只是配置兼容问题，而是运行容量问题。
5. 平台误判的回滚路径，要在发布前写清楚
平台治理能力越成熟，越容易出现一种错觉：只要默认策略足够谨慎，就不需要复杂回滚。
现实不是这样。平台层一旦误判，影响范围通常比团队本地策略更大。一次错误的强拦截、一次过度敏感的风险识别、一次错误的复核路由，都可能让多个团队同时进入异常状态。
所以回滚路径不能等事故发生后再临时讨论，必须在默认配置发布前写清楚。
至少要提前定义四件事：
rollback_trigger：什么信号触发回滚rollback_target：回到哪个配置版本或哪种运行模式rollback_owner：谁有权限执行，谁负责同步影响团队evidence_retention：回滚前后保留哪些证据，供后续复盘使用
一个最小回滚协议可以长这样：
1 | rollback_protocol: |
注意，这里的回滚目标不一定是“退回旧版本”。有时更好的目标是从强拦截降级到软拦截，或者从软拦截降级到只记录。平台治理回滚的核心不是撤销一切，而是先恢复业务运行，再保留足够证据继续判断。
6. 回滚之后不要急着重新发布，要先判断误判类型
很多团队回滚成功后，会立刻讨论“修一下再发”。这很危险。
因为平台误判通常不止一种类型。如果没有分清误判来源，重新发布只是把同一个问题换个参数再来一次。
我会把误判至少分成四类：
threshold_error：阈值太严或太松，判断边界不合理scope_error：策略适用范围选错，把不该覆盖的团队或场景纳入了capacity_error：规则本身有效，但团队复核、值班或专家容量不足semantic_error：平台共性判断无法表达本地业务语义
不同误判类型，对应的后续动作完全不同。
阈值错误可以重新抽样、回放、调参；范围错误要缩小发布对象，重新设计灰度；容量错误要先补复核和运营资源，不应只调低阈值；语义错误则可能说明这项能力不该继续强平台化，而应退回团队覆盖层。
这一步如果省掉，平台团队很容易把所有误判都当成“参数不准”，最后把治理策略调成一堆没人敢碰的魔法数字。
7. 小结：平台化不是把差异抹平，而是把风险变成可管理的版本
LLM 治理能力进入平台层，是一件好事。它能减少重复建设，统一证据结构，降低跨团队复盘成本，也能让成熟经验更快扩散。
但平台化不等于一次性统一所有行为。默认配置要分层发布，先守住底线，再逐步扩大建议策略和强约束策略。团队覆盖层也不是平台失败的补丁，而是本地业务经验的承载层，需要和平台版本保持可解释的兼容关系。
真正成熟的平台治理，不是永远不误判，而是误判发生时能快速降级、保留证据、复盘类型，并决定这项能力应该继续平台化、缩小范围，还是退回团队覆盖层。
换句话说，平台化不是把差异抹平，而是把差异、风险和回滚都纳入版本管理。
下一篇可以继续讨论平台治理能力稳定运行后的评估问题：默认配置发布以后，如何做跨团队采纳率分析、策略有效性衰减监控，以及治理平台自身的年度升级节奏。