第18章 保障计划（2 / 2）

-----------------

周一早晨八点，科兴科学园C栋16层。

Light项目组的办公区弥漫着一种不同于往常的气氛。空调开得很足，却驱不散空气里紧绷的质感。白板上那个曾经刺眼的「99」已经被擦掉，换上了新的数字——「15」。

周博涛站在白板前，双手撑着桌子，目光扫过围坐的二十几个人。所有人面前都摆着电脑，但没人低头。

「都看到了。」周博涛开口，声音不大，但每个字都清晰，「十五天。今天是第一天。」

他拿起马克笔，在白板上画了一条时间轴。

「0-4天，0.8版本群聊核心功能必须完成开发，完成Light0.8叠代。」

「5-9天，0.9版本完成叠代。」

「10-13天，1.0版本上线，完成两天测试。」

「第15天，准备最终汇报。」

有人轻轻吸了口气。

「我知道这听起来像天方夜谭。」周博涛继续说，语气平静得近乎冷酷，「但这是张总定的时间，也是集团赛马的最终时间。十五天后，要麽Light活下去，要麽我们所有人，包括我，打包去别的项目，或者离开腾讯。」

他停顿，让这句话的重量沉下去。

「所以，从今天开始，没有周末，没有固定下班时间。紧急情况下，通宵也是常态。」周博涛的目光扫过每个人的脸，「如果有人身体撑不住，或者家里有特殊情况，现在提出来，可以调去其他项目组。我不记仇，也不拦着。」

办公室里一片寂静。只有空调出风口持续的嗡鸣。

几秒钟后，有人举手——是测试组的一个女生，脸色有些发白：「周老师，我......我家里确实有点事，可能......」

「好。」周博涛点头，「散会后找李婷办手续。」

又陆续有两个人举手。

周博涛一一应下，脸上没什麽表情。

林深安静地坐在靠窗的位置，看着这一幕。

他知道这是周博涛在筛选——筛选出真正愿意背水一战的人。创业团队，尤其是在生死关头，需要的是能豁得出去的心脏。

「还有吗？」周博涛等了十秒，「好，留下的，我就当你们默认接受了这些条件。」

他转身在白板上写下几个大字：

「十五天，三版本，成功，或者失败！」

周博涛看向陈默：「陈默，技术层面你有什麽要强调的？」

陈默站起身，走到白板前：「既然时间定死了，我说几个技术红线：第一，所有代码必须通过自动化测试；第二，每天晚上十点同步进度；第三，遇到阻塞问题立即上报，不要自己硬扛超过两小时。我们输不起时间。」

周博涛点头：「好，现在开始0.8版本规划会。参会人员留下，其他人散会，立即投入工作。」

规划会在产品经理李婷的操办下迅速展开。

周博涛坐在长桌主位，左右分别是陈默和李婷，其馀人依次而坐。

「时间紧迫，直接进入主题。」周博涛开场，「0.8版本的核心是群聊。李婷，你先说产品侧的需求和预期。」

李婷调出投影，展示群聊原型图：「根据用户调研和竞品分析，群聊的基础功能框架已经确定：建群丶成员管理丶消息收发丶历史记录。但如果我们只做这些，和微邮件没有本质区别。」

她顿了顿：「我需要一个差异化亮点，让内测用户感觉Light的群聊更好用。」

周博涛看向陈默：「陈默，技术侧有什麽想法？」

陈默没有直接回答，目光扫过在座的技术骨干，最后停在林深身上：「林深，你昨天向我提过对群聊的一些思考，说说看。」

林深整理了一下思绪，说道「我看了原型，基础功能很完整。」他语气平稳，「但我在想，群聊和单聊的本质区别是什麽？」

他站起身，走到白板前，画了两个简单的示意图：「单聊是一对一沟通，信息精准直达。群聊是一对多，但信息容易在人群中淹没——这是群聊的核心痛点。」

「所以，」林深转身面向众人，「群聊的设计重点，应该是解决「信息如何高效触达需要的人」的问题。现在的设计只是把单聊的机制简单扩展，没有解决群聊特有的痛点。」

李婷追问：「具体指什麽痛点？「

「我想到两个。」林深在白板上写下关键词，「第一，重要信息如何确保被所有人看到？比如群主通知开会时间丶发布重要文件。第二，发错消息怎麽办？在单聊里发错话可能只是尴尬；在群聊里发错——尤其是大群——可能是社交灾难。」

他看向周博涛和陈默：「所以我建议，在基础群聊功能上，增加两个特性，而第二个人特性可以直接应用在单聊上。」

周博涛：「具体说。「

「第一，@所有人功能。」林深详细阐述，「群主和管理员可以发送一条特殊消息，强制推送给所有成员，并在客户端有特殊提醒，这样关键信息不会淹没在闲聊里。」

「第二，消息撤回。」他继续说，「发送者在短时间内可以撤回已发送的消息。这不仅是纠错机制，也是一种社交保护——避免因手滑或冲动发言造成不可挽回的后果。」

会议室里安静了几秒。

周博涛看向陈默：「陈默，技术角度评估一下可行性？」

陈默皱眉思考：「@所有人需要伺服器端特殊处理，消息撤回要保证端到端的同步......技术复杂度不低。林深，你既然提出来了，详细说说技术方案？」

「技术上可行。「林深回到座位上，快速组织语言，「@所有人可以设计成一种特殊消息类型，伺服器识别后做强制推送。消息撤回本质上是一条'删除指令'，需要客户端和伺服器协同，保证在时间窗口内所有端都能同步删除。」

后台组组长王浩提出了关键问题：「时间同步怎麽解决？如果A撤回了，但B的手机当时没联网，后来才收到消息怎麽办？」

「可以在消息协议里加一个'撤回标记'和原始消息ID。」林深显然已经思考过这个问题，「如果客户端收到撤回指令时，本地还有那条消息，就删除；如果还没收到原消息，就直接忽略撤回指令。这样保证最终一致性。」

陈默的手指在桌面上轻轻敲击，这是他深度思考时的习惯。

周博涛转向李婷：「产品价值呢？用户需要这两个功能吗？」

李婷快速翻看手中的调研报告：「群聊的痛点确实是信息淹没和发错消息。我们之前的小范围调研中，有用户提过类似需求。更重要的是，」她抬起头，「微邮件那边没有类似设计，这是我们的差异化机会。」

周博涛沉默片刻，目光扫过在座的每个人，最后做出决策：「好，作为差异化亮点加进去。但时间紧，谁负责？」

林深再次举手：「如果大家信得过，我可以负责这两个功能的设计和核心代码实现。我对消息协议和状态同步这块比较熟。」

周博涛看着林深，看了两秒，点头：「好，就你负责。」他转向陈默，「陈默，你作为技术负责人盯一下。林深，你直接向陈默汇报进度。」

接着，周博涛明确了分工：「王浩负责后台消息路由改造，张维负责客户端群聊UI和基础框架，其他人各司其职，散会。」