复查日的结论贴出来之后，群里最常见的一句话变成了：

“他说72小时完成，看他敢不敢。”

这句话既是质疑，也是制度的试金石——你把“改进项”写成时限，写成编号，就必须在时限内兑现；否则之前所有“编号”都会被一句“你看，都是纸面”打回去。

林远把手机放在桌上，抬头对会议室里的人说：“72小时不是给他们看的，是给我们自己看的。补丁不兑现，复查等于白过。”

---

一、改进项A：接访编号与联验台账合并

改进项A最难，因为它触到一个很隐蔽的痛点：

居民觉得“你们让我们登记，但登记进了另一个系统，我们根本对不上”。

对不上，就会重新回到情绪——情绪最容易被带节奏。

交易中心专员提出方案：“做‘主编号’。所有诉求不管从群里来、接访来、联验来，都挂在同一主编号下。”

林远在白板写下结构：

主编号：CXR-年-月-流水号

下面挂三类子编号：

E类（验收）：联验/复检问题

V类（接访）：投诉/咨询/诉求

R类（整改）：责任单位整改动作与复核签收

“居民只需要记主编号。”林远说，“你想找回执，就在主编号下找。别再让他们记两套号码。”

技术员皱眉：“那历史台账怎么办？全部迁移很费时间。”

林远没犹豫：“不做全迁移，做映射。旧编号保留，新增一个‘关联字段’，把旧编号挂到主编号下。72小时内要可用，不追求完美。”

交易中心专员点头：“映射最快。”

于是，当天中午，一个最简版本上线：公开台账新增一列——主编号。

点进去能看到：

该主编号关联的联验项（清单+点位）

关联的接访诉求（分类+提交时间+答复时限）

关联的整改动作（责任单位+照片+签收）

最关键的一点：同一主编号下，所有状态必须一致。

你不能在接访里显示“已答复”，在联验里显示“无此记录”。

这一点被写成系统规则：状态以“最慢的那条链”为准。

老赵看见这规则，咂舌：“这等于把你们逼着不敢糊弄。”

林远点头：“对。合并编号就是把所有人绑在同一根绳上，谁想糊弄都拖着别人一起掉坑。”

---