LLM 治理准入规则首批校验：用误收、误拒与容量信号决定是否固化

发表于 分类于 阅读次数： Changyan： 本文字数： 6k 阅读时长 ≈ 5 分钟
接着季度复盘后的 admission rule 更新，这篇整理下一季度首批 intake 的验证方法，用 false admit、false reject、例外压力和 owner capacity 判断新规则是否值得固化成稳定基线。

上一篇把季度偏差分成 execution_failure、premise_invalidation 和 capacity_allocation_error，再把重复问题改写成下一季度的 admission rule。

规则已经更新，不代表它已经适合成为长期基线。

新规则在复盘会上通常很有说服力，到了下一季度首批需求，却可能把正常需求挡在门外，也可能仍然放进缺少容量和证据的承诺。若不区分这两类错误，团队很容易因为一次漏拦继续加码规则，或者因为一次争议把必要门禁整体撤掉。

这一篇继续往下走：把下一季度首批 intake 当成验证批次，用 false_admit、false_reject、例外压力和关键 owner 容量判断规则是否有效，再决定保留、修订、回退，还是固化成稳定基线。

1. 先冻结规则版本，再观察首批结果

首批校验需要一个明确的规则版本。边收需求边修改门槛，会让每个项目面对不同条件，最后无法判断规则是否真的改善了准入质量。

1
2
3
4
5
6
7
8
9
10
11
12
admission_validation_batch:
  batch_id: 2026_q4_intake_01
  rule_version: admission_rules_2026_q4_rc1
  intake_window:
    from: 2026-10-01
    to: 2026-10-10
  observation_window:
    to: 2026-10-31
  rule_changes:
    - critical_owner_capacity_proof
    - premise_freshness_window
    - execution_escalation_contract

这里冻结的是判断口径，不是冻结所有业务事实。需求范围、风险等级或依赖关系发生变化时，照常记录；但不能悄悄换一套规则重新判断。

每个候选项至少保留四份快照：原始申请、准入证据、最终决定、观察窗口内的事实。后续判定误收或误拒时，才能回到当时可获得的信息，而不是拿事后结果倒推负责人“早该知道”。

2. 给 accepted、rejected 和 exception 建同一份样本账本

只跟踪被接受的项目，最多能看到规则漏掉了什么，却看不到它错杀了什么。

首批样本应包含三组：正常接受、正常拒绝、通过例外进入。字段保持一致，方便在同一口径下比较。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
intake_sample:
  item_id: policy_replay_automation
  decision: accepted
  decision_path: normal
  matched_rules:
    - critical_owner_capacity_proof
    - premise_freshness_window
  decision_evidence:
    protected_owner_hours: 96
    required_owner_hours: 88
    critical_premise_valid_until: 2026-11-15
  observation:
    milestone_1_met: false
    owner_capacity_remaining: 34
    premise_changed: false

被拒绝项也要留下“如果允许进入，原计划会怎样发展”的观察依据。它不需要真的占用完整交付容量，可以通过 shadow review、替代证据或同类项目数据完成回放。

3. false admit：规则允许进入，但关键失败在准入时已经可见

项目延期不自动等于 false_admit。突发事故、季度中途的法规变化、无法预见的上游故障，都可能让一个合理准入的项目失败。

误收要满足更严格的条件：在准入时已经存在足以拒绝或降级的信号，而当前规则没有识别，或者规则虽识别却被错误判定为通过。

1
2
3
4
5
6
7
8
9
10
11
false_admit_review:
  item_id: policy_replay_automation
  observed_failure: critical_owner_unavailable
  signal_available_at_admission: true
  admission_snapshot:
    required_owner_hours: 88
    protected_owner_hours: 52
    reported_owner_hours: 96
  cause:
    capacity_proof_used_team_total_instead_of_critical_role
  classification: false_admit

