第39章 明牌（二）（1 / 2）

「匹配时，系统不比较坐标，只比较网格编号。」周倩切换幻灯片，上面是复杂的算法流程图，「如果两个用户在同一个网格内，直接匹配；如果在相邻网格，并且满足一定的辅助条件，比如都曾在夜间使用过该功能，或者都搜索过同类关键词，也可以触发匹配建议。」

刘锐飞快记录，然后抬头问：「网格的大小？」

「动态调整。」周倩推了推眼镜，「核心商务区可能只有300米见方，住宅区可能扩大到800米，我们会预先加载每个城市的网格地图，但用户设备上只存储编码，不存储地图本身，伺服器端也只记录匹配发生的网格编号，不记录任何可能反推用户真实位置的信息。」

林深一直在安静地听，这时才开口：「这个方案，研究院做过现成的代码库吗？」

「有基础框架，但需要针对社交场景做大量优化。」周倩说，「特别是实时性要求，从用户摇动手机，到网格定位，到匹配计算，整个链路需要在500毫秒内完成。这需要客户端和伺服器端的高度协同。」

「资源不是问题，」林深看向孙辉，「需要多少计算节点，直接申请。」

会议室里响起轻微的吸气声。

新加入的团队成员们交换着眼神，这种资源调动的气魄，是他们从来没见到过的。

「第二层，实时交互。」程向东继续推进议程，「15秒的双向确认，技术上需要解决两个问题：一是状态同步的精确性，二是高并发下的系统稳定。」

他在白板上快速列出技术要点：

WebSocket长连接保活与心跳机制。

分布式会话状态管理。

时钟同步与超时统一。

断线重连与状态恢复。

「最难的是时钟同步。」程向东的笔尖在第三点重重画圈，「用户A在14.9秒点击确认，用户B在15.1秒点击，这算成功还是失败？伺服器时间丶客户端本地时间丶网络传输延迟……任何细微的偏差都可能导致糟糕的用户体验。」

吴峰举手：「可以用NTP协议做时间同步，但公网NTP的精度可能不够。」

「用腾讯内网的授时伺服器。」林深直接给出方案，「拉专线，做私有化部署，精度控制在毫秒级，孙辉，这个你协调基础架构部解决，今天下午我要看到方案。」

孙辉快速记录：「明白。」

「第三层，用户体验与安全管控。」程向东切换到最后的议题，「刘锐，产品侧有什麽特别要求？」

刘锐站起身，走到白板前，在程向东的技术框架旁边，画出用户交互的完整流程：

「从用户摇动手机开始，我们就要建立一个渐进的信任阶梯。」他的笔在白板上移动，画出一个阶梯状的图示，「第一步，摇动后的瞬间，只显示『正在寻找可能有趣的连接』，不给任何位置提示，不制造焦虑。」

「第二步，匹配成功后，显示极简信息：『一位同样在科技园区的朋友，距离你约500米』。这里的关键词是『约』，是『朋友』，是营造一种安全丶模糊丶友好的氛围。」

「第三步，15秒确认倒计时。这个过程中，可以浮现金句提示，比如『好的连接值得等待』，『双向确认是互相尊重的开始』。这不是功能说明，是价值观传递。」

「第四步，对话开启后的15分钟限时。界面设计上要有明显的时间进度条，要有『保存到本地』和『一键销毁』的快捷操作。在最后60秒，要温柔提示：『对话即将结束，要保存这些珍贵的瞬间吗？』」

他放下笔，看向林深：「整个流程的设计哲学是：不给压力，只给选择；不制造焦虑，只提供安心。我们要让用户感觉，这不是一场充满不确定性的陌生人社交，而是一次安全丶可控丶有趣的探索。」

林深安静地听完，然后问：「举报和风控怎麽融入？」

「深度融合。」刘锐调出另一张设计图，「对话过程中的任何时刻，长按消息气泡都会弹出举报选项。举报后，对话立即终止，双方自动互加屏蔽。但更重要的是，」他顿了顿，「我们要建立一个基于行为的信誉系统。」

会议室里所有人的目光都聚焦过来。

「不是基于身份的信誉，是基于设备的匿名信誉。」刘锐解释，「每台设备都有一个隐形的信誉分。正常使用丶完成对话丶获得好评会加分；被举报丶频繁取消匹配丶发送可疑内容会扣分。当信誉分低于阈值时，这台设备发起的匹配请求会被降权处理，不是完全禁止，而是匹配等待时间延长，匹配范围缩小。」

周倩眼睛一亮：「这可以在算法层面实现，匹配计算时，把设备信誉分作为一个权重参数加入。」

「但对高信誉设备给予奖励。」林深补充，「比如更快的匹配速度，更大的匹配半径，甚至，未来可以考虑一些轻量的专属功能。我们要建立一个正向循环：尊重规则的用户获得更好体验，破坏规则的用户自然被边缘化。」

会议开到中午十二点半，技术方案基本定型。周倩负责差分隐私算法的社交化适配，三天交付核心代码；程向东负责客户端集成与实时交互框架；孙辉牵头后台架构与资源调度；刘锐完成产品互动设计并协调用户测试。

散会后，林深叫住刘锐和周倩，三人走进小会议室。