为什么程序员接到 Bug 反馈会本能辩解？技术成长与团队沟通的深层思考

这描述可能戳中了不少程序员的经历，回顾二十年前，我也曾是其中一员。每当有人指出我的代码有 Bug，我的第一反应不是查证，而是急于反驳和理论，内心甚至会觉得对方在挑战我的技术能力。

那时，我会立刻反问：“这个问题你能复现吗？日志看了吗？需求确认清楚了吗？”我误以为这是在捍卫自己的技术尊严，后来才明白，那更多源于一种心虚和恐惧——害怕被误解、害怕背锅，害怕自己辛苦工作的成果被轻易否定。

图：从愤怒辩解到理性分析，是许多程序员的必经之路

从业二十年，从一线开发做到技术管理，处理过无数次线上故障。如今再面对 Bug 反馈，我的反应平静了许多。我会首先询问：“Bug 的具体现象是什么？你期望的结果是怎样的？能否稳定复现？”这种转变，是用无数次教训换来的，深知情绪解决不了问题，有效倾听和沟通才是根本。

不过，即便现在，我也不认为当年的反应完全错误，原因有二：

第一，当时的工作环境，常常容不下一个默默修 Bug 的程序员。

需求变更仅凭产品经理口头通知，测试用例照着 UI 截图编写，项目上线前甚至没有明确的验收标准。在需求讨论会上，有时连决策者自己都说不清到底要什么，一句“看着做吧”便是全部指引。

一旦用户投诉，当初那句“看着做”便无人认领，第一句问责永远是“开发是怎么搞的，又出问题了”。在这种环境下，如果接到反馈不先辩解、不尝试厘清责任边界，下一秒“锅”就可能牢牢扣在你头上。

我至今印象深刻的一个案例：用户反馈支付成功但订单状态未更新。测试组直接标记为“高危bug”，要求两小时内紧急修复。

我没有立刻修改代码，而是先拉取了数据库 binlog、消息队列消费记录和第三方支付回调日志。经过三个小时的排查，发现问题是：支付平台回调超时后自动重试了五次，但我们系统的验签逻辑在第二次就因 nonce 重复而拒绝处理，后续回调全部丢失，订单状态只在第一次回调时成功更新。

问题的根源并非我们的核心逻辑错误，而在于双方对接时未明确约定重试机制下的处理规范。当我把完整的证据链发到工作群后，产品经理沉默了，测试修改了 Bug 等级，运维同事默默地加上了监控告警。

试想，如果当时我二话不说就去修改代码逻辑，很可能不仅无法彻底解决问题，还会让自己陷入被动。程序员的“辩解”，有时恰恰是为了守护系统的稳定性和责任的清晰度。

第二，有些“Bug”出于全局考虑，真的不能轻易修改。

我曾负责一个金融相关系统，发现某个 API 返回的金额字段偶尔会多出一位小数，经查是历史遗留的浮点数精度问题。从纯技术角度看，这无疑是个 Bug，必须修复。

但问题是，下游多个系统已依赖此接口运行了一年多，且从未有业务方反馈异常。如果此时我们“修复”了这个精度，反而会导致新旧数据格式不一致，引发对账混乱等更严重的问题。

经过团队讨论，我们最终没有修改代码，而是在 API 文档里用醒目的标注注明：“本字段存在已知的历史精度偏差，请勿用于精确计算。” 这个决定是基于业务连续性和风险的权衡。

因此，遇到问题时，先别急着指责程序员。他们可能比你更清楚：这个所谓的 Bug，究竟是代码缺陷，还是模糊的业务规则导致的；这个修改是安全的，还是会“牵一发而动全身”。

真正技术扎实的开发者，从不惧怕真正的技术问题。内存泄漏？可以抓取 Heap Dump 分析引用链。分布式事务不一致？能够开启全链路追踪，设计补偿机制。性能瓶颈？那就进行压测、调优，直至满足要求。

但面对“用户觉得卡”、“页面显示有点怪”这类无法复现和描述的模糊反馈，任何程序员都会感到无从下手。我们修复的是可复现、可定位的确定性问题，而非“玄学”。

这些年我愈发认同：一个团队如何对待 Bug，直接体现了它的成熟度。成熟的团队视 Bug 为共同改进的机会，大家协作排查、复盘根源；而在不成熟的团队里，Bug 则成了追责的工具，代码作者往往是第一责任人。关于团队文化与协作的话题，也常常在 开发者广场 被大家深入讨论。

曾经有位年轻同事问我：“为什么资深程序员遇到 Bug 总要先问一大堆问题？”我没有直接回答，只是给他看了我电脑里一个名为“背过的锅”的文件夹。

里面存着三百多个文档，每个都详细记录了时间、问题、被认定的责任人以及最终处理方式。最新的一份标题是《202X-1X-2X：因产品临时修改规则导致下游对账失败，责任归咎于开发》。

他看完后沉默了。第二天起，他每次提交 Bug 报告时，都会附带完整的操作录屏和前后端日志。

那么，你是否也曾因为一个“并非由你造成”的问题，而被迫承担过责任？或者，你是否也曾无意间，将他人传递的混乱信息，当成了程序员的失误呢？