谷歌工程师自杀后：2000人收到一封"自动邮件"|代码|微软|知名企业|自动邮件|自杀|蓝屏事件|谷歌工程师

2024年12月，谷歌西雅图办公室一名31岁软件工程师从12楼坠落身亡。警方在遗体旁发现一张手写纸条，上面只有一串数字——那是他工牌的员工编号。三天后，公司系统自动向2000名同事发送了一封邮件：「该员工已标记为不可用，项目权限正在转移中。」

没人知道这是系统bug，还是流程如此。但收到邮件的人里，有他上周刚一起吃过午饭的队友，有他辅导过的实习生，有他在内部论坛最后回复过的陌生人。

一个写代码的人，死后被自己的代码通知了死讯。

「我的宗教是数学」

死者Jacob（化名）在谷歌工作四年，负责底层存储系统的性能优化。他的内部主页至今保留着一句话：「Someone once told me my religion was mathematics. 1/2 doubt.」——有人曾说我的宗教是数学，我半信半疑。

这句话摘自他唯一公开的博客文章，写于2022年。文中他描述了一种状态：写代码时的沉浸感接近祈祷，「变量命名像诵经，递归像冥想，找到bug的那一刻像神启」。但他也写道，这种状态的代价是「走出编译器后，现实像没加载完的网页——白屏，卡顿，无法响应」。

同事回忆，Jacob极少参加团建，但会默默修复别人留下的技术债务。他的代码评审记录显示，过去两年他提交了147次「非必要优化」——把那些能跑但不够优雅的代码重写一遍，零绩效加分，纯自愿。

「他像那种会把图书馆倒架的书一本本归位的人，」一位前队友说，「但没人注意到，他归位的时候总在深夜。」

系统如何处理一个人的消失

谷歌的内部系统有个功能叫「继承者管理」（Successor Management）。当员工长期休假、离职或死亡时，系统自动将其项目权限、代码所有权、会议邀请转移给预设的备份人。设计初衷是防止「关键人风险」——某个工程师突然消失，项目陷入瘫痪。

Jacob的权限转移触发于死亡确认后的第72小时。系统判定逻辑很简单：HR标记状态→触发工作流→通知相关方。邮件正文由模板生成，包含三行信息：员工姓名、生效日期、新负责人联系方式。

没有哀悼词，没有暂停选项，没有「该员工已故」的勾选框。

一位收到邮件的工程师在内部论坛发帖：「我知道这是程序，但看到他的名字和『权限转移』放在一起时，我花了十分钟才反应过来这不是恶作剧。」帖子获得340个赞，评论区有人贴出Jacob最后一次提交的代码——一个关于错误处理机制的改进，提交信息写着：「让系统更优雅地失败。」

谷歌发言人事后回应：「我们正在审查相关流程，考虑增加人工审核环节。」但没有解释为何系统没有「死亡」这一状态选项，只有「不可用」。

祈祷的多种形态

Jacob的博客里还有一段被大量转发的话：「For some lucky few of us, (perhaps a select proportion inclined towards depression), prayer can come in many forms.」——对我们中少数幸运儿来说（也许是那些倾向于抑郁的人），祈祷可以有多种形态。

他把写代码比作祈祷，把数学证明比作朝圣。但文章结尾的转折很少被引用：「Unfortunately, we can't live our lives in prayer. Because sometimes, actual life gets in the way. And we are needed by the people around us.」——不幸的是，我们无法活在祈祷中。因为有时现实会挡道。而身边的人需要我们。

这段话写于2023年春天，他母亲确诊阿尔茨海默症之后。同事后来才知道，他申请了远程办公搬回西雅图，是为了每周带母亲做两次认知训练。他的日历里，周四下午永远标着「Mom」，从2023年3月到2024年11月，从未中断。

系统没有记录这些。他的内部档案里，远程办公原因是「个人原因」，项目贡献度评分是「符合预期」，最后一次绩效反馈是「需要更多跨团队协作」。