二、改进项B：轮换与回避核验补丁

改进项B看似简单，其实关系很大：代表机制如果被质疑“利益输送”，前面所有“代表签收”都会被打成“收买”。

街道办代表主动揽下来：“回避核验我们来做。我们不查隐私细节，只核验三类关系：

1）是否为施工/开发关联人员；

2）是否与供应商/劳务存在雇佣关系；

3）是否存在近亲属直接利益关联。”

林远补一句边界：“核验结果只显示‘通过/不通过’，不公开原因细节，保护个人。”

当天晚上，劳务代表与居民代表的名单页新增两栏：

轮换记录（上任/下任时间）

回避核验（通过/不通过，编号）

并加一条硬规则：

未通过回避核验者，不得参与签收。

这条规则一出，群里有人立刻说：“那你们是不是要查我们隐私？”

管理员丢出边界说明编号：“只看是否存在直接利益关联，不公开细节，核验单位为街道办，结果只显示通过/不通过。”

讨论瞬间降温——因为边界明确，攻击点就少。

---

三、兑现方式：不解释，直接上线可查

第二天上午十点，林远要求做一次“公开验收演示”：

在社区活动室里，随机抽一条接访诉求，让提出诉求的居民当场查主编号，看能否对上联验项与答复时限。

一位业主提了一个很常见的问题：“我家卫生间门口地漏返味，之前联验有人记录过，但我没拿到编号。”

工作人员当场用“户号+楼栋+日期”检索，找到旧编号，再自动映射到主编号：CXR-2025-12-0xxx。

主编号页面里清晰显示：

E类：地漏返味（点位编号）

R类：整改动作已提交（照片编号）

V类：业主接访诉求已登记（答复时限剩余：18小时）

业主看着屏幕，愣了两秒，突然说了一句很真实的话：“这样我就不需要天天在群里吵了。”

这一句话，比林远写一万句制度更值钱。

---

四、对手的反扑：攻击“合并编号是控评”

下午三点，对手果然换口径了：

“他们把诉求合并编号，就是为了控评，想把大家的声音收进系统里消音！”