这里的问题不是执行期临时借走容量，而是准入材料用团队总容量代替了关键角色容量。规则方向没有错，校验字段却太宽。

首批准入后出现以下信号，可以进入误收复核：

  • 第一个不可逆 milestone 前，关键前提已经失效
  • 实际保护容量低于准入时声明值，且差异在当时可验证
  • acceptance 或 evidence contract 在进入季度时仍为空
  • 依赖方没有确认容量，却被记录为已满足
  • escalation contract 缺少触发后的默认动作

误收复核的输出应指向规则缺口，不能停在“项目失败”。

4. false reject：规则拒绝了一个本可低风险交付的项目

误拒更难发现，因为被挡住的项目不会产生完整执行数据。

可以从拒绝样本中抽取一部分做 shadow validation：不让它正式进入 roadmap，只允许补齐一份轻量交付推演，或者观察同类能力在其他团队的实际结果。

1
2
3
4
5
6
7
8
9
10
11
false_reject_review:
  item_id: internal_audit_query_api
  rejected_by: workflow_entry_required
  shadow_evidence:
    named_consumers: 3
    repeated_api_calls_per_week: 240
    human_workflow_required: false
    operational_owner_confirmed: true
  risk_if_admitted: low
  classification: false_reject
  rule_gap: stable_api_consumer_path_not_recognized

这个项目没有页面入口，却已经有稳定下游消费者。若规则把“必须有 workflow entry”写成唯一条件，它会拒绝一条同样可验证的 API 消费路径。

误拒检查至少保留一个反事实问题：如果去掉触发拒绝的那条规则，项目是否仍满足风险、容量、验收和可观测性要求？只有答案为“是”，才值得标记为 false_reject。

5. 例外压力说明规则承压，不直接说明规则错误

新规则上线后，例外请求数量通常会增加。单看数量，很容易得出“规则太严”的结论。

例外需要按压力来源拆开：

压力类型 常见诉求 应检查的事实
evidence_bypass 先进入，证据后补 证据是否影响风险判断
capacity_override owner 边做别的边推进 关键路径容量是否真实存在
premise_extension 过期前提继续沿用 是否出现新的有效证据
business_deadline 外部时间不允许等待 缩小范围后能否满足门禁 
1
2
3
4
5
6
7
8
9
10
exception_pressure_summary:
  total_requests: 9
  approved: 2
  rejected: 7
  repeated_pressure:
    type: capacity_override
    count: 5
  finding:
    rule_is_wrong: false
    capacity_contract_is_not_respected: true

五次容量例外不一定意味着容量规则过严。它也可能说明 roadmap 仍在用业务优先级替代可交付性判断。

只有当例外能提供一种原规则未覆盖、风险可接受且可重复验证的路径时，才把它记为规则修订候选。其余情况继续作为执行压力处理。

6. owner capacity 要看声明质量，也要看兑现质量

关键 owner 容量既能暴露误收，也能帮助区分规则缺陷和执行违约。

1
2
3
4
5
6
7
8
9
10
owner_capacity_validation:
  role: policy_runtime_owner
  declared_at_admission: 120
  protected_at_quarter_start: 116
  consumed_by_admitted_items: 84
  unplanned_work: 12
  borrowed_after_admission: 28
  result:
    declaration_quality: accurate
    execution_protection: violated

如果准入声明从一开始就虚高，应该修订 capacity proof 的校验方式。如果声明准确，进入季度后又被其他工作借走，问题在容量保护和升级动作，不该反过来提高准入门槛。

首批校验可以同时看四个数：

  • 声明容量与准入时可验证容量的差值
  • 保护容量与观察期实际可用容量的差值
  • 单一关键 owner 的并发 commitment 数
  • 因容量变化触发的降级、延期和例外数量

这组数据让“资源不足”变成可以定位的偏差，而不是一条无法行动的复盘结论。

7. 用混淆矩阵看规则质量，别只报拦截率

