上一篇用第二批 intake 检查修订后的 admission rule，只有跨批次减少高影响误收、没有制造不可接受误拒，也没有把压力转移到例外通道的规则，才进入 promote。
promote 仍不是发布动作。若团队只把状态从候选改成“稳定”，却没有记录生效版本、适用范围、监控阈值和回退方式，下一次修改很可能直接覆盖线上规则。到月度复盘时，也很难分清指标变化来自业务样本，还是来自一项没有留下记录的配置调整。
稳定基线更接近一份受控合同：当前生产环境采用什么规则，谁能修改，哪些信号说明它开始漂移，触发问题后怎样回到已知可用版本。
这一篇继续往下走，把已晋升规则封装成可发布的 baseline，并补齐 change control、月度 drift threshold 和 rollback contract，再考虑扩大使用范围。
1. 先把“稳定”写成一个可识别版本
稳定基线不能只是一组散落在表单、文档和审批流程里的字段。它至少需要一个不可复用的版本号和一份可以追溯的清单。
1
2
3
4
5
6
7
8
9
10
11
12
| admission_baseline:
baseline_id: admission_rules_2026_q4_v1
status: stable
effective_at: 2026-11-01T00:00:00+08:00
source_candidates:
- admission_rules_2026_q4_rc1
- admission_rules_2026_q4_rc2
validation_batches:
- 2026_q4_intake_01
- 2026_q4_intake_02
owner: governance_program_owner
previous_stable: admission_rules_2026_q3_v3
|
版本号表达的是一份完整判断口径，不只是代码构建号。规则定义、证据字段、阈值、适用范围或默认动作发生变化，都应生成新版本。
同一个版本在所有环境中保持相同语义。若灰度环境采用不同阈值，应明确标记为新的 candidate 或 canary 版本，不能继续沿用生产 baseline 的编号。
2. baseline manifest 要能回答一次准入用了什么
只保存规则名称还不够。半年后复盘某次准入决定时，需要知道当时的字段、阈值和动作。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| baseline_manifest:
baseline_id: admission_rules_2026_q4_v1
rules:
critical_owner_capacity_proof:
revision: 3
applies_to:
- high_risk
- scarce_owner_required
inputs:
- named_owner
- verified_hours
- protected_window
threshold:
minimum_capacity_ratio: 1.1
on_fail: reject
premise_freshness_window:
revision: 2
maximum_age_days: 30
on_fail: require_refresh
|
每条规则至少保留五类信息：适用范围、输入证据、判断阈值、失败动作和规则 revision。准入结果再记录 baseline_id 与命中的 rule revision，就能从一次项目决定回到完整规则现场。
manifest 应作为受控配置保存，而不是从当前 UI 截图反推。页面适合展示当前状态，不适合充当历史事实源。
3. 变更分级决定需要多重验证
稳定基线不是禁止修改，而是让修改成本与风险匹配。可以先把变更分成三类：
| 变更级别 |
典型内容 |
最小验证 |
patch |
文案、非判断字段、可观测性补充 |
配置校验与审阅 |
minor |
阈值微调、证据字段增强、适用范围收窄 |
历史回放加 canary batch |
major |
新增拒绝条件、改变默认动作、扩大适用范围 |
两批 intake 验证与正式晋升 |
1
2
3
4
5
6
7
8
9
10
11
| baseline_change_request:
change_id: acr_2026_11_004
from: admission_rules_2026_q4_v1
proposed: admission_rules_2026_q4_v1_1_rc1
level: minor
rule: critical_owner_capacity_proof
change: minimum_capacity_ratio_1_1_to_1_15
reason: repeated_operation_load_underestimate
required_validation:
- historical_replay
- one_canary_batch
|
分级依据应看行为影响，而不是改动行数。把 minimum_capacity_ratio 从 1.1 改成 1.15 只有一个数字，却可能拒绝一批原本能进入的项目，不能当作无风险配置修正直接上线。
紧急变更也要生成临时版本，并绑定到期时间。先上线再补记录会让“临时”逐渐变成无法解释的长期分叉。
4. 月度漂移检查要绑定规则，而不是只看总量
基线发布后的第一个常见误区，是只看准入通过率。通过率下降可能来自需求质量变差，也可能来自某条规则误拒增加；单一总量无法区分两者。
月度检查可以沿用前两批验证的四组信号，并按规则拆分：
1
2
3
4
5
6
7
8
9
10
11
12
13
| monthly_baseline_health:
baseline_id: admission_rules_2026_q4_v1
window: 2026-11
intake_count: 46
signals:
false_admit_rate: 0.043
high_impact_false_admit: 0
false_reject_rate: 0.065
exception_rate: 0.109
capacity_protection_gap: 0.08
sample_coverage:
outcome_observed: 39
pending: 7
|
pending 不能被算成成功样本。观察窗口尚未结束时，先报告覆盖率，再解释当前信号；否则月初的健康度总会比月底好看。
每项聚合结果都要能下钻到规则、项目和准入快照。指标负责提示异常，具体样本负责决定是否真的修改基线。
5. 阈值使用绝对门槛和变化门槛两套口径
只有绝对阈值，可能漏掉持续恶化但尚未越线的趋势；只有环比变化，又容易被小样本放大。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| drift_thresholds:
high_impact_false_admit:
absolute: 1
action: rollback_review
false_reject_rate:
absolute: 0.10
delta_from_validation: 0.04
minimum_reviewed_samples: 20
action: rule_scope_review
exception_rate:
absolute: 0.15
consecutive_windows: 2
action: bypass_pattern_review
capacity_protection_gap:
absolute: 0.20
action: execution_contract_review
|
高影响误收可以采用低容忍的绝对门槛，因为单个事件就可能足以暂停扩围。误拒率和例外率更适合加入最小样本数与连续窗口，避免一两个边界项目触发频繁回滚。
阈值还需要对应动作。warning、freeze_rollout、rollback_review 和自动回滚不是同一件事，不能只发一条红色告警后等待会议判断。
6. 把规则漂移和执行漂移分开处理
月度指标越线后，不应默认修改 admission rule。
假设容量保护缺口从 8% 升到 24%，需要回到准入与执行快照判断：
1
2
3
4
5
6
7
8
9
| drift_diagnosis:
signal: capacity_protection_gap
baseline_value: 0.08
current_value: 0.24
admission_evidence_accurate: true
capacity_borrowed_after_admission: true
classification: execution_drift
action: enforce_scope_reduction_on_capacity_borrow
baseline_change_required: false
|
如果 owner 在准入时给出的容量本来就无法验证，属于规则或证据合同缺口；如果容量当时真实存在，进入执行期后被其他工作借走，则属于执行漂移。
前者进入 baseline change request，后者触发 roadmap 的范围缩减、里程碑调整或升级动作。混在一起处理，只会让准入规则越来越严，却仍然保护不了进入后的承诺。
7. rollback contract 要在上线前写完
回滚不能等故障发生后再讨论。baseline 发布包需要提前约定触发条件、目标版本、决策人和数据处置方式。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| rollback_contract:
baseline_id: admission_rules_2026_q4_v1
rollback_target: admission_rules_2026_q3_v3
triggers:
automatic:
- manifest_validation_failed
- decision_engine_unavailable
manual_review:
- high_impact_false_admit_gte_1
- false_reject_rate_gte_0_10
- repeated_exception_bypass
authority:
decision_owner: governance_program_owner
technical_owner: policy_runtime_owner
recovery:
preserve_decision_log: true
recheck_inflight_items: true
replay_window_days: 14
|
技术故障可以自动切回上一稳定版本，治理效果异常通常需要人工快速复核。两类触发应分开，避免一个统计波动直接让所有准入失效，也避免运行时故障还要等待月度会议。
回滚后的在途项目不能悄悄沿用旧结果。应标记哪些项目需要重检、哪些决定保持有效，以及新旧版本之间的证据如何保存。
8. 扩围采用 ring，而不是一次切换全部团队
即使规则通过两批 intake，扩大到不同业务线时仍会遇到新的样本结构。可以按使用风险建立 rollout ring：
1
2
3
4
5
6
7
8
9
10
11
12
| baseline_rollout:
baseline_id: admission_rules_2026_q4_v1
rings:
- id: ring_0
scope: governance_pilot_team
status: completed
- id: ring_1
scope: internal_platform_teams
entry_gate: one_month_without_critical_drift
- id: ring_2
scope: cross_business_high_risk_intake
entry_gate: ring_1_health_review_passed
|
每个 ring 都复用同一 baseline 版本。若某个团队确实需要差异化规则，应形成明确的 overlay，并单独记录适用范围和到期条件；不能复制整套配置后各自修改。
扩围期间出现重大漂移时，先冻结下一 ring。已经进入的 ring 是否回滚，要按 rollback contract 判断，避免扩大停止与生产回退被当成同一个动作。
9. 一个可直接复用的稳定基线发布包
把关键内容收敛到一份发布记录，可以使用下面的最小结构：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
| stable_baseline_release:
baseline:
id: admission_rules_2026_q4_v1
previous: admission_rules_2026_q3_v3
effective_at: 2026-11-01T00:00:00+08:00
owner: governance_program_owner
evidence:
validation_batches:
- 2026_q4_intake_01
- 2026_q4_intake_02
promoted_rules:
- critical_owner_capacity_proof
- premise_freshness_window
change_control:
patch: review_and_config_validation
minor: replay_and_canary
major: two_batch_validation
monthly_drift:
minimum_reviewed_samples: 20
thresholds_ref: admission_baseline_thresholds_v1
rollback:
target: admission_rules_2026_q3_v3
contract_ref: admission_baseline_rollback_v1
rollout:
current_ring: ring_0
next_gate: one_month_without_critical_drift
|
这份发布包不替代规则明细、样本账本和操作手册。它提供的是一条索引，让版本、证据、监控、回滚与扩围状态能被一次定位。
小结
通过两批 intake 的 admission rule，才有资格进入稳定基线；真正发布时，还需要把“稳定”变成一套可操作的控制面。
baseline manifest 固定当前规则语义，变更分级让验证成本与行为风险匹配。月度漂移同时看绝对门槛和相对变化，并把规则漂移与执行漂移拆开处理。rollback contract 在上线前明确目标版本、触发条件、责任人和在途数据处置，扩围则按 ring 逐步推进。
这样得到的 baseline 不是永久不动的配置，而是一份知道何时能改、何时该停、出问题后怎样退回的稳定合同。下一步可以用第一个月度窗口验证这些阈值是否过敏或迟钝，再决定是否让 baseline 进入更高风险的业务范围。
本文永久链接: https://www.mulianju.com/learning-notes/ai-learning-notes-llm-governance-versioned-stable-baseline-change-control-drift-threshold-rollback-contract/