二、林远的提案：更新必须像工程变更一样走“变更单”

第二天早上，清远向省信息中心提交了一份提案，标题故意写得像工程管理：

《接口答复库与FAQ更新的变更控制建议（ECN-解释版）》

提案只讲四件事，但每件事都把“更新权”关进流程：

1）版本化：FAQ/答复库必须有版本号（FAQ-v1.0、v1.1…），每次更新必须记录变更点与生效日期。

2）变更单：任何新增/修改/删除口径解释，必须提交变更单，写清：变更原因、影响范围、是否涉及交易条件、是否需要回放评估。

3）回放评估：凡涉及“可能影响刻度判定或X%交易条件”的解释更新，必须对历史数据回放模拟，评估是否改变判定结果。

4）审计旁听：重大更新由审计口旁听，至少抽查变更依据与回放报告。

林远在提案里加了一句很像钉子的结论：

“FAQ属于解释接口的一部分，其更新应等同于规则变更，不应以运营便利替代变更控制。”

这句话把“运营”直接降级成“执行”，把“更新”升级成“变更”。

三、承建单位的反击：变更单会让响应变慢

承建单位负责人在会议上立刻反对：

“FAQ更新如果走变更单，会导致响应慢，企业提问得不到及时答复。”

这话很像关心企业，但实际上是在争“快”的权力。

快意味着可以先回答、后补依据；先形成事实、再谈流程。

林远没有否认“快”的价值，他把问题分层：

“FAQ更新分两类：

解释性补充：比如问法归类、流程指引、引用编号补充——可以快更，但也要版本记录；

口径性变更：比如放宽/收紧边界、改变建议动作优先级、涉及交易条件理解——必须走变更单与回放。”

然后他补了一句让银行很舒服的话：

“可以快，但不能快到能改变钱。”

银行风控总监当场点头：“我们同意。涉及费率梯度与交易条件解释的更新，必须可追溯可复核。”

协会代表换了个角度：“那企业怎么知道你们是不是悄悄更新？更新太频繁也会造成不确定。”

清远分管领导顺势把“更新公告”写进提案：

这章没有结束，请点击下一页继续阅读！

“每次版本更新，必须发布简短公告：变更点、适用范围、引用编号。让企业能追到版本，不用靠截图。”

四、最隐蔽的战术：用“答疑口吻”改边界

会议快结束时，审计口的人突然问了一个很尖的问题：

“如果FAQ不改阈值，只改‘建议动作’，算不算口径变更？”