首批规模通常不大，指标不需要做成复杂模型。一张准入混淆矩阵已经足够暴露方向性问题。

准入决定 观察结果成立 观察结果不成立
接受 true_admit false_admit
拒绝 false_reject true_reject 
1
2
3
4
5
6
7
8
9
admission_quality:
  batch_id: 2026_q4_intake_01
  reviewed_items: 24
  true_admit: 11
  false_admit: 3
  true_reject: 8
  false_reject: 2
  exception_requests: 9
  owner_capacity_overrides: 5

不要急着把它压成单一准确率。治理规则的两类错误成本并不对称：一个高风险项目被误收，可能比三个低风险项目被误拒更严重；但长期只追求零误收，也会把所有项目挡在门外。

更实用的做法是给每条规则单独记录错误类型和影响：

1
2
3
4
5
6
7
8
9
rule_quality:
  critical_owner_capacity_proof:
    false_admit: 2
    false_reject: 0
    impact: high
  workflow_entry_required:
    false_admit: 0
    false_reject: 2
    impact: medium

这样才能分别收紧容量证明，放宽消费路径，而不是整体提高或降低准入强度。

8. 先修订候选规则，再决定是否升为 baseline

首批观察结束后，每条更新规则可以进入四种状态：

  • promote：方向和字段都有效，可以升为稳定基线
  • revise：方向有效，但证据字段、阈值或适用范围需要调整
  • hold：样本不足，保留候选状态再观察一批
  • rollback：副作用高于拦截收益，恢复旧规则
1
2
3
4
5
6
7
8
9
10
11
12
rule_promotion_decision:
  rule: critical_owner_capacity_proof
  current_version: 2026_q4_rc1
  decision: revise
  evidence:
    false_admit: 2
    false_reject: 0
    repeated_gap: team_capacity_used_for_critical_role
  next_version_change:
    require_role_level_capacity: true
    require_owner_acceptance: true
  validation_batch: 2026_q4_intake_02

规则被标记为 revise 后，不应立刻写入长期 baseline。让修订版再经过一批 intake，能避免团队根据首批偶然样本来回摆动。

promote 也要有最小条件：样本来源可追溯，没有高影响误收，误拒处于可接受范围，例外没有形成稳定绕行路径，关键 owner 容量证明能在执行期兑现。

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
32
33
34
first_intake_admission_validation:
  batch:
    id: 2026_q4_intake_01
    rule_version: admission_rules_2026_q4_rc1
    intake_count: 24

  decisions:
    accepted: 14
    rejected: 10
    exception_approved: 2

  outcomes:
    true_admit: 11
    false_admit: 3
    true_reject: 8
    false_reject: 2

  pressure:
    exception_requests: 9
    repeated_type: capacity_override

  capacity:
    declaration_mismatch_items: 2
    protection_violation_items: 3

  rule_decisions:
    critical_owner_capacity_proof: revise
    premise_freshness_window: promote
    execution_escalation_contract: hold
    workflow_entry_required: rollback

  next_check:
    batch_id: 2026_q4_intake_02
    owner: governance_program_owner

模板里的数字必须能回指到具体样本。缺少观察结果的项目标记为 pending，不要为了按时出报告强行归类。

小结

季度复盘产出的 admission rule 先是候选规则，不是天然正确的长期基线。

下一季度首批 intake 要同时跟踪接受、拒绝和例外样本。误收检查准入时已经可见却没有被挡住的风险，误拒检查规则是否挡住了本可低风险交付的项目；例外压力用来定位规则承压点，owner capacity 则要拆开声明质量和兑现质量。

校验结束后，按单条规则选择 promote、revise、hold 或 rollback。需要修订的规则再经过第二批 intake，确认改善不是对首批样本的过拟合，再进入稳定 baseline。

本文永久链接: https://www.mulianju.com/learning-notes/ai-learning-notes-llm-governance-updated-admission-rule-first-intake-batch-validation/