AI 学习笔记（五十三）：LLM 治理资产复用评分、继承冲突处理与新周期基线播种节奏
上一篇把重点放在年度治理资产的分层盘点、失效控制和新周期策略继承边界。
但真正进入新周期时，团队还会遇到一个更细的问题：不是所有被留下来的资产都应该马上复用，也不是所有团队都能用同一套继承规则。
一份旧基线在 A 团队可能已经被验证稳定，在 B 团队却可能因为流量结构、模型版本、人工复核能力和业务容错空间不同，变成新的误判来源。一个历史上有效的例外处理模板，如果没有重新校准适用范围，也很容易在新周期里变成“默认绕过门禁”的通道。
所以，新周期启动不能只做“资产迁移”，还要回答三件事：
- 治理资产是否值得复用，应该怎么评分
- 跨团队继承发生冲突时，谁让步、谁重审、谁降级
- 新周期基线怎么分批播种，而不是一口气全量恢复
1. 复用前先评分，不要把“曾经有用”当成“现在可用”
治理资产最容易被高估的地方，是它曾经解决过真实问题。
一次事故复盘、一套阈值、一份证据模板、一条例外审批规则，只要曾经帮团队避过坑，就很容易被默认继续保留。但 LLM 场景里的上下文变化太快，模型能力、业务目标、请求结构、审查人力和风险承受度都会变。历史有效只能说明它有复盘价值，不能直接说明它有复用资格。
我会给每份准备进入新周期的资产补一个 reuse_score，至少看五个维度：
validated_effect：是否在真实流量或真实评审中证明有效context_stability：适用场景、模型版本、数据结构是否仍然稳定operation_cost：继续维护它需要多少人工、监控和解释成本failure_impact：误用之后会不会放大误判、阻断上线或制造合规风险owner_clarity：是否还有明确 owner 能解释、更新和下线它
评分不是为了制造复杂流程，而是把“要不要继续用”从经验判断变成可讨论对象。
尤其是那些看起来很熟悉的资产，更应该被评分。熟悉会降低警觉性，团队很容易只记得它解决过什么，却忘了它依赖过哪些前提。
2. 复用评分要给出默认动作，而不是只给一个数字
如果评分最后只是一个表格分数，它很快就会变成新的归档噪音。
真正有用的评分，需要直接连到默认动作。比如可以把资产分成四档：
reuse_directly：高收益、低漂移、owner 清晰，可以进入新周期主线reuse_with_guardrail：价值仍在，但需要补监控、补边界或缩小适用范围pilot_before_reuse：证据不足或上下文变化较大，只能先小流量试用archive_only：只保留历史解释价值，不再进入默认治理流程
这个分档的好处，是避免团队在每个资产上都重新辩论一次。
比如一份历史事故证据模板，如果 validated_effect 很高，但 context_stability 已经明显下降，那么它不应该直接进入 reuse_directly。更合理的动作是 reuse_with_guardrail：保留模板结构，但重新绑定当前模型版本、当前监控指标和当前 owner。
再比如一条曾经有效的阈值规则，如果 owner 已经离开、上下文也变了，即使当年收益很高，也只能进入 pilot_before_reuse 或 archive_only。
数字负责暴露差异，动作负责降低执行摩擦。没有默认动作的评分，通常只能让治理会议多一页材料。
3. 跨团队继承冲突不要靠资历裁决，要靠适用范围裁决
新周期里常见的冲突是：一个团队希望继承旧规则，另一个团队认为旧规则会误伤自己。
这类冲突如果靠“谁之前做得多”“谁事故更多”“谁业务更重要”来裁决，很容易变成组织博弈。更稳的方式，是把冲突拆成适用范围问题。
我一般会先问四个问题：
- 两个团队面对的是不是同一种输入风险
- 两个团队使用的是不是同一类模型能力和工具链
- 两个团队的人工复核带宽是否相近
- 两个团队对误杀、漏放、延迟上线的容忍度是否一致
只要其中一个核心前提不同，就不要强行继承同一条规则。
这时更适合把资产拆成 shared_core 和 team_overlay。shared_core 只保留跨团队都成立的底层约束，比如证据必须可回放、例外必须有到期日、回滚链路必须可验证；team_overlay 则放团队自己的阈值、审批人、流量窗口和人工复核策略。
这样冲突就不会卡在“继承还是不继承”，而是变成“哪些东西可以共享，哪些东西必须本地化”。
4. 冲突处理要有临时降级态，避免一争议就阻塞新周期启动
跨团队继承冲突最糟糕的结果，不一定是裁决错误，而是争议拖太久，导致新周期迟迟没有可执行基线。
所以继承冲突需要一个临时降级态。
如果某个资产短期内无法达成一致，可以先进入 provisional_baseline，但必须带上三个限制：
scope_limit：只在明确场景内生效，不扩大到所有团队expiry_time：默认短期有效，到期必须复审evidence_task：争议点必须转成可验证任务，而不是继续口头讨论
临时降级态的价值，是让系统先有一个可控起点，同时不把临时妥协伪装成长期规则。
比如团队对某个拦截阈值是否过严有争议，可以先只在高风险业务线启用，并要求两周内补齐误杀率、人工复核通过率和回滚触发记录。到期以后，用证据决定是否扩大、降级或下线。
没有临时降级态，团队很容易在两个坏选项里摇摆：要么强行全局继承，要么因为争议不决而没有任何基线。
5. 新周期基线要分批播种，不要一次性全量恢复
很多治理体系在新周期第一天就把上一周期留下来的规则全部恢复到主线。
这看起来效率很高，实际风险也最大。因为新周期的业务目标、模型版本、项目组合和团队人力可能都已经变化。全量恢复会让团队很难判断后续问题到底来自新规则、旧规则，还是多个规则叠加后的副作用。
更稳的做法，是把基线播种分成三批：
day_0_seed：只放入低争议、高确定性的硬约束week_1_seed：补入需要少量校准、但 owner 清晰的复用资产week_2_review_seed：把争议资产、试点资产和带 guardrail 的资产纳入复审
day_0_seed 不追求完整，只追求不让系统裸奔。
例如证据留存、例外到期、回滚验证、关键风险告警这些底线，可以在第一天进入基线；而复杂阈值、团队差异化审批、自动化仲裁规则，则更适合等第一周数据回来后再播种。
基线播种的核心不是慢，而是让每一批进入主线的规则都有可解释的进入理由。
6. 播种节奏要和观测窗口绑定
如果基线播种只按日历推进，也会出问题。
有些团队第一周流量很少，规则看似稳定只是因为样本不足；有些团队第一天就遇到大促、发布冻结或模型切换，规则的表现会被特殊窗口污染。
所以播种节奏应该同时绑定观测窗口，而不是只绑定自然时间。
一个比较实用的最小条件是：
- 至少覆盖一个正常业务流量窗口
- 至少经历一次真实准入或变更评审
- 至少产生一组可回放的误杀、漏放或人工复核样本
- 没有触发未解释的异常波动
满足这些条件以后，资产才从 seeded 进入 active_baseline。
这能避免一种常见错觉：规则上线了几天没有问题，于是被认为稳定。对治理规则来说，没有问题不一定代表有效，也可能只是没有遇到足够复杂的样本。
7. 最小台账模板
为了让这套机制能落地，可以把复用评分、继承冲突和播种状态放在同一份台账里。
一个最小版本大概是这样：
1 | governance_asset_reuse: |
这个模板不需要一开始就很完整。
它的作用是把资产是否复用、怎么继承、争议如何处理、什么时候进入主线放到同一个视图里。只要这四件事能被看见，团队就不容易把旧规则无意识地搬进新周期。
8. 小结
新周期治理最容易被忽略的，不是有没有资产，而是资产怎么重新进入系统。
复用评分解决的是“值不值得继续用”；继承冲突处理解决的是“不同团队能不能用同一套东西”；基线播种节奏解决的是“什么时候让它重新影响默认判断”。
如果这三件事缺一件，年度沉淀就可能变成年度负担：资产越积越多，继承越来越重，基线越来越难解释。
我更倾向于把新周期启动看成一次有节奏的重新准入，而不是一次简单迁移。
真正值得保留的治理资产，应该经得起评分、经得起边界拆分，也经得起新周期观测窗口的再次验证。