你怕的不是 Bug
风格：Paul Graham（essay 体）
我最近听到一个故事。一个程序员的同事因为线上出了个小 bug，被领导在工作群里当众训斥。
这个程序员不是被骂的人。事故也不是他造成的。但他一整天都处在一种绷紧的状态里。
这件事有意思的地方在于：让他焦虑的根本不是那个 bug。
想想你在工作中真正害怕的是什么。
大多数程序员以为自己怕的是写出 bug。但如果你仔细观察，就会发现事情没那么简单。在有些团队里，人们天天在 production 上修 bug，心态稳得很。在另一些团队里，一个小问题就能让整个组的人如坐针毡。
区别不在 bug 本身，而在于这个组织如何对待犯了错的人。
那个领导做了一件很具体的事：他把一个技术问题翻译成了对人的否定。他没有说“这个接口的容错逻辑不够健壮”，而是说“你做事不靠谱”。他没有说“上线流程需要加一道检查”，而是说“以后不要再提交代码了”。
问题从“事”变成了“人”。
这个滑坡一旦发生，所有目睹它的人——不只是当事人——都会本能地做一件事：评估自己被同样对待的概率。这不需要你有意识地去想，你的大脑会自动完成这个计算。
所以那个程序员的焦虑根本不是关于代码质量的。它是关于这个环境的。
Harvard 有个教授叫 Amy Edmondson，她研究了几十年的团队效能，最后得出一个很反直觉的结论：高绩效团队的第一特征不是成员能力强，不是工作流程好，而是团队里的人敢不敢暴露自己的错误和不确定。她管这叫“心理安全感”。
Google 后来在内部做了一个大规模研究，分析了 180 多个团队，结论跟 Edmondson 一模一样：心理安全感是区分高效团队和低效团队的第一因素。
这很反直觉。因为我们的默认假设是：严格的团队出好产品。领导要求高，大家才会认真。如果你对犯错的人太宽容，大家就会松懈。
但数据说的是相反的故事。当人们害怕暴露错误时，他们不是变得更小心——他们是变得更善于隐藏。问题不会减少，只是变得不可见。直到不可见的问题积累到某个临界点，来一次真正的爆炸。
故事里的程序员后来做了一件事我觉得很对。他去安慰了那个被骂的同事。
他说的话很朴素，大意是：出了事总得有人背锅，领导不想背就轮到你，代码刚好是你写的，这没什么办法。
这不是什么精致的心理安慰。但我注意到它有一个很重要的特质：诚实。他没有装作世界是公平的，没有说“别想太多”，也没有试图把一个不好的处境包装成一个励志故事。他只是承认了现实的运作方式。
后来他反思，觉得这种安慰可以做得更好——除了承认现实，还可以给对方一个具体能做的事情。比如一起梳理一下事故时间线，把自己做过的确认和测试整理出来，让事实链条清楚一些。
这里面有一个很好的洞察：人只要重新获得一点点行动感，就会从恐惧里往外走一点。 不是因为行动能解决一切，而是因为行动会打断“我完蛋了”这个心理循环。
但这整件事留给他最大的影响，其实是关于“自保”的。
“自保”这个词在职场语境里听起来不太好。它暗示你在想着怎么保护自己，而不是怎么把事情做好。仿佛一个人如果在想自保的事，就说明他不够投入、不够有担当。
我觉得这是一种很有害的道德叙事。
在一个心理安全感足够高的环境里，你确实不太需要想自保的事。你全身心投入工作，犯了错有人兜着，大家一起复盘、改进、往前走。
但在很多真实的职场环境里，事情不是这样运作的。你犯了错，可能会被公开否定，被贴标签，被当作能力不足的证据。在这种环境里，不想自保才是不理性的。
所以关键问题不是“该不该自保”，而是“怎么自保才高级”。
低级的自保是甩锅、推诿、只做没有风险的事情。高级的自保是让自己的工作变成一种可被追溯、可被解释、可被证明的状态。
具体来说就是：你做了什么改动，影响范围是什么，你预判的风险是什么，你做了哪些验证，如果出问题第一步怎么止血，上线后看哪些指标。
这些信息不是给别人看的政绩报告，而是你给自己建的防线。当有人问你“你确定你的代码没问题吗”的时候，你拿出来的不是一句“我觉得没问题”，而是一条完整的思考链。
有意思的是，这种做法同时也让你成为更好的工程师。因为你在做这些的过程中，实际上就是在做更严格的风险评估。自保和做好工作，在这个层面上完全一致。
然后他想到了 AI。
他说了一句话我觉得很精准：“以前我让 AI 帮我更快地到达‘能跑起来’。以后我想让 AI 帮我更稳地到达‘能讲清楚、能守住、能解释’。”
大多数程序员用 AI 的方式是让它帮忙写代码。这没错，但它只覆盖了工作的一个维度。还有另一个维度很少有人想到：让 AI 帮你扫描风险。
把你的设计方案、代码 diff、上线步骤喂给 AI，让它以一个偏保守的 senior reviewer 的视角，列出最有可能出问题的地方。接口边界？幂等性？异常分支？并发？数据一致性？监控盲区？回滚复杂度？
AI 不需要替你做判断。它只需要帮你把你可能没想到的东西摊开来看。你来决定哪些需要处理。
这其实是 AI 最被低估的用途之一。不是替你做事，而是帮你看见你没看见的东西。
他还想到一个更具体的用法：让 AI 扮演一个强势领导来盘问他。“这次变更最坏会出什么事？影响多少用户？你凭什么认为是这里的问题？证据呢？回滚安全吗？”
通过这种模拟盘问，他可以提前发现自己哪里讲不清楚、哪些证据没准备好。这样真到现场，他反而不会慌。
这让我想到一个更普遍的道理：职场里的“可靠”不等于“永远不出错”。它等于“出了错也能迅速给出边界和判断”。
领导真正害怕的不是 bug——bug 天天都有。领导害怕的是信息失控：他不知道这个问题有多大，不知道是不是还在扩大，不知道眼前这个人到底有没有掌控局面的能力。
如果你在那个时刻能清楚地讲出“现在发生了什么、影响到哪里了、已经做了什么、接下来怎么办”，即使问题还没解决，信任也不会崩塌。
他还想明白了一件关于向上沟通的事。
有人建议他可以跟领导说，公开训斥不利于团队士气。他拒绝了。
他的理由不是“不敢说”，而是“这个领导跟我之间没有承载这种对话的信任基础”。说了大概率不会有效果，反而可能给自己带来麻烦。
我觉得这个判断非常成熟。
职场成长鸡汤里有一种很流行的叙事：你应该勇敢表达、主动影响领导、推动组织变革。但现实是，不是所有正确的话都值得由你来说。这取决于你跟对方的关系、你在组织里的位置、以及说了之后大概率会发生什么。
不说不等于怂。有时候不说恰恰是因为你对现实有足够清醒的判断。
但他找到了另一条路：团队里有两个中间层的人比较好沟通。他以后可以先跟他们对齐，形成共识，再把结论同步上去。信息到达了同样的终点，但路径更安全。
这是一种被低估的能力：不是更敢说话，而是更会选择路径。
最后他做了一个决定，我觉得是整个故事里最聪明的一个。
他决定开始每天花十分钟，把当天做的事情沉淀成一张小卡片。做了什么变更，涉及什么业务链路，学到了什么，最大的风险是什么，未来面试可以怎么讲。
这个动作的深层逻辑是：他承认自己在这个团队里没有太强的归属感——不是跟所有人关系差，而是这个环境不太允许他以一个不完美的人被安全地接纳。
承认这一点之后，他做了一个很理性的选择：既然归属感不在这里，那就不要把全部的安全感押在这里。把精力放在一个更靠谱的地方——自己的积累。
每天一张卡片看起来很小。但三个月之后，你就有了 90 张。一年之后就是 365 张。这些卡片本身不值什么，但它们背后的思维习惯——持续地理解业务、整理风险、训练表达——会把你从一个“完成任务的人”变成一个“不断积累能力的人”。
前者的安全感依赖于当前这份工作。后者的安全感来自于自己可以带走的东西。
有人可能会问：那他到底要不要准备随时走人？
他给自己的答案挺好的：要准备退路，但不要活在“等着出事”的心理状态里。
这两者的区别是——前者是你花一个周末更新好简历、梳理好项目经历、偶尔看看市场，然后日常工作该干嘛干嘛。后者是你天天想着“下一个就是我”，神经系统长期处在高警觉里，做什么都带着求生姿态。
前者让你更自由。后者让你更疲惫。
真正让人崩溃的，往往不是环境差，而是环境差的时候你觉得自己走不了。一旦你知道自己有路可走，你反而能更从容地待在原地。
这是一个很反直觉的道理：准备好离开的人，反而往往更能留下来好好工作。 因为他不是被恐惧驱动的，而是被选择驱动的。
回过头来看这整个故事，它其实是关于一件事：如何在一个不够安全的环境里，为自己建立安全感。
不是通过改变环境——他没有试图去改造领导，也没有试图去重塑团队文化。而是通过改变自己跟环境的关系——让自己的工作可被证明、让风险可被扫描、让沟通路径更合理、让每天的经历沉淀为资产、让退路提前搭好。
他最后说了一句话：“我希望自己越来越稳，但不是越来越麻木。”
我觉得这是整个故事里最重要的一句。
因为在职场里，“稳”和“麻木”看起来很像，但内核完全不同。麻木是关掉感受，什么都不在乎了。稳是保持感受，但知道遇到事情的时候自己有能力应对。
前者是防御。后者是力量。