第463章 编号验真与造号生意（1/2）

“投诉工单模板，快速生成SOC编号。”

陈毅把那张截图丢到投影上时，会议室里的人先是皱眉，紧接着就沉默。不是因为这招有多高明，而是因为它太“符合人性”——你把消防门的钥匙做成“编号”，市场就会第一时间教人“怎么拿到编号”，甚至教人“怎么造出编号”。

林远盯着那句广告，没骂，也没嘲笑，只说：“立案。名称就叫——编号验真。”

刘曼有点急：“如果真有人造号，那exception_id这套会被玩坏。我们刚把消防门装上锁，现在有人开始造钥匙。”

“锁没坏。”林远摇头，“锁只是提醒我们：钥匙必须来自独立系统。我们现在缺的不是规则，缺的是对账。”

他在白板上写下一句话：

编号必须可对账，才能算证据。

老许皱眉：“对账说得简单。投诉工单、信访编号、热线……这些系统谁给你接口？隐私、权限、工作量，哪个都不好搞。”

林远点头：“所以我们不做‘看内容’，只做‘验存在’。不拿隐私换公信力。”

1）“验真”不是调出详情，而是证明你没编

当天下午，省信息处牵头拉了一个小范围碰头会，地点选在省政务热线中心（）旁边的会议室。来的人不多，但关键：热线中心主任、信访办一位业务处长、网信办联络、审计旁听、银行何经理、数科安全负责人、陈毅。

热线中心主任一上来就把顾虑摆在桌面上：“你们要核验编号？我们系统涉及个人信息，不能随便给外部查。更不能让城市拿着编号去‘查投诉人是谁’。”

林远直接把方案打开，第一页只有三行字，像极了他做公共接口的习惯——先把边界写死：

不查内容

不查个人

只验存在与时间窗

“我们要的不是谁投诉、投诉了什么。”林远说，“我们要的是：这个编号是不是在你们系统里真实存在；大概是什么时间、哪个地市、属于哪类风险（安全/群体/供应链/政策）。你们给一个‘是/否’，再给一个摘要签章就够了。”

网信办联络立刻问：“摘要签章怎么做？不能把原数据给出去。”

陈毅把技术草案推过去：“我们做两种方式，按你们的能力选。”

方式A：在线验真（推荐）

平台提交：编号 + 地市 + 时间窗（比如最近30天）

热线中心返回：exist=true/false + category（SOC等）+ created_date（只到天）+ attestation_hash（签章摘要）

不返回任何个人信息、不返回正文、不返回联系方式。

方式B：离线对账（过渡）

热线中心每天生成一份“编号清单摘要”：只包含（编号哈希、地市、日期、类别）

用热线中心私钥签名后提供给省平台

省平台用来匹配核验“是否存在”。

主任盯着“编号哈希”四个字，明显松了一口气：“这就好办多了。我们不暴露内容，只提供存在性证明。”

信访办处长也点头：“信访那边也能类似做。但我们需要把‘编号哈希算法’和‘时间窗’写死，避免你们拿哈希做反查。”

林远立刻接：“算法、盐值管理、签章密钥，全都写进规则，由你们掌控。我们只做验真，不接触原文。”

银行何经理在旁边补了一句特别现实的话：“我们支持这种验真。银行并不想看投诉细节，我们只需要确认：风险事件不是编的，且后续整改复测有链路。”

审计旁听把笔记写得很快：“只验存在，符合最小必要原则；签章摘要，符合可追溯。”

热线中心主任最后说了一句像盖章的话：“如果只做到这一步，我们可以配合试点。”

林远点头：“那就做成公共接口的一部分，编号就不再是嘴里说的，是系统里能对账的。”

2）EXC-01升级：造号不是“填错”，造号是干扰源

回到办公室，陈毅把规则草案改成修订版：EXC-01.1。新增一章就叫《事件编号验真》。

里面有三条红线，但同样强调“不误伤”：

1）编号必须验真后才能签发exception_id

SOC/SUP/POL/SAF四类全部进入验真

验真失败：不签发，退回补证

2）一次失败不定性，重复失败定模式

首次验真失败：给予24小时纠错窗口（避免录入错误/系统延迟）

48小时内两次失败：触发“轻度干扰”标记，抽查加密

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