第465章 小火不许开大门（1/2）

RFC-019把“借火警”挡在门外之后，消防门并没有立刻安静下来。

它只是换了一种更聪明的摇晃方式——桶一致、主题码一致、编号也真。申请人不再拿外地的火警来开门，而是拿同区县里一条真实投诉，去撬整个项目的排期。

“火是真的。”陈毅把一条SOC申请投到墙上，“但它可能只是厨房冒烟。对方却写成整栋楼起火。”

申请材料写得极漂亮：

“群体性风险正在扩大”“如不立即处理将引发大规模维权”“建议启用紧急编号插队复测”。附件里是两张截图、三段措辞很像的“群众反馈汇总”，再加一个验真通过的工单号。

林远看完只问一句：“影响范围在哪里？”

“他们写了‘影响范围广’，但没有量化。”陈毅说，“没有几栋楼、多少户、几天内新增多少工单、现场整改链路是什么。”

林远把手机扣在桌上，声音很平：“那就把影响范围写成规则。exception不是因为你有一个投诉，是因为投诉指向系统性风险。”

他在白板上写下四行字，像给消防门装第二道门栓：

SOC必须声明影响范围

影响范围必须可复核

抽查回访只查链条不查人

小火不许开大门

1）SOC-Ipact-01：把“群体性”变成填空题

当晚，公共接口新增了一份模板，编号很短：SOC-Ipact-01。

模板不是作文题，是填空题，必须填“数”：

影响对象：楼栋数 / 单元数 / 车库区段数（按项目指纹范围）

影响周期：起始日期—截止日期（到天）

证据链：

内部工单链路ID（至少1条）

监理日志编号（至少1条）或整改工单编号（至少1条）

/信访编号（可选，但若填则必须验真+关联性PASS）

增量指标：过去7天新增工单数、重复投诉数（只要数量，不要内容）

处置承诺：到期前必须完成哪一项复测（run_id绑定）

最关键的，是模板最后一行：

“影响范围分级（系统自动判定）：S0/S1/S2/S3”

陈毅把分级规则也写进RFC附件里，简单到残酷：

S0（孤点）：7天内新增工单 ＜ 3，且无监理隐患/整改工单链路 → 不允许exception

S1（局部）：新增工单 3–10，且有整改链路 → 不走exception，走“客观加速器”

S2（片区）：新增工单 ＞ 10 或涉及多个楼栋 + 有整改链路 + 复测计划 → 允许exception一次

S3（系统性）：新增工单显着上升且跨阶段扩散（交付期扩至维保、或质量扩至安全）+ 审计旁听 → 允许exception，但到期强制复测+加密抽查

“把‘群体性’做成四档。”林远说，“你想喊大词没用，系统只认你的链条与增量。”

银行何经理听完，在群里丢了一句很像风控的话：“这才像风险事件。银行不怕慢，怕‘一句群体性’就插队。”

2）抽查回访：只查链条，不查投诉人

城市那边很快就提出顾虑：“你们要抽查回访，会不会触碰隐私？会不会让人以为我们在追投诉人？”

林远把边界说死：“不回访投诉人。回访三条链——项目方工单、监理日志、整改闭环。抽查的是‘你有没有把风险当借口’，不是‘谁投诉你’。”

于是抽查回访变成了工程动作：

抽查工单链路是否真实存在、是否有处置动作、是否按时闭环

抽查监理日志编号是否匹配现场阶段

抽查整改工单是否与复测run_id对应

任何一条对不上，SOC分级自动下调；恶意夸大则触发“反表演扣分+复测加密”。

3）第一场“夸大范围”被打回去

两天后，佛山那边提交了一条SOC申请——正是之前那家爱推“申请指导”的服务商参与协作的项目。

材料一眼看上去很强：桶一致、主题码一致、编号验真PASS、关联性PASS。

本章未完，点击下一页继续阅读。