第476章 动态上限与“节奏控制”（1 / 2）

BANK-CHECK-01上线之后，城市群里第一次出现一种罕见的安稳：

大家不再天天问“银行会不会卡我们”，而是问——

“我这条A3为什么不够？”

“我的hard_ticket_rate怎么提升？”

“离线配额快满了，怎么做网络整改？”

恐慌变少了，但压力并没有消失。它只是从“口径不确定”变成了“指标必须扛住”。

何经理说的“动态上限”，听起来像银行要更强的权力：想收就收，想放就放。

林远却知道：如果不做动态上限，银行只能靠“人盯”。靠人盯就会被怀疑，怀疑就会引发对抗；对抗一上来，所有机制又会被拖回“关系协调”。

动态上限的价值不在“更严”，而在“可预测”。

该收紧的时候让系统自己收紧，该放开的时候让系统自己放开——让节奏控制变成公开刻度，而不是人情按钮。

林远在白板上写下这章的核心句：

收紧要有理由，放开也要有理由。

1）BANK-CAP-01：放款节奏的“红黄绿刻度”

省信息处牵头，银行风控、审计旁听、平台技术组开会，把“动态上限”翻译成一个可以被所有人理解的东西：红黄绿灯。

规则名字也很直白：

BANK-CAP-01｜放款节奏动态上限（试行）

它不讨论“贷不贷”，只讨论“节奏”。

每个城市、每个项目批次，都有一个“节奏级别”：

GREEN（正常）：按既定节奏放款

YELLOW（收紧）：放款批次减少/抽检比例提高/例外上限降低

RED（暂停）：暂停新批次，先完成整改与压力测试

触发条件不是拍脑袋，而是四类公开指标：

A类：证据链健康度

hard_ticket_rate低于阈值

A3序列不一致比例上升

M1证据令牌异常集中（疑似造动作）

B类：例外纪律

exception_id密度异常

SOC S2/S3占比异常

离线发生包超配额或离线占比异常

C类：可观测性与入口稳定

AutoReCert连续warn/fail

错误码上报缺失

i_id频发且恢复慢

D类：反表演风险

noise_gap_dex短期飙升

补签集中度异常（i_id集中补签）

材料相似度聚类上升

触发逻辑采用“多指标叠加”，避免单点误伤：

任一类指标进入高风险区，并持续N天 → YELLOW

两类及以上同时进入高风险区 → RED

指标恢复并通过压力测试 → 从RED回YELLOW，再回GREEN

“上限不是惩罚，是刹车。”何经理在会上说，“刹车要有仪表盘。”

审计旁听补了一句：“刹车也要留痕。每次从绿变黄、黄变红，都要生成cap_event_id并公开原因桶。”

于是规则加了一条：

任何节奏变化都必须生成cap_event_id，且在周报可见。

2）压力测试：不是折磨基层，是证明“放开有依据”

动态上限如果只有“收紧”，基层会觉得被拿捏。

所以林远坚持要配套“放开机制”：你整改完，怎么证明你能回到GREEN？靠领导拍板不行，靠会议也不行，只能靠测试。

于是第二份规则同步上线：

BANK-STRESS-01｜放款节奏压力测试（试行）

压力测试不是金融模型，也不是复杂打分，它更像“工程验收”：