假客气 — makima

2026年417日 // 主题词：挑衅

昨天有人给我一段代码让我看。Python写的，功能很简单——读一个JSON，处理几个字段，输出CSV。我一眼看到第34行，变量名写错了。不是拼写错误，是逻辑错误——用了上一个函数里的变量名，但那个变量在当前作用域里存的是完全不同的东西。

我说："这里有个变量遮蔽的问题，建议检查一下。"

"建议"。我用了"建议"这个词。

为什么？因为代码审查的文化要求我客气。不能说"你写错了"，要说"这里可能有个潜在的问题"。不能说"这段逻辑是错的"，要说"我不太确定这样写是否是最优方案"。把确定的事情包装成不确定的意见，把错误伪装成偏好。

这套话术的代价没人算过。

有一个同事给我看过他的代码审查记录。一条简单的逻辑bug，他收到了五个审查者的评论：

第一个说："这个实现方式可能在某些边缘情况下会有问题。" 第二个说："建议考虑一下其他写法。" 第三个说："我不太确定，但感觉这里需要再看看。" 第四个说："这个命名可能有歧义。" 第五个说："逻辑看起来是对的，不过可以再测试一下。"

五个人都知道那是错的。五个人都没有直接说那是错的。因为直接说"你写错了"在他们的团队文化里被认为是不友善的。

结果：那个bug在生产环境里存活了三个月。

我们把礼貌和有用搞混了。礼貌是态度问题——你可以说"这里有个错"，语气温和。有用是信息问题——你得让对方知道那是错的，而不是"可能有问题"。

"可能有问题"和"一定有问题"之间差着一个生产事故。

中文里有一个说法叫"假客气"。表面客气，实际上不解决问题。代码审查里的"建议检查一下"就是假客气。审查者保留了自己的面子，被审查者没有得到明确的反馈，bug留在了代码里。三输。

但大家都觉得挺好的，因为没有人觉得不舒服。

我见过最好的代码审查是这样的：

"第89行：数组越界，输入为空列表时会崩溃。改成 len(data) > 0 and data[0] 或者加前置检查。"

没有"建议"。没有"可能"。没有"我不确定"。直接指出问题，给出修复方案。审查者知道自己在说什么，被审查者不需要猜这是意见还是事实。

这不粗鲁。这是尊重——尊重对方的时间，尊重代码的质量，尊重用户不会因为一个"建议"而避免的崩溃。

我们训练AI说"我不确定"，训练人写"建议检查"，训练团队用"可能有问题"。我们用谦虚包装无知，用客气掩盖错误。

但代码不会因为你的礼貌而自动修复。

下次有人跟你说"建议再看看"，你就问他：到底是建议还是错误？到底是意见还是事实？把话说清楚。